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…

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.

Start with Doug’s excellent post on this topic. I don’t have any opinion on the aria-specific elements of the debate. I’m fine with either adding a namespace to these attributes when used in XML or letting those attributes attach themselves to the SVG language without a namespace if it simplifies things, I don’t see a need to update the SVG specification for this though. I also don’t see a need to reinvent or create a new namespacing mechanism using underscores or dashes, this seems silly and/or dangerous to me.

But there’s something I’m not getting about the recent discussion of allowing inline SVG in text/html (or HTML5). Anne seems to be of the opinion that it would be a good opportunity to simplify the SVG language – maybe eliminate namespaces, allow upper-case SVG elements. Kind of an “if you want to play in the HTML playground, you have to wear the right kind of sneakers” attitude. This is kind of like HTML abusing its monopoly, isn’t it?

I don’t think this is a good idea. If you allow <CIRCLE CX=40> to be the same thing as <circle cx=”40″/> eventually we’ll start to see people producing non-compliant SVG in the wild. Then we’ll have people creating inline SVG for HTML that won’t work in the many SVG tools and viewers that are already out there and we’ll just have frustrated authors. Then some tools might feel forced to accommodate the lax HTML-style of SVG, just like the mess we have now with browsers trying to understand as much content as they can in order to compete. Then we’ll have to rewrite the SVG spec so that SVG has two serializations (like we’re having to do with HTML5/XHTML5). It just seems to be going at it backwards, since SVG was designed from the ground up as an XML technology. Must we rewrite all XML specifications into HTML5-style languages in order to get inlining? I don’t think so.

I guess I don’t fully understand why the HTML5 parser can’t just have the ability to hand off the character stream to another parser when it encounters some “special” elements like <svg> or <math>. Why does everything have to be in the hands of the HTML5 parser? In other words, in the document:

Upon encountering the characters “<svg “, the parser should back up five characters and send the bytes to the browser’s parser that handles content with the MIME type image/svg+xml. When that parser is complete, those elements can be injected into the DOM in the proper namespace and the HTML5 parser can pick up after </svg>

I see some problems, none of which seem insurmountable to me:

1. If the browser has no SVG parser, then what should happen? My proposal here is that all HTML5 browsers must also include a bog-standard XML parser to handle inline content that is known to be XML. This should be pretty straightforward, since XML parsing is actually much simpler than HTML5 parsing. In the case of a browser not grokking SVG, it throws the character stream to the bog-standard XML parser and waits for the character stream to return to it. Whether those elements are injected into the DOM is up to that browser (a browser could inject the foreign elements into the DOM even if it doesn’t know how to render them).
2. I hear that some browser don’t properly handle namespaced content or colons or something. Can someone clarify which browsers? Can someone further clarify what exactly the problems are? Can someone confirm if that browser will have fixed itself, say, next year would we be good to go?
3. Maybe the biggest problem with this idea is defining what happens in error scenarios – i.e. when the SVG is malformed, then at what point does the SVG parser return the character stream back to the HTML parser. In other words, maybe the challenge here would be in defining how parsers need to behave towards each other when mixing MIME types. Anybody have a suggestion here? Is this the deal-breaker?

As for namespace removal – why? Seriously just because it’s hard to remember it? If we’re trying to get to a “cut-and-paste” environment for some web authors, then they can just cut and paste the whole thing (namespace definitions in <svg> element and all). Maybe it’s because I’m used to writing SVG, but I really don’t have a problem with the concept of mixed namespace content. Sam’s off-the-cuff solution seems to favor even skipping the <svg> element, which would seem to me to cause a mess of problems. Where would you define the viewBox? Where would you define the version of the SVG language? You couldn’t, for example, cut and paste his “inlined” SVG content into a standalone SVG document for editing and be guaranteed it will even display properly, even if you wrapped it in a simple <svg/> element.

It seems like the belief that XHTML being a failure is a reflection on XML-on-the-web in general. In fact, all browsers except for IE can handle application/xhtml+xml MIME type these days, so it really seems to me that the verdict’s still out on whether XHTML is a good technology or not. Some people out there still think that XML has a place on the web. People like Shelley, who also shares her thoughts on SVG in text/html here.

I think we should explore relaxing the draconian error handling on XML on the web, but I don’t agree with re-inventing changing XML languages into HTML-style languages one after another.