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

@LeaVerou thanks again for the comments and apologies for taking longer to reply.

*You wrote:*
>The biggest issue is color output. There are four ways to address this:
>...
>option 2. You could clip or gamut map the selected color to sRGB and return an sRGB hex value (or other sRGB color format). The problem is that color selection will not roundtrip for at least 1/3 of onscreen colors in today's displays (and as display technology improves, this will increase).

Option 2 is what we have proposed.  Assuming the author renders the selected color back via CSS in a Chromium browser, there's no way to round trip the colors beyond sRGB regardless of what color format we return.  Until we have a more comprehensive representation of color that can be used throughout the web platform, I'm proposing we follow the existing precedent established by `input[type=color]`'s value property.  

This is the output already produced by eye droppers on the web today (for browsers that provide an eye dropper as part of their `input[type=color]` implementation).  I think this approach avoids jumping ahead of [groups like this one](https://w3c.github.io/ColorWeb-CG/) to create another color representation that will be specific to eye dropper output and potentially misaligned with other web color inputs.  Once we have a better color representation, we can add that representation to the event we dispatch when a color is selected.  I also imagine we'll be updating the interface for `input[type=color]` in a similar way.

*You wrote:*
>b) As long as the eyedropper cannot be used to scrub the screen, and only communicates the user's final selection back to the web application, this does not need a permissions prompt, just like the file input does not need a selection prompt, so open() does not need to be asynchronous (unless you move to a promise-based design, see below).

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?

*You wrote:*
> c) The API is designed around using a PointerEvent but it is unclear what the use cases are for reading coordinates, especially since their presence cannot be guaranteed and selection cannot be constrained to only areas where coordinates can be returned.

There are two pieces of information in the explainer related to this:
1. [Goal 2](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/EyeDropper/explainer.md#goals) says: Provide coordinate information in addition to a color value so that web apps may utilize any data known for the selected pixel whenever the selected color is from a document having a similar origin, e.g. layering information in a painting web app.
2. The second paragraph in the [Solution section](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/EyeDropper/explainer.md#solution) says: The position of the selected color is included to facilitate scenarios where a web app using the eyedropper samples a pixel color from its own document. The web app could, for example, include an alpha channel for the selected pixel or create a palette of colors associated with a pixel's location based on layer information known to the web app. The color value would otherwise be the final composited color as seen by the user.

*You wrote:*
> d) The API is designed around multiple color selection as the primary use case, requiring use of events and explicit `close()`. However, as pointed out by the authors, multiple color selection is primarily intended for fine tuning, but the UA can take care of the fine tuning by showing appropriate UI and only communicating the final color selection back to the app, which is also more privacy preserving. This would allow a promise based design and prevent bugs where the eyedropper mode is left open because something (e.g. an exception) intercepted the call to `.close()`.

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.

Please let me know if any of my comments successfully addressed any of your concerns. :-)  I'd like to find a way to ship this API without needing to wait for wide gamut colors on the web to be a solved problem.  Other points seem more negotiable to me.

Thanks for your help and feedback!
Bo

-- 
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-789504267