search

WICG / proposals

A home for well-formed proposed incubations for the web platform. All proposals welcome.
https://wicg.io/
Other
226 stars 11 forks source link

EyeDropper API #35

Closed ipopescu93 closed 6 months ago

ipopescu93 commented 3 years ago

Introduction

Currently on the web, creative application developers are unable to implement an eyedropper, a tool that allows users to select a color from the pixels on their screen, including the pixels rendered outside of the web page requesting the color data. This explainer proposes an API that enables developers to use a browser-supplied eyedropper in the construction of custom color pickers.

Read the complete Explainer.

Feedback

I welcome feedback in this thread, but encourage you to file bugs against the Explainer.

Kilian commented 3 years ago

This works great already, but I would love to see this expanded with a few more features:

Live preview Use case: I would like to show a visual + textual preview of the selected color as people mouse over the screen. Right now we only get the color on click. Without the mouse position being communicated when in EyeDropper mode, I don't think this gives any security issues, and instantiating the EyeDropper is still an explicit action.

It would also be okay if a preview was implemented (configurably?) in the EyeDropper UI itself.

Multiple selections Use case: it would be useful to let people select multiple colors in sequence, for example to fill out a palette. Interaction would be an issue here of course so that would need some consideration. The default interaction is easy to get out of (even accidentally), so allowing multiple selections should probably be an option you set. When set, there's a few patterns we can consider:

ipopescu93 commented 3 years ago

Live preview Use case: I would like to show a visual + textual preview of the selected color as people mouse over the screen. Right now we only get the color on click. Without the mouse position being communicated when in EyeDropper mode, I don't think this gives any security issues, and instantiating the EyeDropper is still an explicit action.

It would also be okay if a preview was implemented (configurably?) in the EyeDropper UI itself.

One of our goals is to allow browser implementors the freedom to implement eyedropper pixel selection UI that best fits their platform and browser. Note that in the future, the API may be extended to afford web developers more control over that UI.

Multiple selections Use case: it would be useful to let people select multiple colors in sequence, for example to fill out a palette. Interaction would be an issue here of course so that would need some consideration. The default interaction is easy to get out of (even accidentally), so allowing multiple selections should probably be an option you set. When set, there's a few patterns we can consider:

  • Esc to clear out the mode already works and is a straightforward pattern here too.
  • Holding shift selects a color without leaving the EyeDropper.
  • Clicking a designated area in the UI turns the EyeDropper off again (currently a non-goal)

This was a scenario discussed during W3C TAG review and we have decided that for now developers can support it by triggering eyedropper mode again immediately after selection. The current API design doesn't stop adding native support for multiple color selection in the future, if we are going to see that this is a common use case.

Kilian commented 3 years ago

I would like to come back to the live preview feature. When you look at browser extensions (and native color pickers) many have this functionality in some way or form. Seeing the color in a larger area than a (zoomed in) single pixel, along with the textual representation is a big part of many color pickers. In short, none of these extensions would (be able to) use the proposed API:

All of these provide a live preview of the currently focused color, both visually and in text. I'm sure there are many more chrome extensions that do this, not to mention native color pickers.

Edit: In terms of security, all this "live" api would have to give back is the color under the cursor. This circumvents security issues with tracking both the color and mouse position.

travisleithead commented 3 years ago

Looks like we've seen sufficient evidence of interest to transition this proposal into its own WICG repo:

Eyedropper API is now moved into https://github.com/WICG/eyedropper-api