WICG
Do we need EyeDropper instances?
It seems this could just be a method on navigator or some such. Or perhaps a static method on EyeDropper if we wanted to namespace it. @domenic probably knows what's modern.
I've always found that new TextEncoder() seems weird and when I saw this api this was the first thing that came to mind as well. I think maybe an extension to navigator could work?
I kind of assumed there was going to be some statefulness to the EyeDropper, perhaps in future (or previous?) revisions of the proposal. If that's the case then sticking with a class makes sense.
If there's no state and this is purely a function, then window.showColorPicker() would be my recommendation (similar to window.showOpenFilePicker()).
(FWIW, TextEncoder is that way for symmetry with TextDecoder, which has state.)
@ipopescu93 What are your current thoughts?
As we're thinking about adding showPicker() to HTMLInputElement interfaces in https://github.com/whatwg/html/issues/6909 to let web developers programmatically open pickers for color, file, and temporal input elements, we would be happy to have some consistency between method names.
window.showColorPicker() would be nice indeed if states are not needed.
It is expected that state is going to be added for future capabilities of the EyeDropper like: UI customization, restricting the selectable area, etc.
Why can't that be an options dictionary to the hypothetical showColorPicker function?
It shipped in one browser only, I'm somewhat hopeful this can still be changed.
