On Mar 4, 2009, at 16:31, Sam Ruby wrote:
Lachlan Hunt wrote:
Henri Sivonen wrote:
* Make an element with the local name 'meta' in the SVG namespace
and with an attribute charset in no namespace conforming as a
child of a root <svg> element in text/html.
* The above formulation requires <!DOCTYPE html> for <svg> root
element, which *would be well-formed* but *not valid* in XML due
to the html vs. svg name mismatch.
The problem that the SVG WG have described they are trying to
address, at least in internal discussions at Opera, is that people
will produce otherwise conforming SVG documents, which could in
theory be served as XML, but due to the failure to properly
configure their server, somehow end up being served as text/html.
This is basically an error condition that they are trying to
address more gracefully. Such content would not include either a
DOCTYPE or a meta element.
I wasn't trying to address an accident case. I was trying to consider
what it would take to allow deliberate serving as text/html.
On its face, enabling the accident case to the point of allowing stuff
that looks like an XML declaration to set the character encoding seems
dangerous. (Re-implementing all the existing encoding sniffing ways
for Gecko wasn't particularly nice, so I'm not at all keen on piling
on more.)
Besides, the presence of the HTML DOCTYPE should be a clear
indicator that the file is intended to be HTML, not SVG.
I think it's an indicator that the author wants the standards mode. :-)
But by allowing such non-HTML content to include the HTML DOCTYPE
and the meta element, suddenly we've slipped down the slope from
handling an edge case error,
I wasn't considering this as error handling.
to legitimising the abuse of text/html as a dumping ground for non-
HTML content.
I guess that depends on what your world view on text/html and content
types is.
Are content types an architectural error compared to magic numbers?
Does image/png mean a PNG image or does it mean any image as sniffed
from magic?
Do application/xhtml+xml and image/svg+xml mean XHTML and SVG or just
bootstrapping the XML parser with further dispatch on namespace?
Does text/html mean just HTML or browsable Web content? HTTP 0.9 and
<plaintext> FTW! ;-)
I may be wrong, but I don't think that's Henri's point. I think we
can all agree that svg served as text/html should never be
considered conformant.
Actually, I'm not ready to agree on the conformance point. If we go
through the trouble of enabling <svg> as root in text/html, we might
as well make it conforming to allow standalone SVG be written without
the Draconian behavior of XML.
I don't have an informed opinion yet whether enabling <svg> as root in
text/html at all is a good idea. But if we do it, I see point in
making it an error.
What I see Henri's point as being is that in order to make SVG
served as text/html mostly work, some changes are required, and he's
taken a stab at what those changes are. Unfortunately, those
changes may not be enough as they are predicated on the content not
triggering quirks mode.
A possible adjustment would be making an initial <svg> token trigger
the standards mode, but then there'd be no escape if the document
turns out to be bogus later in the parse. But then, there's no escape
if a quirky author copy-pastes a standards-mode doctype.
--
Henri Sivonen
[email protected]
http://hsivonen.iki.fi/
