[whatwg] [dom] attributes collection not fully defined?
bzbarsky at MIT.EDU
Wed May 29 20:34:53 PDT 2013
On 5/29/13 11:08 PM, Michael Day wrote:
> For example, setting an attribute will create a property with the same
> name as the attribute:
> div = document.createElement("div");
> div.setAttribute("foo", "bar");
> alert(div.attributes.foo); // [Object Attr]
The DOM spec as written right now does not support this. This is a
clear bug in the spec in that it's not web-compatible. See
> Except for read-only properties like length, which will not be shadowed
> by attributes:
> div.setAttribute("length", "99");
> alert(div.attributes.length); // 2
This is the normal behavior for WebIDL things with a named getter.
> div.attributes.fruit = "apple";
> alert(div.attributes.fruit); // apple
> div.setAttribute("fruit", "orange");
> alert(div.attributes.fruit); // [object Attr]
> alert(div.attributes.fruit); // apple (!!!)
> Firefox and Chrome seem to be inconsistent on this, but at least in some
> situations they will shadow the property with an attribute, then restore
> the original property when the attribute is removed.
That is also the normal behavior for WebIDL things with a named getter.
> The mind boggles. How are these pseudo-properties supposed to be
> implemented? What magic hook calls them to life?
If Element.attributes were using a named getter, the behavior would be
as defined in http://dev.w3.org/2006/webapi/WebIDL/#getownproperty and
Which is a bit dense but the short of it is:
1) The interface defines some set of exposed names.
2) Exposed names which would shadow something on the proto chain are
ignored at get time.
3) Setting a property name that is not currently exposed creates a
property on the object. If the name later becomes exposed, it will
shadow the value that was set.
4) Setting a property name that is currently exposed does a Reject
(which means throw in strict mode, silently do nothing in
non-strict mode). Unless there is a named setter, of course.
You can see all of this behavior in all sorts of other objects (e.g. in
named access on an HTMLCollection)...
But again, the spec as currently written:
readonly attribute Attr attributes;
does not in fact define any named getter behavior and is simply wrong...
More information about the whatwg