Bug 190626 – [Datalist] imported/w3c/web-platform-tests/html/semantics/forms/the-datalist-element/datalistoptions.html fails after enabling the datalist element

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Forms

[Wenson Hsieh]

See: GenericCachedHTMLCollection.cpp:

GenericCachedHTMLCollection<traversalType>::elementMatches handles DataListOptions by filtering out disabled and empty option elements, which means HTMLDataListElement.options() won't include disabled or empty options. However, this WPT checks that HTMLDataListElement.options() does include empty and disabled options.

The official spec has this to say:

<https://www.w3.org/TR/html52/sec-forms.html#the-datalist-element>

> Each option element that is a descendant of the datalist element, that is not disabled, and whose value is a string that isn’t the empty string, represents a suggestion. Each suggestion has a value and a label.
> 
> datalist . options
> 
> Returns an HTMLCollection of the option elements of the datalist element.
> The options IDL attribute must return an HTMLCollection rooted at the datalist node, whose filter matches option elements.

So the spec makes it clear what a suggestion is w.r.t. the datalist element, but it never specifies that there's a 1-1 mapping between a datalist element's options and its suggestions...

[Wenson Hsieh]

FWIW, removing the `!option.isDisabledFormControl() && !option.value().isEmpty()` check fixes this WPT, but causes another test, fast/forms/datalist/datalist.html, to fail. 

fast/forms/datalist/datalist.html verifies that empty and disabled option elements are *not* included in datalist's list of options, so clearly, one of these tests needs to be updated!

[Chris Dumez]

My interpretation of the specification is that we should returns all options (even if disabled):
https://html.spec.whatwg.org/#dom-datalist-options

"""
The options IDL attribute must return an HTMLCollection rooted at the datalist node, whose filter matches option elements.
"""

That said, it would be worth testing other browsers and match what they do.

[Chris Dumez]

(In reply to Chris Dumez from comment #2)
> My interpretation of the specification is that we should returns all options
> (even if disabled):
> https://html.spec.whatwg.org/#dom-datalist-options
> 
> """
> The options IDL attribute must return an HTMLCollection rooted at the
> datalist node, whose filter matches option elements.
> """
> 
> That said, it would be worth testing other browsers and match what they do.

Chrome passes http://w3c-test.org/html/semantics/forms/the-datalist-element/datalistoptions.html but Firefox fails.

Anyway, it seems Chrome and the spec agree so I would suggest matching Chrome / spec behavior.

[Wenson Hsieh]

(In reply to Chris Dumez from comment #3)
> (In reply to Chris Dumez from comment #2)
> > My interpretation of the specification is that we should returns all options
> > (even if disabled):
> > https://html.spec.whatwg.org/#dom-datalist-options
> > 
> > """
> > The options IDL attribute must return an HTMLCollection rooted at the
> > datalist node, whose filter matches option elements.
> > """

Yep, I agree with this interpretation.

> > 
> > That said, it would be worth testing other browsers and match what they do.
> 
> Chrome passes
> http://w3c-test.org/html/semantics/forms/the-datalist-element/
> datalistoptions.html but Firefox fails.
> 
> Anyway, it seems Chrome and the spec agree so I would suggest matching
> Chrome / spec behavior.

Sounds good — thanks, Chris!

[Ahmad Saleem]

Safari Technology Preview 162 is passing test: https://wpt.fyi/results/html/semantics/forms/the-datalist-element/datalistoptions.html?label=master&label=experimental&aligned

and even Safari 16.3 is passing the test: http://wpt.live/html/semantics/forms/the-datalist-element/datalistoptions.html

Can we close this now?