Questions on the explainer.

Very cool start! Excited for this conversation to move forward, and have lots of questions:

1. Does the following code in the explainer imply that the EyeDropper wouldn't have its own UI when "closed"?

// Enter eyedropper mode
let icon = document.getElementbyId("eyeDropperIcon")
icon.addEventListener('click', e => {
    eyeDropper.open().then(
        () => { console.log("entered eyedropper mode") },
        () => { console.log("could not enter eyedropper mode") }
    )
});

2. While you make a great point about previous art leaning away from the use of an extended <input> element, would you still see this as being an element (there's actually no reference to it actually being an element but for argument's sake) that would be "form associated"? Or would this be something more "over the top" where the resultant e.value would be passed into a input[type="color"] element, or similar, to support this?
3. The element or not question is also pertinent in regards to no UI events except colorselect are dispatched to the web page which implies that the event is triggered on window or document while the example listens on eyeDropper.addEventListener which without being an element would need to be an EventTarget, which I'm not sure actually bubbles its events to window et al.
4. By the statement the colorselect event is only dispatched while the primary pointer is down, do you see the colorselect event as streaming while the pointer is down? Would you pair this with a final event (colorchange, etc) when the pointer is "up" again? Or, as the example implies, would it be for the developer to "decide" when the user is done, possibly through only caring about the first event? If we needed the paired event names, would it make sense to fall back to prior art here and match an input event with a change event for regularity across features?
5. Returning to while the primary pointer is down, how would you expect this API to interact with keyboard only use cases?
6. Would this be a purely JS space feature, or do you see there being an HTML first approach to this?
7. Whether there is "closed UI" or not, there is "opened UI" and that being so what sort of customization pattern do you see being best to deliver with this sort of functionality? More specifically, the reason similarly complex UI/X patterns seem to be repeated often in userspace (see the <select> pattern) is the overly restrictive visual delivery of said patterns, how could this proposal head that issue off at the pass? The possibilities of a completely "headless" version of this experience would be quite interesting.
8. While I appreciate the complexity of submitting a color object model along with this proposal, do you see any short comings around only supporting hex colors? The specifically available color space of hex colors might be too restrictive. Could you see this supporting a type="rgb|hex|hsl|etc" property, or multiple types by default (see the Chrome DevTools colors selectors) to allow for a more expressive color capture mechanism?
9. On the subject of color, in the browser space, there is some context of alpha that could be applied to this picker. Do you see this as being a purely WYSIWYG result (so the fully composited color) only, or is there room for more complex resolution? Maybe not in a v1 but I'd be interested in seeing a possible path to doing so.
10. I'll share thoughts on scoping the parts of the page that the EyeDropper has access to in #382.