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 <mailto:jar...@chromium.org>, mas...@chromium.org,
dan...@microsoft.com
Explainer
https://open-ui.org/components/select
<https://open-ui.org/components/select>
Specification
https://github.com/whatwg/html/issues/9799
<https://github.com/whatwg/html/issues/9799>(see sub-PRs linked there)
Design docs
https://open-ui.org/components/select
<https://open-ui.org/components/select>
Summary
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 <https://www.youtube.com/watch?v=ZFvPLrKZywA>in
earnest (with the original explainer
<https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ControlUICustomization/explainer.md>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
<https://github.com/openui/open-ui/issues?q=is%3Aissue%20label%3Aselect%20sort%3Acreated-asc>,
and in WHATWG <https://github.com/whatwg/html/issues/9799>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 appearanceproperty. Many discussions were
had (e.g. in OpenUI <https://github.com/openui/open-ui/issues/540>and
WHATWG <https://github.com/whatwg/html/issues/10317>) 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
<https://github.com/whatwg/html/pull/10770>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 <https://chromestatus.com/feature/5145948356083712>) 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 component
Blink>Forms>Select
Search tags
select <https://chromestatus.com/features#tags:select>, custom select
<https://chromestatus.com/features#tags:custom%20select>, controls
<https://chromestatus.com/features#tags:controls>, form controls
<https://chromestatus.com/features#tags:form%20controls>, custom
controls <https://chromestatus.com/features#tags:custom%20controls>,
custom form controls
<https://chromestatus.com/features#tags:custom%20form%20controls>
TAG review
https://github.com/w3ctag/design-reviews/issues/1007
<https://github.com/w3ctag/design-reviews/issues/1007>
TAG review status
Issues resolved
Risks
Interoperability and Compatibility
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
<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
<https://github.com/mozilla/standards-positions/issues/1060>
WebKit: No signal
https://github.com/WebKit/standards-positions/issues/386
<https://github.com/WebKit/standards-positions/issues/386>
Web developers: Very strongly positive
https://2024.stateofhtml.com/en-US/features/#reading_list
<https://2024.stateofhtml.com/en-US/features/#reading_list>
Other signals:
Ergonomics
None in particular.
Activation
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:
*
https://developer.chrome.com/blog/rfc-customizable-select
<https://developer.chrome.com/blog/rfc-customizable-select>
*
https://una.im/select-updates/ <https://una.im/select-updates/>
Security
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.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such
that it has potentially high risk for Android WebView-based applications?
None
Debuggability
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.
Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes
https://wpt.fyi/results/html/semantics/forms/the-select-element/customizable-select
<https://wpt.fyi/results/html/semantics/forms/the-select-element/customizable-select>
Flag name on about://flags
None
Finch feature name
CustomizableSelect
Non-finch justification
None
Requires code in //chrome?
False
Tracking bug
https://crbug.com/40146374 <https://crbug.com/40146374>
Estimated milestones
134
Anticipated spec changes
Customizable select is currently in stage 2
<https://whatwg.org/stages#stage2>in WHATWG. We have had spec PRs open
for review since August of last year
<https://github.com/whatwg/html/pull/10548>, and we have been
repeatedly asking for reviews and feedback at WHATNOT meetings.
However, we have not received stage 3
<https://whatwg.org/stages#stage3>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:
*
Should alt text be included in select.value?
<https://github.com/whatwg/html/issues/10317>
*
How should we write about user interactions and events in the
spec? <https://github.com/whatwg/html/issues/10762>
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5737365999976448
<https://chromestatus.com/feature/5737365999976448>
This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>.
--
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+unsubscr...@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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2BX5UTWoDCGNUCpEUHYh%2BhgddTgOerGHugFnBGbQnb-Rg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/442f9883-b8a2-4fd9-93fe-c1de04440651%40chromium.org.
