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 <style> tag.
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 <object> or <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 xsl:transform, html:p, or 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!
Oh god, why do I have the distinct feeling that after almost a decade of real progress in web standards, people are now looking to move backwards?
It seems to me if people want to embed other XML markup, they should use XML. Why are there all these contortions going on to support a broken markup format with yet more broken ideas?
Sorry Michael, don't mean to pick on you in my first comment on your blog :-)
Because there's no good way to serve XHTML on the web these days, I would guess.
Are all these contortions really due to IE not treating XHTML served as application/xhtml+xml correctly?
XHTML can be easily served as application/xml. All you have to do is create a stylesheet that copies all elements verbatim ac literatim by default. If you also use , you can extend XHTML with your own custom tags.
And yes, this does work in IE
Michael, let's meet F2F at XML 2007 to discuss this further... -m