Start Chopping Off Heads

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?

• inline in HTML5 as not-XML (or !XML as I like to call it)
• inline in XHTML (1.1 or 5) as XML
• via the HTML:img element
• via the HTML:object element
• via the HTML:embed element
• via the HTML:iframe element
• via the SVG:image element
• via the SVG:foreignObject element
• as a fragment via the SVG:use element
• via the background-image CSS property
• via the list-image CSS property
• via the border-image CSS property
• directly linking and then browsing to a SVG file

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.

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?

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.