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
