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

Re: More on SVG within HTML pages

From: Shelley Powers <shelleyp@burningbird.net>
Date: Mon, 07 Sep 2009 16:37:40 -0500
Message-ID: <4AA57D24.1000402@burningbird.net>
To: Maciej Stachowiak <mjs@apple.com>
CC: Sam Ruby <rubys@intertwingly.net>, Simon Pieters <simonp@opera.com>, Henri Sivonen <hsivonen@iki.fi>, public-html@w3.org
Maciej Stachowiak wrote:
> 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
Looks like someone is re-writing the validator.

Don't set the Doctype, let it set automatically. You'll then get a 
doctype of SVG 1.1+IRI, XHTML5+ARIA plus MathML 2.0 (experimental)

Huh. Looks familiar, doesn't it? It also doesn't throw errors.

Regardless, of people screwing around with the W3C validator, the markup 
is valid.

And regardless of whether it was or not, is beside the point, and not 
related to the topic under discussion.

Received on Monday, 7 September 2009 21:38:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:51 UTC