Possible Conservative Proposal : no prefixes, but allow xmlns on a root element

Hi Guys,

After reading the various objections to my third proposal, I wonder if I good solution might be the following, rather conservative proposal to address ISSUE-41:

If you want to introduce an extension, and call your HTML documents "extended HTML" then you must introduce your extension in the same manner that SVG and MathML have been integrated into HTML5. That is:


*         Define a root element (like math or svg) that content for your new extension can be included under.

*         If the extension is not yet part of HTML, the root element MUST contain an xmlns.

*         Such a root element MUST NOT be an existing HTML5 tag

*         If the extension is part of HTML, then the parser will infer the xmlns based on the name if no xmlns is currently present

*         If the browser encounters an unknown element with a default namespace declaration, then it should apply that namespace to all descendent nodes.

*         Use a registry to help spec authors ensure that these root elements, and ideally also the other elements, are unique. Also strongly encourage creators of such extensions to talk to the HTML WG. However the registry has no normative function, but is merely a recommended tool to help groups coordinate better.

Advantages of this approach:

*         Compatible with the way we have integrated extensions in the past

*         Compatible with current HTML parsing, except for the currently rare case of an unknown tag with an xmlns attribute

*         Compatible with XML namespaces

*         No ugly prefixes

*         When a feature becomes standard, it does not get stuck with a hard-to-remove prefix

*         When a feature is not standard, an author can see they are using an extension by the requirement to use xmlns.


The use case of this proposal is for specs like SVG and MathML which are intended to be vendor neutral and define presentational content (platform features to use TV Raman's terms). A different mechanism should be used to define "language features", or to define browser-specific experiments.

The exact status of these conventions would depend on the outcome from bug 7034. This could either be a conformance requirement for "extended HTML", a conformance requirement for HTML, or maybe just a separate document giving "guidelines for the creation of extension specifications for HTML5".


What do people think?

As with my last proposal, if it looks like this will get support then I'll write it up. If it looks like there are serious problems then I won't.


Note that this is a proposal from me, and is not an official Intel position.

-Rob