8 ms·

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

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/#colorcontrast https://w3c.github.io/csswg-drafts/css-color-6/#colorcontras...

pyrolistical 4y ago
Seems like something that could be calculated and baked server side
- madeofpalk 4y ago
  except the server doesn't know if the client prefers light or dark mode
- ok_dad 4y ago
  For accessibility, it’s better to do this client side, so clients can adjust it themselves to be more contrasting or whatever.
  - pyrolistical 4y ago
    that's cool. use both. calculate a good default contrast server side, use proposal to allow client side to override default
    - sharlos201068 4y ago
      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.
      - anikom15 4y ago
        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.
        namibj 4y ago
        Both of those are already APIs today in phones. And there's decent reason to not want to tell the server either.
      - eyelidlessness 4y ago
        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.
  - ilyt 4y ago
    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
  - layer8 4y ago
    Clients are free to provide a contrast dial independently of that. For example there’s a Font Contrast extension for Firefox.
- frosted-flakes 4y ago
  If it's a static colour, sure. But if it's set by the user with a colour picker, that doesn't really work.
ilyt 4y ago
Great, maybe HN can use it instead of fucking light gray on white
- frosted-flakes 4y ago
  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.
  - Aeolun 4y ago
    Part of the reason people come to HN is because it never changes.
    - alanh 4y ago
      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.
      - atq2119 4y ago
        I'll bite: How does swallowing emoji exclude people?
        antifa 4y ago
        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 :)
      - 5e92cb50239222b 4y ago
        If a feature excludes a certain kind of people, it might very well be an improvement.

pyrolistical 4y ago

Seems like something that could be calculated and baked server side

madeofpalk 4y ago
except the server doesn't know if the client prefers light or dark mode
ok_dad 4y ago
For accessibility, it’s better to do this client side, so clients can adjust it themselves to be more contrasting or whatever.
- pyrolistical 4y ago
  that's cool. use both. calculate a good default contrast server side, use proposal to allow client side to override default
  - sharlos201068 4y ago
    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.
    - anikom15 4y ago
      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.
      - namibj 4y ago
        Both of those are already APIs today in phones. And there's decent reason to not want to tell the server either.
    - eyelidlessness 4y ago
      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.
- ilyt 4y ago
  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
- layer8 4y ago
  Clients are free to provide a contrast dial independently of that. For example there’s a Font Contrast extension for Firefox.
frosted-flakes 4y ago
If it's a static colour, sure. But if it's set by the user with a colour picker, that doesn't really work.

ilyt 4y ago

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

frosted-flakes 4y ago
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.
- Aeolun 4y ago
  Part of the reason people come to HN is because it never changes.
  - alanh 4y ago
    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.
    - atq2119 4y ago
      I'll bite: How does swallowing emoji exclude people?
      - antifa 4y ago
        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 :)
    - 5e92cb50239222b 4y ago
      If a feature excludes a certain kind of people, it might very well be an improvement.