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

@dbaron 
> It seems to me that for mouse-based interfaces, the starting point is probably the mouse pointer location since the eyedropper essentially is the mouse cursor though I wonder if this is still true if the eyedropper mode is initiated via a keyboard interaction.

Ah yeah, that makes perfect sense. Even if a position is still needed for accessibility, it would make an excellent default.

@BoCupp-Microsoft 

> We looked for a better representation of color while writing the explainer and found some of the GitHub issues you mentioned.  It seems like it might take a while to close on a proper definition of a color type that can serve all the web platform's needs.  Our thinking was that we could decouple from that work by returning the same color value strings [that the input[type=color] element returns today from its value property](https://html.spec.whatwg.org/multipage/input.html#color-state-(type=color)).  When a better color type is available we can then add a new property to the [ColorSelectEvent](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/EyeDropper/explainer.md#web-idl) - similar to what I'm sure we'll do for input[type=color].
>
> Let me know if you agree with that thinking.

`<input type=color>` does not have to match any specific on-screen color, it can just display an sRGB picker and suffer from no such inconsistency. With an eyedropper API, it's quite important that the color the user picked from the screen is the actual color displayed in the web application. If you generate a hex color based on device RGB, which is then interpreted as sRGB on the Web platform, it's not only the colors outside the sRGB gamut that will be different, **every** color that the user picks will be different. The difference is already fairly noticeable on today's P3 screens (up to 7.1 ΔΕ2000 units) and will increase further as screen gamuts expand beyond P3 in the near future.

The discussion about color types is orthogonal, as you are currently returning a string anyway, and there are many other CSS color formats beyond hex.

As an aside, even for `<input type=color>` there is [discussion](https://github.com/whatwg/html/issues/3400) about hex values being insufficient. Regardless, as I explain above, it's not as much of a problem there because the picker UI is constrained, and not the entire screen gamut. If you are able to pick any displayable on-screen color, you need to be able to represent any displayable on-screen color.


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