- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 22 May 2008 09:41:02 +0200
- 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 Pointer? > 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