I want to believe. SVG as an image format.Because my kids are now old enough to grok some complex games, I've introduced them to the Magic: The Gathering card game. They love it. I love it. To continue the fun, we went to a local comic book store and bought a couple booster packs, which apparently are still being sold throughout the world. One of my kids got a Protean Hydra. Sweet! The Hydra is a mythical beast with nine heads, and every time you chop off a head, two more grow back.

The web is like that. And we're not chopping off heads fast enough.

Now that Internet Explorer has come out of its corner swinging with SVG support, I figured it's time to make sure we can actually deploy web pages with SVG content in them. Did you know that there are at least thirteen ways to deploy SVG on the web?

Does anyone know why the <embed> element was not deprecated in HTML5? Was it the realities of the IE deployment difficulties around the <object> tag? It sounds like IE9 will help to fix that so maybe <embed> can eventually be deprecated in HTML6 five years from now?

What's worse is that the properties on the embedding context and the SVG elements affect how the SVG is rendered. The width/height properties on <object>/<embed>/<iframe> tags. The width/height/viewBox properties on the <svg> element. The preserveAspectRatio attribute on the <svg> element.

The width attribute on a <svg> element can be specified in units of em, ex, px, in, cm, mm, pt, pc or it can be unitless or it can be a percentage. Of course the height attribute can be specified in different units.

The embedding context also determines whether scripts are run within the SVG document. Hint: Should not be run in image contexts.

I want to believe. SVG as an image format.But it gets worse. Let's just look at one case: embedding an SVG document in a web page via the <object> tag:

<object type='image/svg+xml' data='...'></object>

For the data attribute you can specify a local file, a http/https URL or a data URI. The browser can treat each of these cases differently.

The file served to the browser can have a MIME type of image/svg+xml or text/xml or application/xml. Browsers might do something different in these cases (though they shouldn't).

If the width/height on the <object> tag are specified, they should override the <svg> width/height if the <svg> width/height are in absolute (not relative/percentage) units. The coordinate system of the SVG should map to the viewBox attribute unless the viewBox attribute is not specified, in which case it should be inferred. Got all that?

If width/height on <object> are not specified, and width/height of the SVG are specified in absolute terms, then the size of the <object> frame should change to match the size of the SVG.

If width/height on <object& are not specified on a Tuesday of a leap year, and the SVG document has an odd-number of bytes in it and includes the string 'rick' or 'roll' anywhere in it, then the browser should play a video instead.

I'm not making this up, it's right here in the spec.

Actually the difficulty of this case is that there are so many dimensions and that it's spread across multiple specs: HTML, CSS, SVG. I think WICD/CDF was supposed to address some (all?) of these cases, but ... are those specs actually valid? And by that I mean, are browser vendors paying attention to them? As Dolores O'Riordan might say: Does anyone care?

I want to believe. SVG as an image format.There's something to be said for the simplicity of the iPhone's "one" button. Android's addition of the "Back" button is a perfect example of how a system can be incrementally improved.

Anyway, I've started to look at just three dimensions of this n-dimensional problem: the HTML embedding context, width/height and viewBox. I wrote a test case showing the 16 possible combinations. I was not really shocked that between all the four major browser engines, only one case displayed consistently across all latest builds: as an <img> with width/height specified on both <img> and <svg>.

I'm really tired of reading specs (I'm sure this will pass), so in absence of a reference rendering of this page, we'll just need to do what we always do: Make it look the same across all browsers. Now that we have IE9, it can act as a tie-breaker between renderings that could be argued one way or the other 🙂

Hopefully I'll be able to talk more about these 16 cases in the future. Now you know where to come if you're having trouble sleeping.

§945 · September 21, 2010 · Software, SVG, Technology, Web · Tags: , , · [Print]

8 Comments to “Start Chopping Off Heads”

  1. Kirby Files says:

    Some interesting results there. It’s nice to see that FF and Opera generally do the right thing with backgrounds. And, once the img tag is fully implemented in FF, its rendering will be almost completely similar to Opera.

    It looks like the safest advice to SVG devs right now is to use 100%/100% and a viewbox on your SVG elements. It looks like most browsers can get that right.

    Thanks for the test cases. Or at least a start on some test cases. I wonder how many of these are in the IE9 test cases submitted to the W3c.

  2. Two more SVG embed methods:

    The svg element inside an SVG (if you’re going to include SVG:image and SVG:foreignObject anyway)

    And using drawImage() in HTML5 Canvas. 🙂

  3. Sheesh – so now we’re at 16 different methods! 🙂

    Thanks both.

  4. Phil says:

    lol. If I would have had flash installed, I would have been Rickroll’d. The svg in this post showed up in IE9 when viewing the page, but not when viewing the feed, interesting.

  5. Alex says:

    I’m also wondering why was added into HTML5, I’ve always thought browsers have had pretty good support for (I knew IE had some issues, but the major ones were fixed in IE7)

  6. Alex says:

    I’m talking about the embed element if my post doesn’t make any sense :p

  7. Alex says:

    I got a picture of your test page as rendered on an iPhone 4, and the results are kind of upsetting.