Tag: Adjust

Using CSS Custom Properties to Adjust Variable Font Weights in Dark Mode

Black isn’t always slimming.

When recently testing a dark mode option for one of my sites, I experienced first-hand the issue that Robin Rendle addresses in this article. All of my page text — headings and body copy — appeared to bulk up when I switched to dark mode. And it didn’t matter what fonts I used or which browsers I tried. The same thing happened with all of them.

For example, here’s what happens with Adobe’s Source Sans Pro in Chrome for Windows:

See those blurry edges when we switch to dark mode?

It’s not an illusion. The light characters really are heavier against dark backgrounds. We can zoom in to see better:

The characters really are thicker in dark mode!

And it becomes really obvious when we invert the dark mode portions of those images:

We can really see the difference when putting the characters side-by-side on the same white background.
We can really see the difference when putting the characters side-by-side on the same white background.

One solution

Since variable fonts enjoy wide browser support, we can use them to help us address this issue. The three panels below demonstrate a solution we’ll be working toward:

The top shows us some light text on a dark background. The middle panel shows what happens in dark mode without changing any font weight settings. And the bottom panel demonstrates dark mode text that we’ve thinned out a bit. That third panel is adjusted to match the weight of its light counterpart, which is what we’re trying to accomplish here.

Here’s how we can get this improved effect:

  1. Reduce font-weight properties in dark mode via one of the following methods:
    1. Manually changing each font-weight assignment directly in a dark mode media query.
    2. Creating a single --font-weight-multiplier custom property that changes its value in dark mode, and by which we can then multiply by each element’s default font-weight value.
    3. Same thing, but instead of calculating each element’s font-weight property individually, we take advantage of CSS variable scoping and the universal selector (*) to apply our multiplier calculation everywhere at once.
  2. Adjust a variable font’s grade (“GRAD”) axis. Not all variable fonts support this specific feature, but Roboto Flex, does. Altering this axis value changes the font’s apparent weight, without affecting the width of the letters.
  3. Adjust a variable font’s darkmode ("DRKM") axis. Dalton Maag’s aptly-named Darkmode, with its eponymous darkmode axis, is uniquely suited for this. As with the Roboto Flex’s grade axis, adjusting Darkmode’s darkmode axis changes the font’s apparent weight. But while the grade axis requires some fine-tuning of values, the darkmode axis is simply switched on (thinner) or off (regular).

The techniques in the first group work for most variable fonts. The solution Robin uses in his article is actually the very first item in the group. I’ll expand on the second and third items in the group by introducing custom properties that help us automatically adjust font weights in dark mode.

The second and third groups involve less common font-variation-settings axes. Though these strategies apply to fewer typefaces, they may be preferable when available. The trick is knowing what a variable font supports before choosing it.

I’ve made a demonstration page including all the strategies covered in this article. You can see what some different variable fonts look like in light mode, in dark mode with no adjustment, and in dark mode with our solutions for thinning out characters.

In addition to the strategies listed above, there’s always one more option: don’t do anything! If you think your fonts look good enough in light and dark mode, or you don’t have the bandwidth right now to wrestle with reflow, element resizing, browser/display inconsistencies, and extra CSS to maintain, then you may not have to change a thing. Focus on the rest of your site and leave yourself open to the possibility of revisiting this topic later.

Strategy 1: Reducing the font-weight value

Most variable text fonts have a weight axis, which lets us assign any specific font-weight value within the weight range available to that font (e.g. 0-1000, 300-800, etc.). Each technique in this strategy takes advantage of this fine control over the weight axis to reduce font-weight values in dark mode. (The need for such font-weight precision is also what renders most non-variable fonts unsuitable for this solution.)

If you’re using variable fonts you have locally, you can check their axes and value ranges at Wakamai Fondue:

At Wakamai Fondue, you can view any local font’s variable axes and ranges.

Keep in mind that, if you’re using the @font-face rule to load fonts, you should set a font-weight range for each of them at the same time:

@font-face {   src: url('Highgate.woff2') format('woff2-variations');   font-family: 'Highgate';   font-weight: 100 900; }

If you neglect this step, some variable fonts may not properly reflect specific font-weight values in current Chromium browsers.

Dalton Maag Highgate’s font-weight set to 800 in Chrome without (left) and with (right) a font-weight range specified in the @font-face rule.

The basic solution: Manually entering each weight

Here’s the technique most of us may reach for. We create a dark mode media query in which we enter some font-weight values that are a bit lower than their defaults.

/* Default (light mode) CSS */  body {   font-weight: 400; }  strong, b, th, h1, h2, h3, h4, h5, h6 {   font-weight: 700; }  /* Dark mode CSS */ @media (prefers-color-scheme: dark) {   body {     font-weight: 350;   }    strong, b, th, h1, h2, h3, h4, h5, h6 {     font-weight: 600;   } }

It works, and it’s no problem to maintain — so long as we’re not planning on adding or editing any other weights at our site! But if we do start incorporating more weights, it can get unwieldy fast. Remember to enter each selector/property combo both outside and inside the prefers-color-scheme media query. We’ll have to do some manual calculations (or guesswork) to determine the dark mode property values for each element.

Creating a weight multiplier custom property and using it in a calculation when setting an element’s weight

I generally try to adhere to Mike Riethmuller’s credo that “media queries are only used to change the value of custom properties.” And that’s the improvement we make in this solution. Instead of having to enter font weights for all our elements in and out of dark mode, the only thing we’re putting in our media query is a --font-weight-multiplier custom property:

