The Color Input & The Color Picker

HTML has a color input that is pretty decent:

<input type="color">Code language: HTML, XML (xml)

That’s it. Support across the board. However, browsers can and do have different approaches to what happens when the input is used.

macOS Chrome (has it’s own UI)
macOS Firefox (uses the macOS system color picker)
macOS Safari (has it’s own UI, allows you to open macOS system color picker)
Windows Chrome (has it’s own UI) (Edge looks the same)

Window Firefox (uses the Windows system color picker)
Chrome on Android (Pixel 8)
Safari on iOS 17

Ultimately: the user activates the input, may choose a color using the provided UI, and the color becomes the inputs value.

It’s not my favorite that you can only get 6-digit HEX colors in and out of it, like #F06D06 and the like. No transparency, no other formats. I have a feeling display-p3 color formats like OKLCH will have a real popularity boom in coming years (because they are sweet: more colors, more logical) and we’ll start wanting better integration, like with color inputs.

The Eyedropper

Note that some of those color panels have an eyedropper function. Those are awfully handy. Sometimes the color I’m shooting for is right on my screen somewhere, and a color eyedropper is the fastest and easiest way to grab it.

Turns out there is a native API for an eyedropper! You don’t have to use a color input to access an eyedropper.

You can test for support like:

if ("EyeDropper" in window) {
  
}Code language: JavaScript (javascript)

And use it like:

// used in case you need to cancel the experience
const abortController = new AbortController();

const eyeDropper = new EyeDropper();

try {
  const result = await eyeDropper.open({ signal: abortController.signal });
  console.log(result.sRGBHex);
} catch (e) {
  console.error(e);
}Code language: JavaScript (javascript)

Demo

Anywhere you use a color input, you might as well offer an eyedropper, too.

Test for support first, of course, but I think that statement above largely holds true. Offering a dedicated eyedropper button means saving users a step in case that’s what they are trying to do anyway.

And using the native one is nice, as I find it’s generally a nicer color picker than anything integrated into app itself. Eyedroppers built into very major design tools like Adobe Photoshop and Figma largely only let you pick colors from inside the documents themselves, not from anywhere on the screen. Boooo.

The demo above shows how a color input and eyedropper button can work together right next to each other.

Support

Support for color inputs is good across the board, but support for the EyeDropper API, at the time of this writing, is just Chrome’n’friends. No Safari or Firefox.

But the real UX story isn’t quite that clear.

In Firefox, the color input opens the native color picker (both macOS and Windows) and that native picker has an eyedropper. So Firefox users have decently quick access if they need it.

In Safari, the native color picker is an extra click away, but it’s still gettable.

Chrome on Android has no support.

I would have assumed iOS didn’t either, and it’s true that it doesn’t support the EyeDropper API, but in a quick play of iOS 17 on an iPhone 15, the native UI for a color picker has an eye dropper (!!). That’s pretty cool. I would think that brings Safari generally a lot closer to offering the API directly.

One response to “The Color Input & The Color Picker”

  1. I find datalist for color-inputs useful. I think it also works in all browsers now.

    https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist

Leave a Reply

Your email address will not be published. Required fields are marked *