Thanks! And as Luke pointed out, https://developer.mozilla.org/en-US/docs/Web/API/HTMLSelectElement/showPicker#browser_compatibility does have the availability data.
On Mon, Nov 11, 2024 at 10:12 AM Daniel Clark <dan...@microsoft.com> wrote: > Looks like it did ship in 121: > https://chromiumdash.appspot.com/commit/6e668e2c8904dc8c2b4d8837afe2459d00991c56 > > Works for me in Chrome Stable: https://almond-noble-kick.glitch.me/ > > And the spec PR that was in question did end up merging: > https://github.com/whatwg/html/pull/9754 > > > > -- Dan > > > > *From:* Jeffrey Yasskin <jyass...@chromium.org> > *Sent:* Monday, November 11, 2024 9:55 AM > *To:* Luke <lukewarlow...@gmail.com> > *Cc:* blink-dev <blink-dev@chromium.org>; yoav...@chromium.org < > yoavwe...@chromium.org>; mike...@chromium.org <miketa...@chromium.org>; > tste...@google.com <tstei...@google.com>; Chris Harrelson < > chris...@chromium.org>; aleventhal <alevent...@google.com>; Daniel > Bratell <bratel...@gmail.com>; mas...@chromium.org <mas...@chromium.org> > *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Ship: HTMLSelectElement > showPicker() > > > > Did this wind up shipping? It still says 121 on Chromestatus, but I don't > see it on https://caniuse.com/?search=showPicker, and the TAG is > wondering what to do about > https://github.com/w3ctag/design-reviews/issues/900. > > > > Thanks, > > Jeffrey > > > > On Sat, Nov 4, 2023 at 5:08 AM Luke <lukewarlow...@gmail.com> wrote: > > Unfortunately there is an ongoing discussion about the behavior in > uncomposed documents and even concerns with the previous `<input>` > showPicker method being inconsistent across engines which is sadly holding > up the PR being merged. I don't believe there's anything within my power to > help move that along (aside from doing some of the showPicker > implementations inside of WebKit). > > I'll wait until the 121 feature freeze but if nothing moves until then > I'll remove the target shipping milestone from chromestatus. > > On Monday, 23 October 2023 at 22:31:57 UTC+1 Luke wrote: > > Just as an fyi I'm still waiting on the HTML PR to get merged. Don't think > there's any blockers. Will update this thread if I end up missing the > release window for 121. > > On Wednesday, 11 October 2023 at 15:37:44 UTC+1 yoav...@chromium.org > wrote: > > LGTM3 once the PR lands :) > > On Wednesday, October 11, 2023 at 4:06:35 PM UTC+2 Mike Taylor wrote: > > LGTM2, same condition. > > On 10/11/23 7:16 AM, Daniel Bratell wrote: > > LGTM1 (dependent on the PR landing) > > Looks like the spec text is more or less complete with no remaining > possible showstoppers. I do find it both amusing and a bit Kafkaesque that > the web community seems to have a process where the spec waits for > implementers and implementers (at least us) wait for the spec. In this case > it was a small and positive change so it was no issue but it could be for > larger changes. > > (Security review not completed in chromestatus but since this is a clone > of the other showPicker(), I find it unlikely that it uncovers some problem) > > /Daniel > > On 2023-10-04 17:34, Mason Freed wrote: > > On Tuesday, October 3, 2023 at 9:47:02 AM UTC-7 Luke wrote: > > That makes perfect sense. For now I've removed the target milestones all > together (they were rather arbitrary). But targeting 120 or 121 seems like > a good idea. As for merging the spec change I think it should be ready to > go assuming my response on the PR satisfies the question you had? > > > > Thanks! I think it'd be good to explicitly target a milestone - perhaps > 121? And yes, thanks for your reply on the spec. It sounds like there is > only a focus question remaining. > > > > Thanks, > > Mason > > > > > > Thanks, > Luke > > On Tuesday, 3 October 2023 at 17:34:15 UTC+1 mas...@chromium.org wrote: > > 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 yoav...@chromium.org wrote: > > On Mon, Oct 2, 2023 at 4:40 AM Luke <lukewa...@gmail.com> wrote: > > Contact emails > > lukewa...@gmail.com, lu...@warlow.dev > > > > 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 blink-dev+...@chromium.org. > > > 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 blink-dev+...@chromium.org. > > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5d5e5c6-bf85-425d-8f20-b00009be2bacn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5d5e5c6-bf85-425d-8f20-b00009be2bacn%40chromium.org?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+...@chromium.org. > > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/234f8753-9a15-4820-a240-40e594f6715f%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/234f8753-9a15-4820-a240-40e594f6715f%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 on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/12d244d1-cba2-4fcc-835c-4a4922dcf89bn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/12d244d1-cba2-4fcc-835c-4a4922dcf89bn%40chromium.org?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/CANh-dX%3DGt4b51rD8%2Bp7kfVBoKvj4Av1n_-NRfi8DsHj4OOyJUQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dX%3DGt4b51rD8%2Bp7kfVBoKvj4Av1n_-NRfi8DsHj4OOyJUQ%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/CANh-dX%3DE57UdHudr8H0nxDZu4Cu5a%2BSbD1_2RafxOyAAk2%2B4HA%40mail.gmail.com.
