Embedding XML islands inside HTML documents is an old idea, and lately the debate about how to standardise this in HTML5 has been heating up again. As someone working on an HTML to PDF converter with strong XML support, I have a keen interest in the outcome of this debate. It would be very helpful if HTML and XML could be mixed and matched as necessary. So let me throw my five cents into the ring. (It would be two cents, but in this decimal age that would round down to zero).
Anne’s suggestion for embedding SVG in HTML is to hardwire the SVG elements into the HTML5 spec, simplifying them if necessary. Sounds tempting, but I think that the ship has sailed when it comes to simplifying SVG. Also, being unable to cut and paste SVG examples directly into HTML documents without editing them makes this solution less practical.
Sam’s idea is to embed SVG inside
<script> tags, which is clever, if a bit mentally jarring. It’s true that SVG can contain scripts, and the script element can contain arbitrary text, but it seems just as logical to use the
Many people have suggested that embedding SVG or MathML directly into HTML documents is a bad idea altogether, and that XML resources should be referenced using
<img>. A common rejoinder is that there are occasions when external resources are unavailable or inconvenient, and being able to paste SVG or MathML directly into documents is a better solution. Blog comments are often cited as an example, and I must say it would liven up a lot of blogs if commenters expressed their opprobrium or approval via equations and diagrams.
My one contribution is to point out once again that XML Namespaces Don’t Need URIs, and that if I say
svg:path you know exactly what I’m talking about, even though I didn’t prime you with any
xmlns attributes first. So why can’t user-agents be that smart?
PS. For those attending XML 2007 in Boston, I will be sitting on the panel Does XML have a future on the web?, which sounds like the ideal place to continue this discussion!