High Definition CSS Color Guide | Hacker News Reader

High Definition CSS Color Guide

developer.chrome.com

164 pointssgammon57 comments

I like that the demo slider is directly from one of Bartosk Ciechanowski's always excellent article [1].

He's really a reference in interactive visualization. There's a link to his article on color spaces labeled "Try it for yourself", but I would prefer a direct and clearer textual attribution to him.

[1]: https://ciechanow.ski/color-spaces

Really low on the part of the authors to not even mention his name.

I mean the source link is right there.

> The following color spaces offer access to larger gamuts than sRGB. The display-p3 color space offers almost twice as many colors as RGB, while Rec2020 offers almost twice as many as display-p3. That's a lot of colors!

Are there any stats on how many people have devices that support these color spaces? Guessing you're not going to get a lot of brands picking p3 colors until it's widely supported by devices in general usage?

p3 has been the default for Apple desktop & mobile displays since 2017 (iPhone 7 era). Other device manufacturers are more likely to have lagged on that but I would imagine a fair number would have added support since.

Also, within CSS & browsers at least, the colours gracefully degrade based on the hardware, so using p3 in a supported browser is not going to look terrible on hardware without p3 support.

Is it fair to say the adoption rate in web design has been low? This is due to device, browser and tooling support or something else?

My general feeling working with designers and web developers is most aren't aware of p3. Figma only got p3 support around 9 months ago I think and Chrome around 1 year ago.

I'd imagine it's largely just due to a combination of inertia & ignorance (though the lack of clarity around display support is almost certainly a factor too).

Apple made a song & dance about it 7 years ago but releases of supporting displays since have been relatively low-key & I'm not aware of any online reference table tracking them - so my guess that support is broad is just that, a guess. I know Samsung & OnePlus phones have it & I assume Pixels (not checked), but laptop adoption could be much lower.

> the colours gracefully degrade based on the hardware, so using p3 in a supported browser is not going to look terrible on hardware without p3 support.

I feel like it makes it difficult for a brand to decide to rebrand themselves using P3 colors if it means their brand colors will be wrong on many people’s displays.

> I feel like it makes it difficult for a brand to decide to rebrand themselves using P3 colors if it means their brand colors will be wrong on many people’s displays.

Only if the colors they choose fall outside the sRGB gamut. And if they do, the brand can specify colors for both gamuts.

  .brand-color {
    /* Fallback for browsers that don't support color-gamut media query */
    background-color: rgb(0, 122, 255); /* sRGB version */
  
    /* For browsers that support wide gamut but without color-gamut media query */
    background-color: color(display-p3 0 0.478 1); /* Display P3 version */
  
    @media (color-gamut: p3) {
      /* For browsers that support Display P3 with color-gamut media query */
      background-color: color(display-p3 0 0.478 1); /* Display P3 version */
    }
  }

FWIW, this is a fairly common thing to have to handle. For example, many brands use colors that can't be perfectly reproduced on paper, t-shirts, etc.

Apple devices (both web and mobile together) are about 23% of web users, even assuming 100% of them are from after 2017. I think you're right that there are quite a few non-Apple displays that support P3, but I can't find stats on how many web users that translates to. I assume it's 50% or less though.

Apple is 23% worldwide, but if a brand is looking at specific markets, it can be as high as 40%+ (US).

As for p3 adoption outside of Apple-land, you're right there's no good stats but I'd wager they're higher than you're making out. 62% of the (global) market is mobile (average replacement cycle is ~2.5 years so most will be a bit newer than 2017). Samsung have adopted p3 & are 24% of global share alone.

Desktop is going to be your smallest share but even there ASUS are selling DCI-P3 laptops for $500. And the growing gamer demographic are going to be investing in their screens after they're done paying for their RTX...

Joke is on them to think I care about any of this when I work on my company-issued ThinkPad T14 with a 45% NTSC screen that maxes out at 300 nits.

Realistically, at this time, this is for developers who works on a MacBook and creates web pages for users that use MacBook or iPad Air/Pro. Most Windows laptops under $600 don't even have sRGB, and even some over $1k don't (like my ThinkPad). sRGB is often as good as it gets with regard to color gamut on (all) Windows laptops, P3 color coverage is very rare. Even more so for Chromebooks. When it comes to monitors, most target sRGB.

Of course what they are doing is important, but it will be a long time before most people can benefit from it.

Mobile devices represent more than half of web traffic in general. Windows laptops are not the primary device CSS color support is trying to address.

Apple, Samsung and Google all ship devices with display P3 capable screens.

I wouldn't call P3 very rare. Thinkpads are available with 100% DCI-P3 OLED displays in addition to 100% sRGB IPS displays. Your company is just cheaping on the configuration. Same goes for Dell XPS line and HP Zbooks, latter which also have P3 IPS display configuration available.

Sure, lots of random corporate office workers might have some crappy bottom of the barrel displays, but then you don't need P3 to see five colors in Excel.

