Intent to Ship: EyeDropper API

[Ionel Popescu]

Contact emails

iopo...@microsoft.com, pc...@microsoft.com

 

Explainer

https://github.com/WICG/eyedropper-api/blob/main/README.md

 

Specification

https://wicg.github.io/eyedropper-api/

 

API spec 

Yes

 

Summary

The EyeDropper API enables developers to use a browser-supplied eyedropper in the construction of custom color pickers.

 

Blink component

Blink>Forms>Color

 

TAG review

https://github.com/w3ctag/design-reviews/issues/587

 

TAG review status

Issues addressed

 

Risks

 

Interoperability and Compatibility

 

The new API can be feature-detected by checking for the existence of the EyeDropper interface on the window object. On browsers without support, web apps can invoke the full color picker programmatically.

 

Chrome: Public support

 

Gecko: No signal

 

WebKit: No signal

 

Web developers: Positive

·         https://github.com/WICG/proposals/issues/35

·         https://twitter.com/argyleink/status/1291056673348415489

 

Debuggability

No special support is needed.

 

Is this feature fully tested by web-platform-tests?

Yes, to the extent that it can be.

 

Flag name

EyeDropperAPI

 

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=897309

 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6304275594477568

 

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/cPTMI1i6d7I

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

LGTM1

This seems like a useful API, that can help users perform creative tasks that are impossible on the web today. (or require the user to jump through hoops)

Looking forward to this being able to represent the actual colors picked, once a `Color` object becomes a real boy.

On Friday, August 13, 2021 at 7:04:09 PM UTC+2 Ionel Popescu wrote:

Contact emails

iopo...@microsoft.com, pc...@microsoft.com

 

Explainer

https://github.com/WICG/eyedropper-api/blob/main/README.md

 

Specification

https://wicg.github.io/eyedropper-api/

 

API spec 

Yes

 

Summary

The EyeDropper API enables developers to use a browser-supplied eyedropper in the construction of custom color pickers.

 

Blink component

Blink>Forms>Color

 

TAG review

https://github.com/w3ctag/design-reviews/issues/587

Great feedback from the TAG!! Thanks for addressing it. 

[Chris Harrelson]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/807e61b9-bedd-4ca0-85be-d6c7daa4fafcn%40chromium.org.

[Mike West]

LGTM3. I'm particularly happy with the way this evolved after excellent feedback from our colleagues in the TAG. Thank you!

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-95m07c-jQx3_iNQrwdbFwPm0RwXVdc80zwRnGvYWg0g%40mail.gmail.com.

[Yoav Weiss]

One question that came up (and that should've been included in the template): Will this be supported on all platforms?

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/807e61b9-bedd-4ca0-85be-d6c7daa4fafcn%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Stephen McGruer]

> One question that came up (and that should've been included in the template): Will this be supported on all platforms?

FYI: This appears to be a problem with Chromestatus-generated I2Ss, I think (as I noticed the same for SPC just now), so I filed https://github.com/GoogleChrome/chromium-dashboard/issues/1498

[Yoav Weiss]

Thanks for filing that, Stephen! :)

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/807e61b9-bedd-4ca0-85be-d6c7daa4fafcn%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Ionel Popescu]

On Friday, 27 August 2021 at 07:42:10 UTC-7 yoav...@chromium.org wrote:

Thanks for filing that, Stephen! :)

On Fri, Aug 27, 2021 at 3:53 PM Stephen McGruer <smcg...@chromium.org> wrote:

