-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow <input type="color"> to give an alpha channel and/or colors beyond sRGB? #3400
Comments
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 |
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 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 |
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. |
Paging @svgeesus because of the earlier username typo. Lack of alpha channel support in |
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:
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.
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. |
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 |
Chiming in from the sidelines here, I think two of the general API design considerations for this sort of thing are:
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 |
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. |
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 |
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 @svgeesus Is my assumption that any CSS color can be represented as |
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 I actually rather like the The |
I'm not a huge fan of introducing another input type. Input |
@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. |
Another idea would be to expose a |
|
For submission, the regular If we decide to extend |
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 |
I would prefer a new tag, though one completely unrelated to 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
Additionally the following apply to some controls but not others: |
@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... |
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 |
In hindsight, I think it was a mistake to extend 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. |
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 |
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.
Both "rec2100-pq" and "rec2100-hlg" should be supported, for parity with Chrome's upcoming HDR canvas.
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". |
I would be hesitant to expand things to include HDR spaces like What @kdashg said is accurate. While we have lots of different schemes in prototyping behind flags (including the auto-tone-mapped 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 Then based on adoption of this new attribute and web developer demand we can consider these items for subsequent iterations:
|
|
@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 color-picker-alpha.mp4 |
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
with |
The new alpha and colorspace attributes give it parity with the 2D canvas API. As part of this change we do away with the "simple color" concept as that has been replaced by CSS colors now. Fixes #3400.
The new alpha and colorspace attributes give it parity with the 2D canvas API. As part of this change we do away with the "simple color" concept as that has been replaced by CSS colors now. Fixes #3400.
I keep coming back here and then closing the tab without commenting.
|
Yes, the PR supports setting it to any CSS color. And to be clear, the |
Great! That might be an even bigger improvement than the new attributes! Some questions:
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
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. |
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. |
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.
Essentially.
In theory, though I would expect the UA to mostly inform itself from the
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.
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. |
The new alpha and colorspace attributes give it parity with the 2D canvas API. As part of this change we do away with the "simple color" concept as that has been replaced by CSS colors now. Fixes #3400.
The new alpha and colorspace attributes give it parity with the 2D canvas API. As part of this change we do away with the "simple color" concept as that has been replaced by CSS colors now. Fixes #3400.
The new alpha and colorspace attributes give it parity with the 2D canvas API. As part of this change we do away with the "simple color" concept as that has been replaced by CSS colors now. Fixes #3400.
The new alpha and colorspace attributes give it parity with the 2D canvas API. As part of this change we do away with the "simple color" concept as that has been replaced by CSS colors now. Fixes #3400.
The new alpha and colorspace attributes give it parity with the 2D canvas API. As part of this change we do away with the "simple color" concept as that has been replaced by CSS colors now. Fixes whatwg#3400.
Or some new related input type.
Suggested in https://twitter.com/jashkenas/status/956321122684878848. It does seem like for a large class of color inputs, e.g. image editors, this would be a good idea.
The text was updated successfully, but these errors were encountered: