Re: [webkit-dev] HTMLSelectElement and namedItem()

2009-04-10 Thread David Moore
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

Re: [webkit-dev] HTMLSelectElement and namedItem()

2009-04-09 Thread Ian Hickson
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

Re: [webkit-dev] HTMLSelectElement and namedItem()

2009-04-09 Thread David Moore
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

Re: [webkit-dev] HTMLSelectElement and namedItem()

2009-04-09 Thread Darin Adler
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

[webkit-dev] HTMLSelectElement and namedItem()

2009-04-09 Thread David Moore
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