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

[Boris Zbarsky]

On 5/30/13 12:06 AM, Michael Day wrote:
> This part still seems inconsistent with current browsers:
>
>> 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.

Behavior here .... varies.  From object to object and from browser to 
browser, depending on whatever bizarre implementation details the 
browsers happen to be using to implement the "properties appear and 
disappear" thing.

In particular, not all browsers are using WebIDL bindings for all 
objects yet, not even close.

> except for a very strange bug in Firefox only, where if I *read* the
> value before removing it, the attribute doesn't go away later:

Yep, that's a result of how this object is currently implemented in 
release Firefox (not as a WebIDL object).  It's a WebIDL object in 
Firefox nightly and Aurora builds if you want to test the behavior there.

It looks like I slightly misread what the spec says about the setting 
case.  Looks like for objects that do not have [OverrideBuiltins] 
setting will create/set a new own property that causes the property name 
to be hidden.  So this testcase:

     div.setAttribute("fruit", "orange");
     div.attributes.fruit = "apple";
     alert(div.attributes.fruit); // apple
     div.removeAttribute("fruit");
     alert(div.attributes.fruit); // apple

alerts "apple" in current trunk Firefox both times, for example.

-Boris