Re: Making it possible to use an <svg> root in text/html

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
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 4 March 2009 14:59:52 UTC