I'm generally supportive of adding showPicker to select elements - it's a handy API for developers and it avoids some JS hacks. I do think we should a) land the spec changes <https://github.com/whatwg/html/pull/9754>, and b) allow some developer test time, before we ship this API. There were some bugs that got discovered while testing input.showPicker, so I'd like to leave some time for those to be found for select. Your chromestatus <https://chromestatus.com/feature/5111537299881984> lists M119 as the target shipping milestone, but the addition of the code <https://chromium-review.googlesource.com/c/chromium/src/+/4875550> landed Sept 29, after the feature freeze for M119. Maybe we should instead target M120 or M121 to ship, at the earliest?
Thanks, Mason On Tuesday, October 3, 2023 at 6:53:59 AM UTC-7 Luke wrote: > > > On Tuesday, 3 October 2023 at 14:43:23 UTC+1 [email protected] wrote: > > On Mon, Oct 2, 2023 at 4:40 AM Luke <[email protected]> wrote: > > Contact emails > [email protected], [email protected] > > Explainer > https://github.com/whatwg/html/pull/9754 > > > Thanks for the explainer! :) > > What's preventing us from landing the PR? > > +Chris Harrelson - Can we mark Chromium as positive for WHATWG purposes? > > I think it's just the needing two supporters, we have Gecko now and I was > told Chrome would require this intent process. WebKit also don't seem > opposed. > > > > Specification > https://whatpr.org/html/9754/input.html#dom-select-showpicker > > Summary > Developers have been asking for a way to programmatically open the option > picker of a select element. See > https://www.google.com/search?q=programmatically+open+select+site%3Astackoverflow.com > > This is currently impossible in almost every browser. Providing > showPicker() gives developers a supported way to do this. Following the > pattern of input.showPicker(). > > > > Blink component > Blink>Forms > > Search tags > showPicker > > TAG review > https://github.com/w3ctag/design-reviews/issues/900 > > > +Aaron Leventhal - Can you take a look at the a11y questions and see that > a) the implementation behavior makes sense from your perspective b) that we > have testing in place to make sure it stays that way. > > Yeah it'd be great if the accessibility aspect could be reviewed (possibly > in the wider context of input.showPicker too?) as for any missing tests I'm > happy to add any that are needed. I think right now it's just the WPT > tests. Wasn't sure how or if it was even possible to test further than > that. > > > TAG review status > Pending > > Risks > > > Interoperability and Compatibility > For interoperability: This feature could end up not being implemented by > all browsers, to mitigate this it's been filed as a HTML spec change with > positions requested early to get everyone on board. > > For compatibility: this feature is specified and designed to give browsers > flexibility in whether they display a picker, or how they display it. > Developers cannot observe either of these. Having said that all browsers > implement pickers for select. > > > > Gecko: No signal ( > https://github.com/mozilla/standards-positions/issues/886) > > > They closed it as "positive" :) > > > Updated the status dashboard entry. > > > > > WebKit: No signal ( > https://github.com/WebKit/standards-positions/issues/258) > > > Am I correct to read Anne's comment as slightly positive, but with some > details left to flesh out? > > Yeah my interpretation is "we're happy to implement provided the spec > allows for iOS's system behaviour" (allowing optional focus of the > input/select when showPicker is called). > > > > > Web developers: No signals > > > You say above that "developers have been asking" for this. Anything we can > point at? > Maybe Chrome devrel folks can help? +Thomas Steiner ? > > https://github.com/whatwg/html/issues/7957 - the original issue that > raised this provides some signal that this would be desired? But if devrel > could get something more concrete that'd be great. > https://twitter.com/quicksave2k/status/1420320560345661440 was used as > the signal for input.showPicker() > > > Other signals: > > Ergonomics > There should be no ergonomic risks with this API. > > > > Activation > This is as simple an API as possible so should be easy for developers to > make use of. It also follows the existing pattern from the HTMLInputElement. > > > > Security > This API can only be used with activation inside of top level or > same-origin frames. This should avoid any potential security issues. It > also follows the existing pattern of HTMLInputElement showPicker() > > > > 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 > No specific DevTools changes are required. This feature is treated like > any other JS method. > > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, Chrome OS, Android, and Android WebView)? > Yes > > Is this feature fully tested by web-platform-tests? > No > > Flag name on chrome://flags > #enable-experimental-web-platform-features > > Finch feature name > HTMLSelectElementShowPicker > > Requires code in //chrome? > False > > Tracking bug > https://bugs.chromium.org/p/chromium/issues/detail?id=1485010 > > Availability expectation > I expect this to be available in all browsers within 12 months of launch > in Chrome. > > Adoption expectation > Feature is considered a best practice for some use case within 12 months > of reaching Web Platform baseline. > > Sample links > > https://select-show-picker.glitch.me > > Estimated milestones > Shipping on desktop 119 > DevTrial on desktop 119 > Shipping on Android 119 > DevTrial on Android 119 > Shipping on WebView 119 > > > Anticipated spec changes > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > > https://github.com/whatwg/html/issues/9757 - The spec (both input and > select) may be updated to allow showPicker to focus a control where > required for implementation. This is not required by blink and thus should > have no impact. > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5111537299881984 > > Links to previous Intent discussions > Intent to prototype: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/521EB459-1D15-44B8-BC84-5F022100BB00%40gmail.com > > This intent message was generated by Chrome Platform Status. > > -- > 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 [email protected]. > > > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE-V8gDmRQCqzrTM%3D8Je4Zin-ViNYoDn1WrUraRZmbobP7Rn3w%40mail.gmail.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE-V8gDmRQCqzrTM%3D8Je4Zin-ViNYoDn1WrUraRZmbobP7Rn3w%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b060cc27-a86d-4045-93d6-7bb7fd6f8f1cn%40chromium.org.
