jar...@chromium.org, mas...@chromium.org, dan...@microsoft.com
https://open-ui.org/components/select
https://github.com/whatwg/html/issues/9799 (see sub-PRs linked there)
https://open-ui.org/components/select
Customizable <select> allows developers to take complete control of the rendering of <select>, including the ability to fully customize both the in-page “button” element as well as the popup picker, with arbitrary content within options. Developers can opt in to this new behavior with a simple CSS declaration that uses a new `base-select` value for the `appearance` property.
This new capability has been in development for a very long time, starting in late 2019 in earnest (with the original explainer from June 2020). Due to that early work, two other platform APIs were identified as prerequisites for customizable-<select>: the popover API and anchor positioning. Now, with both of those APIs landed in standards and browsers, the customizable-<select> is unblocked.
Once the customizable-<select> feature began to get discussed in standards (at OpenUI in 2020, and in WHATWG and CSSWG in mid-2023), it rapidly evolved. Not only did the names of the elements change (<selectmenu>, <selectlist>, then <select>, etc.) but the shape of the API changed considerably. It evolved from a very shadow-DOM centric API using things like the slot attribute to a more HTML-like API using new elements such as the <selectedcontent> element. The WHATWG/CSSWG/OpenUI joint task force worked through the question of how to opt-in to the new behavior, selecting among a new element, an HTML attribute, a CSS property, or something else, and arrived at a consensus of using the CSS appearance property. Many discussions were had (e.g. in OpenUI and WHATWG) about the content model and the allowed set of controls, to ensure the new control is accessible and rational, while still providing a very flexible, powerful API to developers. Overall, the standards process shaped this API into something that follows platform conventions, has natural naming and methods to achieve goals, and builds naturally upon recently added features such as popover, anchor positioning, interactivity:inert, and many others. In addition, the construction of the customizable-<select> API has been a huge catalyst to find other missing platform features and quirks, such as corner cases in the popover API.
Throughout this process, we’ve worked hard to reach out to the developer community, to ensure all common use cases are supported, there aren’t lingering compat issues, and the new customizable-<select> control is as accessible as possible. In some cases, e.g. the necessary changes to the HTML parser to allow arbitrary content, there is still some compat risk. We are working hard to increase our confidence that we can ship those changes via (separate) Finch testing and rollout. However, at this point, we are confident that we have reached a stable API shape with a low level of risk.
Blink>Forms>Select
select, custom select, controls, form controls, custom controls, custom form controls
https://github.com/w3ctag/design-reviews/issues/1007
Issues resolved
Interop risk is low because we have been designing this feature closely with Apple and Mozilla during the standardization process over the last 15 months.
Changing the HTML parser for <select> elements is a prerequisite for this change and has some compat risks, which had a separate intent here: https://groups.google.com/a/chromium.org/g/blink-dev/c/5_9-Qkvlj2M/m/Q96A126vAAAJ
Gecko: No signal
https://github.com/mozilla/standards-positions/issues/1060
WebKit: No signal
https://github.com/WebKit/standards-positions/issues/386
Web developers: Very strongly positive
https://2024.stateofhtml.com/en-US/features/#reading_list
Other signals:
None in particular.
Clear documentation will be required to help developers understand the opt in and how to style and replace various parts of the new select element. We already have some documentation here but will create another blog post for launching the feature:
The picker for customizable select does not extend outside of the web contents like an appearance:auto select does, so there should not be any new capabilities exposed which would have security considerations.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
The customizable select should already be fairly debuggable via existing DevTools features. The new select does add a few new pseudo-elements, which have been added to DevTools.
Yes
Yes
https://wpt.fyi/results/html/semantics/forms/the-select-element/customizable-select
None
CustomizableSelect
None
False
134
Customizable select is currently in stage 2 in WHATWG. We have had spec PRs open for review since August of last year, and we have been repeatedly asking for reviews and feedback at WHATNOT meetings. However, we have not received stage 3 approval yet, which means that the other implementers have not yet signed off on the final design. These are the only remaining open issues that have been raised, and we don’t anticipate any significant changes based on the resolutions of these:
https://chromestatus.com/feature/5737365999976448
This intent message was generated by Chrome Platform Status.
Please request the various bits in your chromestatus entry, thanks.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2BX5UTWoDCGNUCpEUHYh%2BhgddTgOerGHugFnBGbQnb-Rg%40mail.gmail.com.
On 1/28/25 11:03 AM, Joey Arhar wrote:
> Please request the various bits in your chromestatus entry, thanks.
Thanks, Joey.Done
On Tue, Jan 28, 2025 at 7:17 AM Mike Taylor <mike...@chromium.org> wrote:
Please request the various bits in your chromestatus entry, thanks.
On 1/24/25 1:20 PM, Joey Arhar wrote:
Contact emails
jar...@chromium.org, mas...@chromium.org, dan...@microsoft.com
Explainer
https://open-ui.org/components/select
Specification
https://github.com/whatwg/html/issues/9799 (see sub-PRs linked there)
I think this is a very exciting improvement to the web platform so thanks for all the work! That said, I would want to know more about the interoperability picture. Both Mozilla and WebKit have been scarily passive on their standard position issues, even if they have excited engineers working on the spec. When could a web developer expect this to work all across the web?
/Daniel
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Yes, I understand that it's not really fair to ask you about what other browser vendors will do, because they are they. I had kind of hoped for something like "they have an implementation behind a flag and should be right behind us", but I guess that is not the case.
Do you know (yes, again asking unfair questions) if they have done any work on the prerequisite features?
At least, if they have participated in the creation process it
should not be something they can't implement, because as Alex
says, once this ships, changes would be painful and maybe
impossible. A nice use of this feature will still render
reasonably well in older browsers, right?
/Daniel
(I tried to figure out when the <select> element was added
to the web. 1995 or earlier it seems, so that is basically how
long people have wanted more power over it.)
LGTM2
Good luck with the launch! I hope the others follow quickly. (No
official signals from them but they have had plenty of time and
opportunities to object and with your answers I'm confident that
this can become interoperable)
/Daniel
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/50897926-6846-4dc5-a91e-108f353d25eb%40gmail.com.