W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: More on SVG within HTML pages

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 07 Sep 2009 13:52:15 -0700
Cc: Simon Pieters <simonp@opera.com>, Henri Sivonen <hsivonen@iki.fi>, Shelley Powers <shelleyp@burningbird.net>, public-html@w3.org
Message-id: <EDA1E946-CE0C-443E-905C-B8FE0E4213E4@apple.com>
To: Sam Ruby <rubys@intertwingly.net>

On Sep 7, 2009, at 11:08 AM, Sam Ruby wrote:

> Simon Pieters wrote:
>> On Mon, 07 Sep 2009 10:21:55 +0200, Henri Sivonen <hsivonen@iki.fi>  
>> wrote:
>>>> More importantly, this is a HTML5 failure in waiting, because if  
>>>> people inline SVG, chances are they will inline whatever SVG they  
>>>> find in the wild, which may or may not include RDF/XML. Validly  
>>>> include, may I add, in fact recommended when it comes to  
>>>> annotating Creative Commons license info.
>>>
>>> I agree. This problem has no good solutions, as far as I can tell.
>>>
>>>  1) Leave RDF/XML-looking stuff non-conforming. Bad because copy- 
>>> pasting leads to a lot of errors about stuff that browsers will  
>>> ignore--just like they ignore the contents of <metadata> in XML.
>>>  2) Perform full Namespace processing in <metadata> subtrees. Bad  
>>> because this would introduce considerable complexity in order to  
>>> shuffle around namespaces of stuff that browsers (and so far even  
>>> validators!) end up ignoring. Adding a lot of complexity to tweak  
>>> the DOM only so that it can be ignored doesn't make sense.
>>>  3) Leaving the DOM building as-is but proclaiming the RDF/XML- 
>>> looking stuff that infoset-wise isn't RDF/XML as conforming. Bad  
>>> because it would make authors believe that they are actually using  
>>> RDF/XML and worse because if someone wanted to consume that data  
>>> as RDF, they'd need to have dual code paths for text/html and XML  
>>> (and the DOM Consistency Design Principle is all about avoiding  
>>> that situation).
>> 4) Make SVG <metadata> a RAWTEXT element. This will silence the  
>> validator with little effort on Henri, while allowing authors to  
>> invoke an XML parser on its textContent to get the same stuff as  
>> they get when using XML, with more or less the same code path as  
>> when using XML directly. It would still allow validators to  
>> validate the contents if they want to. This has the drawback that  
>> if authors copy-and-paste only the start tag and only test in  
>> legacy browsers, the rest of the page will be eaten in new  
>> browsers. The content model of the SVG <metadata> element would  
>> need to change to allow plain text, at least in text/html.
>
> Suggestion: take a random svg image out of wikipedia and search for  
> "sodipodi".  Getting rid of the errors in a small portion of the  
> image isn't going to undo the damage to both the adoption of SVG or  
> the adoption of the conformance checker by flagging the remaining  
> "errors".

I think many of these cases are also errors in SVG 1.1, and are  
reported as such by the SVG 1.1 validator. Apparently, Wikipedia's  
adoption of SVG has not been hindered by these errors, though one may  
at this point doubt their willingness to adopt conformance checking.

Regards,
Maciej
Received on Monday, 7 September 2009 20:53:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:07 UTC