I'm an enthusiastic LGTM1 on this; thank you so much for pushing this forward.
As part of my vote here, I want to explicitly set the marker that when this ships, incompatible changes will be looked at with extreme skepticism. This is our usual *modus operandi* when we approve an I2S, but given how far ahead we are here, I want to reiterate that this is pouring the concrete, and we won't green-light incompatible changes, no matter how convinced folks at WHATWG are late in the game. Best, Alex On Wednesday, January 29, 2025 at 7:57:43 AM UTC-8 Daniel Bratell wrote: > 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 > On 2025-01-28 17:55, Joey Arhar wrote: > > > There's an impressive amount of related spec work here, and not all of > it landed. How should we think about this? Is everything on track to land, > or are some issues/PRs non-blockers to the feature? > > Yes they're on track to land once editorial review has completed, and no > blocking concerns have been raised other than the two mentioned in the > "Anticipated spec changes" section of the intent to ship. It's possible > other vendors will raise new concerns but we haven't heard any. > > > How should we think about the tests that we are failing? > > Some of the tests are flaky, as you can see since some are passing in Edge > (Windows) but not Chrome (Linux) or vice-versa. There are some open bugs > about the flakiness that we are working on, but it's important to note that > the feature itself works correctly. > > On Tue, Jan 28, 2025 at 8:36 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> On 1/28/25 11:03 AM, Joey Arhar wrote: >> >> > Please request the various bits in your chromestatus entry, thanks. >> >> Done >> >> Thanks, Joey. >> >> >> 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) >>> >>> There's an impressive amount of related spec work here, and not all of >> it landed. How should we think about this? Is everything on track to land, >> or are some issues/PRs non-blockers to the feature? >> >> 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 >>> >>> How should we think about the tests that we are failing? >> >> >>> 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/CAK6btw%2BnT5aX9dncP%2BQ2gUDzYKpYsD2ZJUCQXHAJJnrLR8WHsA%40mail.gmail.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2BnT5aX9dncP%2BQ2gUDzYKpYsD2ZJUCQXHAJJnrLR8WHsA%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/366a2bc8-7cd3-45dc-9345-1008c69f3706n%40chromium.org.
