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.

There are lots of ways of specifying a color on the Open Web:

• rgb(255,0,0)
• rgb(100%,0,0)
• #FF0000
• #F00
• “red”

And it’s not just the 17 CSS color names, there are 147 cool-sounding extended color names like papayawhip. So given that a user can input a color in all sorts of ways, what’s the right way to do this?

The Hard Way

You can build a parser that determines the color format, parses hex and rgb strings and has a table that maps 147 strings to rgb triplets. It turns out there are a lot of JavaScript libraries that already do this. Here’s one.

But then I thought: why am I including yet another JavaScript library to do this parsing when the browser must already know how to map from hex, rgb or color name to an RGB triplet (or equivalent) in order to render the color in the first place? Surely there’s a way to extract this directly out of the DOM?

The DOM Way

It turns out there is. It’s called the CSS DOM and I always seem to forget about this document. Piecing together information from the SVG DOM and the CSS DOM, this is how you would get the red value of a fill attribute on a circle:

var red = someCircle.getPresentationAttribute("fill").rgbColor.red.getFloatValue(1);

That’s just a bit perverse, but at least it’s possible.

In testing this I was delighted to discover that Opera and WebKit let me do it. Sadly, Firefox does not.

The Best-Laid Plans…

Here’s where the plot thickens. Seems like the CSS Working Group was chartered to produce a new version of the CSS DOM to make the interfaces less clunky. Seems like the CSS WG sent out a notice strongly warning browsers not to implement certain DOM interfaces in the CSS DOM. Seems like it’s six years later and there’s no new document.

Unfortunately this is where my sad little tale ends. Erik of Opera suggests that the SVGT 1.2 uDOM is really the right way to do this. It doesn’t matter that I agree with him because I don’t think Webkit or Mozilla have any interest in implementing this any time soon.

It seems kind of sad that folks have to write JavaScript libraries to do color parsing when the browsers already do this natively. It also seems really weird that the SVG DOM interfaces extend obsolete CSS DOM interfaces (SVGColor extends CSSValue which Bert Bos mentions in his email).

#DOMFAIL ?

A warm congratulations to Sam and a heartfelt Good Luck!

• Apple finally pushed a firmware update to their iPhones that makes Safari support SVG. I first heard about it here and then Doug blogged about it.
• Mozilla finally landed SVG effects for HTML, presumably for Firefox 3.1 but I’ll be keeping an ear to roc’s blog for further updates on that.
• Work on the Flex SVG Viewer (FSV) has started to pick up. It is now released under the MIT license and just had its first contributed patch. More on this at a later time.
• Some guy named Tim Berners-Lee chastised Internet Explorer for not supporting SVG and that article has been picked up by the Associated Press – who does he think he is?
• The W3C SVG Interest Group garnered several new members within the last couple days and chatter has picked up on the Mailing List which is a hopeful sign that we’re starting to gel a bit. If you care about SVG and can help in some tangible way, I invite you to consider joining.

At the moment, the issue is dead in the water. Ian Hickson suggested that query parameters could solve this issue. However, query parameters are part of the URI. In my experiments with PHP, I found that query parameters are a good way to ensure the browser actually re-fetches a document and doesn’t rely on the document in the cache. This means that using query parameters would defeat one of the purposes of parameterizing the SVG in the first place (one document in the browser cache that could be used for many purposes).

It’s sad because plugins like Flash have the luxury of being able to pass parameters into their content, but we can’t do that for content the browser understands natively (like SVG and HTML). I failed to convince the benevolent dictator that this is an important capability that the open web stack lacks.

I think this would be a nice way to turn bits of HTML/SVG into simple components without requiring script on the embedding side and without requiring heavier technologies like XBL and/or waiting for browser support of postMessage(). For example, it seems like web page authors using things like Adsense could benefit from this by not having to include foreign script in their pages, but apparently Google has no interest in this.

Eric Meyer’s link-anywhere proposal inspired me to at least float this issue in my blog in case someone else thinks it important. For now, I’m tired. Hm, I wonder if I can use the window.name hack…

What I’ve been trying to do since I began experimenting with SVG several years ago is build up demos of the technology that are, as much as possible, workable in a cross-browser fashion. I usually build my demos to push the edges of browser support just a little. In other words, give a glimpse of some of potential behind the SVG format while highlighting things for the browser folk to work on.

A case in point: My SVG Web Stats web page – or should I say application? Originally the idea was just to have a graph generated automatically from some server log files. Then I decided to push in a little interactivity. With the most recent wave of browsers (Opera 9.5, Firefox 3, Safari 3.1) the performance and behavior were now quite acceptable and consistent across the three main modern web browsers. So what’s the next logical thing to do? Make it slower and buggier again of course (in this case, by adding some SMIL and more functionality that highlight browser inconsistencies) Viva La Push.

Anyway, we want to use the IG as a platform to work on a select number of initiatives that can produce some more tangible results. Among the initial activites are assessing the state of Accessibility, gathering requirements from Designers, authoring some SVG tests and putting together a better SVG community website. At the moment, I have this naïve hope that we can actually produce something useful, so feel free to crush my spirit below. Or, if you’re so inclined and you’ve got some energy to spare, please feel free to Join The SVG Interest Group.

Table Of Contents

• SVG In HTML: Did You Blink?
• SVG Working Group Going Public
• SMIL Getting Some Love
• Cool Demo: GEMi
• Slanty Blog Comments

SVG In HTML: Did You Blink?

For about a week, there was a pretty solid proposal for how HTML5 could include support for existing popular XML languages currently making up the fabric of the ‘open web’ platform – this included Scalable Vector Graphics.

