> Please request the various bits in your chromestatus entry, thanks. Done
On Tue, Jan 28, 2025 at 7:17 AM Mike Taylor <miketa...@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) > > Design docs > > 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 appearance > property. 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 > > 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 > > 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: > > 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://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 > > > 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 > > 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 > > 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/CAK6btwKmCOA4tm7N1wEQDVhqKtp0_Sn4DGEO9nu_mLhQDbqD3A%40mail.gmail.com.
