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:48:43 -0700
Cc: Sam Ruby <rubys@intertwingly.net>, Simon Pieters <simonp@opera.com>, Henri Sivonen <hsivonen@iki.fi>, public-html@w3.org
Message-id: <FDE72AD2-BF7E-4F65-84CA-0F9FAA98091E@apple.com>
To: Shelley Powers <shelleyp@burningbird.net>

On Sep 7, 2009, at 11:29 AM, Shelley Powers wrote:

> 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".
>>
>> - Sam Ruby
>>
>>
>>
> Speaking of which, I copied the Wikipedia logo into an HTML5 page,  
> serialized as HTML, and ran it through the validator:
>
> Result
>
> http://html5.validator.nu/?doc=http%3A%2F%2Fburningbird.net%2Fnewbook%2Fwikiinhtml.php

Here is what the W3C validator says about the original XML version:

http://validator.w3.org/check?uri=http%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2Fb%2Fb7%2FWikipedia-logo.svg&charset=%28detect+automatically%29&doctype=SVG+1.1&group=0

(46 errors, specifically about the use of attributes from foreign  
namespaces in a way that is not allowed by SVG 1.1 itself.)

Regards,
Maciej
Received on Monday, 7 September 2009 20:49:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:48 GMT