- From: Sam Ruby <rubys@intertwingly.net>
- Date: Wed, 04 Mar 2009 09:31:24 -0500
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- CC: Henri Sivonen <hsivonen@iki.fi>, Cameron McCormack <cam@mcc.id.au>, Ian Hickson <ian@hixie.ch>, www-archive@w3.org
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. > > Besides, the presence of the HTML DOCTYPE should be a clear indicator > that the file is intended to be HTML, not SVG. 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, > to legitimising the abuse of text/html as a dumping ground for non-HTML > content. 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. 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. - Sam Ruby
Received on Wednesday, 4 March 2009 14:32:34 UTC