- 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