RE: Possible Compromise solution for namespaces in HTML5

Robert Ennals wrote:
> 
> I'm thinking that parsing into a DOM tree would work exactly the same
> way as it does for XML now, except that:
> 
> * When /validating/ a document, a document is invalid if it assigns a
> prefix a URI that differs from that given in the registry
> * When /validating/ a document, a document is invalid if it assigns
> more than one meaning to an "x-" prefix.
> * When parsing an HTML document, it is legal for a node to use a prefix
> that does not have a corresponding xmlns declaration. In this case, the
> node has a prefix, but has no namespace.
> * Since an HTML5 document is not required to use xmlns, and a prefix
> always has a fixed meaning, tools designed to use HTML5 can ignore
> namespaces and instead work directly with prefixes.
> 
> A user agent doesn't need to know what set of prefixes has been
> blessed, or what namespaces they are expected to map to. This stuff
> only comes into play when validating a document.
> 
> That is, if a file parses and validates in XHTML, and parses as
> validates under my proposal, then the DOM tree will be the same for
> both.
> 

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.

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

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

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?

-Tony

Received on Tuesday, 24 November 2009 20:29:55 UTC