Comment by frosted-flakes | Hacker News Reader

Comment by frosted-flakes | Hacker News Reader

The proposed color-contrast() function in the CSS Color Module Level 6[1] will make solving this problem a lot easier. Rather than doing some messy, complicated calculations on individual color component values, this new function will allow you to pass in a base color, an optional target contrast level, and a list of possible foreground colors (defaulting to white, black). The function will choose the first option that meets the target contrast, or the highest contrast if no target contrast level is supplied.

For example:

  contrast-color(
      wheat tbd-bg wcag2(aa),
      bisque, darkgoldenrod, olive, sienna, darkgreen, maroon
  )

will return "darkgreen".

- "wcag2(aa)" means level AA of the WCAG2.1 luminance contrast algorithm, which computes to "4.5".

- "tbd-bg/tbd-fg" sets whether it is determining the background or the text color.

This proposal is still in the experimental phase, and not all parts of the spec are finalized (such as the tbd-bg or tbd-fg keywords, or even the name of the function itself).

[1]: https://w3c.github.io/csswg-drafts/css-color-6/#colorcontras...

Great, maybe HN can use it instead of fucking light gray on white

HN uses light grey text in certain applications to intentionally make it harder to read. For text submissions, it's to discourage their use over link submissions. It's a mistake, in my opinion, but it's been like that from the very start.

Part of the reason people come to HN is because it never changes.

This is so silly. Just because radical change is alienating doesn’t mean that smaller improvements wouldn't be positively received. For example, an end to silently swallowing emoji would be an improvement, not a regression. Poor design that actually excludes people is not a treasured feature.

I'll bite: How does swallowing emoji exclude people?

It excludes annoying people who use emojis. I just wish it was updated to include removing the ascii emojis they unnecessarily add, often at the end of posts :)

If a feature excludes a certain kind of people, it might very well be an improvement.

Excluding people that want to shove emoji in is morally good thing.

I treasure not having to look at emojis on HN. Not sure who this "excludes" but I'm fine that that

HN changes all the time. There are lots of new features added that were not present when I first stumbled upon this site.

It’s an unfortunate decision. Makes things like thoughtfully written Launch HNs painful (literally, for me anyway) to read.

There are extensions you can get that will insert stylesheets scoped to specific pages. HackerNews, a site that never changes is a perfect use-case for something like this

I use it for a number of sites I browse regularly

I use Dark Reader to increase the contrast of HN and also make it "dark mode". Highly recommended extension; you can undo a lot of designer-inflicted damage with one click.

Even the top bar is barely legible, light grey on light... whatever color is that.

Or maybe just whoever designed that had different monitor settings than average user and it looks okayish there...

Seems like something that could be calculated and baked server side

For accessibility, it’s better to do this client side, so clients can adjust it themselves to be more contrasting or whatever.

that's cool. use both. calculate a good default contrast server side, use proposal to allow client side to override default

Unless it's a dynamic arbitrary colour (user-selected, overlaid on an image, etc.) then there's not much reason to be doing colour contrast calculations.

Your site's design should just have well-chosen colours.

The only reason this is a problem is because different monitors have different display characteristics compounded by arbitrary viewing environments. A client-side function can measure neither the response of the monitor nor the ambient light of the room, so this problem can never be solved in this manner.

Both of those are already APIs today in phones.

And there's decent reason to not want to tell the server either.

So GP was relevant because that’s exactly what GitHub is doing: dynamically picking arbitrary colors and trying to put appropriately contrasting text on them.

But you still need to pick contrasting colors manually ? This one isn't making new ones for you.

CSS function doing "here is color A, here is color B, make one that is same hue as color B but contrasting" would be much more useful

Clients are free to provide a contrast dial independently of that. For example there’s a Font Contrast extension for Firefox.

If it's a static colour, sure. But if it's set by the user with a colour picker, that doesn't really work.

except the server doesn't know if the client prefers light or dark mode

Reply on news.ycombinator.com