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).
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.
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).
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.
No specific DevTools changes are required. This feature is treated like any other JS method.
No. We are able to test the error case behaviors but the actual showing of the picker is not testable using WPT.
Links to previous Intent discussions
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/fEebe5uXQ1I
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.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
LGTM3On Wednesday, December 15, 2021 at 7:51:30 AM UTC-8 Yoav Weiss wrote:LGTM2On 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?