Define customizable `<select>` #10548

josepharhar · 2024-08-05T14:28:06Z

This defines several concepts related to customizable <select>:

Relaxing the HTML parser to allow more tags inside <select>
Updating the content model to allow more elements inside <select> and related elements.
Defines rendering and some interactions for base appearance for <select>
Adds the <selectedcontent> HTML element
Adds a UA stylesheet for <select> with base appearance

Closes #9799
Closes #10557
Closes #10310
Closes #10586
Closes #10317
Closes #10629
Closes #10633
Closes #10520
Closes #10670
Closes #10520
Closes #10762

At least two implementers are interested (and none opposed):
- Chromium
- Gecko
- Standards positions:
Tests are written and can be reviewed and commented upon at:
- Update tests for relaxed <select> parser html5lib/html5lib-tests#178
- https://wpt.fyi/results/html/semantics/forms/the-select-element/customizable-select
Implementation bugs are filed:
- Chromium: Already implemented
- Gecko:
  - https://bugzilla.mozilla.org/show_bug.cgi?id=1933591
  - https://bugzilla.mozilla.org/show_bug.cgi?id=1944403
- WebKit:
  - https://bugs.webkit.org/show_bug.cgi?id=283732
  - https://bugs.webkit.org/show_bug.cgi?id=286642
MDN issue is filed: Customizable select element mdn/content#37857
The top of this comment includes a clear commit message to use.

/dom.html ( diff )
/form-control-infrastructure.html ( diff )
/form-elements.html ( diff )
/grouping-content.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/interactive-elements.html ( diff )
/parsing.html ( diff )
/references.html ( diff )
/rendering.html ( diff )
/scripting.html ( diff )
/text-level-semantics.html ( diff )

source

josepharhar · 2024-08-19T16:23:57Z

FYI: I am likely going to remove the author-provided datalist and fallback UA button in this PR soon based on recent discussions, which will likely reduce the number of changes and complexity.

source

mfreed7 · 2024-10-23T23:40:34Z

Should this PR be closed, to avoid confusion? I believe it's been completely superseded by the list at the top of #9799, right?

josepharhar · 2024-10-30T00:04:59Z

Yes I'm not keeping this up to date anymore since I decided to split out the PRs and have slight redundancies

domenic · 2025-07-18T04:09:08Z

I did a review here to try to finish this off.

I pushed several editorial commits. @josepharhar, please review them.

The conformance requirements look reasonable to me.

However, one issue makes me think this is not ready. There are multiple definitions for option HTML element insertion/removing steps, one in the select element section, and one in the option element section. I cannot tell if they are both supposed to run, or if one has become obsolete, or what.

Please update this by merging them, or deleting the obsolete one.

Also, please moving the HTML element insertion/removing/moving steps, for both option and optgroup, into the sections for those elements, instead of keeping them in the select element's section. That can help prevent this sort of problem in the future.

domenic · 2025-07-18T04:10:40Z

An additional non-blocking note (a followup PR would be fine) is that it would be good to add more examples to the spec that use the new, more complicated forms of select.

josepharhar · 2025-07-18T19:31:23Z

Thanks Domenic! I fixed the duplicate insertion/removal steps. I also started a PR for examples: #11465

domenic · 2025-07-19T02:30:59Z

Great, thank you! Can you also move the optgroup steps to the optgroup element section, instead of having them in the select element section?

josepharhar · 2025-07-21T15:47:59Z

Great, thank you! Can you also move the optgroup steps to the optgroup element section, instead of having them in the select element section?

done

domenic

LGTM. I will merge this now!

dmsnell · 2025-09-10T17:36:49Z

Please pardon me if this is spelled out already and I‘m missing something, but it reads to me in the changes that we only run maybe clone an option into selectedcontent when the parser encounters an end tag whose name is OPTION. However, Chrome seems to be running this even when no end tag exists whose name is OPTION, as if running it on the event of the closing of an open OPTION element.

