W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: Distributed Extensibility

From: Philip Taylor <philip@zaynar.demon.co.uk>
Date: Fri, 03 Aug 2007 19:47:28 +0100
Message-ID: <46B37840.8020206@zaynar.demon.co.uk>
To: Sam Ruby <rubys@us.ibm.com>
CC: public-html@w3.org

Sam Ruby wrote:
> Philip Taylor wrote:
>>
>> If namespaces were added to HTML, I expect it would be quite 
>> beneficial to do it in a way that's sufficiently compatible with IE's 
>> implementation - the basic details appear to be vaguely sane, and must 
>> already be compatible with the existing web content (of which ~2% 
>> already uses namespaces, specifically Office's <o:p> plus a 
>> not-insignificant number of <v:...> and <st1:...> tags presumably also 
>> from Office).
> 
> How do existing user agents handle <o:p>?  Is what I proposed different 
> in any material way?

FF3, Safari 3, Opera 9.2 handle it the same as they handle any 
unrecognised tag, which is about the same as how they handle <span>.

In possibly uninteresting detail: "<o:p>content</o:p>" will create an 
element with properties tagName = nodeName = localName = "o:p" 
(case-preserving in Opera; uppercased in Firefox, Safari, except that 
localName is lowercased in Safari). "<o:p/>" will be treated as a start 
tag and so it will create an element that contains whatever comes after 
that tag.

scopeName = tagUrn = undefined. In FF and Opera, namespaceURI = null; in 
Safari, namespaceURI = "http://www.w3.org/1999/xhtml".

A CSS selector "o\:p" (case insensitive) will match those elements.


IE6/7(/5?) handle it as described before - "<o:p>content</o:p>" makes an 
element with scopeName = "o", tagName = nodeName = "p" (all 
case-preserving, but matched case-insensitively), tagUrn = the value 
from <html xmlns:o=...> (if any, else an empty string). "<o:p/>" always 
makes an empty element.

CSS "o\:p" still matches in IE. CSS namespaces aren't supported, so 
"*|p" (or "*|*") won't match it. document.createElement('o:p') creates a 
namespaced element. document.getElementsByTagName('p') matches the o:p 
element.


 From your proposal, assuming <o:p> is parsed namespacedly regardless of 
whether there's an xmlns anywhere, then I think parsing would happen the 
same as in IE. Interactions with the DOM are more of a problem:

To be compatible with XHTML, elements would have to have tagName = 
nodeName = "o:p", but that conflicts with IE's behaviour; and 
getElementById wouldn't find unknown-namespaced elements, which also 
conflicts. Also CSS "o\:p" would not match those elements, which 
disagrees with the current interoperable behaviour.


The common cases like <o:p> don't seem to be much of a real problem, but 
I would guess there are far more difficulties from a few script-heavy 
sites that attempt to use namespaces - 
<http://blogs.msdn.com/dthorpe/archive/2006/12/18/namespaces-in-html-too-much-trouble-to-bother-with.aspx> 
talks about a Windows Live developer being frustrated that IE's 
non-standard undocumented namespaces-in-HTML thing doesn't work in 
Firefox, and 
<http://blogs.msdn.com/dthorpe/archive/2007/05/27/html-namespace-attributes-and-ie-document-namespaces.aspx> 
about how they hacked things to work with namespaces in all two browsers 
and apparently shipped that code. It would require much more research 
and experience to find how much browsers can change their behaviour 
without breaking sites like those.


Some rough demonstrations of a few bits:
<http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cstyle%3Eo%5C%3Ap%20%7B%20border%3A%201px%20solid%20%7D%3C/style%3E%0D%0Aa%3Co%3Ap%3Eb%3C/o%3Ap%3Ec%3Co%3Ap/%3Ed>
<http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Chtml%20xmlns%3Ao%3Dfoo%3E%0D%0A%3Cbody%20onload%3D%22var%20a%20%3D%20document.getElementById%28%27a%27%29%3B%20w%28a.scopeName%29%3B%20w%28a.tagName%29%3B%20w%28a.nodeName%29%3B%20w%28a.tagUrn%29%3B%20w%28a.namespaceURI%29%22%3E%0D%0A%3Co%3Ap%20id%3Da%3Ea%3C/o%3Ap%3Eb>

-- 
Philip Taylor
philip@zaynar.demon.co.uk
Received on Friday, 3 August 2007 18:47:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:48 UTC