This page isn’t valid…and who cares

I covered my recent experiments in using SVG in HTML in SVG in HTML. I linked two different example pages with SVG inline in HTML: one dependent on HTML5 parsing (Firefox nightly), the other using the library, SVGWeb.

There’s another difference between the two examples other than just their implementation. The first example, dependent on a browser parsing the page as HTML5, doesn’t validate. The example using SVGWeb, does. Yet, both pages display correctly, as long as you use an HTML5 enabled browser for the first. The odder thing is, neither page is “invalid”.

The HTML markup is fine for both, as is the SVG used. However, the Validator doesn’t like inline SVG at this time, because, we’re told, no browser implements SVG inline in HTML, yet. The SVGWeb example validates because the SVG is contained in a script block. The validation problems with the first example go beyond embedding the SVG element directly in the web page, though. The example also incorporates a metadata element in the SVG that contains RDF/XML.

Embedding RDF/XML into the metadata element is perfectly valid with SVG, and in fact, quite common when people attach Creative Commons licenses to their work. The HTML5 Validator, though, doesn’t really know what to do with this RDF/XML. Why? Because RDF/XML uses namespaced elements, and namespaced elements are taboo in HTML. Yet, SVG is acceptable in HTML5.

Herein we discover the paradox that is HTML5: XML allowed in HTML, but parsed as HTML; extensible namespaced elements that are valid in SVG/XML, becoming invalid when embedded in the non-extensible environment that is HTML5. HTML5 as XHTML likes namespaces. HTML5 as HTML does not like namespaces. But HTML5, as both XHTML and HTML likes SVG, and SVG likes namespaces.

Pictorially, the logic of this looks about as follows (which would not be valid if inserted into an HTML5 HTML document):


Oh, what is a web designer/developer to do, who just wants to use a little SVG here and there? Enter, stage left, the HTML5 Doctor.

Recently the HTML5 Doctor was asked about attributes and elements from HTML4 that are now obsolete but conforming (or not) in HTML5. Won’t adding a HTML5 DOCTYPE while still using these elements cause the pages to be invalid?

The Doctor’s answer:

While validation is undoubtedly important for your markup and your CSS, in my opinion it isn’t crucial to a site. Allow me to explain, we recently received a couple of emails pointing out that this site doesn’t validate. While there were some errors that have now been corrected, a primary reason why is the use of ARIA roles in the markup. These attributes currently aren’t allowed in the current specification, however there is work underway to make this happen.

To illustrate this point let’s look at Google, the search giant. If you look at the source on Google’s search pages you’ll see they use the HTML 5 doctype.

<!DOCTYPE html>

However, those pages don’t validate because they use the font and center elements amongst others things that we already know have been removed from the specification. Does this mean that users stop visiting Google? No.

Remember too that the specification is yet to be finalised and may still be changed (thus breaking you’re perfectly valid docments), in partnership with this changes to the specification may not immediately take be implemented in the validators. We also need to bear in mind that HTML 5 takes a “pave the cowpaths” approach to development, meaning that the Hixie, et al will look at what authors already do and improve upon it.

The days of validation being an end all, be all, are effectively over with HTML5. By obsoleting (not deprecating) elements that were perfectly valid in HTML4; by not providing an extensibility path within HTML in HTML5, especially considering that new elements will arise over time—not to mention, the inclusion of perfectly legitimate namespaces elements in SVG— all, combined make “validation” a goal, but not an end when it comes to the web pages of the future. We’re more likely to define a set of supported browsers and user agents and worry more about the pages working with these, then be concerned about whether the pages validate in

So, my one web page with the inline SVG works with the Firefox nightly, with HTML5 parsing enabled. It isn’t valid…but who cares?

SVGWeb and the XML Issue

I’ve been playing around with SVGWeb, liking the library more over time. I re-created the SVG in HTML5 example, and at first it didn’t work. I thought it could be because SVGWeb couldn’t manage the metadata element, but when I loaded the page in Firefox, with Firebug, I found that the SVG/XML still had the bugs I inserted to test whether the Firefox nightly would correct the HTML-enabled errors—the example still had an unquoted attribute, and elements with missing tag ends. In fact, I got XML error messages within the Firebug console exactly I would expect such errors if I loaded the SVG directly in the browser.

