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

Re: SVGWG SVG-in-HTML proposal (Was: ISSUE-41: Decentralized extensibility)

From: Doug Schepers <schepers@w3.org>
Date: Tue, 29 Jul 2008 23:19:13 -0400
Message-ID: <488FDDB1.1050905@w3.org>
To: Ian Hickson <ian@hixie.ch>
Cc: Charles McCathieNevile <chaals@opera.com>, Erik Dahlström <ed@opera.com>, HTML WG <public-html@w3.org>

Hi, Ian-

Ian Hickson wrote (on 7/29/08 8:56 PM):
>
>> The earlier HTML proposal would require a massive amount of 
>> re-engineering from the SVG community, since it would produce a huge 
>> inconstistency with more or less all existing tools.
> 
> This is a misunderstanding of that proposal; the proposal currently 
> commented out in the HTML5 spec in fact supports raw XML as is, without 
> modifications. 

Correct, but it also supports an alternate syntax that other user agents 
do not support.

Speaking for myself (not the SVG WG or W3C), if Internet Explorer were 
to actually implement your initial proposal (or some variation that 
preserves the needed document structure), I would be fine with that 
syntax.  I don't have an attachment to the current syntax for its own 
sake, merely for the pragmatic problems that would be caused by changing 
it in the current environment.

If IE implemented it, true, some UAs would need to change, including the 
authoring tools, but with the weight of the combined market share of IE 
and FF (which I presume would also implement the alternate syntax), I am 
confident that authoring tools would feel sufficient market pressure to 
adapt, as would the mobile browser SVG UAs (eventually, since the 
deployment pattern is different).

This is a matter of critical mass and market impact, and with your 
experimental algorithm (developed solely for HTML, and untested on the 
Web at large), that critical mass simply doesn't exist.  We would need 
to overcome the existing momentum of SVG's XML syntax.

Even a commitment by the IE team to implement this syntax would not be 
enough to shift this network effect, because plans can change.  It would 
need to be a publicly available release of IE.  Chris Wilson, if you 
have thoughts on this, I would welcome them.


> Prefixes must be removed but that is a trivial
> substitution, and is not necessary in most cases anyway since most SVG UAs 
> do not output prefixes. 

This claim seems to be false.  Every SVG authoring tool I'm aware of 
does output namespace prefixes, including the commercial juggernaut 
Adobe Illustrator, and its popular OSS rival Inkscape.  Even browsers 
output prefixes, when they save or give a source view.  Existing generic 
XML toolchains, not specific to SVG but SVG-capable, all output 
namespace prefixes.  What UAs are you referring to?


> Importing SVG content straight from text/html
> requires new code in any case since no SVG UA supports text/html SVG 
> import at all.

This argument is completely unconvincing.  The vast body of evidence in 
15 years of Web history is that people view source and copy code 
snippets.  It's a trivial matter of copying the inline SVG content into 
a new file, minus the HTML wrapper (and tweaking it if necessary, 
another timeworn process that's long since been paved).

In other places, you cite copy/paste as a critical aspect of your 
argument against preserving SVG's existing implemented syntax, so it is 
a weak argument to reject it as a use case.


> Anyway, as I've said before, I have yet to seriously and critically 
> examine the SVGWG's proposal. I am hoping that the issues that Henri, 
> Andrew, and myself have raised can be addressed before I do so.

We have already addressed some of these issues, so please feel free to 
review it in depth, and provide any feedback you feed necessary.

Regards-
-Doug
Received on Wednesday, 30 July 2008 03:22:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:56 UTC