Repository navigation
Customizable <select> element #9799
Description
This proposal includes parser, styling, and rendering changes to make the <select> element fully customizable by authors.
Explainer: https://open-ui.org/components/customizableselect
Spec PR: #10548
Spec PRs (old):
- Relax
<select>parser #10557 - Update content model for customizable select #10586
- Define base appearance for <select> #10629
- Define the
<selectedcontent>element #10633 - Add UA stylesheet for <select> base appearance #10670
CSS spec PRs:
- [css-ui-4] Define appearance:base w3c/csswg-drafts#10691
- [css-pseudo-4] Define ::picker() w3c/csswg-drafts#10865
- [css-pseudo-4] Fix grammar for ::picker w3c/csswg-drafts#10936
- [css-forms-1] Add new pseudo-elements for customizable select w3c/csswg-drafts#10986
Accessibility PRs:
- Update: add mapping tables for customizable select w3c/aria#2369
- [html-aam] Addition: selectedcontent element w3c/aria#2344
- Add
selectedcontentelement and allowances for 'button' part of select w3c/html-aria#528 - Update: legend to provide name to optgroup w3c/aria#2360
Related HTML issues:
- Timing of cloning for the
<selectedoption>element #10520 - Should datalist, option, object, and/or iframe elements be listed in "interactive content"? #10755
- How to spec user interaction for select #10762
- Is it ok for
appearance:base<select>not to require user activation beforeshowPicker()? #10604 - Selection in form control elements, user-select, and customizable select #10876
- Content model and 'what' to render for stylable
<select>elements #10317 - HTML parser changes for customizable
<select>#10310
Related CSS issues:
- [css-ui] Changing UA styles based on the computed value of the appearance property w3c/csswg-drafts#10028
- How to implement and shape API for
<selectedoption>element for<select>w3c/csswg-drafts#10242 - [css-ui] New value(s) for the appearance property to support
<select>stylability w3c/csswg-drafts#10333 - [css-ui] DOM/Box structure for appearance:base-select w3c/csswg-drafts#10380
- [css-ui] Pseudo-elements for stylable select w3c/csswg-drafts#10462
- [css-ui] Pseudo-element for select's UA button w3c/csswg-drafts#10717
- [css-ui] Pseudo-element for select's UA popover w3c/csswg-drafts#10758
- [css-forms-1] Should
::picker(select)match:popover-open? w3c/csswg-drafts#10775 - [css-ui] UA stylesheet for appearance:base
<select>w3c/csswg-drafts#10857 - [css-ui] Pseudo-elements for checkmark and dropdown icon for appearance:base
<select>w3c/csswg-drafts#10908 - [css-ui] Colors to use for appearance:base
<select>w3c/csswg-drafts#10909 - [selectors-4] Should we have :open and :closed? w3c/csswg-drafts#11039
- [css-ui] select:hover and select:active styles w3c/csswg-drafts#11185
Standards positions:
Reacted by Scott O'Hara, Tomasz Jakut, Raura, JAWS-test, Luke Warlow, Adam Argyle, AndrewKGuan, Brecht De Ruyte, Lukáš Moravec, Wesley Luyten and 98 more
Reacted by Clint, Anthony Alaribe, Geoffrey B. Eisenbarth, Arturo Iván Artaza, Vlad Gerasimov, Vinicius, Oliver Williams, Schalk Neethling, Denis Lukianenko, Arif and 17 more
Reacted by Andrew and Sonny Darvish
Activity
zcorpan commentedon Sep 27, 2023
@whatwg/forms
rohankaushal123 commentedon Oct 18, 2023
annevk commentedon Oct 19, 2023
Thank you for bringing this proposal to the WHATWG Joey! I thought this would be a good opportunity to outline how colleagues and I feel about extending HTML in this area. In particular, we feel that new and existing form controls:
We understand that the
selectelement can’t address a variety of scenarios due to parser limitations, but theselectelement could address them in combination with thedatalistelement. One of our big worries with complete duplication is that we end up not solving the problems with the existing controls and that the duplicated controls will have a variety of shortcomings the older controls did not have.(Aside: #5791 seems very related to this issue.)
hsivonen commentedon Oct 23, 2023
I think the explainer doesn't explain the need for a new element in a convincing way, because the multiple examples look addressable in the context of
select: flags are addressable by emoji instead of image files, subheadings by thelabelattribute ofoptgroup, and color and font-level styling seems feasible without a new element.(From off-explainer examples, I gather that the ambition level of the feature is much higher than the explainer makes appear.)
josepharhar commentedon Oct 27, 2023
Thanks for taking a look and discussing with colleagues Anne!
If we made appearance:none or a new appearance value like appearance:base as discussed here and here have a standardized style, then the default appearance:auto appearance could look the same as OS controls. That would be up to each UA to decide, as it is currently for all other form controls.
Agreed! Styleability is the primary driving use case for the current proposal.
Agreed! Domenic left some feedback in this vein and we completely revamped the proposal to use existing HTML element patterns by using new tag names instead of slot and behavior attributes.
Agreed! Existing elements conform to this by letting the browser/OS provide a native picker which unfortunately can’t be styled or customized by web developers, right? It was recommended that we let the browser use native pickers for selectlist on mobile here. Ideally developers would be enabled to make their own pickers that work on these platforms when they want to as well.
Agreed! This is also a core requirement for the proposal. I have been working closely with accessibility experts participating in OpenUI to ensure that the accessibility mappings and keyboard behaviors follow the current best practices in ARIA.
Agreed! The content is fully customizable/replaceable, so it should be localizable and internationalizable, right? The only thing I can think of is supporting right-to-left and vertical writing modes when rendering where the listbox popup goes, which is something we are doing for other form control elements and we can easily do via Anchor Positioning for selectlist. Is there anything else you had in mind here?
It sounds like yall would prefer to reuse the existing
<select>element instead of creating a new tag name. Am I correct? As you mentioned, we can’t have the new content model exist inside the<select>element due to parser rules, but we could try to do something with how datalist works by adding attributes to<select>which refer to the other elements we want to use, which would perhaps look like<select list=my-listbox button=my-button>. However, I don’t think this would work well. This works for<input list=datalist>because datalists are just used to host text data without doing actual rendering. Since we are actually trying to render an authored<listbox>or<button>element inside the select/selectlist, we don’t have the machinery in the browser to render them from an arbitrary location in the DOM. ShadowDOM is perfect for this and is how existing builtin elements like details and summary work. It is also easier and more idiomatic (like<option>and<summary>) for the new listbox and button elements to know when they should have special behavior for selectlist because they can look at their parent context rather than having to keep track of which select element has an attribute pointing at them. A preview of the State of HTML survey I’ve seen also lists<datalist>as a top developer pain point, which perhaps alludes that the ergonomics of referring to a separate element aren’t great.I agree that duplication should be avoided. Selectlist is not a complete duplicate of select.
<select>can draw outside the bounds of the browser window, and<selectlist>has a completely different rendering model that allows full customization. If it were possible to shoehorn into<select>that would be nice, but it looks infeasible.josepharhar commentedon Oct 30, 2023
Thanks for the feedback! I am improving the examples here: openui/open-ui#918
lukewarlow commentedon Oct 30, 2023
I just wanted to point out Windows doesn't provide flag emojis so this specific example is a good use case for needing images not emoji.
annevk commentedon Nov 1, 2023
If you use
appearance:nonethey can usually be styled. And we should do more work here to add something akin toappearance:baseto make that more ergonomic for web developers. I don't think the solution should be adding new elements that don't have platform theming by default as that would make the HTML language inconsistent.For
<datalist id=options>we'd have to clone the options into theselectelement's shadow tree for rendering purposes, I think, much in the same way we probably have to clone one of the options as the selected option. As long as this happens in the internal shadow tree it's largely not observable and should be okay.It would also have the benefit of having a consistent design with
<input type=text list=options>, so we'd tackle combo boxes at the same time (or at least make it possible to reuse the design for them). Since the<datalist>continues to mainly serve as a source of data I don't think there's any need to track what element is pointing to it.(There are some challenges here with how to match these options and their elements from CSS, but that seems like a surmountable problem.)
I haven't looked at survey in detail, but I'd assume that if
<datalist>is mentioned as a pain point it would mainly be around not being able to style it, which is something we'd have to tackle for combo boxes and select alike.josepharhar commentedon Dec 1, 2023
I’ve been discussing with @annevk and @pxlcoder about how to move forward here, and we have reached agreement on some things. Please correct if I misrepresent anything!
<select>element will work<select>to allow particular new child tags like<button>and<datalist><datalist>as a child of<select>will work to replace the listbox with custom contentlukewarlow commentedon Dec 1, 2023
I'm concerned by the implications of the multiple attribute. How does it work with the new parsing?
That being said I am excited by the progressive enhancement possibilities.
gregwhitworth commentedon Dec 1, 2023
@annevk The majority you cannot and it isn't solely about styling but also extending them. While
selectmay be able to be re-used; one of the benefits of introducing the new elements that are interoperable by default and not OS platform styled does make the platform consistent rather than trying to retro-fit all the build-in UI controls. I think we may want to fork this into a more generic issue specific to the introduction of new elements as I'm curious how your assertion holds up forinput type=switchthat not only allows styling but extensibility without a new element;type=file,type=progress, etc?@josepharhar @annevk so will this likewise have the child of
<selectedoption>and ability to modify the initial shadow DOM?91 remaining items
dgrammatiko commentedon Feb 7, 2025
@josepharhar thanks, it makes sense if the browser parser will ignore any of the new relaxed allowed elements.
starball5 commentedon Mar 27, 2025
trans commentedon Apr 17, 2025
I would like to contribute my thoughts to this endeavor. I haven't been exactly sure how to go about that. So initially I wrote up a small blog post, but found no good way to share it (I had nothing but problems trying to get on matrix chat). Then I found this issue, and decided I'd just try sharing it here.
The post is not long, but for a super quick overview, I am suggesting the following:
<options>container element, instead of using a pseudo-selector (picker(select)).<selection>instead of<selectedcontent>.(If this would be better vetted elsewhere, please let me know. I don't have a lot of time to spare but am willing to do what I can.)
josepharhar commentedon Apr 17, 2025
We sort of had this before as a datalist element, but we decided to remove that here: openui/open-ui#1082
<selection>was one of the proposed options when we named<selectedcontent>here: openui/open-ui#1112You can already make customizable select appear like a modal by applying styles to
::picker(select)like this: https://codepen.io/jarhar/pen/NPPPrgxSince its all in CSS, this has the added benefit of being able to change this based on media queries.
Not sure I completely understand, but if you don't want the user to change the value then you can use the disabled attribute on the select element. If you want an option to be selected by default, then you can set the selected attribute on it. Neither of these things are new with customizable select.
JoeMurray commentedon Apr 24, 2025
tl;dr If this progresses normally, what is the likely timeline for it to be generally supported by major browsers?
An open source project I am involved with (CiviCRM) is looking for good accessible alternatives to the select2 widget that failed to be accepted into the WordPress Gutenberg editor about 6 years ago due to pushback from a11y advocates. There don't seem to be any but this initiative would be ideal. However, some of us are thinking that waiting for it is likely over-optimistic on our part. Does it stand a good chance of seeing the light of day including being implemented by all major browsers in the next few years? Hard to guess, I know, but we aren't knowledgeable about how to assess things so far upstream from our work. TIA.
trans commentedon Apr 25, 2025
Well that's unfortunate -- seems datalist is getting axed across the board. From what I read the option container is now just a div (with a popover attribute).
That's what really bothers me about this, it creates a ghost div that has no explicit representation in the HTML. Notice @mfreed7 asked if we would still be able to wrap the option elements in a
divin the HTML, and the answer was "yes". But I tried it on Chrome and it doesn't behave as one would expect because there is this other shadowy div in there wrapping around it. If this div is going to be in there it should be explicit -- if the HTML doesn't have it, it gets added (like e.g. tbody, etc.)So the issue is it is too reminiscent of the text selection pseudo-selector, is that it? Shrug Minor issue anyway.
I was thinking about this and I am not sure how useful
<selectedcontent>will be. What scenario is common that would need this?If I understand it correctly, it can also be emulated by putting content outside the select and styling it look like a select. With a little CSS adjustment it would look pretty much the same. Only thing that might not be easy is exact positioning (popover oddness there) and the placement of the dropdown marker icon (but I'd imagine for such uses the marker will get hidden anyway). Note, I tried it in Chrome for comparison and
selectedcontentdoesn't seem to be working -- it winds up the options div? (https://codepen.io/Thomas-Sawyer-the-looper/pen/ZYYyXjd)To me, what would be much more useful is a way for options to have longer descriptions, but only a short version ends up on the select button. E.g. consider a list of states where you want the the select button to have just the two letter abbreviation but the options to also have the full name, like
<option>FL - Florida</option>. How can you get just "FL" to appear on the select button?That's a good point! You are right I updated my post to retract the "attachment" being based on HTML structure. I still think there option elements container needs to have an explicit manifestation in the HTML though.
I'll try the disabled attribute and see how that works. Thanks. As for the selected attribute, that's actually what I don't want to have to do -- rather, if the
valueof select and thevalueof option match I want the selected attribute to be automatic -- it would simply template loops that build select elements.Define customizable <select>
Bug 1869673 [wpt PR 43640] - Allow <button> and <datalist> in <select…
wpt: exclude selectedcontent-multiple-restore.optional.html from the …