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

Glad to see the improvements in both API shape and spec text!

We discussed this again in our plenary yesterday and while we thought this was an improvement over the previous iteration, we did have a few thoughts and questions.

While it's good that there is some guidance for UAs on when to exit eyedropper mode without a selection (e.g. pressing ESC), it might be good to also provide a way for the application to explicitly close the eyedropper, e.g. a `close()` method or an `AbortSignal` parameter. Since no UI events are dispatched this would not be useful for closing the eyedropper through user interaction (e.g. via additional keyboard shortcuts), but it could be useful for closing the eyedropper (with no selection) in case another high-priority event occurs in the application, e.g. a modal dialog.

Some of us were surprised by the [promise rejection  when no selection is made](https://wicg.github.io/eyedropper-api/#eyedropper-interface) (vs resolving with `null`), since this is [ordinary use and not an unusual bad state](https://www.w3.org/2001/tag/doc/promises-guide#rejections-should-be-exceptional). Do you consider exiting without a color selection an error condition? Did you choose this design to be consistent with another API?

While we think the promise-based design is an improvement, we did notice that it does not address your original use case of picking colors from a drawing application. Only the final composited color will be picked with no means of tracing it back to the top-most color that the user may have intended to pick since no UI events are fired throughout the selection. What are your thoughts on this? Is there another way to accomplish this with the new design or did you decide that this is a non-goal for now?
Also note that for multiple color selection to be possible with a promise-based API like this, subsequent (synchronous) `open()` calls would need to open the eyedropper in the same place it was before. I don't see anything about this in the explainer or the spec.

Btw while `sRGBHex` definitely addresses our feedback on future-proofing this API, do note that a simpler `hex` property would also do, since all hex colors are in sRGB anyway. That also avoids the casing debates raised above.

Relevant, note that there is now an effort to standardize a Color API for the Web Platform by a subset of the CSS WG per recent CSS WG resolution: https://github.com/WICG/color-api and serving this API is listed as an explicit goal.

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