Re: What namespace features popular SVG tools really emit (ISSUE-37)

On Sep 3, 2008, at 15:22, Erik Dahlström wrote:

> On Mon, 04 Aug 2008 17:59:39 +0200, Henri Sivonen <hsivonen@iki.fi>  
> wrote:
>
>> On Aug 4, 2008, at 18:20, Henri Sivonen wrote:
> ...
>>> nonSvgRoot: 0.000000
>>
>> There were no files having root element with a local name other than
>> 'svg'.
>
> Hardly surprising for a collection of svg images. I think the data  
> is biased towards the clip-art use-case, which is fine, as long as  
> one notes that it's not necessarily representative for all svg  
> content.

The purpose was to see if Wikimedia commons had bogus data as SVG or  
whether the URL extraction process had gone wrong.

>>> nonNamespaceSvgRoot: 0.012202
>>
>> Over 1% of the files had the root element in no namespace. (Note that
>> I had configured the entity resolver of the XML parser to resolve or
>> external DTDs to an empty stream in order to approximate what  
>> browsers
>> do.)
>
> So, just to take an example, would the following have given a fail  
> in your tool:
>
> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
>    "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
> <svg viewBox="0 0 100 100">
>  <circle cx="50" cy="50" r="25" fill="blue"/>
> </svg>
>
> Bad practise or not, this is still rendered as svg in Opera,

That might induce other browsers to fake more DTD processing, which  
isn't nice.

> and I believe it would cause a sizable portion of content to fail to  
> render if it was changed to be stricter.

Yes. Firefox, Safari and Chrome fail to render "SVG" content that is  
not in the SVG namespace after parsing without external DTD  
processing, so developers of other SVG-enabled browsers seem to accept  
this level of incompatibility with legacy content in the case of SVG.

>>> prefixedSvgElements
>>> ANY: 0.003227
>>
>> 3‰ of the files have prefixed elements in the SVG namespace. That's 3
>> per*mille*. The SVG WG's proposal requires support for this case, but
>> requires failure in the case of when the namespace isn't declared at
>> all, which accounts for over 1 per*cent*.
>
> It seems strange to analyze a non-XHTML+SVG set of data if you  
> really wanted to know if people use prefixes or not. The typical  
> scenario when they're used is in the mixed-document case, such as  
> XHTML+SVG, or XHTML+MathML+SVG, at least in my experience.

The motivation of the analysis was to discover what popular standalone  
SVG drawing tools emit, since argumentation had been based on taking  
output from popular tools and pasting into text/html.

The motivation wasn't to examine potential migration paths for  
existing XHTML+SVG content, since existing XHTML+SVG content will  
continue to work and won't need migrating. Indeed, the canonical  
example of existing XHTML content, Jacques Distler's blog, uses  
prefixed SVG. Not because of authoring tool or browser issues, AFAIK,  
but because of legacy validation technology.
http://golem.ph.utexas.edu/~distler/blog/archives/001475.html

>>> foreignElementsElsewhere
>> ...
>>> http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd sodipodi
>>> namedview: 0.461396
>>> http://inkscape.sourceforge.net/DTD/sodipodi-0.dtd sodipodi
>>> namedview: 0.085521
>>> http://www.inkscape.org/namespaces/inkscape inkscape perspective:
>>> 0.023537
>>> http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd sodipodi guide:
>>> 0.017420
>>> http://ns.adobe.com/AdobeIllustrator/10.0/ i pgfRef: 0.014387
>>
>> Outside metadata, foreign elements are common and are used for  
>> storing
>> editor-specific state that renderers are supposed to ignore.
>
> Note that failure to export this data (on copy-paste) may impact the  
> editing in a negative way, depending on the tool used.

But not in a more negative way than getting SVG authored with another  
tool.

> ...
>>> internalEntities
>>> ANY: 0.053271
>>> ns_svg: 0.048921
>>> ns_xlink: 0.048871
>>> ns_flows: 0.016016
>>> ns_ai: 0.009880
>>> ns_extend: 0.009880
>>> ns_graphs: 0.009880
>>> ns_adobe_xpath: 0.009331
>>> ns_custom: 0.009331
>>> ns_imrep: 0.009331
>>> ns_sfw: 0.009331
>>> ns_vars: 0.009331
>>> st0: 0.001017
>>> st1: 0.000961
>>> st2: 0.000868
>>> st3: 0.000780
>>
>> Entities declared in the internal subset are mainly weird NS
>> declarations emitted by Adobe Illustrator. Copying and pasting the
>> part of the document after the doctype into text/html under the SVG
>> WG's proposal doesn't work  without further editing. Under the
>> proposal that is commented out in the HTML5 draft, the pasted stuff
>> should render without further editing even though it would be
>> conforming.

s/conforming/non-conforming/

>>
>
> Interesting, though I think allowing defined entities to "leak" into  
> the XML parser would be a way to allow this in the SVG WG proposal.

How do you mean? Should HTML5 predefine the Illustrator entities? How  
would that work when copying SVG fragments *out of* text/html into XML  
on the source level, which is the SVG WG's stated motivation for  
embedding an XML parser?

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

Received on Wednesday, 3 September 2008 13:03:31 UTC