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

We discussed this again this week.

We have consensus that a way to move forward with this and work around the transient issues relating to the lack of wide gamut support on the Web and the lack of a Color object on the Web Platform would be for the property that returns the selected color to be **named in such a way that makes what it is explicit**, and that allows room for future properties to be added, once these problems are solved. The name should indicate both that the color is a string (to allow room for a property that returns an object in the future), and that it is in sRGB (to allow room for an accurate color in the future). For example names like `hex`, `hexString`, `srgbString` would be explicit in that regard, whereas names like `color`, `value`, `srgb`, `colorString` are not (the first two because they are too generic, the last two because they are explicit in one axis but not the other). 

We are still concerned about the event based design and think a promise-based design would be more suitable. The use cases described do not seem to warrant the added complexity of an event based design. A promise-based design would provide a considerably simpler API, and would prevent any issues with the eyedropper mode being left hanging due to a missed call to `close()`.

With a promise based design, `open()` can allow for a permissions prompt or not, based on what the UA wants to expose. E.g. if drag and scrub is allowed, it would make sense to have a permissions prompt, but if the UI only allows selecting individual colors by clicking, it can be omitted. Note that a promise based design does not preclude events from also being fired in the future, if there are compelling use cases.

Security and privacy also came up. You should ensure that sites are not able to maliciously open the eyedropper to sniff, otherwise it could be used for nefarious reasons by advertisers.

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