W3C home > Mailing lists > Public > public-html@w3.org > March 2008

Re: SVG and MathML in text/html

From: Doug Schepers <schepers@w3.org>
Date: Tue, 11 Mar 2008 05:16:47 -0400
Message-ID: <47D64DFF.3060907@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:13 GMT