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

Re: More on SVG within HTML pages

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 7 Sep 2009 11:57:37 +0300
Cc: Shelley Powers <shelleyp@burningbird.net>, public-html WG <public-html@w3.org>
Message-Id: <D904A5C8-6ADB-44C8-911F-0718FE94932E@iki.fi>
To: Henri Sivonen <hsivonen@iki.fi>
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.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Monday, 7 September 2009 08:58:17 UTC

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