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

I agree with the explainer that not extending  `<input type="color">` to create an eyedropper API is a good idea. 

In previous WICG discussion on [Allow `<input type="color">` to give an alpha channel and/or colors beyond sRGB?](https://github.com/whatwg/html/issues/3400), @tabatkins noted that, even for a trivial extension to support alpha,

> Agree that a new input type is likely necessary due to the existing consumers that likely depend on the 6-hex format.

In that discussion [I also noted](https://github.com/whatwg/html/issues/3400#issuecomment-607948859) that the 8-bit sRGB-only hex format suffers from two issues:

1. The Web has been moving from sRGB-only since 2016. A significant percentage of phones, tablets,and  laptops not have a wider gamut RGB space as native (display-p3, derived from DCI P3, seems to be the most common) while much video content is delivered in rec2020 RGB
2. Implementations are moving from 8 to 10, 12, or half-float per color component, because wider gamuts need more precision to get the same banding-free performance.

So making a new API in 2021 which is limited to sRGB-only looks like a very short-term exercise. However, making an extensible API which delivers sRGB as a default (or as the only option in the first version, but is clearly labelled as sRGB) makes it possible to extend (to at least display-p3) soon, without re-writing or abandoning the API.

I note that [the eyedropper explainer](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/EyeDropper/explainer.md) makes no mention of colorspace at all, which should be corrected.

I fully agree with [the TAG feedback](https://github.com/w3ctag/design-reviews/issues/587#issuecomment-767447983) that early clipping of the input color to sRGB is going to cause a compatibility headache - its hard to then not-clip when other color spaces are supported, because this is a change in eyedropper behavior. 

Also as [the example from @LeaVerou  showed](https://github.com/w3ctag/design-reviews/issues/587#issuecomment-761298474) the user experience is confusing if visibly different on-screen colors result in the same picked color. 

And since the explainer states that

> Provide access to the color values of one or more user-selected pixels, including pixels rendered by different origins, or outside of the browser.

the eyedropper will need to pick up colors displayed by native applications, which will not necessarily be in sRGB, even if the browser does not yet support them.

I can see several options:

1. return a tuple of a color and a colorspace, so for example `#1278CF` and `sRGB`, which can be easily extended to support  other colorspaces
2. return two values, one an sRGB fallback and one the actual color, in Lab
3. return an unclipped sRGB color (so negative values, and values greater than 100%, would be legal and represent colors out of gamut)

(I'm assuming strings are returned, since the CSS Typed Object Model is not yet ready to be deployed for colors.)

I suspect the first option is both easier and better, for a near-term implementation; and re-reading the earlier WICG discussion [I see @tabatkins proposed](https://github.com/whatwg/html/issues/3400#issuecomment-610648552) a `colorspace=""` attribute so the content author can say what colorspace they want results returned in 

By the way I appreciated, from the explainer,

> This proposal does not currently define an object model for a color, though it seems like something that would be a good addition to the web platform.

Yes, it would be a great addition to the Web platform but there isn't one yet that is ready for deployment, so for now slinging around strings is the only way; and I appreciate that a quick color object model wasn't developed solely for eyedropper use. A color model for the Web needs to handle CSS, Canvas, WebGPU as well as just colors in HTML.

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