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…

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…