Skip to content

Support <button> in <select>'s native appearance - #12940

Open
annevk wants to merge 1 commit into
mainfrom
select-native-appearance-button
Open

annevk wants to merge 1 commit into
mainfrom
select-native-appearance-button

Conversation

@annevk

@annevk annevk commented Sep 14, 2026

Copy link
Copy Markdown
Member

The first child <button> element of a <select> element was only tied
into the rendering of base appearance, through the select button slot.
But as it takes over the function of the <select> element's button
text, it should apply regardless of appearance value.

Give it a semantics section statement, and define the shown text of a
drop-down box in terms of it. As that text can depend on the selected
<option> element through the <selectedcontent> element, the width of
the <select>'s labels now needs to account for any <option> element
being selected. Collecting the <button> element's text generalizes
collect option text to any element, as its steps were never
<option>-specific.

Also correct the note following the customizable <select> example:
form submission is prevented by the <button> element not being a
submit button, not by it being inert.

Tests: web-platform-tests/wpt#62674

Fixes #12474.

(See WHATWG Working Mode: Changes for more details.)


/form-elements.html ( diff )
/rendering.html ( diff )

@annevk annevk added the topic: select The <select> element label Sep 14, 2026
The first child `<button>` element of a `<select>` element was only tied
into the rendering of base appearance, through the select button slot.
But as it takes over the function of the `<select>` element's button
text, it should apply regardless of appearance value.

Give it a semantics section statement, and define the shown text of a
drop-down box in terms of it. As that text can depend on the selected
`<option>` element through the `<selectedcontent>` element, the width of
the `<select>`'s labels now needs to account for any `<option>` element
being selected. Collecting the `<button>` element's text generalizes
collect option text to any element, as its steps were never
`<option>`-specific.

Also correct the note following the customizable `<select>` example:
form submission is prevented by the `<button>` element not being a
submit button, not by it being inert.

Tests: web-platform-tests/wpt#62674

Fixes #12474.
@annevk
annevk force-pushed the select-native-appearance-button branch from 23092cb to 6f5cd62 Compare September 14, 2026 14:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

topic: select The <select> element

Development

Successfully merging this pull request may close these issues.

Properly define <select><button> semantics

1 participant