LGTM3
On Thu, Jan 30, 2025 at 10:08 AM Daniel Bratell <bratel...@gmail.com> wrote:
> 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
> On 2025-01-29 22:38, Joey Arhar wrote:
>
> > 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/50897926-6846-4dc5-a91e-108f353d25eb%40gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/50897926-6846-4dc5-a91e-108f353d25eb%40gmail.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/CADsXd2Mx8e_S6rFLX%2B6V7sE1eFqCgCBtxVj4UCtCipiwg1xEiQ%40mail.gmail.com.