SVGWeb manages SVG for browsers that can handle SVG by creating an XML document of the SVG. You can tell, because if you click the circle with the new example, all of the namespaces for the RDF/XML elements are handled properly, even though the page is parsed as HTML. To me, this is the way SVG should be handled in a document, whether the document is parsed as HTML or as XHTML. This pretense that SVG is not XML when its in HTML is patently absurd. It doesn’t map to anything that exists in the real world.

The SVGWeb library is a wonderful tool, but I would really prefer all that functionality be embedded directly in the browser handling of SVG in HTML. I read the past discussions on SVG in HTML, about how trying to maintain the XML nature of SVG within HTML would require “exceptional parsing rules”, or something of that nature. It seems, though, that SVGWeb is managing the issue just fine, and doing so without having to make one change to any parser for any browser. SVGWeb works by generating a SVG document and inserting the document into the DOM (if the browser supports SVG). Technically, this is little different than what happens for inline SVG in XHTML now. So why is this a perfectly acceptable approach when using script, but not acceptable when not using script?

I’m also aware of the discussions about mixing content, such as SVG in MathML, and MathML in SVG, and HTML5 in both. I made another copy of the example, this time inserting an HTML5 paragraph element into the SVG. Since the syntax I used was proper XML (no unquoted attributes, closing paragraph), it parsed without an error, but the paragraph didn’t display. Of course not, because there is no paragraph element within SVG, and the SVG is treated as an SVG document, not an SVG in HTML document. The thing is, though: the paragraph wouldn’t do anything in SVG within an XHTML document today.

However, returning to the example I linked earlier, I did insert HTML into the SVG using the SVG foreignObject element, with proper syntax, and as you can see, the HTML does display correctly. In fact, if you scroll down, I also created a second SVG element, this time with MathML as the foreignObject contents, which renders fine in Firefox, and partially everywhere else, depending on MathML support.

All of this works, and works well, when using SVGWeb. You can even access namespaced Rdf/XML elements in the XML, using the proper namespace functionality, but the page still validate using All of the portentous grumblings about the horrors of mixing HTML and XML just don’t ring as ominously when one can see that, contrary to the dire warnings, and tales of potential woe, the two can mix. Unfortunately, the only way to mix the two, now, is to be dependent on a Google JavaScript library. Don’t get me wrong: I’m grateful for the library. So grateful, in fact, that I don’t recommend the use of SVG inline with HTML unless you use this library.

I just don’t like being dependent on JavaScript for that which should be and can be, natively supported in a browser. This approach requires library intercession for all instances of SVG use, which means the SVG markup won’t be accessible to server-side applications that disregard the script element. This JavaScript dependency also means the SVG won’t be visible if scripting is disabled, even though SVG does not require scripting support. When scripting is enabled, the approach is still inherently inaccessible.

These are the two choices facing us with SVG in HTML: SVG/XML treated as HTML, and all the problems this causes; or SVG/XML treated as XML, but requiring JavaScript.


I’m writing an article on using SVG for site decoration and backgrounds. Since SVG is now allowed in HTML via HTML5, it seemed a good time to introduce people to the concept. Especially since the nightly build of Firefox 3.7 has a configuration option (“about:configure”) where you can enable HTML5.

To test the new option in the Firefox nightly, I created a simple file, with a SVG red circle that can be resized with JavaScript. (HTML5 version and XHTML version).

Clicking on the circle will resize it, but also throws up some alerts outputting information about metadata in the element, including namespace, prefix, and element tag name. I wanted to see how Firefox parsed the SVG via HTML, as compared to XHTML. After all, it’s not unusual for SVG files to have namespaced entities in them, for metadata (Creative Commons RDF/XML), or even placed by a tool (Inkscape).

The results are about what I expected. The namespace, prefix, and tag element name all displayed according to their namespace goodness in XHTML, but the namespace didn’t work with the HTML parsing.

To me, this isn’t a showstopper. People who have been working with the DOM and JavaScript have had to deal with differences through the years, such as event handling differences between IE and the rest of the browser world. You just check to see MIME type of page, and either expect to look for the localname as a mashup between prefix and local name, or it’s handled properly.

It’s a little *challenging because prefixes aren’t always going to be the same. However, for the most part, if you need to access the data, you can either control the prefix used, or you can work through the differences without having to resort to rocket science. I rather expect both Dojo and jQuery to incorporate this functionality, once HTML5 gets wider use.

