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, JulianReceived 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