SVG: The race to 100% compliance
Tuesday, September 11, 2007 9:58:11 PM
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 # Wednesday, September 12, 2007 12:24:57 AM
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).
Ice ArdorIceArdor # Wednesday, September 12, 2007 2:11:01 AM
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 # Wednesday, September 12, 2007 2:51:32 AM
Anonymous # Wednesday, September 12, 2007 3:48:33 AM
David Storeydstorey # Wednesday, September 12, 2007 7:48:27 AM
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 # Wednesday, September 12, 2007 4:50:23 PM
Alexis DeveriaFyrd # Wednesday, September 12, 2007 5:22:49 PM
@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.
Erik DahlströmMacDev_ed # Wednesday, September 26, 2007 2:04:14 PM
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.
Anonymous # Tuesday, June 7, 2011 5:58:26 AM