W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2011

Re: setAttributeNS(): should it change the namespace prefix?

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Tue, 29 Nov 2011 21:45:16 +0200
Message-ID: <4ED5364C.9050107@helsinki.fi>
To: David Flanagan <dflanagan@mozilla.com>
CC: www-dom@w3.org
On 11/29/2011 09:35 PM, David Flanagan wrote:
> 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.
How is that absurd? setAttributeNS() sets anyway the attribute
namespace, name and value, why prefix should be special cased?
I prefer consistency, so I think Gecko's behavior is reasonable.


> 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.
prefix is readonly in DOM4, not in DOM2 or DOM3.
One option is to go back to the DOM2/3 behavior.


> 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:45:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:59 UTC