chromium and Safari currently differ on how they handle getting named items
from HTMLSelectElements. If you have this html:
<select id="mymenu" >
<option value="value1" name="foo">
</select>
this JS code
document.getElementById('mymenu').foo
returns null for Safari and the HTMLOptionElement for chrome. I would like
to create a new layout test to enforce the proper behavior. But I'm not
positive that Safari's current implementation is the expected one. This
comment in HTMLSelectElement.idl suggests that you should be able to access
option elements by name from the select element:
// These methods are not in DOM Level 2 IDL, but are mentioned in
the standard:
// "The contained options can be directly accessed through the
select element as a collection."
Node item(in [IsIndex] unsigned long index);
Node namedItem(in DOMString name);
So what's the right thing to do here? Should we be returning null or the
element? And what should we do if there is more than one element with the
same name? For HTMLOptionsCollection Safari returns a collection of the
nodes that have that name. That also differs from chromium, which returns
just one of the elements (as does Firefox). I want to make that behavior the
same as well (and create a layout test to cover it).
I don't have a strong preference here. I'm happy to make chromium behave the
same as Safari currently does as long as it's the expected behavior.
Dave
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
