According to the HTML5 spec we should be returning a node collection if
there are multiple matches, both for HTMLSelectElement and
HTMLOptionsCollection. So neither Safari or chromium is in conformance to
this. Safari always returns null for named elements in HTMLSelectElement no
matter how many ma
On Thu, 9 Apr 2009, David Moore wrote:
>
> I've looked at FF, IE and Opera. FF doesn't support named item access
> from an HTMLSelectElement. It does support it from
> HTMLOptionsCollection, and returns 1 element even if there are multiple
> options with the same name.
>
> IE doesn't support na
I've looked at FF, IE and Opera.
FF doesn't support named item access from an HTMLSelectElement. It does
support it from HTMLOptionsCollection, and returns 1 element even if there
are multiple options with the same name.
IE doesn't support named item access from either HTMLSelectElement or
HTMLOpt
On Apr 9, 2009, at 11:50 AM, David Moore wrote:
So what's the right thing to do here? Should we be returning null or
the element?
Normally we take a look at what other browsers do when deciding on
this sort of this. We should look at IE and Firefox behavior. Also,
lets check if HTML 5 has
chromium and Safari currently differ on how they handle getting named items
from HTMLSelectElements. If you have this html:
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
5 matches
Mail list logo