- From: Joey Arhar <notifications@github.com>
- Date: Thu, 22 Oct 2026 16:35:50 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1264/6353684699@github.com>
josepharhar left a comment (w3ctag/design-reviews#1264)
Thanks for the review!
> Do you know how current usage of `<input>`-inside-`<select>` parsing rules compares to historical dependence on the `<button>`-inside-`<select>` parsing rules at the time that change was made? If the usage numbers are comparable or lower for `<input>`-inside-`<select>` then this may still be feasible in terms of web compat. Progressive enhancement remains a problem though unless all browser implementations can align in shipping this change.
I didn't look at `<button>` in `<select>` in particular, I don't remember that having special parsing rules like `<input>` and `<textarea>` do.
I added some use counters for parsing `<input>` in `<select>`, and this one contains many websites which I manually confirmed would be broken by changing the parser to simply allow `<input>` in `<select>`: [https://chromestatus.com/metrics/feature/timeline/popularity/5546](https://chromestatus.com/metrics/feature/timeline/popularity/5546)
<details>
<summary>Long aside about another idea to make nesting input in select work:</summary>
Mason had a good idea of only allowing `<input>` in `<select>` if the select element hasn't parsed any option elements yet, which would avoid breaking most sites since the ones relying on this generally put options before the input. Use counter for that [here](https://chromestatus.com/metrics/feature/timeline/popularity/5894). Unfortunately, this isn't perfect either.
As a progressive enhancement strategy, sites might actually want to put `<input>` after all the `<option>`s though in order to prevent the option elements from getting dumped out after the end of the select on older browsers. Here's a demonstration of how the parser works today:
<table>
<thead>
<tr>
<th></th>
<th>HTML from server:</th>
<th>Parsed DOM today <br>(unsupporting browser)</th>
</tr>
</thead>
<tbody>
<tr>
<td>Naive HTML</td>
<td>
<pre><code><select>
<input>
<option>one</option>
<option>two</option>
</select></code></pre>
</td>
<td>
<pre><code><select></select>
<input>
<option>one</option>
<option>two</option></code></pre>
</td>
</tr>
<tr>
<td>Defensive HTML <br>for progressive enhancement</td>
<td>
<pre><code><select>
<option>one</option>
<option>two</option>
<input>
</select></code></pre>
</td>
<td>
<pre><code><select>
<option>one</option>
<option>two</option>
</select>
<input></code></pre>
</td>
</tr>
</tbody>
</table>
As you can see, the "defensive" approach which puts the input tag at the end still gets its options inside the select element. With some CSS to hide the input element, you'd still have a working select element, it just wouldn't have the filtering input. We could have custom slotting code to make sure that this input element gets slotted into the correct spot regardless of where it shows up inside the select.
However, if we went with the idea of only allowing the parser to nest input in select when it comes before the options for compat reasons, it would break this progressive enhancement. I get that progressive enhancement is probably not what most people want compared to a polyfill, but customizable select (and therefore filterable select) is already not very polyfillable due to the HTML parser changes, so progressive enhancement for all this select related stuff is my best advice for authors.
</details>
> Assuming B remains a non-starter for those reasons, we'd support an approach like the one proposed [here](https://github.com/whatwg/html/issues/12050#issuecomment-5441690356), where `<select>` gets a `filterable` attribute as described in Option C that would make the common case easy, and something like Option A is pursued later if there is still demand for flexibility beyond what C can achieve. The internal `<input>` would need to be styleable through a pseudo element. It's unfortunate though if a lot of properties specific to filtering would need to be added to `HTMLSelectElement` to support this, especially if they'd be redundant with properties eventually added to HTMLInputElement for Approach A or for [Combobox](https://open-ui.org/components/combobox.explainer/). From the discussion in [openui/open-ui#1491](https://github.com/openui/open-ui/issues/1491) it looks like only a few properties would be needed, but if that list grows this approach should probably be reconsidered in favor of Option A.
Thanks! Agreed, and hopefully more developer testing should make it clear how much we need to expose.
> The [proposed UA stylesheet](https://open-ui.org/components/filterable-select.explainer/#css-reactive-rendering-filtered) has `option:filtered` given `display: none !important`, but the `!important` seems overly constraining. What if a developer wants to have filtered options grayed-out or crossed-off instead of disappeared (although devs would need to be careful to exlude such options from the a11y tree and from focus order)? It'd be good to ensure that animations between filtered and non-filtered states also work well.
Thanks, I am going to remove the !important here: https://github.com/openui/open-ui/pull/1536
> * The explainer mentions the `search` attribute a couple times in passing but it isn't really defined in this document. We assume this is referring to https://open-ui.org/components/combobox.explainer/#the-search-attribute -- if so it'd be good to link that directly, or inline an explanation into this explainer.
> * We assume `<select multiple>` is in scope here since the GitHub label picker example is a multi-select. It would be good to have the explainer confirm this, and to ensure the accessibility implications with `<select multiple>` are also being considered (as was at least briefly discussed in [Filtering a listbox with a text field (filterable select) w3c/aria#2841](https://github.com/w3c/aria/issues/2841)).
Thanks, I am addressing these here: https://github.com/openui/open-ui/pull/1537
> * For option A, is "sibling" a hard requirement or can the `<input>` and `<select>` (and `<selectedcontent>`) be in different places in the DOM? It may be best not to be too strict on this requirement to allow for different DOM structures. For full composability, it could be desirable to have these be linkable across shadow DOM. Reference Target could forward the `filter` ID into a shadow root. Consider adding a corresponding reflecting IDL attribute like `input.filterElement`, which would allow the filter `<input>` to connect to a `<select>` in a parent shadow.
Sibling is not a hard requirement at all, I just found the word "sibling" to be useful when describing how to use it. The prototype should work totally fine without them literally being siblings in the DOM.
> * If Option A is selected, the attribute name `filter` may be worth bikeshedding. The current name sort of reverses the intended semantics: `<input filter=foo>` could be read like the thing with ID `foo` is the filter for the input, but what we want to express is the other way around where the `<input>` is the filter for the `<select>` foo. `<input filters=foo>` could work better since it reads like "this input filters the element with ID foo", but maybe the `s` could be confused for a pluralization. Maybe `filterfor`?
Thanks, I filed an issue to discuss this: https://github.com/openui/open-ui/issues/1538
--
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1264#issuecomment-6353684699
You are receiving this because you are subscribed to this thread.
Message ID: <w3ctag/design-reviews/issues/1264/6353684699@github.com>
Received on Thursday, 22 October 2026 23:35:55 UTC