- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 4 Mar 2009 16:59:10 +0200
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, Cameron McCormack <cam@mcc.id.au>, Ian Hickson <ian@hixie.ch>, www-archive@w3.org
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