RE: Possible Compromise solution for namespaces in HTML5

Tony Ross wrote:
> Robert Ennals wrote:
> >

[snip]

> 
> I have some clarification questions, mostly for cases where the
> document would not parse as XHTML:
> 
> 1. Would the "svg:" and "math:" prefixes be special? In other words,
> would they cause a user agent to place their elements in the
> appropriate namespace even without an xmlns:prefix declaration?
> Alternatively we could disallow these specific prefixes and stick with
> the current HTML5 handling for SVG and MathML elements.

I have no strong opinion. My preference would be to keep things simple and treat svg and math exactly like any other prefixed element. However this allows two possible behaviours:

1.) If the user agent /supports/ a particular prefix, then it automatically fills in the namespace for elements with that prefix.

2.) The namespace is only set if an xmlns declaration is present, but the user-agent ignores the namespace and will correctly handle elements with a supported prefix correctly, even if they don't have a namespace.

I'm not sure which I prefer, or whether the difference even matters. Option 1 makes it more likely that your namespace will be right, but makes parsing behavior depend on what namespaces your user agent /supports/ - which seems kind of icky. I think I'm gently leaning towards option 2.

More generally, I'd like to encourage a model where HTML tools largely ignore the namespace and instead look only at the prefix.

> 2. What namespace would HTML user agents assign to prefixed elements
> when no xmlns:prefix declaration is present? I can see two logical
> options if we're not requiring the user agent to lookup the prefix in
> the central registry:
>     a. namespaceURI = null (This seems to be the currently implied
> answer)
>     b. namespaceURI = http://www.w3.org/1999/xhtml

I don't have a strong preference on this - since I expect tools to largely ignore the namespace and just look at the prefix.

That said, option "a" (null) is indeed what I had been thinking of, and it seems to be the most logical. 

Interestingly, option "a" is what IE and Firefox currently do, and option "b" is what Safari and Chrome currently do. Option "b" is what the spec currently calls for, but I think that could be changed with minimal disruption.

> 3. Similar to (2) and likely tied to its answer, what type of element
> would be created for prefixed elements? This choice can impact what
> APIs are available on an instance of that element. I also see two
> logical options here (presuming "svg:" and "math:" are either
> disallowed or handled specially):
>     a. Element
>     b. HTMLUnknownElement

For consistency with things like svg and mathml, it seems sensible to say that the element is guaranteed to be some subclass of Element, where the type depends on the prefix (NOT the namespace) and whether the user agent supports that type. Thus, e.g. an element with the "svg" prefix would be of type "SVGElement". 

Follow up specs for particular extensions can then say what type is required for elements with particular prefixes (NOT namespaces).

> 4. Is the intent that the answers to (2) and (3) can be overridden if
> defined as such in another specification? In other words, can "Foo in
> HTML" state that all elements prefixed with "foo:" are in the
> "http://foo" namespace and implement the FooElement interface?

Maybe... WRT setting the namespaces, that would correspond to my option 1 above, but I'm not yet sure whether I like option 1. 

WRT specifying what interfaces a node should support: yeah, the spec for an extension would say what interfaces must be supported by its nodes.


-Rob

Received on Tuesday, 24 November 2009 21:59:44 UTC