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

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

Thanks for your feedback!

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

We haven't seen evidence that this is a common scenario, but I don't see any harm in providing an optional `AbortSignal` parameter to facilitate such a scenario.

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

Since selecting a color is a user initiated action, I think exiting without a color selection should be treated as an exceptional case.
This is also consistent with how other APIs behave when the user aborts the operation by dismissing the UI.

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

We would have to include the position of the selected color to facilitate this scenario and we have decided that this is a non-goal for now.

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

I think that a Color API would be a great addition to the Web Platform and we expect that a color object will be the primary mechanism by which authors will access the selected color in the future.

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