Re: More on SVG within HTML pages

Henri Sivonen wrote:
> On Sep 7, 2009, at 11:21, Henri Sivonen wrote:
> 
>> 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.
> 
> This is violation of our Design Principles, because it puts theoretical 
> purity ahead of users who copy and paste.
> 
> Note that Support Existing Content doesn't apply, because when you 
> paste, you are authoring something new and Support Existing Content is 
> about supporting stuff that's already being served out there.
> 
>> 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.
> 
> This is a violation of our Design Principles, because it puts 
> theoretical purity ahead of parser implementors.
> 
>> 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).
> 
> This is a violation of our Design Principles, because there'd be 
> conforming stuff that doesn't have DOM Consistency.

<aside>I love this email</aside>

I would argue that 3.2 (Priority of Constituencies) doesn't just 
identify which ones of these are violations, it identifies which one to 
select.

More specifically, it would select #3.

I'd also argue that as you have stated #3 you are begging the question 
(presuming a proposition which requires proof).  There are quite a 
number of ways that HTML5 takes things that are 
application/xhtml+xml-looking and yet places them in the DOM in ways 
that are not consistent with XML.  I will willfully concede that such 
concessions are a single item here and a single item there vs. wholesale 
such as this case, but the entire reason that SVG was essentially 
adopted wholesale was to enable the precise use case of copy/paste.

I will further argue that the way to address this is with a note that 
there will be DOM differences, but that things that appear to use 
namespace inspired syntax will be treated as conforming when found 
inside foreign content -- ONLY.

I will state from personal experience that typical SVG documents of the 
kind that one is likely to find on the web is SVG infested with 
namespaces.  Not just infested but infused, to the point where it takes 
a non-trivial amount of effort to remove such (effort I routinely take 
for my weblog).

Should a conformance checker ever have a polyglot mode, checking for 
undeclared prefixes and other common namespace-well-formed errors would 
make sense in this mode.  Flagging declarations of xlink with a prefix 
other than 'xlink' would also make sense.

- Sam Ruby

Received on Monday, 7 September 2009 13:55:05 UTC