SVG: The race to 100% compliance
Tuesday, 11. September 2007, 21:58:11
During the development of Kestrel, I was hearing of the advancements in our SVG support. Not being a SVG person I wasn't familiar with everything that was added, but I was interested in checking out the W3C SVG test suite to see how our progress was doing. Being a W3C test suite, it looked both intimidating and time consuming so I never got time to run through the tests. Fortunately I didn't have to, as Jeff Schiller took the public Alpha through its paces and updated his support graph.
I'm not sure if this includes SVGT 1.1 or just SVG full 1.1 (I suspect the latter), but Kestrel has improved Opera's support to 93.4% of the test suite. That makes it not only the most compliant browser, but also the most compliant user agent full stop, even beating the impressive Batik 1.7. The closest browser is Firefox 3 with 58%. Now we have full CSS3 selector support, I'm looking forwards to the race to full SVG compatibility, and I think Batik will give us a good run for our money. It's a shame Jeff's chart doesn't show the tests that fail for each browser.
I've heard a number of web developers complain about Opera focusing on SVG, but there is a few reasons for this and it doesn't effect our other work, and I certainly agree it shouldn't be our primary focus, but:
- We have different developers that work on different areas, so working on SVG isn't taking people off JavaScript or CSS layout for example
- SVG was often a carrier requirement for inclusion on mobile devices, and is much more useful and widespread in the mobile world, than it is on desktop.
- It is a standard that shows promise once support is widespread, and if we are going to do something, we are going to do it properly
- SVG is very useful on things like device projects where Opera is the interface to the device using WebUI. Think games consoles for instance
- Other browser vendors like Safari and Firefox are adding SVG support and it shouldn't be too long before get good quality cross browser support. IE will be the problem, and in that way it will be similar to the PNG situation pre IE7, but IE is under active development now and they have a great team, so I wouldn't rule them out.
Now Opera has good compatibility with SVG, developers can take it for a spin and start learning the basics of SVG in preparation for the future. I recommend to start looking at using it for background-images in places that degrade well without the image, such as the gradient example two posts ago. Once Safari and Firefox add support for SVG through CSS you can start using this technique across browser, and send a rasterised png/jpeg version to IE through conditional comments. The size and bandwidth savings should be quite substantial, the scaling is much better and it is so easy to edit the file if you want to change the colour, edit the gradient etc. The possibilities of adjusting the image through the DOM should be fascinating too (rotate a arrow bullet on-click in a tree list for example) , but this wont be so easy to do fallbacks for IE.



porneL # 12. September 2007, 00:24
However quality of text rendering in Opera's SVG is almost a dealbreaker:
* Text is awafully blurry (on OS X at least). Worse than worst case in Flash (blurry, but not even precisely anti-aliased)
Safari 3 can render SVG with subpixel rendering, even after transformations are applied to text! (it doesn't get kerning quite right, but at least it's readable).
Opera could at least use standard system rendering for straight non-transformed text.
* Text selection works poorly and is not seamless with other elements on the page (start select on HTML, finish on SVG - not working). I hope I could get rid of sIFR someday...
99th percent is probably support for <svg:foreignObject>, but that would help a lot in SVG-based UIs (layout and forms are PITA in SVG).
IceArdor # 12. September 2007, 02:11
I've noticed that Kestrel supports SVG differently in several aspects, and that's definately something to be proud about. 100% compliance, here we come!
Anonymous # 12. September 2007, 02:51
I'm glad to hear that Opera is making such strides in its various standards. Kestrel is so nice that it almost breaks my heart to limit myself from playing with some of these new toys that were added in Kestrel and to have do some work-arounds on my latest project for bugs that are fixed in Kestrel.
That said, while it's nice to have, I really don't like having to use SVG to do rounded corners in Opera. Not just because it means I have to create one more file in order to do rounded corners just for one browser, but also because of the additional HTTP requests that will be made to download the SVG file. It gets even worse once Firefox and Safari add SVG in CSS support, because they can already do rounded corners with border-radius. That said, I will try and push for the use of this where possible (i.e. where I can get away with not having IE support, which is sadly not often enough).
Off topic: Is there a time limit for how long your captias are good for? I've found I always have to hit back and re-submit my post with the new captia value every time I post a comment I spent a decent length of time writing.
Anonymous # 12. September 2007, 03:48
@David: The W3C Test Suite I use covers SVGT, SVGB and SVGF 1.1. However, the test suite has some bugs and is not anywhere near complete (at only 275 tests).
W3C just released a preview of their SVGT 1.2 test suite and it is on the order of 500 tests.
@Brian Lapore: I agree that the extra HTTP request in this instance is a bummer - but at least it can be cached, right? I wonder if there's a way to get best of both worlds (i.e. inline SVG that is somehow used for background-image, or maybe the data: protocol).
Btw, as I'm sure you're aware, SVG also allows you to do gradients and cooler things too. On the other hand if you're just looking for rounded corners, then yeah, maybe using the CSS property for it as on the other browsers is the more sensible approach...
dstorey # 12. September 2007, 07:48
I don't really like the idea of inline SVG as it breaks the presentation abstraction from the mark-up, just like inline CSS.
I noticed the SVG 1.2 test suite. I'm looking forward to seeing your test results from that. I guess I should find out if someone has added them to our automated test server. We are almost certainly going to drop in compliance as we don't support all of SVGT 1.2. I don't know enough about SVG to know if any other user agent supports any of SVG 1.2, but I suspect we'll still be the furthest along.
FataL # 12. September 2007, 16:50
Fyrd # 12. September 2007, 17:22
@FataL
Did you see my blog post on that issue? It's fairly simplistic and I haven't incorporated IE as a supported browser there, but it kinda works.
MacDev_ed # 26. September 2007, 14:04
Do you mean that svg textrendering on OS X is worse than the html textrendering? I'm not aware of any differences at the moment, but if you have any testcases feel free to share. You can also try all the different possible values for the 'text-rendering' property to see if that has positive effects on your testcase(s).
About the text-selection, see http://www.w3.org/TR/SVG11/text.html#TextSelection and http://www.w3.org/TR/SVG11/implnote.html#TextSelectionImplementationNotes. It would be great to have support for selections spanning across more than one element, but in the SVG case that may give you something that doesn't look like what you expected. Integration with html selections would require some specification of how that should work.