Intent to Ship: HTMLInputElement showPicker()

[François Beaufort 🇫🇷]

Contact emails

fbea...@google.com

Explainer

https://github.com/whatwg/html/pull/7319

Specification

https://html.spec.whatwg.org/multipage/input.html#dom-input-showpicker

Summary

The HTMLInputElement showPicker() method allows web developers to programmatically show a browser picker for input elements (temporal, color, file, and those with suggestions like datalist or autofill).

Blink component

Blink>Forms

Motivation

Developers have been asking for years for a way to programmatically open a browser date picker. See https://www.google.com/search?q=programmatically+open+date+picker+site:stackoverflow.com

Because of that, they had to rely on custom widget libraries and CSS hacks for specific browsers.

This is currently possible in some browsers, for some controls, via the click() method. However this is not interoperable (https://github.com/whatwg/html/issues/6909#issuecomment-897097048) and considered a bad idea (https://github.com/whatwg/html/issues/3232#issuecomment-345279014). Providing showPicker() gives developers a supported alternative to click(), and will allow us to align Chromium's click() behavior with the specification and other browsers in a future Intent to Ship.

Initial public proposal

https://github.com/whatwg/html/issues/6909

TAG review

https://github.com/w3ctag/design-reviews/issues/688

TAG review status

Pending

Risks

Interoperability and Compatibility

For interoperability: This feature was developed in collaboration with Gecko engineers, who are positive. It also will help with improving click() interoperability in the future, which is currently messy (https://github.com/whatwg/html/issues/6909#issuecomment-897097048).

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 things (except for file pickers, which fire certain events), so we will not be constrained by any JavaScript-observable behavior if we need to make future changes to form control UIs.

Gecko: Positive - https://github.com/whatwg/html/pull/7319#issuecomment-988837778

WebKit: No signal - https://lists.webkit.org/pipermail/webkit-dev/2021-December/032071.html

Web developers: Positive - https://twitter.com/quicksave2k/status/1420320560345661440 (6 Retweets and 29 Likes) - https://github.com/whatwg/html/issues/6909 (9 👍  and 5 ❤️) show that developers like this particular solution. Plus the evidence of developer interest in the use case, per the Motivation section above.

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. We are able to test the error case behaviors but the actual showing of the picker is not testable using WPT.

https://github.com/web-platform-tests/wpt/tree/master/html/semantics/forms/the-input-element

Flag name

chrome://flags/#enable-experimental-web-platform-features

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=939561

Estimated milestones

M99

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5692248021794816

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/fEebe5uXQ1I

[Joe Medley]

When are you hoping to ship this?

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--
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/CAPpwU5Lh3nwAzZs4P1eHdg80dViZomPc%2BY0HpQ9HYpxgUSgnQA%40mail.gmail.com.

[Joe Medley]

You already answered that in the intent. I'm blind.

[Mike West]

LGTM1.

Given that this codifies existing Chrome behavior in a way that it seems like other vendors can get on board with, I'm supportive of shipping this more standardized mechanism for showing native UX. I do wonder what we're going to do with `click()` in the long term. Is there a deprecation plan for that behavior, since it seems unlikely to become interoperable otherwise?

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2b76c6cd-3df5-46ff-85f6-2523b379ab67n%40chromium.org.

[Yoav Weiss]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Alex Russell]

LGTM3

[François Beaufort 🇫🇷]

On Wed, Dec 15, 2021 at 5:59 PM Alex Russell <sligh...@chromium.org> wrote:

LGTM3

On Wednesday, December 15, 2021 at 7:51:30 AM UTC-8 Yoav Weiss wrote:

LGTM2

On Wednesday, December 15, 2021 at 4:18:50 PM UTC+1 Mike West wrote:

LGTM1.

Given that this codifies existing Chrome behavior in a way that it seems like other vendors can get on board with, I'm supportive of shipping this more standardized mechanism for showing native UX. I do wonder what we're going to do with `click()` in the long term. Is there a deprecation plan for that behavior, since it seems unlikely to become interoperable otherwise?

@Domenic Denicola outlined a plan for showPicker and click() at https://github.com/whatwg/html/issues/6909#issuecomment-897097048

In the meantime, I've just added a use counter for HTMLInputElement click() so that we can track how much the web platform relies on this feature. See https://chromium-review.googlesource.com/c/chromium/src/+/3358063

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2b76c6cd-3df5-46ff-85f6-2523b379ab67n%40chromium.org.