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...
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!
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.
(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.
(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!
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?