With the normalized format being defined as a simple color, it's quite likely that both clientside and serverside logic have come to depend on this for processing the value. There are likely also use cases where only accepting opaque colors is desirable.

Taking that into consideration, it's probably necessary to introduce a new alpha-color (or color-alpha) type which takes a CSS <color> as its value to avoid breaking existing expectations. This can potentially be normalized to the eight-digit hexadecimal notation to make the two color types consistent and easier to transition between.

Just adding some references here to other disucssion as I just became aware of this limitation. Could hardly believe that didn't support the CSS3 transparency stuff. Seems like a serious inconsistency in the the cooperating language specs.

References:

Discussion at w3c/html#1422 which was closed, suggesting further discussion here.

https://bugzilla.mozilla.org/show_bug.cgi?id=1613301 My bug report on Firefox, before I became aware this was a spec issue.

@Zirro is probably correct that a new type would be required.

Agree that a new input type is likely necessary due to the existing consumers that likely depend on the 6-hex format. I also agree that just using the 8-hex format for this type="color-with-alpha" (or whatever) is the easiest way to go about this.

Thinking a little further, tho, CSS has grown colors beyond what the hex format can describe, both with wider gamuts than the 0-255 range and with more precision than those integers can provide. We might want to instead consider a format that allows more expansive color definitions; this would require more impl support promises than the seemingly-obvious addition of just throwing in alpha, but it has promise.

In particular, the most general format of built-in colors that we could use for serializing the value is, I believe, the lab() function. (Ignoring things like imported color profiles, which requires more support than I think would be reasonable for an input type.) @svgeezus might have more details on that.

There was a link in one discussion I found to a tool used in DevTools of the "big 3" browsers already: https://bgrins.github.io/spectrum/ but it doesn't seem to have lab() function output.

It might be a good model to follow for a picker, if it can be extended to support the broadest CSS color spaces, and I agree that there is no point in making an extension one step at a time.

One thing that seems nice about this picker is the conversion functions so that you can obtain the colors in a variety of formats. While a new picker implementation should probably support the broadest currently-planned or standardized color spaces, perhaps the new HTML input type should have a way of specifying what format is desired for output, which would not only serve the purpose of allowing compatibility with the current type=color (which could be revised ot use the same picker, if practical implementation-wise), but would cover the case of future additions to color-spaces, should any happen: while the picker could get improved to handle even broader color-spaces, the input type could have a way to specify the format it wants back, for compatibility with the usage it is put to, avoiding the need to invent more new input types for future color-space expansion.

In particular, the most general format of built-in colors that we could use for serializing the value is, I believe, the lab() function. (Ignoring things like imported color profiles, which requires more support than I think would be reasonable for an input type.) @svgeezus might have more details on that.

Paging @svgeesus because of the earlier username typo.

Lack of alpha channel support in <input type=color> is the main reason we have a custom color picker implementation in Chrome DevTools at this point. We'd love to get rid of our custom color picker in favor of the platform!

Thanks @mathiasbynens :)

I agree that the addition of alpha has merit; note that now in CSS Color 4, the rgb() form can also have an optional alpha and rgba is legacy.

Also agree with @tabatkins that a new input type will be required to avoid breaking code that assumes 6-digit hex, only.

If a new input type is defined now, to add alpha, how likely is it that another one could be added further down the line? Do we only get one shot at this? Some considerations:

• other, wider gamut RGB(A) colorspaces are coming, notably display-p3 which corresponds to the wide gamut screens already shipping on phones, laptops and external monitors
• because of that, greater bit-depth that 8 bits per component is desirable (for a wider space you need more bits to avoid banding). display-p3 really needs 10 bits per component; rec2020 requires a minumum of 10 and really needs 12. CSS already has a way to specify arbitrary precision, for example rgb(87.234% 23.123% 6.987654321%) but existing implementations tend to truncate this to 8 bits per component.

So, when minting a new color input type that accepts alpha, being able to accept a) a higher bit depth than 8-per-component and b) being able to accept other RGB spaces than sRGB should at least be considered, as useful future proofing.

Looking further forward, CIE Lab (and LCH, the polar form) are coming, CSS Color 4 specifies them and there is implementer interest; CSS Color 5 uses these to do color modification such as color mixing. These types really need to use 3 floats. LCH is also a nice model for a color picker because it is perceptually uniform unlike, say, HSL.

