I haven't really given a good 'SVG News Digest' in well over a year, but there was enough recent news that I thought I should post a little bit about what's going on in the Scalable Vector Graphics world. Fair warning: This blog post is long, I probably should have spread it over 4-5 days worth of blogging, but I lose patience when queuing up posts...
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.
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>
<svg xmlns="http://www.w3.org/2000/svg" ...>
<a href="http://example.com/" xlink:href="http://example.com/" ...>
<text ...>1. Joe Blow Says:</text>
</a>
</svg>
</div>
<div>
<p>... comment text goes here ...</p>
</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>
<svg xmlns="http://www.w3.org/2000/svg" ...>
<a href="http://example.com/" xlink:href="http://example.com/" ...>
<text ...>1. Joe Blow Says:</text>
</a>
</svg>
</div>
<div>
<p>... comment text goes here ...</p>
</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...
You wrote: “it could not be a requirement because User Agent requirements are out of scope of the HTML5 specification”.
To clarify — it’s _user interface_ requirements (UI requirements) that are out of scope. They are out of scope because we have no idea what effect they may have. For example, it would make no sense to ask the browser on an iPod Touch to have a feature that let you copy out the XML version of the DOM — the OS has no “paste” functionality.
The spec does strongly encourage that such a UI be made available though (and indeed that encouragement is still there, even after we removed the SVG-in-text/html text, because even in XHTML, inline SVG might not be easily copy-and-paste-able from the source without such a feature).
HTH.
Thanks, Ian for the clarity, I’ve updated my post.
I think that UI requirements can be stated as conditionally normative statements, such as, “User Agents which allow copy/paste or which allow the user to view the source must provide a way to export any SVG fragment as a namespace-well-formed XML fragment.” This does not completely allay my concerns regarding the proposal, but it’s an example of how we can better lead the way to a more interoperable “ecosystem” of UAs that implement open Web standards.
Toolchain issues like this, which provide intuitive and simple functionality for end users, are crucial for Web apps to be competitive to (and compatible with) OS-level apps. I would love to know that I could copy some SVG from a site, and it would paste as a raster into Paint, as vector graphics in Inkscape, and as markup in TextMate. This is something Chaals and I have working on in the Clipboard Operations spec. (Similarly, MathML clips could paste as mathematical entities and operators in a calculator, and as plain text or markup elsewhere.)
@Doug: I was going to make a similar proposal (except I wouldn’t limit the markup export as XML to SVG, as I’m sure you didn’t intend to do).