I also have been trying the new SVGWeb product from Google, and fine folks like Brad Neuberg, which enables SVG in HTML for all browsers, including IE. It does this by incorporating a JavaScript library that implements most of the SVG in Flash. Since Flash is pretty much ubiquitous, folks won’t have to install something new for the page to work.

I’ve used SVGWeb to manage the background image for The SVG Feed, which is now formatted as HTML5, and served as HTML. It works nicely in Safari, Opera, Firefox, and even SVG-challenged Chrome, but IE has a problem. Unfortunately, height and width are handled differently with IE as compared to the other browsers, so the values are coming up null in IE. However, Brad has added this as a bug, and I expect this page will work in the next iteration of the product.

Now, there are some differences between SVG parsed by an HTML5-enabled browser, and using SVGWeb. My earlier example embedded SVG directly in the page, but SVGWeb expects an inline SVG element to be enclosed in a script tag:

<script script type="image/svg+xml">

Embedded SVG in a script tag won’t work if you’re only dependent on HTML5 parsers. However, SVGWeb also works with HTML5 parsers, so you’re set, either way.

Until all browsers support SVG, in HTML or XHTML, SVGWeb provides the first real breakthrough in using SVG on the web. And here you thought that SVG was only good for **Scrapbooking.

*It’s a little more challenging for server-side applications parsing the web page, but again, the differences aren’t insurmountable.

**The background SVG I’m using for my site originated as a scrapbook pattern for the cutting machine, Cricut.

Zooming with SVG

I wanted to highlight a comment Bruce Rindahl made to an earlier post (with his permission): is a modification of a project I have been working on. I hacked together some code to mimic the animation effect of the Hard Rock site. First some credits.

The original work was funded by the State of Colorado and Division of Water Resources. Earlier work by the Urban Drainage and Flood Control District.Everything was based on work done by (and GPL’d) at

The animation was done using SMIL attributes in the SVG standard. It requires the Adobe SVG plugin. It will run on say a Windows 2000 machine in IE6 using a 5-year old plugin […]. The imagery is over 60 GB (almost 2 orders of magnitude more than Hard Rock) served up via an Open standard WMS server (Mapserver) via a Python based cache program (TileCache). Vector data is displayed via SVG using an open source database (PostgreSQL/PostGIS). Without the animation it works in Opera, Safari, Firefox3, and IE with the plugin. The animation works in Opera but has a bug in it which makes it jump – I am tracking that down. Safari should handle it soon. The animation can be jumpy at times but part of that is the coordinate system I am using. The Adobe SVG plugin struggles with numbers that high. Everything is controlled via JavaScript.

Bottom line for me – meh. The animation is cute for a while but it is not worth the extra overhead. Keeping all the downloaded photos just so the user always sees an image is not worth the memory required. The default display is just like Google maps which most users are familiar with. I agree with Mr. Ellis that the development tools are not there to match what is available for Flash but then who would build them when Microsoft won’t support it?

Unlike my earlier silly little example, Bruce’s work is impressive, especially when you consider that most of the technology and specifications used in the effect have been out for years, and it works with Adobe’s now old SVG plug-in in IE6. His work isn’t based on one packaged framework, either, and pulls together previous GPL’d work, as well as several open source technologies into one, cohesive whole.

Bruce also makes an important point: why do the effect? It takes up bandwidth, requires extra work, and what does the functionality provide, other than a few useful implementations like Google Maps? If you want to know why something like JPEG 2000 hasn’t been implemented in most browsers, and only brokenly with Safari (because of a broken implementation in the Mac OS X), it’s because few people are asking for this functionality. In addition, as Bruce notes, why would people expend effort when we know the work won’t work with IE?

I see work like Bruce’s and others as a worthwhile effort, regardless of Microsoft’s unwillingness to meet its earlier commitment to standards. Adobe’s SVG plug-in is not the only SVG plug-in, as Examotion is actively working on an SVG plug-in, which should handle what Adobe does, and more.

More importantly, the more we use these technologies, the more tools created, leading to more sophisticated works, leading to better tools, and so on. We have to prime the pump before we can draw water.

As for whether the effect is useful is really in the eye of the beholder. For instance, I don’t see that the previously linked Hard Rock Cafe’s application to be useful, especially given how limited the access is to the application. However, I’d like to have the pieces that go into the effect, of which Bruce has demonstrated an open source equivalent. (About the only thing missing is JPEG 2000 for advanced image compression. )

By having the pieces in place, we’ll be ready when we do get ideas of how these effects can be combined into something useful, or innovative.

