Apply/Cancel using showPicker() of type="color"

[codedread]

TL;DR I think all browser implementations of color pickers should include explicit and distinguishable actions for commit and cancel. I also have a suggestion for improving the showPicker() API.

The exact thing I want to build is the following:

1. A Paint Bucket button that, when clicked
2. Opens a modal color picker where users can play around and choose a color and then
3. User either chooses Apply or cancels their selection
4. Web app does something if a new color value was chosen and ignores/resets if it was cancelled

I realize it's early days with showPicker(), but it seems the above should be achievable. However, when I went about trying to implement this, I did the following:

• Added an <input id="myInput" type="color">
• Did addEventListener('click') on a button to call myInput.showPicker()
• Look at change events to decide when a change has occurred.

I know I can listen for 'change' events on the input and respond, but in playing around with implementations:

• Chrome's color input does not have any visible indication of how to close nor does it respond to the Escape/Enter keys. This seems to imply the user must blur / click outside of the modal picker once they have chosen a color to close it.
• Firefox's color input is a modal dialog with a close button. It also closes when the user presses Escape.

The current state of affairs suggests that neither the user NOR the web app can distinguish when selection or cancelling has occurred. Maybe the spec for type="color" needs to add further requirements to the implementations? https://html.spec.whatwg.org/#color-state-(type=color)

====

More thoughts:

a) Can I use <dialog> with <input type="color"> to build this myself?

Not really. There is no way to embed the picker into a dialog directly or programmatically call showPicker(). So this means the user has to launch a modal and then click the input, and then still be faced with big differences in browser implementations on how to close the native picker before then clicking my Apply/Cancel buttons. Modals within modals and multiple needless clicks is bad UI design.

b) Would the foreshadowed closePicker() help?

No. Choosing a color is a finicky business and users usually take multiple tweaks before they are satisfied with their color selection. How would the web app know when to closePicker().

c) Could the API be changed to fix this issue?

Maybe!

If showPicker() returned a Promise<string|null>. When the Promise resolves to a string, it contains the selected value (#rrggbb for color). If the Promise resolves to null, then the user cancelled. This puts the onus on browsers to implement visual controls that distinguish selection vs cancelling in order to fulfill the API. Promise that resolves to a boolean would also work, it would just require that web devs continue to listen for 'change' events and update local state.

[domenic]

This seems like something you need to file on individual browsers, as the UI decisions of how to implement pickers and what capabilities they provide are up to each browser's UI team and not in scope for the HTML Standard.

[codedread]

Can someone explain how to detect when a user has cancelled a picking operation (i.e. closed the picker without making a selection)? Is it just "never getting a change event"?

[codedread]

I'd like this to be reopened to get someone to look at my spec change suggestion at the bottom of my overlong text:

I strongly believe that if showPicker() returned a Promise whose resolution indicated selection or cancellation of the modal picker, it would vastly improve the situation.

[mfreed7]

@domenic WDYT about the suggestion for showPicker() to return a promise? It'd be backwards compatible (I think) and would offer a standardized way for all pickers to detect what happened. It would seem to beat the approach of adding cancel to all inputs with pickers.

[domenic]

Well, first it runs into #7790.

Second it'd be inconsistent with what we already decided for input type=file, of using input/change vs. cancel events.

Third it's not clear that the constraints on the user interface that this implies, or the leakage of bits about user behavior, are desirable for all implementers. E.g. it could make it hard for an implementation to switch from an explicit close button to a light-dismiss behavior because of how websites have taken dependencies on the result.

Finally, it really misses https://whatwg.org/faq#adding-new-features step 1 and step 2.