- From: Doug Schepers <schepers@w3.org>
- Date: Tue, 11 Mar 2008 05:16:47 -0400
- To: HTMLWG Tracking WG <public-html@w3.org>
Hi, Henri- Jeff Schiller wrote (on 3/10/08 7:21 PM): > On Mon, Mar 10, 2008 at 4:44 PM, Henri Sivonen <hsivonen@iki.fi> wrote: >> On Mar 10, 2008, at 23:14, Jeff Schiller wrote: >> >> I meant that a text/html doc with SVG inside it won't be readable by >> existing SVG tools and viewers in general, because the surrounding >> HTML almost always isn't well-formed and because the tools probably >> aren't expecting some non-SVG stuff around the SVG markup. In your >> sample case the HTML happens to be well-formed if treated as XML but >> this is not generally true of HTML. > > Thanks for clarifying Henri. I was talking from a copy-paste > perspective. For instance, it's perfectly conceivable that someone > might view > source, take the <svg> snips out into their own text > editor and bring the SVG up in a SVG editor like Inkscape. I've done > this and it works quite nice... > > But I agree that editors would have a problem with the surrounding > HTML "cruft", which I wouldn't expect them to handle. Jeff has stated my own concerns eloquently, so I won't repeat them (especially since you and I already had a similar conversation on IRC). In addition to the use case of extracting the SVG from an HTML document for the purpose of editing it, there is the strong case for reuse. The fact is, there is a very large deployed base of SVG UAs on mobile devices, many hundreds of millions, that cannot easily be upgraded or revised. Deliberately making incompatible changes to SVG such that the resulting content will not be viewable on the vast majority of deployed UAs is a very risky strategy, one that I don't think can be taken so lightly. This is a huge marketplace advantage over proprietary solutions (Flash Lite has a much smaller deployment, and Silverlight barely exists yet), and I would be concerned that fracturing the serializations would severely hamper the success of SVG. My suggestion would be that such inconsistencies be avoided in the first iteration of the specification, and reexamine that decision in a later iteration if indeed, as you suspect, the authors and autogenerators have considerable problems. Failing that, perhaps it would be better to restrict inline SVG to the XHTML serialization. (This is not a statement by the SVG WG, just my own opinion. I feel pretty strongly about it, but I'm open to other arguments, especially if there is strong evidence backing them up.) Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI
Received on Tuesday, 11 March 2008 09:16:59 UTC