W3C home > Mailing lists > Public > public-html@w3.org > May 2008

Re: null namespace Re: Next steps for the ARIA syntax discussion

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 22 May 2008 09:41:02 +0200
Message-ID: <4835238E.8050502@gmx.de>
To: Robert J Burns <rob@robburns.com>
CC: Charles McCathieNevile <chaals@opera.com>, "www-tag@w3.org" <www-tag@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-xhtml2@w3.org" <public-xhtml2@w3.org>, "wai-xtech@w3.org" <wai-xtech@w3.org>

Robert J Burns wrote:
>> It results from a misinterpretation. People naively assumed that what 
>> you would like to have (attributes inherit the namespace of the 
>> element they are attached to unless otherwise declared), but that 
>> isn't what the spec says. The consequence is something near a decade 
>> of null namespaces in a few widely used specifications.
> The spec actually says it both ways (as null URI and according to the 
> element they are attached to). And implementors followed the 
> inappropriate way the spec describes (perhaps not anticipating the 
> problems it would create). I seriously doubt correcting that mistake in 
> current implementations would lead to serious problems. However, 
> correcting it would make things work much easier for authors and 
> authoring tool developers. Though I guess you're right correcting it now 
> would break existing XML content. My point was that we do not want to 
> repeat the same mistakes of XML in introducing prefixes, or full-on 
> namespaces to HTML5.

For the record: I don't think there's any agreement in the XML community 
that there is something wrong with respect to what namespace 
non-prefixed attributes live in.

It was one of several possible choices, and I haven't seen any evidence 
it's harmful. People learn how it works and that's it.

Introducing something that looks similar but behaves differently 
probably would make things worse, not better.

> No, the spec says two different things and implementors went with the 
> wrong one. Why that is I don't know, but one probably led the way and 


> the others followed. I understand changing it now would be a problem, 
> but its not a matter of wanting the spec to say something else. The spec 
> in fact does say something else.
>> I do not think it is worth trying to change now - because to be honest 
>> I don't see it causing massive problems. (Yes, people make mistakes 
>> from time to time due to this - and I made mine very publicly :(, but 
>> equally they can still learn in about 3 minutes, and it seems that 
>> they do).
> No, I think it is a major headache for authoring situations. Again, we 
> have reversed the priority of constituencies here as we so often do in 
> this WG. It should be users, then authors, and then implementations. Of 
> course getting a group largely controlled by implementation developers 
> leaves that largely up to the honor system.

How is it a "major headache"? And how exactly would it help authors if 
the behavior would differ in different serializations?

BR, Julian
Received on Thursday, 22 May 2008 07:42:15 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:33 UTC