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

Thanks for the great comments, @LeaVerou.

Regarding this point you made:
> Hex colors are in sRGB, which cannot represent all on-screen colors

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.

@dbaron, regarding the EyeDropper starting point, as you suggest, it should begin at the cursor location.  For keyboard accessibility the same should be true and the the arrow keys should move the mouse cursor.  Actually at any time the user should be able to move the cursor location with the mouse or with the arrow keys and go back and forth.  You can see this pattern in the Snip and Sketch tool for Windows and with the new [Smart Copy feature recently released for the Edge browser](https://techcommunity.microsoft.com/t5/discussions/smart-copy-is-available-in-edge-now/m-p/1909748).

@LeaVerou, regarding this comment on selecting multiple colors:
> However, I am missing a list of use cases that require such multiple color selection

You can find an example in Photoshop.  The eyedropper is just another tool in the tool pallete and it remains in eyedropper mode until you switch to a different tool.  I find the multiple selection model useful when the app shows a preview of what you selected as you select it.  When selecting from an anti-aliased region or wherever some color dithering has happened, the user may not prefer the first color they select and will select another nearby color until they get the desired result.

@LeaVerou, regarding your comments on containing color selection:
> Note that to replicate the UIs that do support multiple color selection with an eyedropper, merely preventing the eyedropper from closing or re-opening it does not suffice. These UIs typically exclude an area of the screen from selection, and this area contains some of the color-related UI and provides feedback for the color selection.

You are absolutely right.  We currently have this written in the explainer:
> This proposal does not currently define a mechanism to allow developers to hide or show the eyedropper's pixel selection UI while remaining in eyedropper mode, but a future version may allow that, for example, to facilitate clicking on application UI elements instead of selecting a color value.

I have it in the non-goals section, but agree the multiple color selection experience would be lacking without some mechanism to tag portions of the UI as not color selectable.  Since we don't have the mechanism for doing that sorted out yet we may split the proposal into two-levels - the first being a single select model that we can deliver while we figure out the API surface for excluding portions of the document to support the multi-select model.

Note I also have an issue already opened on this topic [here](https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/382) with one thinly defined proposal.  If you have any thoughts on how you think it should work feel free to jump in.

Thanks!

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