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

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.

>> 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, and I believe it would cause a sizable portion of content to fail to render if it was changed to be stricter.

> The Adobe SVG plug-in at least used to render files like this.
> Firefox  doesn't support files like this. According to http://www.w3.org/mid/op.ue2v5dj2wxe0ny@widsith.local
>   , Opera has knowingly removed support for files like this without an
> outcry.
>
> I'd like to re-emphasize, that the figure is over 1%!

What was changed in Opera 9.5 was to not qualify documents where the root element of the document is named 'svg' and the document was sent with mimetype "image/svg+xml", as an svg element in the svg namespace. Example (serve as "image/svg+xml"):

<svg viewBox="0 0 100 100">
  <circle cx="50" cy="50" r="25" fill="blue"/>
</svg>

This is a less common case, and this far we haven't heard complaints about it.

...

>> hasMetadata: 0.559070
>
> 56% has child elements in the metadata element.
>
>> hasStyleAttribute: 0.816338
>> hasPresentationAttributes: 0.372199
>> hasStyleElement: 0.102816
>
> The style attribute is the most popular way to style SVG.

In practise that's what authoring tools generate yes. I wouldn't necessarily draw the conclusion that that's the most commonly used way for handcoded svg:s, though it shows that CSS is commonly used in 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.

...

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

...

>> fontParent
>> ANY: 0.007303
>> defs: 0.004956
>> svg: 0.001785
>
> The <font> element does occur outside of <defs>  relatively often.

Right, so I would argue that it must be allowed, but then again that's what the SVG spec says anyway.

...
>> piTargets
>> ANY: 0.006054
>> xpacket: 0.006036
>> adobe-xap-filters: 0.000137
>> xml-stylesheet: 0.000012
>> xL: 0.000006
>
> Processing instructions pertain mainly to XMP.

Looking at mostly self-contained clip-art svg:s is likely to give a biased view on the uses of XML PI:s.

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

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.

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Wednesday, 3 September 2008 12:23:41 UTC