Components: Support the `EyeDropper` API in `ColorPicker`

[ciampo]

Why

Adding an Eye Dropper tool to the ColorPicker would enhance its UX and features set

What

We should embed an Eye Dropper tool following the EyeDropper APIs:

• explainer
• Draft APIs

Note: this API are not stable yet and, at the time of writing, is only supported in Chrome >= 95

A/C

• [ ] Get the updated designs including the EyeDropper button
• [ ] Show the EyeDropper button only when supported is detected
• [ ] Implement the EyeDropper functionality (assign the color picked with the Eye Dropper tool to the currently opened ColorPicker)
• [ ] Edge case: make sure that the Eye Dropper tool is closed (canceled) if for any reason the ColorPicker is dimissed

[javierarce]

Here's a proposal for the eyedropper:

• I placed the tool inside of a new header. This header could contain a title and also allow users to drag the popover and move it around.
• For the zoom element I followed Chrome's idea of replacing the cursor with the picker. The zoom would follow the cursor around.
• The RGB code uses a monospaced font, so its width is always the same.
• I think we don't currently have an eyedropper icon, so we'll need to create one (the one I used on the design is just for reference)

Figma file

[ciampo]

cc'ing @mtias @pablohoneyhoney and @jasmussen regarding the potential UX around an eyedropper tool in the `ColorPicker.

(example codepen: https://codepen.io/matanbobi/pen/GREoZvo)

[pablohoneyhoney]

Nice!

For some reason I'm not able to see the codepen EyeDropper API is not supported on this platform in any browser and would love to.

Not sure if we want this right away and that's why it wasn't explored initially. If we do, there are cases where the color picker doesn't have a header or it isn't clear if we do need that header all times.

It might work with the RGBA codes but perhaps the eyedropper could live alongside the control icon if we don't need to label?

[javierarce]

If we do, there are cases where the color picker doesn't have a header or it isn't clear if we do need that header all times.

In that case we could go for a placement similar to Figma's color picker:

[pablohoneyhoney]

It does unbalance the UI heavily, no? Is there perhaps a different way to display the RGBA codes so it could live on the left of the controls icon? For example.

[javierarce]

Is there perhaps a different way to display the RGBA codes so it could live on the left of the controls icon? For example.

I'll think about alternative ways to display the color, but I think we could pull that off by just slightly increasing the width of the component and reducing the space between the color parts:

Quick test:

Question: the blue color implies that the RGBA are links, right? What happens when the user clicks them?

[ciampo]

For some reason I'm not able to see the codepen EyeDropper API is not supported on this platform in any browser and would love to.

I am able to run the codepen on the latest stable Chrome for MacOS (Version 94.0.4606.81)

[javierarce]

I'm also on that version, but it didn't work for me I had to install Chrome Canary.

[jasmussen]

This is a sweet feature. Because it's such an advanced browser feature that it's barely rolled out to Chrome yet, though, I would echo Pablo that it seems worth it to restrict the button to exist in context of other advanced configuration tools for the time being. Then as browser support becomes wider, the button could literally graduate in the UI.

That said, it could be nice to include a small enhancement for power-users, such as allowing people to press the i key to invoke the eye-dropper when the color picker is open.

It seems important to change the cursor also, though, when the tool is selected. Ideally we create an entirely custom cursor, pending browsers adding a system-level eye-dropper cursor. Altenately, the crosshair cursor might hold us over.

[jorgefilipecosta]

Should we implement this feature now (with a check and if not supported we don't render anything)? Or it is something for the future when browser support increases?

[ciampo]

Personally, I think this would a nice-to-have feature with (at the moment) a low priority. We could probably use our resources for higher-priority issue and come back to this once browser support looks a bit better.