Define customizable `<select>` by josepharhar · Pull Request #10548 · whatwg/html

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:
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 )

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.

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

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 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

This implements parsing part of customizable <select> spec update. See whatwg/html#10548.

Introduce the HTMLSelectedContentElement and integrate it into <select>, <option> and HTMLParser. See whatwg/html#10548. There are two bugs with WPT tests which causes the third subtest in selectedcontent.html and selectedcontent-mutations.html fail. See whatwg/html#11882, whatwg/html#55849.

- Rename HTMLOptionElement's `owner_select_element()` to `nearest_select_element()` to better match spec terminology. - Update HTMLSelectElement's option list related algorithms. This change is part of the customizable <select> spec work. See whatwg/html#10548.

Introduce the HTMLSelectedContentElement and integrate it into <select>, <option> and HTMLParser. See whatwg/html#10548. There are two bugs with WPT tests which causes the third subtest in selectedcontent.html and selectedcontent-mutations.html fail. See whatwg/html#11882, web-platform-tests/wpt#55849.

- Rename HTMLOptionElement's `owner_select_element()` to `nearest_select_element()` to better match spec terminology. - Update HTMLSelectElement's option list related algorithms. This change is part of the customizable <select> spec work. See whatwg/html#10548.

Introduce the HTMLSelectedContentElement and integrate it into <select>, <option> and HTMLParser. See whatwg/html#10548. There are two bugs with WPT tests which causes the third subtest in selectedcontent.html and selectedcontent-mutations.html fail. See whatwg/html#11882, web-platform-tests/wpt#55849.

… "in select" The 8 remaining corpus cases (tests1.dat#29/#99, webkit02.dat#35/#38/ #40/#41/#42) were previously classified as confirmed-stale test expectations, on the basis of html5lib's Python InSelectPhase dispatch table matching BlueIce's own ignore-outright behavior. That classification was itself wrong: html5lib is stale relative to the current WHATWG living standard, not the other way around. The "Customizable Select" feature (whatwg/html#10548, merged mid-2025, already shipped in Chromium and Gecko) removed the dedicated "in select"/"in select in table" insertion modes entirely, folding <select>'s content model into ordinary "in body" processing -- confirmed against the spec's current source and its own merged test-suite update (html5lib/html5lib-tests#178). Reimplement step_in_body's "select"/"option"/"optgroup"/"hr"/"input" arms per the current algorithm (each checking "has a select element in scope" directly, no dedicated mode), removing step_in_select/step_in_select_in_table and the Mode::InSelect/ Mode::InSelectInTable states. Also fixes a latent, independent bug this surfaced: is_special approximated the "special" element category as "not a formatting element" instead of the real enumerated list, wrongly treating <option> as special and blocking </optgroup>'s generic-end-tag scan from reaching the <optgroup> below an open <option> -- replaced with an explicit SPECIAL_ELEMENTS list. Corpus pass rate: 57.3% -> 58.3% (1022/1753), unclassified failures: 0. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VzUcwXuvot5qUrqWyi26hd

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