[S] this solution must not interfere with existing HTML elements or attributes

Any element name with no dots in it is treated as HTML (including HTML rules on handing unrecognized elements)

[S] must support HTML nested inside an extension vocabulary.

Unless overridden, HTML documents are treated as if all localnames explicitly listed in the specification are HTML boundary elements.

[S] we can simplify our lives by saying "namespaces in HTML are only ever needed for non-standard customized fragments."

In other words, if you want to put in SVG into an HTML document, there are not name clashes (in context) so there is no purpose served by namespaces. All the HTML committee needs to do is say something like

"These are the standard vocabularies: HTML, SVG, RDF, etc etc, if you find an element belonging to them, that starts a new branch."

In formal terms, you could see it as having a notional name-rewriting step (which could be specified in ISO DSRL by the way) that goes from bare names to qualified names.

[S] My proposal: only allow setting the default prefix, as in xmlns='....'

It's compatible with both HTML and XML and should not greatly complicate existing HTML parsers. The drawbacks are that you cannot mix attributes from a different namespace, and that if you embed clumps from xmlns A inside B, a lot, you might get more verbose, with the emphasis on might.

[S] 1) the purpose of namespaces is disambiguation, but when we start with HTML we rarely find that elements with the same local name are used, and certainly not in the exactly the same context, and 2) the namespace URI is used as a symbol to connect to schemas etc, but when we use HTML we find that browsers operate by built-in knowledge that does not require extra resolution of the URI,

we can simplify our lives by saying "namespaces in HTML are only ever needed for non-standard customized fragments."

In other words, if you want to put in SVG into an HTML document, there are not name clashes (in context) so there is no purpose served by namespaces. All the HTML committee needs to do is say something like

"These are the standard vocabularies: HTML, SVG, RDF, etc etc, if you find an element belonging to them, that starts a new branch."

In formal terms, you could see it as having a notional name-rewriting step (which could be specified in ISO DSRL by the way) that goes from bare names to qualified names.

The advantages: * HTML keeps plain and simple, and no-one has to worry about namespace markup * people who want to add custom bits can do so, and can use namespaces and so on using the current mechanism. * XHTML can continue on without change * mixed convention documents need not be distrupted * no big effort for defining a new syntax, which may be an exercise in shifting verbosity from one location to another, would be required

(Another way of achieving much the same thing would be to allow multiple namespaces as the default, with a schema-linked mechanism where the namespace URI can be chosed by matching the local name in context with unambiguous choices in a list of schemas. Not less defaulting, but smarter!)