Specifically, the spec described how HTML5 could allow inline markup that (very closely) resembled SVG and MathML (in a special mode of the HTML5 parser). However, very recently, the SVG WG requested the SVG part of the proposal be removed from the HTML5 spec so that the SVG WG could investigate if there were any improvements that could be made that would preserve interoperability with existing user agents and tools.

My biggest concern about the original proposal was that ’round-tripping’ SVG images was not guaranteed. Round-tripping means that I should be able to take a valid SVG document made in an editor like Inkscape and copy-paste that XML code into an HTML5 document and vice versa. The trip from Inkscape-to-HTML was supported by the original proposal (where the HTML parser would just ignore namespace prefixes). But the trip the other way (copy-paste from a HTML5+SVG document to Inkscape) was not guaranteed.

This is because the HTML5 parser is much more forgiving about certain things. It does not mandate namespace prefixes, double-quotes on attribute values, or case sensitivity for all modes. It doesn’t even require you to close all your elements. This is by design.

This means that an author could not be guaranteed to take valid SVG markup embedded in HTML5 and paste it into a standalone document and expect a graphical editor to be able to bring up the image.

However, if we require that any browser supporting SVG-in-HTML5 must support a means of exporting the DOM as XML – then my concerns are very much alleviated. It was clarified to me that this was indeed recommended, but it could not be a requirement because User Agent Interface requirements are out of scope of the HTML5 specification. I’m not really sure why – we are not talking about capturing all UA requirements, only those that are required for interoperability with a foreign language such as SVG – but c’est la guerre. See Ian’s comment below for more clarity.

SVG Working Group Going Public

The SVG Working Group has been rechartered as a Public Working Group. This means that the general public will be able to read emails, conference transcripts, action items, etc. I really think this is a great idea, and I look forward to more transparency around SVG activities. Here’s their new charter.

Another activity within the W3C surrounding SVG is the creation of a SVG Interest Group. This is an interesting idea – not sure if it’s the first of its kind within the W3C. Based on their charter, the IG will:

“provide requirements, specification feedback, errata suggestions and tests to the SVG WG”

Sounds like a good opportunity to gather more folks interested in vector graphics on the web into one place for some interaction.

SMIL Getting Some Love

In case you missed it, the WebKit nightly builds now includes some support for declarative animation (SMIL). I’m really pleased to see two native browsers now supporting SVG animation interoperably. Now I’d like to see this patch land as soon as Firefox 3 ships so that we can have some declarative animation support in all 3 major native SVG browsers.

Cool Demo: GEMi

Domenico Strazzullo announced today a very nice demo of a windowing system built in SVG for browsers. Kind of reminds me of AjaxWindows, but this GEMi demo actually works really well in all 3 major SVG browsers without the help of XUL. Apparently it also works in IE+ASV.

I was really impressed with this – but I can’t wait to see if anybody tries to build anything with it, since the goal of the project was a framework that can be integrated into some other project.

Click here to try it out!

Slanty Blog Comments

More blog experimentation last night by adding ‘slanty comments’. After futzing with PHP, CSS, HTML and SVG, I finally got the effect I was after. It took me over 2 hours. Of course that was also testing it in Firefox 2, Firefox 3, Safari 3.1, Opera 9.20, WebKit nightly, Internet Explorer 6 and on two platforms (Windows and Linux).

Unfortunately, when all was said and done, I wasn’t really happy with the result. Maybe I’m just not used to seeing that on a website? If anybody has ideas on how to improve it, I’ll gladly steal them.

What I thought was really interesting about this? Well first, let me explain how I serve my website and blog: I author my content in XHTML served the content as application/xhtml+xml for those browsers that support it (which is, incidentally, all major browsers except for Internet Explorer). For IE, I simply change the MIME type to text/html and cross my fingers (ok, in fairness, I did do some tweaking and did design a horrid little HTML table-based fallback menu).

Anyway, for my slanted comment links, I use inline SVG. Here is a snip of the code for a blog comment:

  <div>

  </div>

Most browsers (IE included) simply ignore elements they do not recognize. So how does the above look to IE6? See the bold markup below:

  <div>

  </div>

So the svg:a element looks like a html:a element to IE. So in this one case, my inline SVG kinda sorta falls back as HTML content for the one browser that doesn’t support SVG (again, Internet Explorer). Yes, I know – horrible horrible horrible. However, it works. I kind of shudder to think what this would do in IE8 (without an SVG plugin), I guess I’ll have to test it eventually.

Oh, and if you don’t know what I mean by slanty comments, well you’ll just have to post a comment…

Making Flash-like visually “high-impact” (sorry about the marketing BS term) sites using the openly specified Web platform but without the Draconianness of XML in such a way that the whole thing uses retained-mode graphics and lives in one DOM for easy scripting (i.e. no need for scripts to deal with object or iframe sub-DOMs).

(link)

I guess that’s what I want… but more important to me than removing the “Draconianness of XML” is that I want this stuff to work in every major browser on every major platform. And no amount of specifying can guarantee that. It takes willingness of all participants. I use the term “participants” here in a broad sense, because based on the first IE8 Beta, it seems that Microsoft is not really working in close communication with the HTML Working and Web Application Formats Working Groups. The WG seems to be trapped in a constant state of reverse-engineering the things that Microsoft has done and sadly I don’t see this changing in the future.

Can an open specification really compete with a company that can throw gobs of money at developing a glitzy-but-proprietary standard, who then proceed to throw gobs and gobs of money at organizations to use that new standard? Further reading: Sam Ruby’s SVG Shiv.

Sorry, I guess that was my cheery thought for the day.