I am aware that there are ThinkPads with P3 displays, but only in very specific configuration. Most come with 45% NTSC displays, and 100% sRGB is an upgrade option in T series. If you don't believe me, you can go to lenovo.com and check this right now. With regard to other brands, yes they have P3 "available", but most standard configurations come with 100% sRGB. And yes I did research on that as well.

Yeah, there's a $1700 hp on my desk with a 6 bit per channel display.

iPhones and Android phones don't exist? Perhaps all Android phones are $200 and don't support HDR.

There's a lot of windows laptops that support P3 or in the case of some OLED displays exceed Display P3's gamut.

The same for monitors. There's 4K OLEDs hitting the market hitting about 80% rec 2020 and completely covering Display P3.

Your display market knowledge is a few years outdated.

When I say "rare", I didn't mean that the models don't exist. I meant that the screens in devices that most people actually buy are crap. I am very aware that there are laptops with OLED screens, and OLED monitors. But they are still in the minority, especially those expensive OLED monitors. If you want to know what the market is really like for Windows devices or monitors, go to Amazon or Best Buy, find the best selling items, and check the display specs. I can guarantee very few support P3.

Surprising to see #rrggbbaa to be <1%, when #rrggbb is the most popular. If you’re already used to hex then why switch to eg rgba when you need alpha? I find it quite useful. Maybe it’s recent and less known.

I feel it is easier to read/write rgba(125,125,125,0.9) compared to #7d7d7de6.

Indeed the RGB values don’t lend themselves to manual tweaking so #ABCDEF is acceptable, but the alpha value is often set manually and most people are not good at writing numbers in hex compared to decimal.

I think it may be because unlike RGB values, which one usually doesn't pick by hand but rather visually through a color picker, the opacity value is something you may want to tweak by hand, and decimal is easier than hex for that purpose.

The #rrggbbaa syntax was indeed introduced much later -- https://caniuse.com/css-rrggbbaa says it only started getting into browsers in 2016-2017, many years after https://caniuse.com/css3-colors added support for rgba().

You answered your own question. It’s less known about, by the time the #rrggbbaa syntax came out people would use rgba() for alpha. Some would also argue the rgba() syntax is more readable when alpha is involved.

If alpha support came out with hex from the beginning then it may be a different story

I personally far prefer rgb() over #rrggbb, it’s really just muscle memory making me use the latter. So given that #rrggbbaa was introduced later, I don’t and won’t get that muscle memory.

99% of the new css features are not known or just unknown, because it's a hassle to use them. Syntax is just plain braindead. Just look at animations, grid and flexbox. These are supposed to fix lots of CSS2 era problems, and they do so in a mindboggingly shitty way. I mean anyone, who was responsible should be shot. And since it's a standard, it won't change for years to come.

So the idiots who established these new, contrived CSS syntaxes literally making people go on all fours, because... well, because they have the power to release such a mountain of shit.

Microsoft's Internet Explorer bullied every web developer for decades. Now Safari earned the honour of becoming the bully amongst web browsers, with their we just couldn't care less attitude. They do things here and there just a tad bit different, because, well, they are Apple, and everyone can fuck off. Like their fullscreen media query implementation, or the blur rendering outside viewport shenanigans just to name a few of their idiotic choices.

And Chrome... we need to wrestle away the browser from Google. The sooner, the better.

A bit hyperbolic, no? Do you really find grid that hard to work with?

And flexbox? Was floats with all those clearings easier? or inline blocks that made us reset whitespace between elements? Or akhem... tables?

Definitely hyperbole. Syntax is not nearly _the_ problem of CSS

Non intuitive syntax is a nogo.

I don't know whether humans or aliens work at the CSS standards bodies, but as time progresses from the advent of the internet the end result gets more and more unusable.

This is important for people who care about color. If you're more of a "sRGB ought to be enough for anybody" person, it will always be there for you.

Blessed are the colorblind, for whom 4 bits/channel is plenty, and color accuracy is a punchline. I’m sorry, normal-visioned person, is this display calibrated so poorly that orange and green are the same color? Welcome to my world.

Hello, fellow colorblind person! Certainly, better color expression doesn't hurt us. And depending on the severity of your color deficiency, the wider range of available colors in large-gamut color spaces can enable us to more easily distinguish between colors that might otherwise appear similar or identical in sRGB.

Why isn't there a more convenient okHSL/HSV way to input colors?

(rather unfortunate such a bad format like RGB is so dominant)

The tracking issue: https://github.com/w3c/csswg-drafts/issues/8659

As noted there, okHSL/HSV keeps the perceptual uniformity by removing some peaks beyond the geometric limit of HSL/HSV, and it is unclear whether it is what users do expect or not.

that's such a minor issue compared to the fact that it's the only human-comprehensible notation (but one that fixes serious hsl/v flaws) that the original question still stands

