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.

In the meantime, I’ve been carefully watching WebKit creep closer and closer to implementing the W3C File API (Go Kinuko!). Something I’ve been eagerly waiting for more browsers to do so you can open up local files in SVG-edit.

And then it hit me.

Why not a comic book reader done directly in the browser?

In case you don’t know, comic book archive files are just ZIP or RAR files containing JPEG images. Browsers can handle images. Some browsers can now handle opening local files. Even binary ones. So theoretically you could write unzip/unrar in pure JavaScript, extract the JPEGs, turn them into data: URIs and shove them into an <image> element. You can even do the unzipping in a separate thread using Web Workers.

Theoretically.

kthoom was how far I was able to get in a weekend.

Some limitations:

• Unzipping is slow. None of the code has been optimized yet and I’m probably doing a lot of really stupid things.
• Only supports CBZ files, not CBR files at the moment – I am accepting patches
• Unzipping is really slow. I need to provide visual progress reporting from the Web Worker thread, I know.
• kthoom will crash Firefox 3.6 about half the time. Firefox nightly (3.7) seems to handle it just fine. I opened this bug.
• Did I mention that unzipping is slow?

If I’m honest, this was really an exercise to see just how easy/hard it would be to do something like this in the browser – and to get some hands-on experience with Web Workers. And hey, I’m not the first or even second person to think of doing unzip/deflate in JavaScript either.

It was my first experience writing JavaScript to handle binary files. It was fun. It took a weekend.

Some essential tools: Firebug, a hex editor, pen & paper, a clear mind, patience.

Now swinging my attention back to stuff I should be working on…

I decided to go with my Solitaire demo because it was the most complete, didn’t infringe on any copyrights (looking at you Tetris), and most visually recognizable. It’s not the most innovative, but then again the point of this is not necessarily to win any prizes. It’s really about increasing awareness.

Unfortunately, the SVG (26kb) and JavaScript (16kb + 21kb) totaled 63kb. I did some cleanup of the SVG, minified the JS and then put the script inline with the SVG and then gzipped it. The result was a .svgz file that was 9kb. Perfect!

I then got an email from a friendly marketing/evangelism person at Microsoft who said that the engineers did not know how to open the svgz file to review the code to ensure it was under 10k. Woops! I explained to her that I thought it would be ok for the SVG to be gzipped, much as PNG/GIF files use compression and sent her the uncompressed SVG file for them to review. After all, SVG is just an image format, right?

Was I following the rules? Did Microsoft give me a fair shake? See for yourself. Who knows, maybe this is the first time a Microsoft admin had to figure out how to serve SVG on a Microsoft web server.

Out of curiosity, I later tried to see how far I was able to get down the Solitaire game: 5811 bytes. Not bad for a complete game that has scalable graphics. I’d be curios to see the equivalent SWF file.

I don’t expect you to vote for my entry, but what I do expect you to do is now go out and submit .SVGZ entries to the MIX 10k challenge. That one SVG entry is looking pretty lonely. If I can get Solitaire down to 5811 bytes, surely you can do better?

Thanks a lot to Amy, the evangelist/marketing person who really was quite patient with me.

A warm congratulations to Sam and a heartfelt Good Luck!