SVG is becoming more and more popular. At least, among implementors. Within a year Opera Software, Apple and the Mozilla Foundation will ship products with decent SVG support. Adobe already ships a plug-in and products outputting SVG images. Problem is however that products outputting SVG files are mostly broken. MIME types seem to be less of an issue here, as I believe the Adobe SVG plug-in is quite strict about that. To the point in not supporting SVG when it has the correct namespace, an XML MIME type, but not the image/svg+xml XML MIME type. (I might be wrong here, I have never installed it and I am not planning to.) but more things like not outputting a namespace, implementations that are not interoperable with other implementations, et cetera. The namespace problem is also one in XHTML, but thanks to solid initial implementations and no WYSIWYG mess nobody complains. Besides, few people are using XHTML so it does not really matter. Let me elaborate. XHTML has a DTD. Inside the DTD you find the definition for the root element:
<!ELEMENT html (head, body)> <!ATTLIST html %i18n; id ID #IMPLIED xmlns %URI; #FIXED 'http://www.w3.org/1999/xhtml' >
SVG has the same thing. Declaring the SVG DOCTYPE implies http://www.w3.org/2000/svg except it does not. The problem is that browsers do not use validating XML parsers. The only reason some HTML entities remain to work in XML context with certain DOCTYPEs is because some browsers — Mozilla, at least — do some DOCTYPE sniffing for XML documents. To see if an XHTML DOCTYPE is used. If that is the case, an internal entity file is appended at the start of the document. That is actually viewable using the DOM inspector: see #comment inside #document before html. To get back to SVG, the DTD is not the only problem. Adobe's plug-in for example also thinks http://www.w3.org/2000/svg is implied when someone gives them a file with the image/svg+xml MIME type. (Perhaps only when the local-name is svg, but that does not make it less evil.) See this and this test to see if you are running something compliant. (Of course, when you do not run a browser with SVG support there is nothing to test.)
There are lot more problems. For example with the specifications as seen here. It would be nice if The Web Standards Project focused on these issues instead of writing scripts with memory leaks.
There is no point in this article, it is not complete, the last sentence in the previous paragraph was only semi-meant and all this should not come as a raging shock to anyone. Feel free to flame, comments are moderated.
Firefox (Deer Park Alpha 2) behaves very well, while Opera renders the first test case improperly.
I have a dream, that one day, SVG will be in every-day web developer's life as usual as CSS.
But that might take veeery long ...
The two links don't work in my Deer Park, although there is a site with lots of SVG images created for showing the "amazing" SVG support in Deer Park.
For the record, the two links, both named "this" (the horror), should return either an XML DOM tree or some unstyled fu.
do some
DOCTYPEsniffing for XML documents.
That is misleading. There is no mischief or unusual sniffing in the parser. The cheating is in the entity resolver.
If that is the case, an internal entity file is appended at the start of the document.
Rather, a heavily abridged surrogate DTD (external entity) is fed to the parser by the entity resolver. (If the public id has no mapping, the parser is given a zero-length stream, which has some implication compared to not resolving external entities at all.)
I call this sniffing. Too bad I can not point to a dated version of that file, so I will quote it here:
static const nsCatalogData kCatalogTable[] = {
{ "-//W3C//DTD XHTML 1.0 Transitional//EN", "xhtml11.dtd", nsnull },
{ "-//W3C//DTD XHTML 1.1//EN", "xhtml11.dtd", nsnull },
{ "-//W3C//DTD XHTML 1.0 Strict//EN", "xhtml11.dtd", nsnull },
{ "-//W3C//DTD XHTML 1.0 Frameset//EN", "xhtml11.dtd", nsnull },
{ "-//W3C//DTD XHTML Basic 1.0//EN", "xhtml11.dtd", nsnull },
{ "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN", "mathml.dtd", "resource://gre/res/mathml.css" },
{ "-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN", "mathml.dtd", "resource://gre/res/mathml.css" },
{ "-//W3C//DTD MathML 2.0//EN", "mathml.dtd", "resource://gre/res/mathml.css" },
{ "-//WAPFORUM//DTD XHTML Mobile 1.0//EN", "xhtml11.dtd", nsnull },
{ nsnull, nsnull, nsnull }
};Using blame, you can link to a specific revision.
P.S. The need to escape ampersands is not really obvious. I saw it nearly immediately, but the warning message "XHTML is not well-formed" might perhaps be improved upon. :)
I call this sniffing.
I think the MathML CSS loading constitutes doctype sniffing and is bad.
I would not characterize the use of public ids for the purpose of locating an external entity in a catalog doctype sniffing, because that’s what public ids are meant for. However, I do think that what Mozilla’s entity resolver does is harmful.