- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 9 Mar 2009 19:09:24 +1100
- To: Doug Schepers <schepers@w3.org>
- Cc: public-svg-wg@w3.org
Doug Schepers: > To clarify: I don't see a compelling use-case for doing this > *purposefully*. Situations where the server is misconfigured, where the > author accidentally gave the file an "*.html" extension instead of > "*.svg", etc. are a different matter that I am inclined to treat more > sympathetically. OK. So you’d be open to having this <svg>-as-root as non-conforming but working? > Henri was pretty clear that he wasn't trying to solve the borken case, > as we discussed, but rather to propose some new behavior. [1] And even > he didn't claim to be advocating for it, just noodling out a possible > solution. Acknowledged. But would there be any difference in behaviour between catering for the mistakenly- and the deliberately-served-as-text/html cases (apart from conformance)? >>> and tying ourselves to a drastic solution like Henri proposed seems >>> like it will make it more difficult to code cleanly in XML-next, with >>> more permissive error recovery. >> >> Could you elaborate? > > No. > > :) > > Or rather, I just don't see the benefit in doing this on purpose, so I'm > not particularly eager to invest energy catering to that case. > > I guess my thought are vaguely along the order of... if something is > codified in HTML5, and down the pipe the XML community changes XML to be > permissive-but-not-identically-to-HTML5 (as I think is likely), but > there is already some sort of established back-door practice where > people just use HTML5 algorithms for parsing SVG, then SVG is forked in > multiple incompatible ways. Or something. I see. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 9 March 2009 08:10:02 UTC