- From: David Flanagan <dflanagan@mozilla.com>
- Date: Tue, 29 Nov 2011 11:35:53 -0800
- To: www-dom@w3.org
On 11/29/11 10:25 AM, Boris Zbarsky wrote: > You're talking about a different issue than Anne is. He's talking > about what happens when a different qualified name is used for the > same namespace+localname pair. You're talking about what happens when > the same qualified name is used for different namespace+localname pairs. > I'm talking about Anne's issue; I was just overly optimistic about the scope of the issue and thought it opened the door to a big simplification. I based my response on old memories of my implementation and did not re-read the spec carefully before replying. Sorry for my sloppiness and thanks for clarifying, Boris. So here are my modified thoughts: Webdevs use setAttribute() and setAttributeNS() to set attribute values. We think of them as setAttributeValue() and setAttributeValueNS(). So it is absurd that setAttributeNS() has the potential side effect of changing the prefix of an attribute. It's counter-intuitive that Gecko changes the prefix of an attribute while setting its value. But it's equally counter-intuitive that Webkit and Opera change the value of an attribute whose prefix does not match the prefix that was passed to setAttributeNS(). It is just a bad method. To go back to Anne's original example: > document.head.setAttributeNS("test", "x:a", "a") > document.head.setAttributeNS("test", "e:a", "b") I think the only implementation that comes close to being reasonable would be to throw a NamespaceError in the second call. But that would presumably break web compatibility. I don't see any particular reason that prefixes should be immutable, and for ease of serialization, it might actually be nice if Element.prefix and Attr.prefix were both writable attributes. But it appears that element prefixes are immutable and attribute prefixes are immutable except for the setAttributeNS() mis-feature. If I had to pick Gecko or Webkit behavior, I guess I'd go with Anne and say that Webkit's behavior is "somewhat preferable". But the DOM level 2 and DOM 4 specs have always been unambiguous that setAttributeNS can change an attribute's prefix. Gecko implemented the spec correctly and I don't think a "somewhat preferable" implementation of a fundamentally broken API is strong enough reason to change the spec now. (And I do think that DOM4 should add a non-broken attribute manipulation API that ignores prefixes and is based only on namespaces and local names.) David
Received on Tuesday, 29 November 2011 19:36:22 UTC