Bruce also supplied a link to a variation of the application that works with Firefox, Opera, and Safari.

SVG doesn’t need to compete and neither do I

The worst mistake I made in the recent discussions about open compared to proprietary technologies was to allow myself to be pulled in by sweeping statements such as, “the W3C has failed”. Not only be pulled in, but to get into some form of competition over which is the best: SVG/Ajax, Silverlight, or Flash.

The W3C has failed because Rich Internet Applications are the way of the future, or so goes the prescient among the pundits. Standards are dead, said others. Silverlight is the future. No, no, make that Flash. Silverlight! Flash! And on it goes, with poor SVG dragged along like the cousin who showed up at the dance without a date.

At the same time I waded into the battle of the—well, we really can’t call it vector graphics, as there is so much more involved— I also wrote about IE6 and the difficulty of ending the life of this seven-year-old browser. A seven-year-old browser that still dominates so much of the web. Person after person told me about this place or that with umpteen thousands of employees all using IE6. Someday, I’m told, we’ll signal the EOL of IE6, but not today. Not today.

These are two different views of the world, neither of which is compatible with the other. Either the world is ready to leave the W3C and other web standards organizations in the dust as we leap into the bright future where all the web is a box embedded in a single page with a big friggen cloud behind it, or we’re living on the edge just using transparent PNGs.

The Hard Rock Cafe website is fun, but it doesn’t work on my pre-Intel Mac, nor with Opera, and crashed my Safari on Windows XP and caused my not low-end laptop to spike at 80%…when idle. But it is pretty and is cool, and makes use of new JPEG compression techniques that are very cool, and we need pretty and cool, just to keep excited about all this stuff.

However, the world will still turn, every day and every night, to Google Maps, created with technologies in use today— standard and proprietary technologies, both—and now so much a part of our lives that we’ve forgotten when we considered it cool.

Years ago, one group of companies proposed one way of doing 2D vector graphics, and another proposed a different way and from the clash came SVG. However, Microsoft did its own thing, and implemented VML, and created what is probably the last battleground in the war of the browsers. I don’t know why Microsoft went with VML. I imagine one reason is that Microsoft was not willing, then and now, to commit to the necessity of XHTML. Either that or the company was being purblind, pig-headed stubborn. Either way, Microsoft went one way, everyone else went another, and now we’re left with no meeting ground between two positions. To say the situation is disappointing is to say that the Midwest got a touch wet this spring.

Maybe HTML5 will be the bridge that brings the sides together. I hope so, but that’s in the future and we have to think of the now. The now that celebrates the latest whizzy from Microsoft and Adobe, while having to continue to support IE6. The now that needs the standards, even when most of the people don’t realize how much they need them. And OK, the now that needs Silverlight, and Flash, and whatever else new comes along, because that’s what the web is, has been, and probably will always be.

I’ve always said we need more women in technology because I believe we women bring balance to technology. I like to think that we foster cooperation, rather than competition, but perhaps that’s my own bias, or even my own stereotype, shame on me. However, I didn’t bring any cooperation to this discussion. I was right in there with the boys: snorting, stomping, and digging my feet into the dirt, as I rolled up metaphorical sleeves and prepared to wade in with code. Of course, it was little bitty code, and all I managed to really do was look a little silly. Worse though, is I looked silly at the same time I was saying stuff that was anything but. I guess that makes me a real tech because I can be just as purblind, pig-headed stubborn as every other tech I’ve ever met. Stubborn and with code—that’s a dangerous combination.

I like SVG. I like SVG for itself. I like that you can add 2d graphics directly into a web page; that you can use JavaScript to manipulate the SVG after the page loads—not to mention the really fun declarative animations. I like that it is interactive. I like that it’s free, and that it’s open; that it belongs to all of us. Most importantly, I value that it’s built into the browser, not added via a plug-in, and I can depend on it being there. Well, mostly there. I have many more fun things I want to try with SVG (and the Canvas object and JavaScript and CSS)—even if it means I’ll be putting the results of my efforts on a four-legged stool with one leg missing.

I like SVG, but SVG is not Flash. SVG is not Silverlight. However, that doesn’t make SVG better or worse than Flash or Silverlight—it just makes SVG different. And that’s where my time should go: celebrating the difference, not trying to trip the other guy up, so I can kick dirt in his face when he’s on the ground.

Enough rambling, back to the book.