Re: Another possible compromise re namespaces in HTML

On Wed, 25 Nov 2009 09:33:02 +0000, Toby Inkster wrote:
> How about this - I think it allows people wanting to use namespaced
> content in HTML a great deal of flexibility, yet without making things
> too complicated for parsers.
> 
> 1. In the HTML serialisation, xmlns:* attributes may be used to declare
> any namespaces. The default xmlns attribute cannot be bound to anything
> other than the HTML namespace.

Do you mean the last sentence as a syntactic rule only? Or or are you 
talking about the single instance when it has any effect declaring a 
default namespace? 

In the latter case, are you saying that, inside foreign content, one 
may declare the default HTML namespace and expect that it takes effect? 
If so, then I think we instead we could consider using a default prefix 
for HTML - such as "htm:" - see further down below.

If you meant the former, the syntax, then you forgot to express why/how 
it is permitted to declare the default namespace inside the 
out-of-the-box foreign-namespaces such as <svg>.
 
> 2. The namespace URIs which HTML supports "out of the box" (e.g. SVG,
> XML, HTML itself) do not have to be declared, and may not be declared
> using any prefix other than their standard prefix as specified by the
> HTML syntax spec. 

"Do not have to be declared". But may be declared, I suppose. See above.

> Those standard prefixes cannot be used with other
> namespace URIs. There is precedent for such a rule - in XML, the prefix
> 'xml' and namespace URI 'http://www.w3.org/XML/1998/namespace' may only
> be bound to each other. Such non-conformant namespace declarations would
> be ignored.

Likewise: the very "xmlns:" prefix itself can only be bound to the 
namespace "http://www.w3.org/2000/xmlns/". (Further more, the xmlns 
"must not be declared".) [1]

> 3. Namespaced attributes (foo:bar="baz") are conformant, but validators
> *may* issue warnings about them.
> 
> 4. Within so-called foreign content (e.g. SVG), namespaced elements are
> conformant, but validators *may* issue warnings about them. Elsewhere,
> namespaced elements are non-conformant. Namespaced elements are parsed
> the same way any other unknown elements are.

How does one place HTML content "within socalled foreign content"? 

By declaring a default HTML namespace? Or by using a predefined HTML 
namespace prefix? Or both ways? Should there not be a default prefix - 
such as "html:" or "htm:" - for HTML itself? E.g. so that one could do 
for example <html:table> or <htm:table> within foreign content? 

And what about the use of the HTML prefix inside "native" content? 
(Both on attributes and on elements.) 

One reason I ask is that e.g for the <caption> element, if it was 
permitted to do <htm:caption>, then it would actually work outside 
<table> ... Thus, inside native HTML, one option could be to permit the 
"HTM:" prefix only on certain elements, specifically for the purpose of 
dealing with legacy parsing of the un-prefixed version.  

Hence, text/HTML Web user agents would be required to support selecting 
<htm:caption> via the CSS rule caption{} (but also required to not 
apply _all_ the legacy parsing to to the prefixed canvas element). 
While legacy user agents would - in CSS - select <htm:caption> using 
htm\:caption{}.

This means that "htm" as a prefix would be reserved, which has a 
precedent in the XML namespace specification: [2]

]]
All other prefixes beginning with the three-letter sequence x, m, l, in 
any case combination, are reserved. This means that:
	*	users should not use them except as defined by later specifications
	*	processors must not treat them as fatal errors.
[[

> 5. People wishing to use namespaced elements outside foreign content are
> instead advised to use CURIE values within @role. It may be useful for
> browsers to expose the contents of @role as an array in the DOM with
> CURIE prefixes already expanded out.

Intriguing.
 
> 6. Namespace-aware DOM functions (getAttributeNS, etc) should work.
> 
> I can't imagine there's very much existing content in the wild that
> would break under these rules. The aforementioned example of Creative
> Commons licenses within SVG would work and be considered conformant; the
> Google Jotspot example would work but be considered non-conformant.

Thanks for a very clear proposal. I have to say that this compromise is 
what appeals to me the most, so far. I hope, after some debate of 
course, you will file it as a proposal in the Bugzilla.

[1] http://www.w3.org/TR/REC-xml-names/#xmlReserved
[2] http://www.w3.org/TR/REC-xml-names/#xmlReserved
-- 
leif halvard silli

Received on Wednesday, 25 November 2009 13:29:49 UTC