Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add appearance:base-select to select explainer #1050

Merged
merged 3 commits into from
Apr 30, 2024
Merged

Add appearance:base-select to select explainer #1050

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
f35ab44
Add appearance:base-select to select explainer
josepharhar Apr 30, 2024
959c913
Merge remote-tracking branch 'upstream/main' into appearance
josepharhar Apr 30, 2024
73a6e7d
fix table of contents
josepharhar Apr 30, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 17 additions & 4 deletions site/src/pages/components/selectlist.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,9 +40,7 @@ The [2020 MDN browser compatibility report had feedback](https://mdn.dev/archive

## Opting in to the new behavior

The `<select>` element will continue to behave as it currently does unless a `<button>` or `<datalist>` element is provided as a child of the `<select>`. `<button>` elements replace the native button which opens the listbox, and `<datalist>` replaces popup listbox. By replacing the native components with regular web content, the contents are fully stylable and customizable.

The current behavior in the HTML parser for `<select>` is to remove all tags which aren't `<option>` or `<optgroup>`. We will change the HTML parser to allow `<datalist>` and `<button>` as a child of `<select>`, and allow any other content within that `<datalist>` or `<button>`.
The `<select>` element will continue to behave as it currently does unless it has the `appearance:base-select` CSS property. Previously proposed opt-ins included a new tag name, an additional HTML attribute, and the presence of a child `<button>` or `<datalist>`.

Here is a basic `<select>` element today:
```html
Expand All @@ -54,7 +52,19 @@ Here is a basic `<select>` element today:

And here the same `<select>` with opt ins to the new stylability behavior which this explainer proposes:
```html
<select>
<select style="appearance:base-select">
<option>one</option>
<option>two</option>
</select>
```

## HTML parser changes

The current behavior in the HTML parser for `<select>` is to remove all tags which aren't `<option>` or `<optgroup>`. We will change the HTML parser to allow `<datalist>` and `<button>` as a child of `<select>`, and allow any other content within that `<datalist>` or `<button>`. The `<button>` allows authors to replace the in-page button which opens the popup, and the `<datalist>` allows authors to replace the popup element containing the options.

Here is a basic example which uses the parser changes:
```html
<select style="appearance:base-select">
<button>
<selectedoption></selectedoption>
</button>
Expand Down Expand Up @@ -534,3 +544,6 @@ The HTML parser will not allow `<button>` or `<datalist>` children when the `mul
- [Why not make selection follow focus](https://github.com/openui/open-ui/issues/742)
- [Why not allow select or datalist in size/multiple select](https://github.com/openui/open-ui/issues/977#issuecomment-1910874971)
- [Why `<button type=popover>`](https://github.com/openui/open-ui/issues/939#issuecomment-1910837275)
- Why opt-in with CSS
- https://github.com/whatwg/html/issues/9799#issuecomment-1789202391
- https://github.com/whatwg/html/issues/9799#issuecomment-1926411811