DEV Community: Oscar

Die Nächte sind erfüllt von Maskenfesten

Oscar — Wed, 05 Feb 2020 12:27:37 +0000

Note: This post has originally been published on my own blog. If you want to see the implementation in a live environment, have a look over there.

I’m late to the party. I can’t help it. If there is a possibility to be late, I am. But I do like a party. Sometimes I even do like parties in dark rooms. So, implementing dark mode has been out of question.

I had implemented it on two sites I built from scratch recently. It was so straight-forward that I thought it couldn’t be too hard for this site. The only different thing is that the code for this site is a bit … it is code written by someone who did not know what they were doing. Read: a younger me.

In the following I am showing you how I approached it, as well as explaining the basics of CSS Custom Properties, as they are an integral part of the implementation.

Getting colourful

Luckily, I knew that it is a good idea to keep your colours somewhere safe and only use named variants in your CSS, just in case red does not cut it as the primary colour anymore and you want to switch to something different.

Here are all colours I use:

$colors: (
  main: #b00000,
  main-light: lighten(#b00000, 30),
  main-dark: darken(#b00000, 10),
  light: #f8f2e3,
  dark: #0e0e0e,
  dark-lighter: #685d5d,
  light-darker: #cdc9bd
);

Up until now, I’ve been using them through a SASS function named color.

@function color($key) {
  @if map-has-key($colors, $key) {
    @return map-get($colors, $key);
  }

  @warn "Unknown `#{$key}` in $colors.";
  @return null;
}

If I want to make something red (my main colour), I have used it as such:

.main-headline {
  color: color('main');
  font-family: $fonts-secondary;
  font-size: var(--type-xlarge);
  margin: space(double, relative) 0 space(half, relative);

  &:first-child {
    margin-top: 0;
  }
}

This has been alright since the site never needed to change these values once they were parsed into my stylesheet. Now, with the ominous dark mode, I need to do this. If a media query matches, all the colours need to change.

Putting a media query everywhere I need a colour change is tedious. Work I would probably don’t do properly. Luckily, there’s another way.

Enter custom properties

Custom properties, often called CSS variables, are a kind-of-new addition to a web designer’s toolbox. The name variables gives it away: They make value definitions variable. Browser support is solid since a while, with every browser except IE 11 supporting them. If you care about providing a fallback for not supporting browser – which you should – there is a PostCSS plugin which adds a static fallback to your definitions.

Before I talk about switching colours, let me give you a brief introduction to how these custom properties aka variables work.

Let’s create a utility class for a square box.

.is-square {
  height: 2rem;
  width: 2rem;
}

If you need a different size, you would need to create a modifier and redeclare all values.

.is-square {
  height: 2rem;
  width: 2rem;

  &--large {
    height: 8rem;
    width: 8rem;
  }
}

Things will get verbose quite quickly, as more complex code bases tend to need boxes in many different sizes.

The cool thing about custom properties is that they allow you to overwrite them as needed, allowing for much more flexibility. Let’s refactor the box to use custom properties:

.is-square {
  --box-size: 2rem;

  height: var(--box-size);
  width: var(--box-size);
}

On line 2, we have declared the property, or variable, and used it for both width and height by calling the var function.

Tip: Always namespace such properties. Just naming it --size invites a whole lot of trouble, since it’s very like that at one point another declaration will define --size.

Defining other sizes becomes much easier:

.is-square {
  --box-size: 2rem;

  height: var(--box-size);
  width: var(--box-size);

  &--large {
    --box-size: 8rem;
  }
}

As the value of width and height is variable, we can change both by redeclaring the variable.

And if there is a use case where you need a slightly different box, you can do so from everywhere in your CSS.

Say we have an avatar in a user profile.

<img class="user-avatar is-square" src="..." srcset="..." alt="Profile picture of Jane Doe">

After adding the is-square utility class, we can redefine the size by updating the --box-size property:

.user-avatar {
  --box-size: 3.5rem;

  border-radius: 50%;
}

The --box-size variable is scoped into the class we first defined it in. There is a way to declare «global» variables.

Coming back to colours, let’s take a look at an example:

:root {
  --clr-main: #b00000;
}

Once declared, we can use the property --clr-main everywhere:

.main-headline {
  color: var(--clr-main);
}

One last thing that’s good to know about using custom properties is that you can specify a fallback value, by adding a second parameter to the function call.

.main-headline {
  color: var(--clr-main, #b00000);
}

Stefan Judis recently tweeted about a little trick, with which «you can use undefined properties with a fallback value to then define them later».

Making colours variable

The first step is to declare all the colours. I could do this by hand, but as I’ve stored them in a SASS map already, a loop saves a bit of time here:

:root {
  @each $color,
  $value in $colors {
    --clr-#{$color}: #{$value};
  }
}

I use the --clr namespace for colours, to avoid name-clashing and be clear what kind of value to expect.

And while the map saves me typing, I also find it easier to scan and maintain, than a list of property definition, but that’s a personal preference.

In the parsed CSS it will look like this:

 :root {
  --clr-main: #b00000;
  --clr-main-light: #ff4a4a;
  --clr-main-dark: #7d0000;
  --clr-light: #f8f2e3;
  --clr-dark: #0e0e0e;
  --clr-dark-lighter: #685d5d;
  --clr-light-darker: #cdc9bd;
}

Naming can be confusing

One step I took before actually implementing dark mode, was to add a layer of naming. Why’s that? Because, in dark mode, light becomes dark and I always find it confusing to see a declaration like color: var(--clr-dark) and see light text in the browser.

Aliasing the colours makes my design decisions more evident:

:root {
  @each $color,
  $value in $colors {
    --clr-#{$color}: #{$value};
  }

  --clr-bg: var(--clr-light);
  --clr-fg: var(--clr-dark);
  --clr-accent: var(--clr-main);
  --clr-accent-dark: var(--clr-main-dark);
  --clr-accent-light: var(--clr-main-light);
  --clr-decent: var(--clr-dark-lighter);
}

These declarations make it very clear which purpose the colour fulfils, and abstracts from the actual value, which is not as important anymore.

Using these classes looks something like this, nice, clean and declarative.

body {
  background-color: var(--clr-bg);
  color: var(--clr-fg);
}

The last thing left to do was to do a search and replace for all places where I’ve used the color SASS function and replace these declarations with my new variables.

.main-headline {
  color: var(--clr-accent);
}

Getting dark

Now, finally to updating colours for dark mode. I target a dark mode user preference using the prefers-color-scheme media feature. It’s supported by all browsers that also support custom properties.

After setting up the project, the change is straight forward:

@media (prefers-color-scheme: dark) {
  :root {
    --clr-fg: var(--clr-light);
    --clr-bg: var(--clr-dark);
    --clr-accent: var(--clr-main-light);
    --clr-accent-dark: var(--clr-main-light);
    --clr-accent-light: var(--clr-main-dark);
    --clr-decent: var(--clr-light-dark);
  }
}

If the media query matches, I invert my color scheme, and since I use var() everywhere, these changes will cascade down from the root element.

The cascade is a beautiful feature. If you are starting out learning CSS and it feels a bit daunting, Amelia Wattenberger has recently published a fantastic primer on how it works.

Two names I’m not happy with are accent-dark and accent-light. Currently, I do what I didn’t want to do: applying a light colour to a dark name and vice versa. Naming is hard. I tend to change this to accent-to and accent-from as I use them mostly for gradients. Let’s see what I come up with.

Colour is complicated

Inverting the colour setting was a valuable first draft, but not the end of the story. My standard dark colour is very close to true black, which feels quite harsh when applied as a page background. I brightened my dark grey a bit to reduce this.

The second value I tweaked was --clr-accent. In the swap out version I used the light shade of the main colour. I did so to maintain the contrast between it and the background. But now my design was missing a colour, and the light shade felt very bright when used for large type. To mitigate this I used a slightly darker red as the accent colour.

This is the colour scheme in use now:

@media (prefers-color-scheme: dark) {
  :root {
    --clr-fg: var(--clr-light);
    --clr-bg: var(--clr-dark-lighter);
    --clr-accent: var(--clr-main-darker);
    --clr-accent-dark: var(--clr-main-light);
    --clr-accent-light: var(--clr-main-dark);
    --clr-decent: var(--clr-light-dark);
  }
}

Even with a fairly simple colour scheme like mine, simply swapping out colours wasn’t a satisfactory solution. Things get even more complicated when the colour scheme gets more nuanced.

In another project I ended up creating not one but two maps. Instead of looping over all colours once and assigning them afterwards, I looped over each separately.

:root {
  @each $color, $value in $colors {
    --clr-#{$color}: #{$value};
  }

}

@media (prefers-color-scheme: dark) {
  :root {
    @each $color, $value in $colors-dark {
      --clr-#{$color}: #{$value};
    }
  }
}

As the keys in both maps are identical, usage didn’t change after the variables were declared.
Regardless which approach you take, make sure to test for contrast ratio, legibility and harmony.

A quick note on handling type: White text on a black background tends to appear smaller than dark text on a light background. You might need to tweak your font sizes, especially the small ones.

For the heart

With all colours updated there was one final, but essential, step to take. You might have noticed the small little floral heart underneath the title of this article. It called Fleuron and is a glyph with age-old origins. While it started as a punctuation mark, today it is mostly used as an ornamental mark as I do on my side. You may also find it as a divider on the text archive page.

I load the image as an SVG file and have the gradient lines on each side of it. This needs to adapt, too.

The CSS for it is a bit more involved (and most likely deserves a clean up). Let’s take a look at what I had for a start:

.u-floral-heart-gradient {
  background-image: linear-gradient(
      to right,
      color(main-light),
      color(main-dark)
    ),
    url('~assets/img/icons/floral-heart-dark-red.svg'),
    linear-gradient(to right, color(main-dark), color(main-light));
  background-position: 4vmin calc(100% - 2rem), center calc(100% - 1.66rem),
    calc(100% - 4vmin) calc(100% - 2rem);
  background-repeat: no-repeat;
  background-size: 40% 0.125rem, 1rem, 40% 0.125rem;
}

Breaking it down, we have three background-imagess, which are a gradient, the fleuron, and another gradient. They are sized to always fit into the container and are positioned at the bottom of it.

First, I replaced the colours with variable calls:

.u-floral-heart-gradient {
  background-image: linear-gradient(
      to right,
      var(--clr-accent-light),
      var(--clr-accent-dark)
    ),
    url('~assets/img/icons/floral-heart-dark-red.svg'),
    linear-gradient(to right, var(--clr-accent-dark), var(--clr-accent-light));
  background-position: 4vmin calc(100% - 2rem), center calc(100% - 1.66rem),
    calc(100% - 4vmin) calc(100% - 2rem);
  background-repeat: no-repeat;
  background-size: 40% 0.125rem, 1rem, 40% 0.125rem;
}

The beautiful thing about custom properties is that you can assign any CSS property to them and make it work; this includes url values:

:root {
  --layout-fleuron: url('~assets/img/icons/floral-heart-dark-red.svg');
}

Swapping the SVG happens in the media query mentioned above:

@media (prefers-color-scheme: dark) {
  :root {
    /* colours omitted for brevity */

    --layout-fleuron: url('~assets/img/icons/floral-heart-light-red.svg');
  }
}

I now have an adapting fleuron that I can use by calling var(--layout-heart).

For the gradient, I decided to take it one step further and replaced some more repeating values with custom properties:

.u-floral-heart-gradient {
  --gradient-size: 40% 0.125rem;
  --gradient-bottom-offset: calc(100% - 2rem);
  --fleuron-bottom-offset: 1.66rem;

  background-image: linear-gradient(
      to right,
      var(--clr-accent-light),
      var(--clr-accent-dark)
    ),
    var(--layout-fleuron),
    linear-gradient(to right, var(--clr-accent-dark), var(--clr-accent-light));
  background-position: 4vmin var(--gradient-bottom-offset), center calc(100% - var(--fleuron-bottom-offset)),
    calc(100% - 4vmin) var(--gradient-bottom-offset);
  background-repeat: no-repeat;
  background-size: var(--gradient-size), 1rem, var(--gradient-size);
}

I decided to make the bottom offset variable since this makes adapting it much more straightforward. Without these variables, I needed to update the whole background-position declaration, even if just two numbers changed.

The archive header uses my utility class but positions the fleuron and lines closer to the bottom. By modifying the offsets, the change is very clean:

.archive-header {
  --gradient-bottom-offset: calc(100% - 1rem);
  --fleuron-bottom-offset: 0.66rem;

  margin-bottom: 5vh;
  min-height: 33vh;
  padding-bottom: 5vh;
  padding-top: 10vh;
  text-align: center;
}

Wrap-up

I wanted to implement dark mode and by doing so, ended up with a cleaner codebase and property names that communicate my design intent rather than the blank values.

Working with custom properties beyond colour updates opens a whole new world of piecing together CSS that I’m eager to explore.

And, as always, good design requires nuance and a fair bit of staring at the screen.

One thing I am going to add is a user toggle. If you are interested in this, Andy Bell has written an in-depth article about his approach.

Acknowledgements

The title image has been taken by Jimena Egger and published on Unsplash.

The post is named after a song by the wonderful Bersarin Quartett.

A Non-Business Case for Supporting Old Browsers

Oscar — Fri, 22 Nov 2019 14:14:30 +0000

This article has originally been published on my website.

CSS Tricks has published yet another take on why we all need to abandon support for IE 11 as soon as possible.

I think that’s wrong. Let me explain why.

Often, when talking about «abandoning» support for a browser we forget that this simply isn’t possible. Users will visit your site with whatever browser they have at hand. Under whatever network conditions. And that’s okay. That’s great even. Resilience is one of the foundational principles of the Web.

And it’s not just the Web. The internet itself around is build upon resilient layers. TCP/IP is dumb. And, as Jeremy Keith puts it, that is «its secret sauce». Browsers were, from the beginning, instructed to ignore HTML (and later CSS) they do not understand; without breaking the whole document.

In her article Teaching CSS Rachel Andrew remarks

Yet, a website built back then that is still online, or one accessed via the Wayback Machine will still work in a modern browser. Such is the care that has been taken to not break the web by the CSS Working Group, and the other groups working to add features to the web platform.
To call for abandonment runs afoul of this work and as such against the web itself.

In his talk The Layers of the Web Jeremy Keith challenges this mindset by illustrating how languages on the web were build upon another.

Websites aren’t just broken or working. At least they don’t have to be. This requires thinking in steps. And not to put everything in your JavaScript stack.

The web, and I am going to lean on Jeremy Keith again, is not like other platforms. In fact, the word platform might not be apt to describe it at all. Maybe it’s more like a continuum.

Which requires a different mindset, then one which just knows on or off. Building for the web offers the unique possibility of building experiences that are gradually enhanced.

Building Layers

If we use HTML for Markup, CSS for styling and JS for behaviour sprinkled on top, we can go a long way towards supporting a multitude of User Agents.
And while it certainly is true that including all the polyfills will bloat the scripts to send, it is also true that this is a solved problem.

Chris Coyier explained this in his article Differential Serving. We can use a clever combination of JavaScript modules and the nomodule attribute to load one version of our scripts to modern browsers, and the other to old ones that do not support script type="module".

Phil Walton has described this approach in more depth. We are using this technique at Kitchen Stories in production since January. By using dynamic imports we can debundle our bundles even further.

What goes for JS is also true for CSS. Even though the gains might be smaller here.

All we need is a little bit of trickery with Media Queries. By adding the media attribute to the link tag that references a stylesheet it is only loaded if this Media Query evaluates to true.

And here the layers strike again. If a browser does not understand a media query it will not load the styles, regardless if it encounters the query in a style block or a link.

The tricky thing is knowing which queries to use.

PSA: I am pretty sure I did not come up with the following solution by myself. But: I do not find the original source anymore. If you can point me somewhere please ping me on Twitter and I will happily include a link in this article.

We need the following to happen: One query that targets old versions of IE and one that targets modern browsers.

For IE we can use -ms-high-contrast (MDN). This could also make Edge load the styles. Luckily Microsoft deprecated the value none in Edge.

By including the following link tag in a page, we can load styles only in old versions of IE. It works back to Windows 8.

<link rel="stylesheet" media="(-ms-high-contrast: none)" href="css/ie.css">

Now, for modern browsers. Media Queries, as CSS as a whole are constantly evolving. As such there are Media Queries Level 4. None of them are supported in IE. Some of them are not supported at all. In our case the pointer media feature serves us well.

As we don’t really care which pointer is used, we can query for every possible value: (pointer: fine), (pointer: coarse), (pointer: none).
The whole link tag will look like this:

<link rel="stylesheet" media="(pointer: fine), (pointer: coarse), (pointer: none)" href="css/modern.css">

With this combination of two output bundles and media queries we have achieved what we need: Modern features in modern browsers and old features in old ones.

You can see this in action on the Conditionally Load Styles demo site.

Being Pragmatic

Making sure (some of) your code works in older browsers, does not mean all functionality has to work everywhere. But, mind you, ninety percent of web development means putting text and images in boxes.

And to be honest, there is no reason to not enable this everywhere. Same for form submissions.

Make it boring. Make it solid. And sprinkle delight on it.

Putting the blame on the users, saying «they can complete the transaction on another device», is a lazy mindset. And one that will hurt your bottom line. They will not complete the task on another device. They will leave for good.

In the same vein that the Web is a continuum, User Experience can be that too. If all the latest shiny technology is available, you are free to build the most amazing experience. If not, serve something that at least enabled core functionality.

If we embrace these layers, we will be able to build interfaces that work in the future. As well as the first web browser.

And, as we talk about the first browser:

We Say Old Like It’s a Bad Thing

We often talk about «old browser», as something to be discarded, because they are old. Seldom do we remember that these old browsers paved the way for everything we use today. This includes IE 5, the first browser to ship XMLHttpRequest and complete support for CSS 1. Or Mosaic, which shipped the now ubiquitous img tag (which has a remarkable story to tell).

I am not saying that we should all be using these browsers – or not be glad that some of the weirdness they forced upon is long gone. Still, all of these browsers managed to do one thing: keeping the continuum alive. We as people who build for the web should never forget this.

And, then there are people who are sticking with one older browser. The reasons are manifold. Some don’t know how to update, some maybe don’t want to upgrade.

An Accessible Elephant Enters the Room

The case against IE 11 is often justified by the fairly low percentage of people using it. And that might be true. In the grand scheme of things, anyways. And this is also where this line of reasoning gets problematic.
What it misses is a group of users that is all too often dismissed while developing sites; users of Assisitive Technology.

WebAIM regularly conducts a survey of screen readers. They published the 2019 edition in September. While the number of participants is fairly low and as as such not representative, they paint a picture that is remarkably different than «it’s only one percent and dwindling».

IE 11 is the third most popular browser in the survey (see the browser section of the results), used by 10 % of the respondents. The majority of the participants (85 %) are living in North America or Europe and almost half of them are 21–40 years old. This might sound like your target audience.

Now, taking a look at your analytics and making an informed decision is not the worst way forward. Keep in mind, though, that your analytics are skewed towards the people already using your site. The numbers don’t tell you about the people who could never use it.

Never Stop Building this Way

By broadening of definition of «support» and keeping in mind that support does not mean optimisation, by being thoughtful and resilient, the sites we build now will have a bright future, as well as being portable to the past.

And as my website works in the first ever browser, the first ever website works in modern browsers.

If that’s not amazing, I don’t know what is.

Acknowledgements

Thanks to Jeremy Keith, Rachel Andrew, Ethan Marcotte, Brad Frost and all people I’ve not linked in the text, but who wrote or spoke about building for the web and whose thoughts formed this post.

Now is probably a good moment to re-read A Dao of Web Design. Nineteen years old now and as relevant as ever.

Title image courtesy of NeONBRAND on Unsplash.