[whatwg] [dom] attributes collection not fully defined?

[Boris Zbarsky]

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 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21986

> 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]
>      div.removeAttribute("fruit");
>      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 
http://dev.w3.org/2006/webapi/WebIDL/#defineownproperty

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...

-Boris