Re: [w3ctag/design-reviews] EyeDropper API (#587)

@BoCupp-Microsoft 

### On color spaces

I don't think it's particularly contentious that an eyedropper that returns an incorrect color for about 1/3 (!) of on-screen colors is pretty seriously flawed. To reiterate, the color input is not a good analogy; a color selection tool can just constrain its selection to in-gamut colors. An eyedropper (especially with this proposed design) does not have this luxury. And even for the color input, the decision to go with hex colors is now seen as a design mistake, as @svgeesus points out above.

**There is however a way forwards**, as @svgeesus suggested, which we hadn't realized earlier. This is actually how Chrome and other UAs plan to ship other color-related features, such as `color-mix()`: a mandatory colorspace argument. It could be a [(dictionary)](https://w3ctag.github.io/design-principles/#prefer-dict-to-bool) parameter of the `open()` method. If the author explicitly declares that they want results in sRGB, it should be no surprise that colors outside sRGB will be gamut mapped (not clipped, which can cause large hue shifts). Once wide gamut colors are implemented, an appropriate default can be chosen (e.g. Lab) so that the argument is no longer mandatory. This also allows authors control over the returned format so that it better suits their use case.

### On privacy

> As you mention in point d, the API is designed to accommodate selecting multiple colors, so an async API seems appropriate for now. Note that I realize the explainer calls out some open issues around the selection of multiple colors, so maybe we won't initially ship a multiple color picking implementation until those are resolved, but it seems like a good idea to shape the API so that a multiple color picking implementation could be delivered. Do you agree?

I think you misunderstood this point in our feedback. The permissions prompt isn't needed for multiple color selection either, *unless* the API continuously communicates the color the eyedropper is on, essentially "scrubbing" the screen, but that would be poor design for reasons beyond privacy. As long as the only color(s) that are communicated back via the API are those intentionally selected through explicit user action, it does not need a permissions prompt, in the same way that the file input doesn't need a permissions prompt even for selecting multiple files. 

### On coordinates

It's clear that there are use cases where coordinates are useful. What is unclear is if there are such use cases that do not _also_ require constraining the selection area to areas that *can* produce such coordinates, which is currently explicitly listed as a non-goal. Allowing selection from anywhere on the screen when you really mean to let the user select a color from their graphics document seems like a footgun, which will create poor, buggy user experiences. 

a) In many cases it will end up being completely unhandled because developers only tested by picking colors within their document
b) Even when developers realize they need to handle selection out of bounds, since they cannot prevent it, they will need to handle it as an error condition post-hoc. Creating error conditions that could have been prevented is a usability antipattern.

There is only one use case listed in the explainer for coordinates, and that is also a use case that requires constraining selection to the document.

### On single vs multiple color selection 

> I agree there's risk of bugs in web apps and missing the call to `close()`. We have the following text in the explainer to try to mitigate getting stuck in eye dropper mode: "provide the means for the user to exit that mode, for example, by pressing an ESC key and not allowing the behavior to be cancelled by the author." The UA may decide to show UI educating the user that ESC will exit the mode, similar to what happens for fullscreen.

You are discussing how these bugs could be mitigated by the UA, but not any rationale for the current design that would justify its added complexity and bug potential over a far simpler single-selection-by-default promise based design. Note that multiple color selection is still possible with such a design, either via the UA allowing fine-tuning, or even by the developer triggering eyedropper mode again immediately after selection.

Also, I have reservations about the user experience of arbitrary calls to `.close()` as the primary mechanism for exiting eyedropper mode. The more "heavyweight" the change in UI is (with notices about ESC and the like), the more jarring it will be to exit this mode without explicit user action.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/587#issuecomment-793212928