As per https://github.com/whatwg/html/pull/10456

The spec PR has been merged.

This is needed to be able to pick display-p3 colors with the eyedropper as <input> proposal.

:hsinyi, do you have any idea when this feature will be available ?

We need bug 1629388 to have some control over color picker.

(I didn't mean to clear my NI)

Bug 1629388 is in progress.

Removing some dependencies:

1. The graphic dependency is about picker but we can still implement the attribute without actually having P3 picker. We can convert sRGB value from picker to P3 representation to fulfill the spec requirements. Users would still be only able to choose within sRGB range though. Using P3 for the picker is straightforward but right now doing so is no-op, as it turns out that we don't do color mapping - gradient in P3 white-to-red looks exactly same to sRGB white-to-red even on MacBook P3 display.
2. In the same way, technically we don't have to fix the Android color picker to implement this. Alpha should be disabled until Android gets the picker support though, for feature detection purpose. The Android work would need some actual Android person to take. (gamut detection is possible through matchMedia("(color-gamut: p3)").matches.)

note: there should be tests to ensure that setting colorspace/alpha HTML attributes via setAttribute also runs value sanitization.

I realized that this should not be specific to IDL setter.

Release Note Request (optional, but appreciated)
[Why is this notable]: Implementing extra attributes for input element
[Affects Firefox for Android]: Yes
[Suggested wording]: Adding colorspace HTML attributes for <input type=color> elements will now affect the value to be expressed in the requested colorspace and/or with alpha. They do not affect the color picker behavior yet, but it's coming in bug 2007532. alpha is Nightly only for now.
[Links (documentation, blog post, etc)]:

For MDN/BCD purpose, we currently mark it incomplete for color() syntax support in HTML input element. We can mark it complete. The alpha value will be filtered out until it's enabled in stable...

Backed out for causing reftest failures @transformations-1.html.

• Backout link
• Push with failures
• Failure Log

Huh? How come is this Android specific?

It also fails on linux.

Thanks, then it makes much more sense.

(But it doesn't fail locally, it even gives 0 pixel difference. 🤔)

Just want to point out that the current plan to ship the attributes without the picker behaviour does mean that feature detection is effectively impossible. I think it's less important for color space but for alpha especially it seems problematic to advertise support when you don't have it. If I wanted to decide whether to show a custom picker or use the default browsers one this means I can't do that.

At the very least it would seem good if alpha was wired up to the platform pickers where possible before the web picker ships (macOS's and GTKs definitely support it).

I thought about not shipping alpha, but changed my mind after realizing that alpha does affect the value too and is not fully unusable without alpha slider... But probably alpha should be behind pref for now, yeah. Thank for the feedback.

https://hg.mozilla.org/mozilla-central/rev/adbed6a1d5fb
https://hg.mozilla.org/mozilla-central/rev/1a3672c20420
https://hg.mozilla.org/mozilla-central/rev/dcf5f918e1fc

Added with this wording::

You can now set specific color spaces and transparency (alpha) on <input type="color"> elements, with alpha support currently exclusive to Firefox Nightly. While the visual picker hasn't changed yet (tracked in Bug 2007532), it will now output values in your requested format.

The note will be part of the Nightly release notes for 3 cycles (149-151).
When we extend the support to the release channel, a new release note request will be needed.