@media (prefers-color-scheme: dark) {   :root {     --font-weight-multiplier: .85;   } }

Then, for all our font-weight properties throughout the stylesheet, we’ll multiply the variable’s value by our preferred default weight value for each element — thus lowering the font weight by 15% in dark mode. If we’re not in dark mode, we’ll multiply the default weight by 1, meaning it doesn’t change at all.

Here’s what I mean. Normally, we’d use this to set a body font weight of 400:

body {   font-weight: 400; }

For this solution, we use this:

body {   font-weight: calc(400 * var(--font-weight-multiplier, 1)); }

In the var() function, notice that our variable has a fallback value of 1. Because --font-weight-multiplier is only set in dark mode, this fallback value will be used the rest of the time. So, by default, our font weight for body text stays at 400 (400*1). But in dark mode, the weight decreases to 340 (400*.85).

We’ll also do this with bold elements:

strong, b, th, h1, h2, h3, h4, h5, h6 {   font-weight: calc(700 * var(--font-weight-multiplier, 1)); }

These weights will decrease from 700 to 595 (700*.85) in dark mode.

And we can use the same technique for any other elements where we want to set the font-weight to something other than 400 by default.

I’m using a value of .85 for --font-weight-multiplier, because I’ve found that to be a good general value for most fonts (like Adobe Source Sans Pro, the free typeface I use in most of this article’s demos). But feel free to play around with that number.

Here’s how this looks put together:

/* DARK-MODE-SPECIFIC CUSTOM PROPERTIES */ @media (prefers-color-scheme: dark) {   :root {     --font-weight-multiplier: .85;   } }  /* DEFAULT CSS STYLES... */ body {   font-weight: calc(400 * var(--font-weight-multiplier, 1)); }  strong, b, th, h1, h2, h3, h4, h5, h6 {   font-weight: calc(700 * var(--font-weight-multiplier, 1)); }

Creating a weight multiplier variable and automatically calculating and applying it to all elements at once.

When using many CSS custom properties, I think many of us stick to a “set as needed and manually apply everywhere” approach. That’s what the previous solution does. We set our custom property value in the :root (and/or use a fallback value), set it again in a media query, then apply it with calc() and var() functions throughout our stylesheet each time we assign a font-weight value.

The code might look something like this:

