> Do you know (yes, again asking unfair questions) if they have done any
work on the prerequisite features?
Yes, firefox and safari have both shipped popover. Anchor positioning is
proposed for interop 2025.
> A nice use of this feature will still render reasonably well in older
browsers, right?
Yes. Older browsers will still render whatever text the author puts in
their <option> elements in the browser native UI.
On Wed, Jan 29, 2025 at 10:26 AM Daniel Bratell <bratel...@gmail.com> wrote:
> 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.)
> On 2025-01-29 18:48, Joey Arhar wrote:
>
> > 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?
>
> The other browser engine representatives have been consistently
> enthusiastic about solving the problem in this case, and have been quite
> involved in reviewing the design. This is evidenced by the fact that
> they've all agreed that the API is at stage 2 ("Consensus that the rough
> API shape defined in the draft specification is the right approach to solve
> the problem") and have almost agreed to stage 3. Given that, and that there
> is very strong developer demand for this feature, we see no reason why they
> would not implement it soon.
>
> On Wed, Jan 29, 2025 at 8:20 AM Alex Russell <slightly...@chromium.org>
> wrote:
>
>> 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/CAK6btwKqB7C42YyuVscpQt9YxJ147yv4vzaVoVxnuUseyKqM8A%40mail.gmail.com.