> One question that came up (and that should've been included in the template): Will this be supported on all platforms?

FYI: This appears to be a problem with Chromestatus-generated I2Ss, I think (as I noticed the same for SPC just now), so I filed https://github.com/GoogleChrome/chromium-dashboard/issues/1498

On Friday, August 27, 2021 at 9:23:51 AM UTC-4 Yoav Weiss wrote:

One question that came up (and that should've been included in the template): Will this be supported on all platforms?

Thanks for pointing this out! I have added the missing information.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Initially, we are planning to support this only on desktop operating systems and will consider bringing it to mobile if there is demand.

[一丝]

I plan to migrate the color picker in Chrome Devtools to the EyeDropper API, but there are currently several problems:

1. There is no independent cursor on the left side of the magnifying glass (the magnifying glass will cover the content at the bottom of the screen, making it difficult to move the cursor)
2. It is not possible to continuously click to select the color.
3. macOS pre 10.15 magnifying glass is square(see bug 1130415).

[Ionel Popescu]

On Tuesday, 31 August 2021 at 01:32:01 UTC-7 一丝 wrote:

I plan to migrate the color picker in Chrome Devtools to the EyeDropper API, but there are currently several problems:

 Thanks yiorsi@ for the work to integrate the new EyeDropper API into the devtools color picker! I have followed up on the opened crbugs and github issue.

[Anne van Kesteren]

On Fri, Aug 13, 2021 at 7:04 PM 'Ionel Popescu' via blink-dev
<blin...@chromium.org> wrote:
> https://wicg.github.io/eyedropper-api/

It seems some security issues were opened against this document post
LGTMs. And after these issues were raised there hasn't been a lot of
activity on the repository which makes me wonder what is going on.
Does anyone know?

[Joey Arhar]

I am enabling this on Android in M158 because the latest version of Android now has a native eyedropper API that we can hook into.

I will follow up on feedback and alternative proposals for this API.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78jYKAh8%3Dpe859_PubwcBOoWW%2BHdQDJ8jcJmbOYeotodRg%40mail.gmail.com.

[PhistucK]

What will previous versions of Android experience? An unexposed API?

☆PhistucK

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKBNe13UR6d8y9Ygc%2BmP8-dTsn-hK2LrgmSQJ89HPUGOA%40mail.gmail.com.

[Joey Arhar]

In previous versions of android, the API will throw an error.

[Mike Taylor]

That's a little surprising. Do you have any published developer guidance (feature detection? try/catch?) to avoid foot guns? 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKZCPE0mp3HUPsFLgxRkkwgYY8TiRpeyZLPNVbVGuGgaw%40mail.gmail.com.

[Joey Arhar]

> That's a little surprising.

Do you think it would be better if it didn't throw an error? That seems more obvious to the author what is happening compared to returning a fake value or something.

> Do you have any published developer guidance (feature detection? try/catch?) to avoid foot guns?

It looks like the MDN article already has a catch in its example code: https://developer.mozilla.org/en-US/docs/Web/API/EyeDropper#examples

It doesn't explain that this catch will be hit in this scenario with older versions of android though, so I filed an issue here: https://github.com/mdn/content/issues/46163

[Mike Taylor]

On 10/15/26 3:58 p.m., Joey Arhar wrote:

> That's a little surprising.

Do you think it would be better if it didn't throw an error? That seems more obvious to the author what is happening compared to returning a fake value or something.

I'm not 100% sure... errors are great for developers when testing and debugging. But it's possible (and likely, if we're being honest) that devs aren't testing on multiple versions of Android to know that it might break for users that haven't upgraded. 

Updating documentation is helpful - thanks for filing an issue.

What is the feature detection story? https://wicg.github.io/eyedropper-api/#platform-support suggests that it's not exposed where it isn't supported. Can we do that?

[Mike Taylor]

On 10/15/26 6:15 p.m., Mike Taylor wrote:

On 10/15/26 3:58 p.m., Joey Arhar wrote:

> That's a little surprising.

Do you think it would be better if it didn't throw an error? That seems more obvious to the author what is happening compared to returning a fake value or something.

I'm not 100% sure... errors are great for developers when testing and debugging. But it's possible (and likely, if we're being honest) that devs aren't testing on multiple versions of Android to know that it might break for users that haven't upgraded. 

Updating documentation is helpful - thanks for filing an issue.

What is the feature detection story? https://wicg.github.io/eyedropper-api/#platform-support suggests that it's not exposed where it isn't supported. Can we do that?

Ah, I see that's what Xidorn also suggested already in the thread.

[Xidorn Quan]

I think it would be better not to expose the API at all if it isn't supported. Web apps might use the API's presence to adjust the UI. It would create a poor user experience if the UI appears but the functionality fails. Throwing an error on open makes feature detection almost impossible.

Xidorn Quan

xid...@canva.com

www.canva.com

in

ig

x

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/rdniQ0D5UfY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwLdBYjFJ6CL_2QSR5EB3M5muHn76XNo-%2BbAtMVN9EFQjQ%40mail.gmail.com.

[Joey Arhar]

Ok, sounds like I should find a way to remove the IDL on older versions of android. Thanks for the feedback!

[PhistucK]

Are there many precedents of such cases where a feature is only supported on a few versions of a specific platform and are we fine with this?

Is there no way to implement this on older versions? I assume most users are not on the latest version...

☆PhistucK