Should there be some mention in generate implied end tags, or even in the stack of open elements section indicating that when popping an OPTION element, the maybe clone an option into selectedcontent algorithm should run?

annevk · 2025-09-11T06:19:23Z

@dmsnell can you please file a new issue on that?

Synchronization with specifications: whatwg/html#10548 html5lib-tests updated. Unfortunately, we had to add the <search> tag in this patch, rather than in a separate one. Also in this patch, foreign content parsing has been changed. Brought into line with the specification. This related #256 issue on GitHub.

https://bugs.webkit.org/show_bug.cgi?id=299959 Reviewed by NOBODY (OOPS!). This implements the parser aspects of whatwg/html#10548 behind a flag. The old code path continues to be tested through our legacy HTML parser test suite. This does not yet implement new logic for the <select>, <optgroup>, <option>, and <hr> classes to account for the fact that <optgroup>, <option>, and <hr> can now appear as descendants and as such this is only useful for testing. (Until this <select> changes were made the legacy HTML parser test suite was synchronized with the WPT test suite and we'll remove it once it's easier to add tests HTML parser tests on the WPT side.)

https://bugs.webkit.org/show_bug.cgi?id=299959 Reviewed by NOBODY (OOPS!). This implements the parser aspects of whatwg/html#10548 behind a flag. The old code path continues to be tested through our legacy HTML parser test suite. This does not yet implement new logic for the <select>, <optgroup>, <option>, and <hr> classes to account for the fact that <optgroup>, <option>, and <hr> can now appear as descendants and as such this is only useful for testing. Remove fast/parser/input-textarea-inside-select-element.html test as it was duplicative of both the legacy HTML parser test suite and WPT coverage. (Until these recent <select> changes were made the legacy HTML parser test suite was synchronized with the WPT test suite and we'll remove it once it's easier to add tests HTML parser tests on the WPT side.)

https://bugs.webkit.org/show_bug.cgi?id=299959 rdar://140875257 Reviewed by NOBODY (OOPS!). This implements the parser aspects of whatwg/html#10548 behind a flag. The old code path continues to be tested through our legacy HTML parser test suite. This does not yet implement new logic for the <select>, <optgroup>, <option>, and <hr> classes to account for the fact that <optgroup>, <option>, and <hr> can now appear as descendants and as such this is only useful for testing. Remove fast/parser/input-textarea-inside-select-element.html test as it was duplicative of both the legacy HTML parser test suite and WPT coverage. (Until these recent <select> changes were made the legacy HTML parser test suite was synchronized with the WPT test suite. We'll remove it once it's easier to add HTML parser tests on the WPT side.)

https://bugs.webkit.org/show_bug.cgi?id=299959 rdar://140875257 Reviewed by Ryosuke Niwa. This implements the parser aspects of whatwg/html#10548 behind a flag. The old code path continues to be tested through our legacy HTML parser test suite. This does not yet implement new logic for the <select>, <optgroup>, <option>, and <hr> classes to account for the fact that <optgroup>, <option>, and <hr> can now appear as descendants and as such this is only useful for testing. Remove fast/parser/input-textarea-inside-select-element.html test as it was duplicative of both the legacy HTML parser test suite and WPT coverage. (Until these recent <select> changes were made the legacy HTML parser test suite was synchronized with the WPT test suite. We'll remove it once it's easier to add HTML parser tests on the WPT side.) Canonical link: https://commits.webkit.org/300998@main

josepharhar force-pushed the selectcomplete branch from 8be5f47 to 0bee650 Compare August 5, 2024 14:38

josepharhar mentioned this pull request Aug 5, 2024

Customizable <select> element #9799

Closed

josepharhar force-pushed the selectcomplete branch 2 times, most recently from 4691e13 to bef9083 Compare August 7, 2024 22:31

scottaohara reviewed Aug 8, 2024

View reviewed changes