[blink-dev] Intent to Ship: HTMLSelectElement showPicker()

2023-10-01 Thread Luke 
Contact emails
lukewarlow...@gmail.com, l...@warlow.dev

Explainer
https://github.com/whatwg/html/pull/9754

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

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)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/258)

Web developers: No signals

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+unsubscr...@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.

Re: [blink-dev] Intent to Ship: HTMLSelectElement showPicker()

2023-10-03 Thread Yoav Weiss 
On Mon, Oct 2, 2023 at 4:40 AM Luke  wrote:

> Contact emails
> lukewarlow...@gmail.com, l...@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?


> 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.


> 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" :)


>
> 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?


>
> 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  ?


>
> 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

Re: [blink-dev] Intent to Ship: HTMLSelectElement showPicker()

2023-10-03 Thread Luke 


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  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 we

Re: [blink-dev] Intent to Ship: HTMLSelectElement showPicker()

2023-10-03 Thread Mason Freed 
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 , 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 
 lists M119 as the 
target shipping milestone, but the addition of the code 
 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  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

Re: [blink-dev] Intent to Ship: HTMLSelectElement showPicker()

2023-10-03 Thread Luke 
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,
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 , 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 
>  lists M119 as the 
> target shipping milestone, but the addition of the code 
>  
> 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  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 AP

Re: [blink-dev] Intent to Ship: HTMLSelectElement showPicker()

2023-10-04 Thread Mason Freed 
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 , 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 
 lists M119 as the 
target shipping milestone, but the addition of the code 
 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  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 sec

Re: [blink-dev] Intent to Ship: HTMLSelectElement showPicker()

2023-10-11 Thread Daniel Bratell 

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
, 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
 lists M119
as the target shipping milestone, but the addition of the code

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
 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

Re: [blink-dev] Intent to Ship: HTMLSelectElement showPicker()

2023-10-11 Thread Mike Taylor 

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
, 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
 lists
M119 as the target shipping milestone, but the addition of
the code

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
 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.


T

Re: [blink-dev] Intent to Ship: HTMLSelectElement showPicker()

2023-10-11 Thread Yoav Weiss 
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 , 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 
>  lists M119 as the 
> target shipping milestone, but the addition of the code 
>  
> 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  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?
>

Re: [blink-dev] Intent to Ship: HTMLSelectElement showPicker()

2023-10-23 Thread Luke 
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 , 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 
>>  lists M119 as the 
>> target shipping milestone, but the addition of the code 
>>  
>> 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  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 picke

Re: [blink-dev] Intent to Ship: HTMLSelectElement showPicker()

2023-11-04 Thread Luke 
Unfortunately there is an ongoing discussion about the behavior in 
uncomposed documents and even concerns with the previous `` 
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 
>>> , 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 
>>>  lists M119 as the 
>>> target shipping milestone, but the addition of the code 
>>>  
>>> 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  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 hap