Proposal: <input type=color> hint for eyedropper-only

[inexorabletash]

Background:

The <input type=color> form control allows selecting a color. User agents typically implement this using a pop-up color picker. In some user agents, the picker includes an "eyedropper" control, either implemented by the UA or by the OS-provided picker.

Example:

The eyedropper control causes the app to enter a modal state; the cursor changes to an eyedropper; when the cursor is clicked - on any part of the desktop, whether over the page, the UA, or another application - the underlying color is selected.

Feature Request and Use Case:

We've had feature requests against Chrome from numerous developers of web-based design tools. (tracking bug) to provide the ability to show an eyedropper without the pop-up color picker. This would allow such web applications to provide the same functionality as native desktop applications, integrating an eyedropper into the color picker into their UI. Here's the UI for a typical desktop native app (Gimp) showing an eyedropper control:

Proposal

This functionality could be added progressively by adding an attribute to <input type=color> that effectively "skips" the popup if supported. For example:

<input type=color eyedropper>

• It gracefully falls back to a semantically identical control on older UAs.
• If not supported by the UA on that platform (e.g. one without cursors, etc), it behaves exactly as <input type=color>.
• Web apps can customize the UI by creating a hidden element and calling click() as is common for other form controls (like <input type=file>)
• Feature detection can be done by examining HTMLInputElement.prototype.

... but other proposals to support the use case are welcome.

Chrome is interesting in implementing support for this use case.

[ericlaw1979]

Cool!

Presumably ESC or similar function keys disable the operation?
For security purposes, I assume that the JavaScript in the page cannot get any color information until the user actually "Clicks" and the feature itself is gated behind the same user gesture requirements (1 gesture per invocation) that INPUT TYPE=FILE requires?

[annevk]

cc @whatwg/forms

[inexorabletash]

Presumably ESC or similar function keys disable the operation?

Yeah. Details would be up to the UA, but I think that's how they're typically implemented.

For security purposes, I assume that the JavaScript in the page cannot get any color information until the user actually "Clicks"

Maybe. I definitely agree that the script should not be able see mouse coordinates and color (otherwise it can potentially reconstruct what the user is mousing over). But some native drawing apps with eyedroppers display the current color under the cursor within their "active color" widget, updating it live as the user moves the mouse. If UAs can suspend delivering mouse events to script while in the eyedropper mode then maybe updating the HTMLInputElement's value "live" would not be a privacy concern, and would match native app behavior. I think we should explore this, but I agree the fallback is as you suggest.

and the feature itself is gated behind the same user gesture requirements (1 gesture per invocation) that INPUT TYPE=FILE requires?

Yep, whatever is the latest convention for such things.

[inexorabletash]

Some folks have put up an explainer for a different API proposal here:

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/EyeDropper/explainer.md

They request feedback via this link:

https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/new?assignees=BoCupp-Microsoft&labels=EyeDropper&template=eyedropper.md

[inexorabletash]

Closing this in favor of https://github.com/wicg/eyedropper-api/