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

> @LeaVerou regarding this comment:
> 
> > `<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.
> 
> Depending on the implementation, `<input type=color>` does have the ability to use an eyedropper to pick the color that will be turned into an RGB hex string. Here's a [screencast showing that in Chromium](https://drive.google.com/file/d/1N7pSFYZV0aBIhKQgUEnuVfxx4-fE_fhu/view). Isn't that the same issue?

The UI for `<input type=color>` is largely left up to the implementation. Since no spec defines this UI, the fact that an eyedropper appears in one browser (in fact, in its nightly version) should not set a precedent about what makes it into the Web platform.

To answer your question, yes, this suffers from the same issues. I've tried to illustrate with a video below.

https://user-images.githubusercontent.com/175836/104795005-51cd4b00-5779-11eb-8fbe-288f452d68f3.mp4

The gradient on the right is a gradient from P3 red to gray (you only see part of it). At first, I'm using OSX's native color meter to show you device RGB coordinates. As you can see, these are all different colors and the coordinates smoothly change as I move my pointer downwards. Then, I use the Chrome picker to consecutively pick colors lower and lower down. As you can see, they all yield `#ff0000` and I need to select several until I start seeing a discernible difference, because apparently Chrome seems to convert the P3 coordinates to sRGB and then just clips them. In practice, these means that the most saturated 33% of on-screen colors would be squashed onto the same hex value.



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