I would love to see Lab and LCH added but, if now is not the time, their likely impact should be considered when making a new RGB(A) input type.

While a new picker implementation should probably support the broadest currently-planned or standardized color spaces, perhaps the new HTML input type should have a way of specifying what format is desired for output

That would be a very useful, and nicely future proof, addition which would lessen the impact when it gets extended because developers would already be asking for the specific format their scripts are expecting.

the most general format of built-in colors that we could use for serializing the value is, I believe, the lab() function. (Ignoring things like imported color profiles, which requires more support

Not specific to a color input type, but just for clarification: color profiles, such as for CMYK, take as input a Lab value so the lab() function would be just fine there too. I agree though that a color input type should probably not be offering CMYK etc choices (and in particular, should not offer them if it is doing naive conversion).

Chiming in from the sidelines here, I think two of the general API design considerations for this sort of thing are:

• <input> is already a mess. We could add more to the mess (e.g. a new type="" value, or a format="" that applies only to type="color", or valueWithAlpha/valueAsWideGamut getters, or...). Or we could start over with a new input type (e.g. like switch attempted). Although it'd be nice to avoid extending the mess, it sure is convenient and expedient.

• Reusing <input> also has a better backward-compatibility story. For example if we did <input type="alphacolor"> then in browsers that don't implement the user would get a text box, which might be better than nothing. Or, if we reused <input type="color"> and added some of the additions mentioned above, we could have sites which accept alpha-less colors in older browsers and alpha-ful colors in new ones.

So overall, I guess I'd urge thinking about what you want your story to be for web developers, when they are trying to support both browsers that implement the new type, and browsers that don't. That guides whether to reuse <input> or not, and if so, how to extend it.

By the way, an example of an LCH color picker, with alpha (which I have been using to help me make examples for CSS Color 4). Not that this helps the design of an HTML input control, just that people who have not come across Lab and LCH might find it interesting to play with.

So overall, I guess I'd urge thinking about what you want your story to be for web developers, when they are trying to support both browsers that implement the new type, and browsers that don't. That guides whether to reuse <input> or not, and if so, how to extend it.

For new input types, the web developer story has always been detecting support, and loading a custom fallback implementation if needed, à la:

function supportsInputType(type) {
  const input = document.createElement('input');
  input.type = type;
  return input.type === type;
}

if (!supportsInputType('color')) {
  enhanceColorInputs();
}

In my opinion, adding a new input type, separate from color, seems like the way to go.

While a new picker implementation should probably support the broadest currently-planned or standardized color spaces, perhaps the new HTML input type should have a way of specifying what format is desired for output

That would be a very useful, and nicely future proof, addition which would lessen the impact when it gets extended because developers would already be asking for the specific format their scripts are expecting.

So, something like:

<input type="color-2.0" colorspace="display-p3">
input.value; // -> 'color(display-p3 1 1 1 / 0.42)'

<input type="color-2.0" colorspace="srgb">
input.value; // -> 'color(srgb 1 1 1 / 0.42)'

We could also provide input.valueAsColor(colorspace) (similar to input.valueAsNumber() and input.valueAsDate()), which lets developers programmatically get a serialized CSS <color> of the form 'color(colorspace 1 1 1)' in the colorspace of their choosing.

@svgeesus Is my assumption that any CSS color can be represented as color(...) correct? Will this be true going forward? In that case, color(...) seems like the ideal serialization.

Is my assumption that any CSS color can be represented as color(...) correct? Will this be true going forward? In that case, color(...) seems like the ideal serialization.

This is currently true, and there's a good chance it will remain true in the future. However, CSS has made the affirmative decision to serialize with the more specific functions when we can; sRGB colors with rgb(), lab colors with lab(), etc., and we would presumably match that here.

I actually rather like the .valueAsColor() idea, because it lets us separate the ideas of colorspace and serialization format (so we could serialize as hsl() or lch() if the author wanted, which could def be useful).

The colorspace="" attribute would still be useful on the input itself, so it knows what color range to show in the picker; presumably it would default to sRGB if unspecified.

I'm not a huge fan of introducing another input type. Input type="color" has pretty low usage overall and I think as long as we by default return what we do today we shouldn't need a new input. Can we do progressive enhancement here, such that adding in the attribute of colorspace will result in the value being changed?

@gregwhitworth You’d need at least one attribute for the colorspace and another attribute to enable the alpha-channel. Personally I’d rather avoid the combinatorial explosion of options if we can avoid it.

I actually rather like the .valueAsColor() idea, because it lets us separate the ideas of colorspace and serialization format (so we could serialize as hsl() or lch() if the author wanted, which could def be useful).

Another idea would be to expose a Color constructor as CSS.Color (although this would be specified in CSSOM, not HTML), which could programmatically represent CSS color values and convert them to various formats and across color spaces. (It’s not either-or; we could do .valueAsColor as well if that seems useful.) cc @zcorpan

valueAsColor() doesn't help with submission.

For submission, the regular .value would be used, which for a new <input type="css-color"> could be the serialized CSS color.

If we decide to extend <input type="color"> instead, e.g. <input type="color" alpha widegamut>, we could do the same thing, except that if none of the new attributes are present the current "valid simple color" serialization is used.

If we decide to extend instead, e.g. , we could do the same thing, except that if none of the new attributes are present the current "valid simple color" serialization is used.

This is exactly what I had in mind. One aspect that I would be open to entertaining that I've been wanting to explore but haven't dug into the HTML parser too far is doing away with the input type within HTML (not the API extension) altogether for complex inputs. Color is actually a prime example of this, while yes it can be represented as a string, very few end user scenarios are actually going to enter them in as such so PE for this doesn't make much sense in the majority of use cases. Even for pros they'll normally have them separated out where the color input is actually represented by different inputs using a text field - photoshop being a prime example of this:

What if, color 2.0 is actually just <color>? It would then get its own HTMLColorInputElement which we would hopefully be able to have a base interface from HTMLInputElement (maybe this is already the case in IDL form as well) as we would of course still need to support value, validation, etc.

What if, color 2.0 is actually just <color>?

I would prefer a new tag, though one completely unrelated to HTMLInputElement. (You can't have that as a base class without inheriting all of its complexity.)

There are no parser concerns if it parses like any unknown/custom element. (I.e., the end tag is required.)

See my above comment at #3400 (comment).

@domenic that's great - sorry I missed that statement but I would really prefer to have a new control altogether with HTML tag and input element. My only hesitation is while HTMLInputElement is a mess we may have to duplicate a lot of the properties that do overlap still. I'm going to float this by our devs though just in case I'm missing something here.

I don't quite understand what you mean by "have a new control altogether with HTML tag and input element". But in general I'd encourage you to look at https://github.com/tkent-google/std-switch/, or just at <select> or <textarea>, which are existing examples of form controls that don't use <input>. The overlap is basically:

• Validity stuff
• form, labels
• name, type
• disabled

Additionally the following apply to some controls but not others: required, placeholder, readonly, autocomplete, minlength, maxlength. One of the major benefits of using a new element (like select/textarea/std-switch) is to only include the ones from that list which apply to your case.

@domenic my concern was only the duplication of that overlap; if it's relatively straight forward then I am even more interested in this approach.

Awesome. The main downside of a new control is the fallback story being less automatic, but @mathiasbynens seems to indicate that most developers use JavaScript for fallbacks anyway, so maybe it's less of a concern.

Yeah, fallback to text, while barely acceptable for color input, is still pretty terrible, so a JS-driven fallback is pretty much required for a decent UX.

I need to finally get the Typed OM story together for CSSColorValue objects, so this could return one of those...

Yeah, fallback to text, while barely acceptable for color input, is still pretty terrible, so a JS-driven fallback is pretty much required for a decent UX.

I don't want to hijack this thread but has there been a general discussion around ALL inputs and which should get the same treatment? If not I'll fork this one as I'd like to do that in one fell swoop and possibly in alignment with the folks doing research at Open UI.

Specific to naming, it's surprising to see how few component frameworks actually create a color picker (name matrix here). But it seems that if we're going to create a new element then it should either be <color> or <colorpicker>. Colorpicker has 2 usages where as color has 1.

In hindsight, I think it was a mistake to extend input for the cases where text input fallback isn't useful enough (like color, date/time, range). To continue to add new types or extensions to existing types to represent new controls will add to the complexity further.

A downside to creating a new element for colorpicker is that there would be 2 ways to create a colorpicker. We already have this situation with buttons, without it causing much trouble, as far as I can tell.

I want to second the mention of https://github.com/WICG/color-api I think a new Color object would be very useful. I assume that without it the value would be something like color(display-p3 1 0.5 0)?

Would the enumerated attribute allow you to specify multiple values? For example if you wanted to support multiple colour spaces?

I also want to say while it's a slightly different concept it would be interesting if we could allow a user to pick something other than hex, such as HSL, or oklch?

Chrome dev tools has a very rich colour input (see below) and it would be interesting if we could allow web authors to get more of that functionality.

Editor of Color API here (and CSS Color). I recently proposed we focus on shipping a Level 1 that can only describe colors, and defer all the manipulation stuff for later levels, exactly to support these types of use cases ASAP. If that is of interest, we'd love to hear from implementors about what might be reasonable to include in L1 so it could ship quickly.

WRT the HTML element API discussed here, I do think the use cases for wide gamut and the use cases for alpha are separate. It's common in native apps to have a color picker that can only pick opaque colors because the underlying setting does not support transparency, and it's a jarring user experience to select a color with alpha only to have the alpha discarded, not to mention clutters the color picking UI. That's why most web components that have a color picker provide a separate control point for this (e.g. see <sl-color-picker>)

If you enable display-p3 editing, please also include Rec.2100 editing too, since that's the canvas format that Chrome browser supports.

FWIW, on iPhones when doing the "Markup Mode" for adding text and lines to photographs, it uses a Display-P3 hex format that you can edit directly as text. (RGB colorstretched to cover the whole DCI-P3 colorspace)

Although linearized DCI-P3 is not common, it seems to be what was used for this specific Apple iOS-builtin colorpicker screen.

Personally, I'd like the ability to edit Rec.2020 and Rec.2100 (intensity level included) for the brighter-than-white available in Chrome's CANVAS in "Experimental Web Platforms Features" enabled. But I understand it's a giant rabbit hole.

This would be an enumerated attribute that is reflected to allow for feature testing. And we'd like it to minimally support "srgb" and "display-p3" as values for parity with canvas, but are open to supporting more color spaces defined in CSS Color. Not sure if the current "simple color" value space needs its own attribute value or if that should be the fallback.

Both "rec2100-pq" and "rec2100-hlg" should be supported, for parity with Chrome's upcoming HDR canvas.

We do not think that alpha channel needs a separate control point.

Agreed.

However, keep in mind rec2100-pq and rec2100-hlg canvas, you can use brighter-than-white, so you can use numbers bigger than 1 with rec2020 CSS4, such as color(rec2020 0 3 0) to have a very bright green (that works in Chrome/Edge). This would require additional thought. I use an Intensity control point in my custom colorpicker, but there are also other workflows for this.

Observation: It seems like Safari is standardizing around DCI-P3 and Chrome/Edge is standardizing around Rec.2100 (at least for CANVAS graphics). I would like to see all of these supported. Otherwise, it is likely better to support neither until such time that all web platforms can agree on a common set of WCG/HDR standards applicable to both browsers.

I would not describe what I know of WCG/HDR standardization as "webkit -> display-p3, blink -> rec2100".
My understanding of the current path forward for hdr canvas in Chrome is effectively just unclamped float srgb/display-p3 values mapped into the maybe-hdr display color-profile of the monitor. @ccameron-chromium is the one to ask, though.

I would be hesitant to expand things to include HDR spaces like rec2100-pq et al, because I'm not sure they're the right direction to go.

What @kdashg said is accurate. While we have lots of different schemes in prototyping behind flags (including the auto-tone-mapped rec2100-hlg and rec2100-pq), at present the only HDR canvas scheme that is sufficiently-well-defined-and-future-proof to ship is the "extended range" mode. The explainer for that shows how it would be extended to things like HDR10 mode (natural to use with rec2100-pq), but that will require ensuring interoperable conversions (this issue, which is making progress in standards but not quite ready yet).

Also of note is that in terms of specifying HDR colors, the scheme promoted by HDR gainmap images has proven much better at integrating into operating systems compared to the "broadcast" schemes of PQ and HLG. In such a scheme, one can only specify an HDR color via a mechanism that indicates "use color X in SDR and color Y on displays with HDR headroom Z". I am hoping that (via the aforementioned standards work), we can shoehorn PQ and HLG into such a framework.

Based on the discussion thus it seems like colorspace with values TBD ("plain", "legacy", "default"?), "srgb", and "display-p3" would work. Once we have this attribute in place it should be quite easy to add additional color spaces. How rich the color picker ends up being remains up to the implementation and they could offer multiple color spaces for selection, as long as they serialize per the colorspace attribute value.

Then based on adoption of this new attribute and web developer demand we can consider these items for subsequent iterations:

• Additional color spaces (as mentioned).
• Exposing the value as a JavaScript object.
• Configuring aspects of the color picker, such as whether it allows selection of the alpha channel.
• "Eyedropper" support, as suggested in Consider extending <input type=color> instead WICG/eyedropper-api#35.

I'm glad to see that Safari DevTools has implemented Eyedropper, and am eager to see Eyedropper integrated in input color as well.

Based on the discussion thus it seems like colorspace with values TBD ("plain", "legacy", "default"?), "srgb", and "display-p3" would work. Once we have this attribute in place it should be quite easy to add additional color spaces. How rich the color picker ends up being remains up to the implementation and they could offer multiple color spaces for selection, as long as they serialize per the colorspace attribute value.

Then based on adoption of this new attribute and web developer demand we can consider these items for subsequent iterations:

• Additional color spaces (as mentioned).
• Exposing the value as a JavaScript object.
• Configuring aspects of the color picker, such as whether it allows selection of the alpha channel.
• "Eyedropper" support, as suggested in Consider extending instead WICG/eyedropper-api#35.

srgb and display-p3 are all RGB spaces with different gamuts. Given that other color spaces are far more suitable for color picking (OKLCh, OKHSL, even HSL), it seems far more useful to include some of these. Also, the color model and the gamut selected are somewhat orthogonal — there's a lot of value in using LCH to pick a color, yet staying within the P3 gamut. So, perhaps they should be separate settings?

@LeaVerou this is not about dictating UI. A user agent is free to use other color spaces (or offer multiple) in the picker itself. This is about the colors that will be returned to the website.

I've implemented a color picker with alpha by combining it with an input range(Demo), and the main problem I'm having is the flickering that occurs with repeated calls to showPicker().

@LeaVerou this is not about dictating UI. A user agent is free to use other color spaces (or offer multiple) in the picker itself. This is about the colors that will be returned to the website.

More reason to frame it around gamut rather than color space then.

I'm not entirely sure what you mean by that. "Color space" is the term we use elsewhere to pick between srgb, display-p3, and a possible future rec2020. I don't think we want to deviate from that here.

I also wanted to share that we got some feedback internally that configuring alpha would be nice from the get go. I think that would make the amended proposed API look like

<input type=color colorspace=display-p3 alpha>

with alpha being a boolean attribute. Perhaps the initial value for colorspace could be "hex" referencing the color serialization syntax we use there, which these days can also support an alpha channel.

I keep coming back here and then closing the tab without commenting.

1. Color spaces are not just gamuts but also define the coordinate space of how you specify a color. Here you’re essentially specifying a gamut, so I personally find the name colorspace confusing. To me, a colorspace attribute implies that it affects the UI as well, not just the gamut of the color returned, which is not the case here. I’m aware that the corresponding Canvas parameter was called colorSpace, but that’s less confusing because there is no UI to be affected so no author confusion.
2. Supporting just two values seems strange. If you have two values that restrict gamut, you should at least also a value that doesn’t (which could return a lab or oklab color).
3. If <input type=color> starts returning things like color(display-p3 0 1 0) it’s a reasonable author expectation that they can set the value IDL attribute to any valid CSS color. It has already been confusing that they couldn't when it only accepted 6 digit hex colors. I wonder if we could also support that? With the Color API you could frame it as calling Color.parse() and then color.to("display-p3").

Yes, the PR supports setting it to any CSS color. And to be clear, the colorspace attribute is also a hint for the user interface of selecting a CSS color, but the observable (and most normative) bits are what gets returned by value and submitted to the server.

Yes, the PR supports setting it to any CSS color.

Great! That might be an even bigger improvement than the new attributes!

Some questions:

• What happens when you set it to a CSS color that is outside the gamut specified by the attribute? Does it get gamut mapped? Clipped? Is it just out of range?
• If output colors are serialized to color(display-p3), does that mean the format the color was in is discarded? Does the UA have access to it so it can use it to inform the UI displayed?

If any CSS color is accepted, it would be good to at least support some kind of opt-in syntax that roundtrips properly and/or allows the UA to return any valid CSS color. Perhaps colorspace="any" or colorspace="unrestricted"?

And to be clear, the colorspace attribute is also a hint for the user interface of selecting a CSS color, but the observable (and most normative) bits are what gets returned by value and submitted to the server.

It shouldn’t be though. You almost never want an RGB-based UI for selecting a color — typically color pickers use polar spaces (HSL, HSV, LCH, OKLCH, etc) for their UIs since they’re closer to how humans think about color.

I suspect what you mean is that it’s a hint about the gamut the UI should expose, which brings us back to what I’m saying — none of this is really specifying a color space for the picker, just a gamut and serialization format for the result…

Also, by separating output gamut from actual color space used for the selection, you leave open the future possibility of specifying a hint for the color space used in the color selection UI, which is orthogonal to the gamut the selected color is in. E.g. you may want to hint that the UA should display an OKLCH-based UI, but still constrain the output to the P3 gamut. E.g. see https://oklch.com/ for one example of what a gamut-constrained picker in an unconstrained color space could look like.

Btw I’m having trouble finding the list of use cases for this new attribute, if you could point to it, that would be quite helpful.

It shouldn’t be though. You almost never want an RGB-based UI for selecting a color — typically color pickers use polar spaces (HSL, HSV, LCH, OKLCH, etc) for their UIs since they’re closer to how humans think about color.

Depends on the industry. Graphics artist app? Vision science? Display calibration patterns? Or something else?

While HSL is superior in many ways, it isn't wanted by all. It depends on the industry / who / use case / etc. Some focus on RGB colorspace.

Also, the built audience of web developers are used to RGB hex color spaces, which means HSL is often a learning curve to them if they aren't graphics artists.

In addition, many color pickers let you switch between RGB and HSL color pickers, so that should ideally be the path forward for most colorpickers presented on the web.

As creator of TestUFO, I work in the display industry, and displays are based on R/G/B pixels, and TestUFO display-testing website uses the R/G/B colorpicker workflow. This continues under TestUFO 2.0 WCG/HDR. From CRTs to plasma to LCD to OLED, they all are based on the R/G/B principle, and testing the color channels directly requires precise control of the pixels.

TLDR: Browser based color pickers should provide a choice of either RGB and HSL workflows.

What happens when you set it to a CSS color that is outside the gamut specified by the attribute?

This depends on what the conversion between color spaces ends up doing. For "limited-srgb" though we will also clip as we have to serialize using hex digits.

If output colors are serialized to color(display-p3), does that mean the format the color was in is discarded?

Essentially.

Does the UA have access to it so it can use it to inform the UI displayed?

In theory, though I would expect the UA to mostly inform itself from the colorspace attribute and the capabilities of the OS and associated hardware.

I suspect what you mean is that it’s a hint about the gamut the UI should expose, which brings us back to what I’m saying — none of this is really specifying a color space for the picker, just a gamut and serialization format for the result…

That's accurate, but I don't think introducing new language for that is needed at this point as it would go against the precedent we set with canvas and confuse matters too much for the rather simple needs we have. If indeed we saw a need to separate the two in the future there's ample syntax we could use for that, though I doubt it will be needed as at that point we'd probably expose the color as an object as well so people can do whatever.

Btw I’m having trouble finding the list of use cases for this new attribute, if you could point to it, that would be quite helpful.

I think we only have this thread. But the main use case is that now P3 displays are more prominent it would be good if you could select all their colors in the HTML color picker. And alpha channel has been a missing feature that is available in platform color pickers and has been requested quite a few times so would be good to add as well.