OkLCH is the best version of that.

Sure, you have to worry about chroma limits, but they reflect the reality of color differences (blues are never going to be as vivid as greens)

it's similar to all the others: either a non-generally-human-comprehensible notation (how is pure red oklch(62.8% 0.25768330773615683 29.2338851923426) treating you?) or seriously flawed (like HSL)

Are you sure you’re not thinking of okLAB? okLCH is basically HSL, with numbers that are consistent. Not sure why those numbers wouldn’t be human comprehensible. You’ve got a lightness of about 62%, which sounds right - that’s how far between black and white you are at pure red. You have a chroma of 0.25, which you need to understand as being ‘quite high’ (0.33 is about as high as chroma goes), which I appreciate is a thing you have to learn, but it’s not beyond human comprehension. Most importantly if you lower that chroma you get colors that are as red, but less intense - which is what you would expect. And then you have a hue, which is an arbitrary angle. Add 180 to it to get a complement though, or add or subtract 120 to get to green or blue.

> 62%, which sounds right - that’s how far between black and white you are at pure red.

First, it's not 62%, but 62.8%, so that's already a fail at producing a basic color. Second, it doesn't sound right - you have no general knowledge/experience clue that this much light between black and white is red, so have no chance for a good guess

> I appreciate is a thing you have to learn, but it’s not beyond human comprehension.

Can you not appreciate that 0-100 is something that you almost don't have to learn?

> if you lower that chroma you get colors that are as red, but less intense - which is what you would expect

Yes, that's the good part!

> And then you have a hue, which is an arbitrary angle

That's another common flaw of all these color notations (they should allow "r" for red and then +-degrees for deviations), but it this case it's worse because it's again not a clean 29 number for a "clean" color

> Add 180 to it to get a complement though, or add or subtract 120 to get to green or blue.

If you remember the whole wheel. Not beyond "human comprehension", just UI fail for the non-expert general human

Why do you want this particular red to be a special easy to pick color?

Such "pure" colors are foundational mental categories, or anchors, so that's only natural they should be the easiest - it makes working with colors more accessible

But they should all be easy, and your suggestion fails at multiple points as I've explained above, not only for red, so the I'm puzzled why you insist it should be that hard and want a proof of the opposite

Red is a much bigger category of color than #ff0000 though.

So? The value of anchor doesn't depend on it being the only color in its category

You can shorten that to oklch(62.8% 0.2576 29.23) and it will still max out the red subpixel on your sRGB monitor, not that this is a particularly serious flaw with okLCH anyway IMO, especially compared to the incomprehensible nonsense that is #RRGGBB unless you're specifically working with sRGB subpixels/pixels and not colour

By some weird coincidence I've been trying to make a wide gamut display work properly on Windows just yesterday. Short version: no success. We're so close but still so far.

Long rant: I've got a Windows 10 machine with NVidia graphics, a company issued Windows 11 laptop with an integrated Intel GPU and a fairly recent Macbook. The display in question is MSI MAG274UPF, which can be considered wide gamut.

Mac (presumably) pulls RGB primaries from the EDID and performs the necessary gamut mapping without losing the ability to display images in P3 space. Colors are perfect, wide gamut tests pass, everyone's happy.

Windows 10 has no idea what to do with WCG and displays everything in ultra vivid, extra saturated colors even after trying to mess with vendor-provided ICC profile. WCG tests fail.

Windows 11 should have Auto Color Management, which in theory should bring us roughly to feature parity with macOS, but for some reason it allows me to turn it on only on the laptop's internal display, which has ~60% sRGB coverage. Apparently Windows does not want to enable gamut mapping in SDR mode on HDR certified displays, even if they conform only to DisplayHDR 400 specification, which is an abomination in itself. Results are the same as with Windows 10.

My disappointment is immeasurable. We could have proper WCG support in Windows world.

This seems important.

edit: omg non-banded gradients, finally.

Sadly only less banding.

With the tiny pixels of modern displays and dithering, couldn't even more colors be achieved?

The article says #rgb is used 25% of the time... but Chrome gives a warning about it

Is your point that people shouldn't be using a standard feature because chrome doesn't like it or that chrome shouldn't be complaining because 25% of all colour declarations use this syntax?

I think Chrome should stop complaining ;)

Anyone else irked by the inclusion of `currentColor`? I don't see the relevance.

It simply lists all the ways in which developers specify color in css, and explicitly typing currentColor is a valid option. I use currentColor as an SVG default for instance, when icons should match text color.

Good to know for instance that a bunch of stuff could be deprecated.

I understand what it does and it certainly has its uses but it has little relation to high definition color usage this blog covers.

Can you elaborate on the deprecation part though?

It is not that strange to use `currentColor` to define properties other than `color` itself.

See also https://notes.dt.in.th/HDRQRCode which was discussed here about a year ago, allowing you to create brighter-than-#fff

Reply on news.ycombinator.com