Re: SVGWG SVG-in-HTML proposal (ISSUE-41, ISSUE-37)

On Jul 30, 2008, at 06:19, Doug Schepers wrote:

> 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.

The SVG WG proposal seems to allow HTML content that isn't supported  
by existing SVG UAs to precede an SVG subtree in a text/html document.  
(Besides, existing UAs such as Firefox, Opera and WebKit put the  
document onto a non-SVG track already upon seeing the HTTP-level text/ 
html Content-Type.)

> 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.

Interesting. I disagree that the SVG WG's proposal solves pragmatic  
problems, but let's consider IE for a moment.

It seems that IE already provides some kind of interface between the  
text/html parser and ActiveX components (such as MathPlayer and the  
Adobe SVG Plug-in). So far, despite repeated requests, no one has  
described this interface on this list or pointed to a description that  
matches the implementation.

Does that interface involve reparsing the relevant range of source  
text as XML with eager fatal errors? If not, wouldn't the SVG WG's  
proposal effectively disadvantage other UAs relative to IE?

> 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).

Currently, there are authoring tools for SVG-in-XML even though IE  
doesn't support it. It seems that non-IE UAs are enough of a  
complement for Inkscape to exist.

Moreover, you can author for the commented out proposal using Inkscape  
or Illustrator. (More below.)

>> 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?

Your claim, even though not false, is highly misleading.

When I've used Inkscape or tried Illustrator, both of them have  
emitted SVG element names without prefixes by default. (I've tried  
CS2. I haven't tried CS3. Right now I don't have access to  
Illustrator.) To check my recollection, I inspected a dozen SVG file  
authored with Inkscape, Illustrator CS2 and CS3 from Wikimedia  
Commons. In all cases, the elements from the SVG namespace were  
unprefixed. (Naturally, the attributes specified in the SVG specs were  
unprefixed, too, since they aren't in a namespace.)

Inkscape and Illustrator do emit prefixed names in some cases.  
However, those prefixed names aren't for elements or attributes that  
are rendering-sensitive and specified in the SVG spec. The prefixed  
names are used for serializing product-specific editor state and for  
metadata. Both are things of that renderers are supposed to ignore.

Although the commented out proposal produces a different DOM for the  
prefixed names compared to an XML parser, the difference does not  
affect SVG rendering.

(Also, debating whether things that get ignored should be put in a  
different namespace before getting ignored should not presuppose a  
full XML parser in the case namespace-processing.)

>> 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.

I argue that reserializing is a more robust approach than trying to  
make authors out there be friendly to copying and pasting source. I  
also argue that the parser complexity required to keep SVG-in-text/ 
html XML-safe is not worth the trouble.

>> 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.

I think the issues I raised haven't been addressed.

Here's an additional issue that I forgot to raise initially: How does  
the SVG WG's proposal deal with (ill-formed) HTML in foreignObject.  
(Existing HTML generation systems usually cannot guarantee well- 
formedness, but you might still want to add some vector graphics eye  
candy around output from a legacy HTML producer.)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 30 July 2008 11:04:29 UTC