- From: Doug Schepers <schepers@w3.org>
- Date: Sat, 15 Mar 2008 13:49:07 -0400
- To: HTMLWG Tracking WG <public-html@w3.org>
Hi, Boris- Boris Zbarsky wrote (on 3/15/08 1:18 PM): > Doug Schepers wrote: >>> That's a fallacy. As I have pointed out before, *no* SVG-in-text/html >>> scheme can capitalize on compatibility with deployed SVG-as-XML >>> clients, because the clients trip up on the text/html Content-Type or >>> at least the HTML wrapped around the SVG image. >> >> No, that's the fallacy. >> >> As has been pointed out numerous times, just because a piece of >> content starts in an HTML file doesn't guarantee it's going to stay >> there. It could very well be copy-pasted into a standalone file, with >> absolutely no HTML in it, and be expected to work in an existing SVG UA. > > As Henri pointed out, if the SVG content contains unquoted attributes > (which got ignored when it got parsed as part of the the HTML per your > proposal), it won't work as a standalone document in an existing SVG UA. No, you're right... the idea was that it would be obvious to the author that something was wrong, while still allowing some looser error handling for the HTML context. > The only way I see to make the copy-paste scenario work is to require > that any XML well-formedness error in the SVG fragment in HTML lead to > the whole fragment not being displayed. That is, have the same > "Draconian" error handling that XML parsing does. Or am I missing > something? No, only that I was trying to be a little more flexible. Not rendering that fragment anything (but also not causing an unrecoverable error) would also be acceptable to me. Note that if you had multiple SVG fragments in an HTML page and only one of them was "broken", the others should render fine. (Obvious, but worth stating.) Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Received on Saturday, 15 March 2008 17:49:42 UTC