h1 {   font-weight: calc(800 * var(--font-weight-multiplier, 1); }  summary {   font-weight: calc(600 * var(--font-weight-multiplier, 1); }

But when we use this technique for various elements, you can see we have to do these three things every time we assign font-weight values:

  • Include the calc() function
  • Include the var() function
  • Remember the --font-weight-multiplier custom property’s name and default value

Instead, I’ve recently started inverting this approach for certain tasks, taking advantage of CSS variable scope with a “set everywhere and apply once” method. For this technique, I replace every font-weight property in the stylesheet with a --font-weight variable, keeping the name the same except for the dashes, for simplicity’s sake. I then set this value to the default weight for that particular selector (e.g. 400 for body text). Neither calc() nor var() is needed — yet. This is how we set everywhere.

Then we apply once, with a lone font-weight property in our stylesheet that sets every text element’s weight via the universal selector. Modifying our snippet above, we’d now have this:

h1 {   --font-weight: 800; }  summary {   --font-weight: 600; }  * {   font-weight: calc(var(--font-weight, 400) * var(--font-weight-multiplier, 1); }

The calc() function multiplies each of our --font-weight custom properties by our multiplier variable, and the font-weight property then applies the value to its appropriate element.

It’s unnecessary to use only a single var() for each custom property in the stylesheet. But I often like doing so when performing calculations and/or using a helper variable, as we do here. That said, while this is certainly the cleverest technique for adjusting font weights, that doesn’t mean it’s the best technique for all projects. There is at least one serious caveat.

The primary advantage of using the universal selector technique — that it applies to everything — also introduces its chief risk. There may be some elements that we don’t want thinned out! For example, if our form elements retain dark text on light backgrounds in dark mode, they may still get steamrolled by the universal selector.

There are ways to mitigate this risk. We could replace * with a long selector string containing a list of only elements to thin out (having them opt-in to the calculation). Or we could hard-code font weights for the elements that we don’t want affected (opt-out):

* {   font-weight: calc(var(--font-weight, 400) * var(--font-weight-multiplier, 1)); }  button, input, select, textarea {   font-weight: 400; }

Such fixes may ultimately make code just as complicated as the previous technique. So, you’ll have to gauge which is appropriate for your project. If you still have concerns over performance, code complexity, or think this technique might introduce undesired (even unpredictable) results, the previous technique might be safest.

The final code:

/* DEFAULT CUSTOM PROPERTIES */ :root {   --font-weight: 400;   --font-weight-multiplier: 1; } strong, b, th, h1, h2, h3, h4, h5, h6 {   --font-weight: 700; }  /* DARK-MODE-SPECIFIC CUSTOM PROPERTIES */ @media (prefers-color-scheme: dark) {   :root {     --font-weight-multiplier: .85;   } }  /* APPLYING THE CUSTOM PROPERTIES... */ * {   font-weight: calc(var(--font-weight, 400) * var(--font-weight-multiplier, 1)); }

We’re not required to set the default --font-weight: 400 and --font-weight-multiplier: 1 custom properties in the above code, because we’ve included the fallback values in the var() functions. But as code gets more complicated, I often like assigning them in a logical place, just in case I want to find and alter them later.

A final note on this strategy: we can also apply weights with the font-variation-settings property and a "wght" axis value, instead of font-weight. If you’re using a typeface with several axes, maybe you find it more manageable to do all your font tweaking that way. I know of at least one font (Type Network’s Roboto Flex, which we’ll be using later in this article) that has 13 axes!

Here’s how to apply our solution via a font-variation-settings property:

* {   --wght: calc(var(--font-weight, 400) * var(--font-weight-multiplier, 1));   font-variation-settings: "wght" var(--wght); }

Strategy 1 Addendum: Handling letter-spacing

One side effect of lowering our type weight is that, for most non-monspaced fonts, it also narrows the characters.

Here again is what happens when we lighten Source Sans Pro with our multiplier. The top two panels below show Source Sans Pro in light and dark mode by default. And the lower panel shows the lighter version.

Adobe’s Source Sans Pro in light mode, dark mode by default, and dark mode thinned out.

With no adjustments, the characters in light mode and dark mode are the same width. But when we lower the font weight, those characters now take up less space. You may not like how this change affects your flow or element sizes (e.g. narrower buttons). And some designers think it’s a good idea to add letter spacing in dark mode, anyway. So, if you want, you can create another custom property to add some space.

Implementing a custom property for letter spacing

Just like we did with our font-weight multiplier variable, we’re going to create a letter spacing variable with a default value that gets overridden in dark mode. In our default (light mode) :root, we set our new --letter-spacing custom property to 0 for now:

:root {   /* ...other custom variables... */   --letter-spacing: 0; }

Then, in our dark mode query, we raise the value to something greater than 0. I’ve entered it as .02ch here (which combines pretty well with a --font-weight-multiplier value of .85). You could even get clever and fine-tune it with some calculations based on your font weights and/or sizes, if you like. But I’ll use this hard-coded value for now:

@media (prefers-color-scheme: dark) {   :root {     /* ...other custom variables... */     --letter-spacing: .02ch;   } }

Finally, we apply it via our universal selector (with a fallback value of 0):

* {   /* ...other property settings... */   letter-spacing: var(--letter-spacing, 0); }

Note: Though I use the ch unit in this example, using em also works, if you prefer. For Source Sans Pro, a value of .009em is about equal to .02ch.

Here’s the full code for a font weight multiplier with letter spacing:

/* DEFAULT CSS CUSTOM PROPERTIES */ :root {   --font-weight: 400;   --font-weight-multiplier: 1;   --letter-spacing: 0; }  strong, b, th, h1, h2, h3, h4, h5, h6 {   --font-weight: 700; }  /* DARK MODE CSS CUSTOM PROPERTIES */ @media (prefers-color-scheme: dark) {   :root {     /* Variables to set the dark mode bg and text colors for our demo. */     --background: #222;     --color: #fff;      /* Variables that affect font appearance in dark mode. */     --font-weight-multiplier: .85;     --letter-spacing: .02ch;   } }  /* APPLYING CSS STYLES... */ * {   font-weight: calc(var(--font-weight, 400) * var(--font-weight-multiplier, 1));   letter-spacing: var(--letter-spacing, 0); }  body {   background: var(--background, #fff);   color: var(--color, #222); } 

Fonts with constant-width characters (aka multi-plexed fonts)

In addition to monospaced fonts, there are some other typefaces specifically designed so that their individual characters take up the same amount of horizontal space, regardless of weight. For example, if an “i” occupies five horizontal pixels of space at a weight of 400, and a “w” occupies thirteen pixels at the same weight, they will still occupy five and thirteen pixels, respectively, when their weights are increased to 700.

Arrow Type’s Recursive Sans is one such typeface. The following image shows how Recursive’s characters maintain the same widths in light mode, default dark mode, and dark mode with our font weight multiplier, respectively:

The characters in Arrow Type’s Recursive maintain their widths regardless of font weight.

Multi-plexed typefaces, like Recursive, are designed so you won’t need to adjust letter spacing when changing their font weights in dark mode. Your element sizes and page flow will remain intact.

Strategy 2: Adjust a variable font’s grade axis

The grade axis ("GRAD") changes a font’s apparent weight without changing its actual font-weight value or the widths of its characters. When using fonts with this axis, you may not need our font weight multiplier variable at all.

For Type Network’s free Roboto Flex font, a grade of -1 is thinnest, 0 (default) is normal, and 1 is thickest. With this font, I start by assigning its grade axis a value of around -.75 for dark mode.

Roboto Flex in light mode, dark mode default, and dark mode with “GRAD” set to -.75
:root {   --GRAD: 0; }  @media (prefers-color-scheme: dark) {   :root {     --GRAD: -.75;   } }  body {   font-variation-settings: "GRAD" var(--GRAD, 0); }

So, adjusting the grade axis seems like the perfect solution if it’s available to you, right? Well, maybe. There are a few things to keep in mind when considering it.

First, the scale for all fonts doesn’t always go from -1 to 1. Some range from 0 to 1. At least one typeface uses percents, making 100 the default. And other fonts align the grade scale with font weights, so the range may be something like 100-900. If you want to use the grade axis in the latter case, you may have to set all your font weights everywhere to a default of 400, and then use the grade axis for all weight changes. For dark mode, you’ll then want to treat grade essentially like we do in our font weight multiplier solution — applying the multiplier to the "GRAD" axis in font-variation settings.

The second caveat is that some typefaces don’t let you grade a font to a value below its default weight. So, grade can’t lighten it at all. Apple’s San Francisco typeface (which can be tested via font-family: system-ui; on Apple devices) has both of these issues. As of macOS Catalina, San Francisco has a grade axis. It’s scaled to line up with font weights, and its minimum value is 400.

San Francisco’s grade and weight axes use the same scale, but have different ranges.

Because we can’t set the grade to a value lower than 400, we can’t lighten fonts from a default of 400 in dark mode. If we want to go lower, we’ll need to lower the weight axis value, instead.

Strategy 3: Adjusting a variable font’s darkmode axis

There’s currently only one typeface with a darkmode ("DRKM") axis at the time of this writing: Dalton Maag’s Darkmode.

The darkmode axis is essentially a grade axis without any fine-tuning. Just turn it on (1) for a thinner appearance in dark mode, and leave it off (0, the default) for normal display.

Darkmode in light mode, in dark mode with “DRKM” unset, and in dark mode with “DRKM” set to 1.
:root {   --DRKM: 0; }  @media (prefers-color-scheme: dark) {   :root {     --DRKM: 1;   } }  body {   font-variation-settings: "DRKM" var(--DRKM, 0); }

I like the Darkmode font a lot. But beware that it is a commercial license that’s required for professional use. Dalton Maag offers a trial version that can be used for “academic, speculative, or pitching purposes only.” I’m hoping this typeface is a pilot for more Dalton Maag families to get a darkmode axis, and that other font foundries will then follow suit!

Other factors to consider

We’ve covered a few big strategies for working with variable fonts in a dark mode context. But, as with most things, there are other things to consider that might sway you toward one solution or another.

Dark mode on high-resolution (“retina”) screens

On screens with higher pixel densities (e.g. most modern phones, MacBooks, iMacs, etc.), the thickening effect of dark mode is often less pronounced. Therefore, you may not want to thin the fonts on these screens out as much — if at all!

If you still want to lighten fonts a bit, you can add another media query to make the effect less severe. Depending which solution you’re using, you can raise the --font-weight-multiplier value closer to 1, raise the --GRAD value closer to 0, or disable --DRKM altogether (since it’s either on or off, with no in-between).

If you add this query, remember to place it below the original prefers-color-scheme query, or it may have no effect. Media queries don’t add CSS specificity, so their order matters!

@media (prefers-color-scheme: dark) and (-webkit-min-device-pixel-ratio: 2),         (prefers-color-scheme: dark) and (min-resolution: 192dpi) {    :root {     --font-weight-multiplier: .92;     /* Or, if you're using grade or darkmode axis instead: */     /* --GRAD: -.3; */     /* --DRKM: 0; */   } }

If you don’t want to lighten fonts at all on high density screens in dark mode, you can update your original dark mode prefers-color-scheme query to the following, to omit these screens:

@media (prefers-color-scheme: dark) and (-webkit-max-device-pixel-ratio: 1.9),         (prefers-color-scheme: dark) and (max-resolution: 191dpi) {     /* Custom properties for dark mode go here. */  }

Mixing fonts with different axes (and mixing variable fonts with non-variable fonts)

If you’re using more than one typeface on your site, you’ll need to consider what effects these adjustments may have on all of them. For example, if you’re using multiple fonts with intersecting axes, you could wind up accidentally combining the effects of multiple strategies (e.g. reducing both grade and weight simultaneously):

If your stylesheet includes solutions for several typefaces/axes, then the effect on fonts that have multiple axes (like this example’s Roboto Flex, which has both grade and weight axes) may be cumulative.

If all the fonts on your site are variable and have a grade axis with a matching scale and range (e.g. if they all range from -1 to 1), that’s the solution I’d recommend. However, you’ll have to revisit this if you plan to add other fonts later that don’t meet those criteria. Same goes for the darkmode axis, too, if it becomes more widespread.

If all your fonts are variable, but they don’t all share the same axes (e.g. grade and darkmode), then using only the --font-weight-multiplier custom property may be your safest bet.

Finally, if you’re mixing variable and non-variable fonts, know that the non-variable fonts will not change appearance with any of these solutions — with some exceptions. For example, if you’re using the font weight multiplier with the font-weight property, it is possible that some — but maybe not all — of your font weights will change enough to move to the next lower weight name.

Say your site includes a font with three weights: regular (400), semi-bold (600), and bold (700). In dark mode, your bold text may lighten up enough to display as semi-bold. But your regular font will still stay regular (as that’s the lowest weight included on the site). If you want to avoid that inconsistency, you could apply your variable font weights via font-variation-settings, and not font-weight, so your non-variable fonts aren’t affected at all. They’ll just always maintain their default weight in dark mode.

In closing

It’s always a happy coincidence when complementary technologies attain common usage near the same time. With the rise in popularity of both dark mode and variable fonts, we have the luxury of using the latter to mitigate one of the challenges of the former. Using CSS custom properties in conjunction with weight, grade, and darkmode axes, we can bring some consistency to the look of our text in both light and dark modes.

You can visit my interactive demo with the fonts and axes from this article.


The post Using CSS Custom Properties to Adjust Variable Font Weights in Dark Mode appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , , , , , ,

Using JavaScript to Adjust Saturation and Brightness of RGB Colors

Lately I’ve been taking a look into designing with color (or “colour” as we spell it where I’m from in New Zealand). Looking at Adam Wathan and Steve Schroger’s advice on the subject, we find that we’re going to need more than just five nice looking hex codes from a color palette generator when building an application. We’re going to need a lot of grays and a few primary colors. From these primary colors we’ll want a variety of levels of brightness and saturation.

I’ve mainly been using hex codes or RGB colors when developing applications and I’ve found I get slowed down by trying to work out different levels of lightness and saturation from a single hue.  So, to save you from getting RSI by carefully moving the color picker in VS Code, or continually opening hexcolortool, let’s look at some code to help you manipulate those colors.

HSL values

An effective way to write web colors is to use HSL values, especially if you plan to alter the colors manually. HSL stands for hue, saturation, lightness. Using HSL, you can declare your hue as a number from 0 to 360. Then you can note down a percentage for saturation and lightness respectively. For instance:

div {   background-color: hsl(155, 30%, 80%); }

This will give you a light, muted, mint green color. What if we needed to throw some dark text over this div? We could use a color close to black, but consistent with the background. For example, we can grab the same HSL values and pull the lightness down to 5%: 

div {   background-color: hsl(155, 30%, 80%);   color: hsl(155, 30%, 5%); }

Nice. Now we have text that is very close to black, but looks a bit more natural, and is tied to its background. But what if this wasn’t a paragraph of text, but a call-to-action button instead? We can draw some more attention by ramping up the saturation and lowering the lightness a little on the background:

.call-to-action {   background-color: hsl(155, 80%, 60%);   color: hsl(155, 30%, 5%); }

Or, what if there was some text that wasn’t as important? We could turn back up the brightness on the text, and lower the saturation. This takes away some of the contrast and allows this less important text to fade into the background a bit more. That said, we need to be careful to keep a high enough contrast for accessibility and readability, so let’s lighten the background again:

div {   background-color: hsl(155, 30%, 80%);   color: hsl(155, 30%, 5%); }  .lessimportant {   color: hsl(155, 15%, 40%); }

HSL values are supported in all major browsers and they are a superior way of defining colors compared to RGB. This is because they allow you to be more declarative with the hue, saturation and lightness of a color.

But, what if you’ve already committed to using RGB values? Or you get an email from your boss asking “is this going to work on IE 8?”

Libraries

There are a lot of great color libraries out there that are able to convert HSL values back into hex codes or RGB colors. Most of them also have a variety of manipulation functions to help build a color scheme.

Here is a list of some libraries I know:

  • If converting between formats is a problem, try colvertize by Philipp Mildenberger. It’s a lightweight library providing a lot of conversion methods and a few manipulation methods.
  • Then we have color, maintained by Josh Junon. This allows you to declare, process and extract colors using a fluent interface. It provides a variety of conversions and manipulation methods.
  • Another one is TinyColor by Brian Grinstead over at Mozilla, which can handle a whole lot of input types as well as utility functions. It also provides a few functions to help generate color schemes.

Also here is a great CSS-Tricks article on converting color formats.

Colour Grid Tool

Another option is you can try out a color tool I built called Colour Grid. To quote Refactoring UI, “As tempting as it is, you can’t rely purely on math to craft the perfect color palette.”

Naturally, after reading this, I built a React app to mathematically craft a color palette. Okay, it won’t solve all your problems, but it might start you off with some options. The app will create 100 different levels of saturation and lightness based the hue you select. You can either click a grid item to copy the hex code, or copy a color as a CSS custom property from a text area at the end. This could be something to try if you need a quick way to get variations from one or two hues. 

Here are some techniques I learned for processing RGB colors as well for if you are using RGB colors and need a way to transform them.

How to find the lightness of an RGB color

Disclaimer: This technique does not account for the intrinsic value of a hue. The intrinsic value of a hue is its inherent brightness before you’ve started adding any black or white. It’s illustrated by the fact pure yellow looks a lot brighter to us than a pure purple.

This technique produces the level of lightness based on a programmatic measure of how much white or black is mixed in. The perceived brightness is affected by more than this measure so remember to also use your eyes to judge the level of light you need.

The level of lightness of an RGB color can be worked out by finding the average of the highest and lowest of the RGB values, then dividing this by 255 (the middle color does not affect the lightness).

This will give you a decimal between zero and one representing the lightness. Here is a JavaScript function for this:

function getLightnessOfRGB(rgbString) {   // First convert to an array of integers by removing the whitespace, taking the 3rd char to the 2nd last then splitting by ','   const rgbIntArray = (rgbString.replace(/ /g, '').slice(4, -1).split(',').map(e => parseInt(e))); 
   // Get the highest and lowest out of red green and blue   const highest = Math.max(...rgbIntArray);   const lowest = Math.min(...rgbIntArray); 
   // Return the average divided by 255   return (highest + lowest) / 2 / 255; }

Here’s a CodePen using this function:

How to saturate an RGB color without changing lightness or hue

What can we do with our newfound ability to find the lightness of an RGB? It can help us saturate an RGB color without changing the lightness.

Saturating an RGB comes with a few problems, though:

  • There is no information in the RGB format of a gray color to tell us what the saturated version will look like because gray doesn’t have a hue. So if we’re going to write a function to saturate a color, we need to deal with this case.
  • We can’t actually get to a pure hue unless the color is 50% lightness — anything else will be diluted by either black or white. So we have a choice of whether to keep the same lightness as we saturate the color, or move the color towards 50% lightness to get the most vibrant version. For this example, we’ll keep the same level of lightness.

Let’s start start with the color rgb(205, 228, 219) — a light, muted cyan. To saturate a color we need to increase the difference between the lowest and highest RGB value. This will move it toward a pure hue.

If we want to keep the lightness the same, we’re going to need to increase the highest value and decrease the lowest value by an equal amount. But because the RGB values need to be clamped between 0 and 255, our saturation options will be limited when the color is lighter or darker. This means there is a range of saturation we have available for any given lightness.

Let’s grab the saturation range available for our color. We can work it out by finding the lowest of these two:

  • The difference between the RGB values of a gray with the same lightness as our color, and 255
  • The difference between the RGB values of a gray with the same lightness as our color, and 0 (which is just the gray value itself)

To get a fully gray version of a color, we can grab the end result of the getLightnessOfRGB function from the previous section and multiply it by 255. Then use this number for all three of our RGB values to get a gray that’s the same lightness as our original color. 

Let’s do this now:

// Using the previous "getLightnessOfRGB" function const grayVal = getLightnessOfRGB('rgb(205, 228, 219)')*255; // 217 // So a gray version of our color would look like rgb(217,217,217); // Now let's get the saturation range available: const saturationRange =  Math.round(Math.min(255-grayVal,grayVal)); // 38

Let’s say we want to saturate the color by 50%. To do this  want to increase the highest RGB value and decrease the lowest by 50% of the saturation range. However, this may put us over 255 or under zero, so we need to clamp the change by the minimum of these two values:

  • The difference between the highest RGB value and 255
  • The difference between the lowest RGB value and 0 (which is the value itself)
// Get the maximum change by getting the minimum out of:  // (255 - the highest value) OR (the lowest value) const maxChange = Math.min(255-228, 205); // 27 
 // Now we will be changing our values by the lowest out of: // (the saturation range * the increase fraction) OR (the maximum change) const changeAmount = Math.min(saturationRange/0.5, maxChange) // 19

This means we need to add 19 to the highest RGB value (green) and subtract 19 from the lowest RGB value:

const redResult = 205 - 19; // 186 const greenResult= 228 + 19; // 247

What about the third value?

This is where things get a bit more complicated. The middle value’s distance from gray can be worked with the ratio between it and the distance from gray of either of the other two values.

As we move the highest and lowest values further away from gray, the middle value increases/decreases in proportion with them. 

Now let’s get the difference between the highest value and full gray. Then the difference between the middle value and the full gray. Then we’ll get the ratio between these. I’m going to also remove the rounding from working out the gray value to make this more exact:

const grayVal = getLightnessOfRGB('rgb(205, 228, 219)')*255; const highDiff = grayVal - 228; // -11 subtracting green - the highest value const midDiff = grayVal - 219; // -2 subtracting blue - the middle value const middleValueRatio = midDiff / highDiff; // 0.21739130434782608

Then what we need to do is get the difference between our new RGB green value (after we added 19 to it) and the gray value, then multiply this by our ratio. We add this back on to the gray value and that’s our answer for our newly saturated blue:

// 247 is the green value after we applied the saturation transformation const newBlue = Math.round(grayVal+(247-grayVal)*middleValueRatio); // 223

So after we’ve applied our transformations, we we get an RGB color of rgb(186, 247, 223 — a more vibrant version of the color we started with. But its kept its lightness and hue.

Here are a couple of JavaScript functions that work together to saturate a color by 10%. The second function here returns an array of objects representing the RGB values in order of size. This second function is used in all of the rest of the functions in this article.

If you give it a gray, it will just return the same color:

function saturateByTenth(rgb) {   const rgbIntArray = (rgb.replace(/ /g, '').slice(4, -1).split(',').map(e => parseInt(e)));   const grayVal = getLightnessOfRGB(rgb)*255;   const [lowest,middle,highest] = getLowestMiddleHighest(rgbIntArray); 
   if(lowest.val===highest.val){return rgb;}      const saturationRange =  Math.round(Math.min(255-grayVal,grayVal));   const maxChange = Math.min((255-highest.val),lowest.val);   const changeAmount = Math.min(saturationRange/10, maxChange);   const middleValueRatio =(grayVal-middle.val)/(grayVal-highest.val);      const returnArray=[];   returnArray[highest.index]= Math.round(highest.val+changeAmount);   returnArray[lowest.index]= Math.round(lowest.val-changeAmount);   returnArray[middle.index]= Math.round(grayVal+(returnArray[highest.index]-grayVal)*middleValueRatio);    return (`rgb($  {[returnArray].join()})`); } 
 function getLowestMiddleHighest(rgbIntArray) {   let highest = {val:-1,index:-1};   let lowest = {val:Infinity,index:-1}; 
   rgbIntArray.map((val,index)=>{     if(val>highest.val){       highest = {val:val,index:index};     }     if(val<lowest.val){       lowest = {val:val,index:index};     }   }); 
   if(lowest.index===highest.index){     lowest.index=highest.index+1;   }      let middle = {index: (3 - highest.index - lowest.index)};   middle.val = rgbIntArray[middle.index];   return [lowest,middle,highest]; }

How to desaturate an RGB Color

If we completely desaturate a color, we’ll end up with a shade of gray. RGB grays will always have three equal RGB values, so we could just use the grayVal from the previous function to make a gray color with the same lightness as any given color.

What if we don’t want to go straight to gray, and only want to slightly desaturate a color? We can do this by reversing the previous example.

Let’s look at another example. If we start with rgb(173, 31, 104), we have a saturated rouge. Let’s grab the decimal measure of lightness and multiply it by 255 to get the gray version:

const grayVal = Math.round(getLightnessOfRGB('rgb(173, 31, 104)') * 255); // 102

This means that if we fully desaturate this color to gray we’re going to end up with rgb(102, 102, 102). Let’s desaturate it by 30%.

First, we need to find the saturation range of the color again:

const saturationRange = Math.round(Math.min(255-grayVal,grayVal)); // 102

To desaturate our color by 30%, we want to move the highest and lowest color by 30% of this range toward full gray. But we also need to clamp the change amount by the distance between either of these colors (the distance will be the same for the highest and lowest), and full gray.

// Get the maximum change by getting the difference between the lowest (green) and the gray value const maxChange = grayVal-31; // 71 // Now grab the value that represents 30% of our saturation range const changeAmount = Math.min(saturationRange * 0.3, maxChange) // 30.59999

And add this change amount to the lowest RGB value and subtract it from the highest value: 

const newGreen =Math.Round(31+changeAmount); // 62 const newRed =Math.Round(173-changeAmount); // 142

Then use the same ratio technique as the last function to find the value for the third color:

const highDiff = grayVal - 173; // -71 subtracting red - the highest value const midDiff = grayVal - 104; // -2 subtracting blue - the middle value const middleValueRatio = midDiff / highDiff; // 0.02816901408 const newBlue = Math.Round(grayVal+(142.4-grayVal)*middleValueRatio); // 103

So that means the RGB representation of our rouge desaturated by 30% would be rgb(142, 62, 103). The hue and the lightness are exactly the same, but it’s a bit less vibrant.

Here’s a JavaScript function that will desaturate a color by 10%. It’s basically a reverse of the previous function.

function desaturateByTenth(rgb) {   const rgbIntArray = (rgb.replace(/ /g, '').slice(4, -1).split(',').map(e => parseInt(e)));   //grab the values in order of magnitude    //this uses the getLowestMiddleHighest function from the saturate section   const [lowest,middle,highest] = getLowestMiddleHighest(rgbIntArray);   const grayVal = getLightnessOfRGB(rgb) * 255; 
   if(lowest.val===highest.val){return rgb;}      const saturationRange =  Math.round(Math.min(255-grayVal,grayVal));   const maxChange = grayVal-lowest.val;   const changeAmount = Math.min(saturationRange/10, maxChange);                                   const middleValueRatio =(grayVal-middle.val)/(grayVal-highest.val);      const returnArray=[];   returnArray[highest.index]= Math.round(highest.val-changeAmount);   returnArray[lowest.index]= Math.round(lowest.val+changeAmount);   returnArray[middle.index]= Math.round(grayVal+(returnArray[highest.index]-grayVal)*middleValueRatio);   return (`rgb($  {[returnArray].join()})`); } 


Here’s a CodePen to experiment with the effect of these saturation functions:

How to lighten an RGB color keeping the hue the same

To lighten an RGB value and keep the hue the same, we need to increase each RGB value by the same proportion of difference between the value and 255. Let’s say we have this color: rgb(0, 153, 255). That’s a fully saturated blue/cyan. Let’s look at the difference between each RGB value and 255: 

  • Red is zero, so the difference is 255. 
  • Green is 153, so the difference is 102. 
  • Blue is 255, so the difference is zero. 

Now when we lighten the color, we need to increase each RGB value by the same fraction of our differences. One thing to note is that we are essentially mixing white into our color. This means that the color will slowly lose its saturation as it lightens.

Let’s increase the lightness on this color by a tenth. We’ll start with out lowest RGB value, red. We add on a tenth of 255 to this value. We also need to use Math.min to make sure that the value doesn’t increase over 255:

const red = 0; const newRed = Math.round( red + Math.min( 255-red, 25.5 )); // 26

Now the other two RGB values need to increase by the same fraction of distance to 255.

To work this out, we get the difference between the lowest RGB value (before we increased it) and 255. Red was zero so our difference is 255. Then we get the amount the lowest RGB value increased in our transformation. Red increased from zero to 26, so our increase is 26.

Dividing the increase by the difference between the original color and 255 gives us a fraction we can use to work out the other values.

const redDiff = 255 - red; // 255 const redIncrease = newRed - red; // 26 const increaseFraction = redIncrease / redDiff; // 0.10196

Now we multiply the difference between the other RGB values and 255 by this fraction. This gives us the amount we need to add to each value.

const newGreen = Math.round(153 + (255 - 153) * increaseFraction); // 163 const newBlue = Math.round(255 + (255 - 255) * increaseFraction); // 255

This means the color we end up with is rgb(26, 163, 255). That’s still the same hue, but a touch lighter.

Here’s a function that does this: 

function lightenByTenth(rgb) {    const rgbIntArray = rgb.replace(/ /g, '').slice(4, -1).split(',').map(e => parseInt(e));   // Grab the values in order of magnitude    // This uses the getLowestMiddleHighest function from the saturate section   const [lowest,middle,highest]=getLowestMiddleHighest(rgbIntArray);      if(lowest.val===255){     return rgb;   }      const returnArray = [];    // First work out increase on lower value   returnArray[lowest.index]= Math.round(lowest.val+(Math.min(255-lowest.val,25.5)));    // Then apply to the middle and higher values   const increaseFraction  = (returnArray[lowest.index]-lowest.val)/ (255-lowest.val);   returnArray[middle.index]= middle.val +(255-middle.val)*increaseFraction ;   returnArray[highest.index]= highest.val +(255-highest.val)*increaseFraction ;      // Convert the array back into an rgb string   return (`rgb($  {returnArray.join()})`); }

How to darken an RGB color keeping the hue the same

Darkening an RGB color is pretty similar. Instead of adding to the values to get 255, we’re subtracting from the values to get toward zero.

Also we start our transformation by reducing the highest value and getting the fraction of this decrease. We use this fraction to reduce the other two values by their distance to zero. This is a reversal of what we did lightening a color.

Darkening a color will also cause it to slowly lose its level of saturation.

function darkenByTenth(rgb) {      // Our rgb to int array function again   const rgbIntArray = rgb.replace(/ /g, '').slice(4, -1).split(',').map(e => parseInt(e));   //grab the values in order of magnitude    //this uses the function from the saturate function   const [lowest,middle,highest]=getLowestMiddleHighest(rgbIntArray);      if(highest.val===0){     return rgb;   }    const returnArray = [];    returnArray[highest.index] = highest.val-(Math.min(highest.val,25.5));   const decreaseFraction  =(highest.val-returnArray[highest.index])/ (highest.val);   returnArray[middle.index]= middle.val -middle.val*decreaseFraction;    returnArray[lowest.index]= lowest.val -lowest.val*decreaseFraction;                                              // Convert the array back into an rgb string   return (`rgb($  {returnArray.join()}) `); } 

Here’s a CodePen to experiment with the effect of the lightness functions:


If you ever do need to work with RGB colors, these functions will help you get you started. You can also give the HSL format a try, as well as the color libraries to extend browser support, and the Colour Grid tool for conversions.


The post Using JavaScript to Adjust Saturation and Brightness of RGB Colors appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , , ,
[Top]

A Quick Look at the First Public Working Draft for Color Adjust Module 1

We’ve been talking a lot about Dark Mode around here ever since Apple released it as a system setting in MacOS 10.14 and subsequently as part of Safari. It’s interesting because of both what it opens up as as far as design opportunities as well as tailoring user experience based on actual user preferences.

This week, we got an Editor’s Draft for the Color Adjust Module Level 1 specification and the First Public Working Draft of it. All of this is a work-in-progress, but the progression of it has been interesting to track. The spec introduces three new CSS properties that help inform how much control the user agent should have when determining the visual appearance of a rendered page based on user preferences.

color-scheme is the first property defined in the spec and perhaps the centerpiece of it. It accepts light and dark values which — as you may have guessed — correspond to Light Mode and Dark Mode preferences for operating systems that support them. And, for what it’s worth, we could be dealing with labels other than “Light” and “Dark” (e.g. “Day” and “Night”) but what we’re dealing with boils down to a light color scheme versus a dark one.

Source: developer.apple.com

This single property carries some important implications. For one, the idea is that it allows us to set styles based on a user’s system preferences which gives us fine-grained control over that experience.

Another possible implication is that declaring the property at all enables the user agent to take some responsibility for determining an element’s colors, where declaring light or dark informs the user agent that an element is “aware” of color schemes and should be styled according to a preference setting matching the value. On the other hand, we can give the browser full control to determine what color scheme to use based on the user’s system preferences by using the auto value. That tells the browser that an element is “unaware” of color schemes and that the browser can determine how to proceed using the user preferences and a systems’s default styling as a guide.

It’s worth noting at this point that we may also have a prefers-color-scheme media feature (currently in the Editor’s Draft for the Media Queries Level 5 specification) that also serves to let us detect a user’s preference and help gives us greater control of the user experience based on system preferences. Robin has a nice overview of it. The Color Adjust Module Level 1 Working Draft also makes mention of possibly using a color scheme value in a <meta> element to indicate color scheme support.

There’s more to the property, of course, including an only keyword, chaining values to indicate an order of preference, and even an open-ended custom ident keyword. So definitely dig in there because there’s a lot to take in.

Pretty interesting, right? Hopefully you’re starting to see how this draft could open up new possibilities and even impacts how we make design decisions. And that’s only the start because there are two more properties!

  • forced-color-adjust: This is used when we want to support color schemes but override the user agent’s default stylesheet with our own CSS. This includes a note about possibly merging this into color-adjust.
  • color-adjust: Unlike forcing CSS overrides onto the user agent, this property provides a hint to browsers that they can change color values based on the both the user’s preferences and other factors, such as screen quality, bandwidth, or whatever is “deem[ed] necessary and prudent for the output device.” Eric Bailey wrote up the possibilities this property could open up as far as use cases, enhanced accessibility, and general implementations.

The current draft is sure to expand but, hey, this is where we get to be aware of the awesome work that W3C authors are doing, gain context for the challenges they face, and even contribute to the work. (See Rachel Andrew’s advice on making contributions.)

The post A Quick Look at the First Public Working Draft for Color Adjust Module 1 appeared first on CSS-Tricks.

CSS-Tricks

, , , , , , , ,
[Top]