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
                    <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
                    
<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
                    
<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
                    <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
                    <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
                    <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
            <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
            <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
                    
<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
                    <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
                    <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
                    <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
                    
<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+unsubscr...@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+unsubscr...@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/2e9845dc-f31e-46dd-bc90-57e43c358861%40chromium.org.

Reply via email to