DEV Community: Andy Bell

A Modern CSS Reset

Andy Bell — Tue, 01 Oct 2019 00:00:00 +0000

I think about and enjoy very boring CSS stuff—probably much more than I should do, to be honest. One thing that I’ve probably spent too much time thinking about over the years, is CSS resets.

In this modern era of web development, we don’t really need a heavy-handed reset, or even a reset at all, because CSS browser compatibility issues are much less likely than they were in the old IE 6 days. That era was when resets such as normalize.css came about and saved us all heaps of hell. Those days are gone now and we can trust our browsers to behave more, so I think resets like that are probably mostly redundant.

A reset of sensible defaults

I still like to reset stuff, so I’ve been slowly and continually tinkering with a reset myself over the years in an obsessive code golf manner. I’ll explain what’s in there and why, but before I do that, here it is in its entirety:

/* Box sizing rules */
*,
*::before,
*::after {
  box-sizing: border-box;
}

/* Remove default padding */
ul[class],
ol[class] {
  padding: 0;
}

/* Remove default margin */
body,
h1,
h2,
h3,
h4,
p,
ul[class],
ol[class],
li,
figure,
figcaption,
blockquote,
dl,
dd {
  margin: 0;
}

/* Set core body defaults */
body {
  min-height: 100vh;
  scroll-behavior: smooth;
  text-rendering: optimizeSpeed;
  line-height: 1.5;
}

/* Remove list styles on ul, ol elements with a class attribute */
ul[class],
ol[class] {
  list-style: none;
}

/* A elements that don't have a class get default styles */
a:not([class]) {
  text-decoration-skip-ink: auto;
}

/* Make images easier to work with */
img {
  max-width: 100%;
  display: block;
}

/* Natural flow and rhythm in articles by default */
article > * + * {
  margin-top: 1em;
}

/* Inherit fonts for inputs and buttons */
input,
button,
textarea,
select {
  font: inherit;
}

/* Remove all animations and transitions for people that prefer not to see them */
@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Breaking it down

We start with box-sizing. I just flat out reset all elements and pseudo-elements to use box-sizing: border-box.

*,
*::before,
*::after {
  box-sizing: border-box;
}

Some people think that pseudo-elements should inherit box sizing, but I think that’s silly. If you want to use a different box-sizing value, set it explicitly—at least that’s what I do, anyway. I wrote about box-sizing more over on CSS From Scratch.

/* Remove default padding */
ul[class],
ol[class] {
  padding: 0;
}

/* Remove default margin */
body,
h1,
h2,
h3,
h4,
p,
ul[class],
ol[class],
li,
figure,
figcaption,
blockquote,
dl,
dd {
  margin: 0;
}

After box-sizing, I do a blanket reset of margin and padding, where it gets set by the browser styles. This is all pretty self-explanatory, so I won’t get into it too much.

I will mention the situation with lists, though. I select only lists that do have a class attribute because if a plain ol’ <ul> or <ol> gets used, I want it to look like a list. A lot of resets, including my previous ones, aggressively remove that.

body {
  min-height: 100vh;
  scroll-behavior: smooth;
  text-rendering: optimizeSpeed;
  line-height: 1.5;
}

Next up: body styles. I keep this really simple. It’s useful for the <body> to fill the viewport, even when empty, so I do that by setting the min-height to 100vh. I also like smooth anchor scrolling, so I set scroll-behavior: smooth, too.

I only set two text styles. I set the line-height to be 1.5 because the default 1.2 just isn’t big enough to have accessible, readable text. I also set text-rendering to optimizeSpeed. Using optimizeLegibility makes your text look nicer, but can have serious performance issues such as 30 second loading delays, so I try to avoid that now. I do sometimes add it to sections of microcopy though.

ul[class],
ol[class] {
  list-style: none;
}

Just like the margin and padding rules, I only reset list-style where a list element has a class attribute.

a:not([class]) {
  text-decoration-skip-ink: auto;
}

For links without a class attribute, I set text-decoration-skip-ink: auto so that the underline renders in a much more readable fashion. This could be set on links globally, but it’s caused one or two conflicts in the past for me, so I keep it like this.

img {
  max-width: 100%;
  display: block;
}

Good ol’ fluid image styles come next. I set images to be a block element because frankly, life is too short for that weird gap you get at the bottom, and realistically, images—especially with work I do—tend to behave like blocks.

article > * + * {
  margin-top: 1em;
}

I really like this CSS trick and I’ve finally been brave enough to add it to the reset. The lobotomised owl selector targets direct descendants of an article and adds 1em of top margin to them. This gives a solid rhythm to flow content. I actually use a .flow utility in every project now. You can read more about it on 24 Ways. In fact, I reckon it’s my most used CSS these days.

input,
button,
textarea,
select {
  font: inherit;
}

Another thing I’ve finally been brave enough to set as default is font: inherit on input elements, which as a shorthand, does exactly what it says on the tin. No more tiny (mono, in some cases) text!

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Last, and by no means least, is a single @media query that resets animations, transitions and scroll behaviour if the user prefers reduced motion. I like this in the reset, with specificity trumping !important selectors, because most likely now, if a user doesn’t want motion, they won’t get it, regardless of the CSS that follows this reset.

ℹ️ Update: Thanks to @atomiks, this has been updated so it doesn’t break JavaScript events watching for animationend and transitionend.

Wrapping up

That’s it, a very tiny reset that makes my life a lot easier. If you like it, you can use it yourself, too! You can find it on GitHub or NPM.

What do you find the most difficult with CSS?

Andy Bell — Sat, 28 Sep 2019 12:22:06 +0000

I’m writing a new book that teaches you how to write CSS from scratch, so I’m curious about what people find the most difficult with CSS.

Also, what do you wish you were taught about CSS, early on in your career?

Create a semantic “breakout” button to make an entire element clickable

Andy Bell — Fri, 27 Sep 2019 00:00:00 +0000

A common design pattern is to have something like a “card” element that has to be fully clickable. This is usually because it links to another page or triggers a JavaScript action.

The problem though, is that often, you end up with stuff that looks like this:

<div onClick="alert('Nope')">Please don’t ever do this.</div>

You should absolutely never attach a click event to a <div> element, though, even if you sprinkle it with aria roles to “fake” a real button. Although this is technically possible, if assistive technology doesn’t support the aria roles in question, the user will just get <div>s and nothing else. Not cool.

In this article, we’re going to remedy this common crime by instead using the magic of CSS to give us the desired fully clickable element effect, while also using proper semantic elements and JavaScript and as an enhancement.

What we’re making

We’re going to use the context of an <article> that when a button is clicked, a JavaScript alert fires. Here’s a CodePen demo:

To code along, you’re going to need a HTML file, a CSS file and a JavaScript file. I recommend that you use a service like CodePen that does all of this for you.

For the rest of this section, we’re going to be laying the foundations. If you’re in a rush, you can skip this section and use this starter CodePen instead.

Getting started with markup

We need some HTML to work with, so add this:

<article class="box">
  <h1>A semantic, breakout button</h1>
  <p>This whole box is clickable, but still uses a button element, correctly.</p>
  <button class="breakout-button" type="button">Say Hi 👋</button>
</article>

We’ve got an article, a heading, a paragraph and a button. Job done for HTML for now.

Base CSS styles

Before we get into the proper CSS stuff, let’s set some base styles. Add this CSS:

body {
  background: #efefef;
  padding: 3rem 2rem;
  line-height: 1.4;
  font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Helvetica, Arial,
    sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol';
  font-size: 1.2rem;
}

h1 {
  font-size: 2rem;
  line-height: 1.1;
  font-weight: 600;
}

.box {
  color: #fff;
  padding: 2rem;
  max-width: 30rem;
  background: #252525;
  position: relative;
  box-shadow: none;
  transition: transform 300ms ease-in-out, box-shadow 400ms ease, background 100ms ease;
}

.box:hover,
.box:focus-within {
  background: #111111;
  box-shadow: 0 1rem 1rem rgba(0, 0, 0, 0.3);
  transform: translateY(-0.5rem);
}

.box > * + * {
  margin-top: 1em;
}

Looking pretty decent, right? That’s it for our base styles.

Creating the breakout button component

We’ve got base styles, so let’s focus all of our attention on the .breakout-button component.

Core component styles

In your CSS, add the following:

.breakout-button {
  font: inherit;
  font-weight: 600;
  padding: 0.6rem 2rem;
  background: transparent;
  color: currentColor;
  border: 1px solid;
  transition: background 100ms ease;
  position: static;
}

Here, we have some simple styles for our button which make it looks nicer. A handy takeaway trick here is that because we are using font: inherit and color: currentColor, we get all of our text styles for free, using the cascade, which is by far my favourite aspect of CSS. Also notice that we are setting .breakout-button to be position: static. This is because we want our “breakout element” (coming up) to literally break out of the button!

Related to this is that the .box element has position: relative, which means that any child elements without a relative parent that have position: absolute will be contained in this .box. Because that’s what our breakout button will do as its sole purpose, you should always remember to make its containing parent behave like this. The position: static on the .breakout-button itself is a failsafe to make sure the “breakout element” isn’t ever contained to the .breakout-button element.

Right, let’s add some more code. Under the .breakout-button component style, add this CSS:

.breakout-button,
.breakout-button::before {
  cursor: pointer;
}

We’ve set both the button and its ::before pseudo-element to have a pointer cursor. There’s some contention around wether a <button> should have a pointer cursor and I very much sit in the camp that by proxy of exposure, it is now an expected style and shouldn’t really have a negative user experience impact.

Anyway, we digress… Add the following CSS to create the “breakout element”:

.breakout-button::before {
  content: '';
  display: block;
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

It’s pretty straightforward. We make this pseudo-element an absolutely positioned block element that will “break out” until it hits the bounds of a relative, absolute or fixed parent. In our context, this parent is the .box element because it has position: relative set.

The “breakout element” is visually hidden, so to help you understand how it behaves, check out this demo where I’ve added some colour to it:

Interactive styles

Now that we’ve got the core component setup, let’s style up the interactivity. Add this to your CSS:

.breakout-button:focus {
  outline: none;
}

.breakout-button:hover {
  background: #333333;
}

The first thing we do is remove focus outline from the button. I can’t stress this enough, though: you must have visible focus styles for interactive elements, so keyboard users can actually see where their focus currently is. If you remove the default outline CSS rule, you must replace it with something effective and obvious.

This is exactly what we’re going to do now, by adding a solid outline to our “breakout element” when the parent button is focused. Add this CSS:

.breakout-button:focus::before {
  outline: 1px solid #ffffff;
  outline-offset: -0.8rem;
}

Now that we’ve sorted our button out, let’s add some hover styles to our .box element. Add this to your CSS, with all of the other .box styles:

.box:hover,
.box:focus-within {
  background: #111111;
  box-shadow: 0 1rem 1rem rgba(0, 0, 0, 0.3);
  transform: translateY(-0.5rem);
}

This makes our box shift up either on hover, or if there’s focus inside it, which means when our button element is focused, our box’s appearance will change.

That’s it! Our “breakout button” finished and this is what it should look like:

Improving our breakout button with progressive enhancement

As usual, I make you think that you’re done, but then slip in some progressive enhancement when you least expect it, because as it stands, our project is just ok. Because we’re using a <button>, it’ll be about as useful as a chocolate teapot when JavaScript isn’t available. What we’re going to do to fix this is hide the button by default with a hidden attribute, and when JavaScript is available, we’ll show it by removing the hidden attribute.

We’re also going to add a bonus bit of attention to detail and only display the interactive states when JavaScript is available too, using a data attribute as a style hook.

Open up your HTML and add a hidden attribute to the <button> like this:

<button class="breakout-button" type="button" hidden>Say Hi 👋</button>

Now we need to add some JavaScript to show the <button> by removing that hidden element:

const button = document.querySelector('.breakout-button');

if (button) {
  button.removeAttribute('hidden');
}

Like I said above, though, we should also only show interactive styles such as :hover and :focus states when the button is available too. Let’s replace your existing JavaScript with this JavaScript:

const button = document.querySelector('.breakout-button');

if (button) {
  button.parentElement.setAttribute('data-interactive', '');
  button.removeAttribute('hidden');

  button.addEventListener('click', evt => {
    evt.preventDefault();

    alert('Oh hi there 👋');
  });
}

We’ve added an event handler for the button’s click event, but most importantly, we’ve added a data-interactive attribute to the button’s parent, which means we can now use this as a style hook.

Amend your CSS by deleting this block:

.box:hover,
.box:focus-within {
  background: #111111;
  box-shadow: 0 1rem 1rem rgba(0, 0, 0, 0.3);
  transform: translateY(-0.5rem);
}

And now, replace it with this block:

[data-interactive]:hover,
[data-interactive]:focus-within {
  background: #111111;
  box-shadow: 0 1rem 1rem rgba(0, 0, 0, 0.3);
  transform: translateY(-0.5rem);
}

Now, the .box will behave like a normal element when JavaScript isn’t available, like so:

Wrapping up

That’s it, we’re done. Yours should now look like this:

Hopefully this article shows that when you think outside the box (or inside it in this context), CSS, semantic HTML and a sprinkle of JavaScript can give you solid, progressive components that work for everyone.

Bite Sized Basics: Box Sizing

Andy Bell — Mon, 23 Sep 2019 19:39:00 +0000

I originally posted this on https://cssfromscratch.com

If there’s ever one really important thing to remember when writing CSS is that everything is a box. Regardless of how it looks visually—it’s still a box.

Take the above example: it’s visually a circle, by proxy of border-radius, but it’s still a box, as far as the browser is concerned.

Padding and borders

When we add padding and borders to an element, by default, their values will be added to the computed width and height. This can be confusing—especially when you are first starting out.

.box {
  width: 100px;
  padding: 10px;
  border: 10px solid;
}

What happens here is your .box’s computed width is actually calculated as 140px. This is how the box model works, out of the box (pun intended), and is expected behaviour. Most of the time though, it’s preferable for this not to be the case, so we add this little snippet of CSS:

.box {
    box-sizing: border-box;
}

This completely transforms the browser’s calculation because what it does is say “Take the dimensions that I specified and also account for the padding and border, too”. What you get as a result, is a box that instead of being 140px wide, is now 100px wide, just like you specified!

The box-sizing rule is usually added as a global selector to a reset, or default normalising styles, so to set a more complete example, this is how our box CSS now looks:

/* Reset rule */
*, 
*::before, 
*::after {
    box-sizing: border-box;
}

/* Box component */
.box {
  width: 100px;
  padding: 10px;
  border: 10px solid;
}

What this now does is instead of just targeting the .box, it targets every element on the page and any pseudo-elements.

Wrapping up

You can read more on box sizing over on MDN, where there is some very good documentation.

Setting box-sizing: border-box is such a life saver—especially for responsive design. This is so much the case that we even have “International box-sizing Awareness Day” on February 1st, every year.

Anyway: sign up for updates on Product Hunt, subscribe to the RSS feed or follow @cssfromscratch on Twitter to keep in the loop.

Keeping it simple with CSS that scales

Andy Bell — Wed, 18 Sep 2019 00:00:00 +0000

This is the written version of my new talk, “Keeping it simple with CSS that scales”, which I first delivered at State of the Browser 2019.

It’s a very long read, so I recorded an audio version, too:

CSS has a weird place on the web today. There’s a lot of polarisation, with the opinion being seemingly split on “CSS sucks” and “CSS rules, learn it better, fools”.

I empathise with the “CSS rules” camp and I’ll explain why: I have a theory as to why the “CSS sucks” camp have the attitude that they do. I think it’s a combination of them over-engineering their CSS, not fully understanding the power of CSS and finally, approaching it like it is a language like JavaScript and expecting it to work in the same way.

What I’m going to do in this piece, is tackle the first bit and talk to you all about how we can simplify CSS to give us incredible power, while also being as low-tech as possible. The secret sauce is that most of the content isn’t actually about CSS, but that’ll all become clearer, later.

Let’s talk about scale

I absolutely hate it when we use the term, “Scale”. I think we are stuck with it though, just like we are stuck with “JAMstack”, “Serverless” and “performant”.

They’re all equally awful words, but one thing they do is create a common, recognisable construct for communication. As much as it pained me, it’s exactly why I named this talk “Keeping it simple with CSS that scales”. You probably knew before I even opened my gob that I’d be talking about working on massive codebases, which at some point in this talk, I’ll get to.

One thing that I do get pissed off about with “Scale”, though, is that gets slightly muddied when people use it as an excuse to over-engineer something.

Let’s take this common example. It usually gets said by some Bay Area tech bro:

We use a CSS-in-JS library because our product needs to scale

Let’s be honest for a moment, folks: most of the tepid guff that these tech bros are making will only scale as far as the bin, so it’s not much of a valid excuse, is it?

I’ll also be bold and straight-up say that I don’t think using scale as an excuse for over-engineering stuff—especially CSS—is acceptable, even for huge teams that work on huge products. Keep that in mind, because I hope, by the end of this session, you’re going to be in agreement with me.

Four key things

I think we can focus on four key things today, and for the rest of this piece, I’m going to run us through them in detail with a little progress thing, so you know roughly how much longer you have to endure me for.

I could package this up as DCCS and really mop up the upvotes on that orange website, right?

Anyway, let’s dive in.

Don’t panic

One of my favourite books is The Hitchhiker’s Guide to the Galaxy. It’s about the earth being blown up to make way for a hyperspace highway and our main character, Arthur Dent proceeds to hitchhike around space with his alien guide, Ford Prefect.

I know, that’s a proper rubbish synopsis, but you all didn’t come here to read me chatting about this book.

The actual Hitchhiker’s Guide to the Galaxy is a sort of interactive encyclopaedia—well, interactive by 1979 standards...

The thing that has always resonated with me about the encyclopaedia is on the cover it says: “Don’t Panic”. The phrase is used so many times throughout the story, even when the context very much calls for panic.

I find myself really resonating with Ford Prefect, guiding Arthur Dent—a bumbling brit through the understandably mind-boggling adventure in space. Ford always approaches challenges in a calm, pragmatic way, just like the guide tells him to: “Don’t Panic”, and I think that’s a takeaway for us too.

In fact, when Arthur first gets the book handed to him, he says:

“I like the cover...‘Don’t Panic’. It’s the first helpful or intelligible thing any-body’s said to me all day.“

Right, anyway, I digress…“don’t panic”. It’s such good advice because when we panic, we make silly mistakes. Think about it: how many horrendous CSS hacks have you made when you’re up against-it in a project and you just needed to get it done.

A lot of people do it and it’s because we’re panicking. The deadline is looming and there’s no time to work out why our CSS is borked, so we throw !important at it until it’s fixed.

This is fine: we all do it, but what isn’t fine is technical debt. Often panic goes beyond a little hack here-and-there and escalates into something much more serious, like employing a CSS-in-JS framework, which is the equivalent of taking out a Wonga loan to pay of your house mortgage.

Incredibly high interest technical debt, which frustratingly, the developers who took it out, only pay a bit off, because that developer has probably already gone and got a new job. It’s mainly the user who takes the biggest hit, in terms of performance, and this boggles my mind when you consider what we have available to us with modern CSS.

The current state of CSS

Really, we’ve never had it better with CSS. We have CSS Grid with 93% support and Flexbox with 98.8% support. Approach using them with a safe progressive enhancement mindset and your layout is sorted. Job done. No worries.

We also get CSS Custom Properties which are native CSS variables. They’re incredibly handy for tokenising our CSS. Because they are also affected by the cascade, we can can override them, contextually. This makes them useful for theming, algorithms and display modes, such as dark mode.

:root { --primary: #8e8e8e;}.box { background: var(--primary);}.badge { color: var(--primary);}

These are just a subset of powerful new features, but you can see how modern CSS is an incredibly powerful, effective styling tool. But it can come up a bit short, especially when you do have lots of CSS. So let's look at how we can deal with that.

Sass for the win!

All of this native functionality is cool as heck, right? Let’s not forget native nesting too, but who does all of the work when we use that? Yep: the browser!

In most cases, that’s fine, although the thought of native CSS terrifies me—especially when we are already kludging up the browser with heavy JavaScript frameworks.

Basically, what I’m saying is we don’t have to abandon Sass because native language features are coming. It’s probably better to cautiously pre-compile your CSS and not force the browser to work as hard. It’s already working hard enough, re-rendering the DOM every time one piece of data changes (cough reactive frameworks cough), so why make it work harder just so you can have native nesting? It smells like developer experience over user experience to me.

We rush to throw stuff in the bin without thinking about the wider implications. Yeh, we’ll get nesting soon, but how is a low-powered device going to handle 5 levels of nesting with chained selectors? How is a low-powered device going to handle calculating the colour of a Custom Property that has been overridden by the cascade 5 times? It doesn't matter how good the native tools are because if we keep throwing rubbish code at browsers, the users will suffer for it.

The beauty of Sass is that you can have the best of both worlds. You get cool stuff like nesting, but if you do it right, you can get nice, flat selectors. You also get components and if you want, you can set your project up to get multiple bundles. You can also lint your CSS at build time, so you know when stuff is getting out of hand, right in your terminal or GUI.

The most important thing is that with Sass—well, SCSS, you’re writing CSS still. SCSS is smart enough to just do what it needs to focus on and leave the rest of your CSS alone. To me, it feels like a pretty perfect setup.

Communicate

We seem to be in an era where tools and methodologies are dreamed up to help avoid communicating with each other.

Generated CSS class names is a classic example of this. It’s a very typical problem. Some might at this point start having an existential crisis, or dream of machine-generated classnames, but check this out: we’re going to try this novel thing called talking:

Dev #1 - Lucrecia

“This component I came up with already exists. Let me have a quick look in git and see who created it. Ah, it was Isabella”

Lucrecia to Dev #2, Isabella

“Hey, Dev Isabella, is there a reason why this component is called 'block'?”

Isabella to Lucrecia

“Ah yeh, this very important reason. How about you call that component 'box' instead?”

Now this important reason could be anything you dream up:

A stakeholder decision
A legacy codebase issue
A Design decision

Importantly, Isabella, a professional, who knows how to communicate effectively, comes up with an alternative.

Lucrecia

“That’s a great idea. Thanks!”

How wholesome was that?? It’s amazing what happens when we actually talk to each other.

So-called “soft skills” which I prefer to call core skills are shunned in favour of being able to build your own linked-list or do fizz buzz on a whiteboard. This winds me up because to be an effective member of a team, you have to be able to communicate, whereas the only time you ever do fizz buzz in the real world is during that life-draining interview process…

Documentation is everything

Another incredible way to communicate that’s not actual talking is writing. I love writing and you probably noticed, I do a lot of it… In fact, I write almost everything down because I never know when I might need it. It also helps me to commit stuff to memory.

There’s a real value in writing everything down—especially in a large team of front-end developers, writing CSS—or any code, really. You can document your thought-process and explain how and why you’ve done things. You can write documentation, so if another developer picks up your code, they know what’s going on.

By documentation, I don’t mean that you have to write reams and reams of structured docs: I’m talking goddamn comments in your code.

Take this example:

.card { background-color: #ffffff !important;}

If I landed on this I would be like “What the heck is going on here?”

How about this, though?

.card { /* When this card is used in the legacy app, there is a collision between existing styles, so unfortunately we had to go nuclear. It’s certainly a refactor target. */ background-color: #ffffff !important;}

Now if I landed on this, I would be more like: “Huh, fair enough. I’ve got a spare bit of time: maybe I should see if I can work out the specificity issue”.

Good written communication can prevent unnecessary collisions between people, which can in turn, prevent expensive technical debt created by silly tools

A win-win in my books!

Right, enough of me yammering on about how to be functioning adults for a minute, because I’m this far into this piece and I’ve not talked about how to write CSS yet. Let’s do it.

Consistency

I think consistency is key to scaling CSS (sorry I said scale again). Really, this is what these over-abstractions are trying to give you, in my opinion, they just go way too far.

I use a methodology that is sort of a devolution of BEM—a simplified version. I call it C-BEUT , which stands for Cascade , Block , Element , Utility and Token. It’s a proper rubbish name, I know, but it suits the rest of the awful stuff that we come up with for names, doesn’t it? I’ll explain how C-BEUT works.

Cascade

The “C” in CSS stands for “Cascading”. Cascade is my favourite part of CSS because if you use it right, you can write very little CSS and get really good results in return. With this methodology, cascade is the first port of call. I set sensible defaults, higher level theming and typography as high up as I can. This gives us so much power.

The components can then be much more skeletal and deal only with how they are different than the globals, rather than dealing with everything.

Block

This is your component, your card or your button. It’s the building block of your user interface. And that's about it really—a construct and nothing else.

Element

This is something that is a dependent of your block—a child element. It always lives in its parent block. A good example of this is within your card, you might have a card__image.

I try to keep the elemental classes as light as possible and use CSS algorithms to distribute content, rather than diving even deeper.

Again, this keeps our component files light and skeletal.

Utility

This is a class that does one job and does it well—like a plumber or a tin opener. An example of a utility class is a one that centers text or applies some top margin. Simple, low-fidelity tools.

Importantly, it means you can write common CSS and apply it where you need it, rather than repeating yourself over-and-over again.

Token

This is actually a utility class, but a specific utility class that implements a design token and is often generated by a separate tool.

What’s a design token? they scream: I’ll let my pal Jina explain them, because they invented them!

Design Tokens are the visual atoms of the design system – specifically, they are named entities that store visual design attributes. We use them in place of hard–coded values in order to maintain a scalable and consistent visual system.

— @jina

These little classes are great for decoupling the scaffold of your UI from the design system. It enables the system to live away from the code context that you are in, which gives it great power.

The .text-600 token is a reference to a size scale, just like this one off my website. It uses a major-third scale which gives us that lovely curve between sizes.

It’s used for everything, too:

Sizing text
Spacing elements
Adding inner padding

That’s it really and I won’t sit here, telling you that it’s the best way to write CSS, because it probably isn’t. What it is though is consistent. Just like BEM is or ITCSS is. At the end of the day, find something that works for your team, stick to it and document the hell out of it. Enable people in your team to make consistent decisions without slowing them down.

One thing I will say about methodologies is that if you find yourself restricted by one: invest the time to experiment with something different. Things change, so accept and embrace that fact. It’s why I now use C-BEUT, rather than BEM. I think BEM is amazing, but I also ran into issues where my modifiers were getting out of hand, so I sat back, simplified what I was trying to achieve, and settled on using utilities and tokens instead.

Always be open to change. We live in a dynamic world and work in an incredibly dynamic industry. If you stick to your guns too tightly, you’re probably going to end up causing more problems not just for yourself, but everyone else, in the future.

Simplification

It’d be wild if I did a presentation, titled “Keeping it simple with CSS that scales” and didn’t talk about simplification, wouldn’t it?

Let’s start by talking about frameworks. Do you really need one? I don’t think that you do anymore.

Bootstrap is an incredibly powerful framework. It came at a time when we were learning how to build responsive websites and fighting relentless compatibility issues with browsers. It was a hellish time and Bootstrap, to its credit, made it all much easier. In fact, I’d go as far as saying that by accident, Bootstrap is one of the best design systems ever created.

Using Bootstrap today—when we have actual native tools for layout, such as grid and flex—is like using a sledgehammer to crack an egg. It can also bring complications of its own, too. Because of the way it is built, it uses very global selectors to aggressively set styles. This results in stuff like this again:

.card { background-color: #ffffff !important;}

The same goes for most CSS frameworks to be honest. An example that gives me a heart attack is Tailwind CSS generates over 40 thousand lines of CSS by default (source). Bonkers.

If you have a solid methodology like BEM, ITSCSS, SMACSS or even C-BEUT, you could sprinkle a bit of a grid system with, y'know GRID, add some layout helpers with flex and you are golden.

This is the approach that we took with Every Layout—a book that I co-authored with my good pal, Heydon Pickering.

For our layouts, we find the most robust solution by simplifying and distilling our problem. We then hint the browser, using axioms and rudiments, rather than micro-manage it to allow it to call the shots. This results in a very solid layout system that works upwards with progressive enhancement at the forefront.

It’s been a really cool project and resonated with a lot of people, so go ahead and check it out.

On the subject of progressive enhancement, gather around and take a knee for a moment, everyone.

Don’t dismiss modern CSS because you have to support IE11.

It’s a ridiculous mindset and it pisses me off whenever someone shares a cool trick on Twitter and a Chad will pop into the comments with “WhAt aboUt IE 11 tHOuGh”.

Stop trying to pixel push your designs and instead, use progressive enhancement to create a sensible default that automatically improves where support is available.

Take this example: we’ve got a good ol’ three column grid. In times gone by, we’d employ some hacks not just to lay it out, but also make it look like this in every browser.

What I propose is that we take a step back, simplify the problem , and find a sensible baseline, and here it is: Good ol’ stacking with space. We can achieve 100% coverage with tiny amounts of CSS now.

This is a handy little grid system that uses minmax to distribute columns. It means we get a responsive grid with no media queries.

.auto-grid { display: grid; grid-template-columns: repeat(auto-fill, minmax(16rem, 1fr)); grid-gap: 1rem;}

But, grid still isn’t quite full supported, but thanks to CSS’s nature, it’ll ignore stuff it doesn’t understand and move on, so we can add this below our grid code:

.auto-grid > * { max-width: 25rem; margin-left: auto; margin-right: auto;}.auto-grid > * + * { margin-top: 1rem;}

Now, thanks to @supports, we can reset some of that where there is support. If a browser supports grid, it supports @supports, so job done.

It's 22 lines of CSS, with no hacks and works all the way back to IE9 (and probably beyond).

See the Pen Progressively enhanced, media query-free grid by Andy Bell (@andybelldesign) on CodePen.

Slow down

The last point on simplification and really, the last point of this presentation before I wrap up is “slow down”.

Seriously, slow down. I know it’s hard when you are working sprint-to-sprint or on a massive project, but trust me, when shit hits the fan, just slow down.

I came a cropper to this earlier in the year. I was working on a massive system/pattern library and we were hit with some early complications. What I should have done was stop, stepped back and put some critical thinking in place. But what I did instead was plough on through each sprint, each retro and each planning session until it got to the point where not slowing down had massive negative implications. I was cashing tech debt like I was earning air miles on it.

We had two or three grid systems, some fluid type and some utility driven type that conflicted and a card component that was pretty much a website in itself. If I had slowed down and stepped back, I could have seen these problems, but I didn’t. So seriously, slow down and you will save so much time.

I’ll leave you with this take-home advice: instead of moving fast and breaking things, move slowly and deliberately instead.

You can watch me deliver this talk at State of the Browser 2019, here.

You can see the slide deck from that presentation, here.

Create a user controlled dark or light mode

Andy Bell — Fri, 31 May 2019 00:00:00 +0000

Ever since the prefers-color-scheme media query landed, folks have been rolling out dark themes for their websites as often as they use the entire React library to power a hamburger menu on their static blog.

A lot of the time, folks rightly add a dark/light switch to give the user a choice. Oftentimes, though, folks will do one of the most dangerous things in design: make a presumption and roll out a dark theme if the user’s operating system preference is dark mode, and just leave it at that.

It’s important to not make presumptions in design if you can help it, so I’m going to show you a quick and easy way to honour the user’s operating system preference by default, but also give them a toggle button to change their preference, manually.

What we are building

Watch video

The video shows that because my operating system is in dark mode, the demo honours it by default. I then use the toggle to switch the theme. This is then maintained by local storage.

Laying the foundations

You can skip this section completely and fork the base code on CodePen. If not, follow along to add the following base code.

You’re going to need a HTML file, a CSS file and a JavaScript file. I’ve built this in Codepen to make things easier for us all.

In your HTML file (or HTML panel in CodePen), add the following code:

<main> <article> <h1>Dark mode should be a user preference—not presumed</h1> <p> Yes, by default, when a user has <code>@media (prefers-color-scheme: dark)</code> set, we should set a dark theme, but we should also provide a switch for if the dark them isn’t working out for them. </p> <p>This also benefits users that don’t have <code>@media (prefers-color-scheme: dark)</code> set because they get a toggle to choose, too.</p> </article> <div class="user-toggle"> <div role="status" class="[visually-hidden][js-mode-status]"></div> <button class="[toggle-button] [js-mode-toggle]"> <span class="[toggle-button__text] [js-mode-toggle-text]">Enable dark mode</span> <span class="toggle-button__icon" aria-hidden="true"></span> </button> </div></main>

That’s all of the HTML that we need and the <article> element only serves as a demo. Everything that lives in .user-toggle is the important part.

Next up, let’s add some CSS. We’ll add our core presentational styles first. Paste this into your CSS file (or CSS panel on CodePen):

/* Presentational demo styles */body { font-family: sans-serif; padding: 2rem 1rem; line-height: 1.4; display: grid; place-items: center;}article { max-width: 75ch; margin: 0 auto;}article > * + * { margin-top: 1em;}h1 { font-size: 2.5rem; line-height: 1.1;}p { font-size: 1.2rem; opacity: 0.9;}code { font-weight: 700; font-size: 1.3em; white-space: pre;}.visually-hidden { display: block; height: 1px; width: 1px; overflow: hidden; clip: rect(1px 1px 1px 1px); clip: rect(1px, 1px, 1px, 1px); clip-path: inset(1px); white-space: nowrap; position: absolute;}

Cool—we’ve got our base HTML and CSS in place. You might also want to add this reset that I use for my demos.

CSS Custom Properties are doing the heavy lifting for us, so next, let’s define some at the :root level, which is on the <html> element.

:root { --color-mode: 'light'; --color-dark: #141414; --color-dark-alpha: rgba(0, 0, 0, 0.1); --color-light: #efefef; --color-light-alpha: rgba(255, 255, 255, 0.9); --icon-sun: url('data:image/svg+xml,\ <svg version="1.1" xmlns="http://www.w3.org/2000/svg" fill="currentColor" viewBox="0 0 24 24">\ <path d="M18 12c0-0.811-0.161-1.587-0.455-2.295-0.304-0.735-0.75-1.395-1.303-1.948-0.552-0.552-1.213-0.998-1.948-1.303-0.707-0.293-1.483-0.454-2.294-0.454s-1.587 0.161-2.295 0.455c-0.735 0.304-1.395 0.75-1.948 1.302s-0.998 1.213-1.302 1.948c-0.294 0.708-0.455 1.484-0.455 2.295s0.161 1.587 0.455 2.295c0.304 0.735 0.75 1.395 1.303 1.948 0.552 0.552 1.213 0.998 1.948 1.303 0.707 0.293 1.483 0.454 2.294 0.454s1.587-0.161 2.295-0.455c0.735-0.304 1.395-0.75 1.948-1.303s0.998-1.213 1.303-1.948c0.293-0.707 0.454-1.483 0.454-2.294zM16 12c0 0.544-0.108 1.060-0.303 1.529-0.202 0.489-0.5 0.929-0.869 1.299s-0.81 0.667-1.299 0.869c-0.469 0.195-0.985 0.303-1.529 0.303s-1.060-0.108-1.529-0.303c-0.489-0.202-0.929-0.5-1.299-0.869s-0.667-0.81-0.869-1.299c-0.195-0.469-0.303-0.985-0.303-1.529s0.108-1.060 0.303-1.529c0.202-0.489 0.5-0.929 0.869-1.299s0.81-0.667 1.299-0.869c0.469-0.195 0.985-0.303 1.529-0.303s1.060 0.108 1.529 0.303c0.489 0.202 0.929 0.5 1.299 0.869s0.667 0.81 0.869 1.299c0.195 0.469 0.303 0.985 0.303 1.529zM11 1v2c0 0.552 0.448 1 1 1s1-0.448 1-1v-2c0-0.552-0.448-1-1-1s-1 0.448-1 1zM11 21v2c0 0.552 0.448 1 1 1s1-0.448 1-1v-2c0-0.552-0.448-1-1-1s-1 0.448-1 1zM3.513 4.927l1.42 1.42c0.391 0.391 1.024 0.391 1.414 0s0.391-1.024 0-1.414l-1.42-1.42c-0.391-0.391-1.024-0.391-1.414 0s-0.391 1.024 0 1.414zM17.653 19.067l1.42 1.42c0.391 0.391 1.024 0.391 1.414 0s0.391-1.024 0-1.414l-1.42-1.42c-0.391-0.391-1.024-0.391-1.414 0s-0.391 1.024 0 1.414zM1 13h2c0.552 0 1-0.448 1-1s-0.448-1-1-1h-2c-0.552 0-1 0.448-1 1s0.448 1 1 1zM21 13h2c0.552 0 1-0.448 1-1s-0.448-1-1-1h-2c-0.552 0-1 0.448-1 1s0.448 1 1 1zM4.927 20.487l1.42-1.42c0.391-0.391 0.391-1.024 0-1.414s-1.024-0.391-1.414 0l-1.42 1.42c-0.391 0.391-0.391 1.024 0 1.414s1.024 0.391 1.414 0zM19.067 6.347l1.42-1.42c0.391-0.391 0.391-1.024 0-1.414s-1.024-0.391-1.414 0l-1.42 1.42c-0.391 0.391-0.391 1.024 0 1.414s1.024 0.391 1.414 0z"></path>\ </svg>'); --icon-sun-filter: invert(0.61) sepia(0.8) saturate(5) hue-rotate(0deg) brightness(0.92); --icon-moon: url('data:image/svg+xml,\ <svg version="1.1" xmlns="http://www.w3.org/2000/svg" fill="currentColor" viewBox="0 0 24 24">\ <path d="M21.996 12.882c0.022-0.233-0.038-0.476-0.188-0.681-0.325-0.446-0.951-0.544-1.397-0.219-0.95 0.693-2.059 1.086-3.188 1.162-0.696 0.047-1.399-0.027-2.077-0.226-0.656-0.192-1.29-0.501-1.874-0.932-0.655-0.484-1.181-1.074-1.575-1.729-0.409-0.68-0.676-1.432-0.792-2.206s-0.082-1.571 0.11-2.342c0.184-0.741 0.514-1.46 0.999-2.115 0.142-0.191 0.216-0.435 0.191-0.691-0.053-0.55-0.542-0.952-1.092-0.898-1.117 0.109-2.186 0.399-3.172 0.843-1.005 0.452-1.925 1.065-2.723 1.808-0.883 0.82-1.618 1.801-2.159 2.901-0.523 1.064-0.863 2.238-0.978 3.485-0.125 1.347 0.024 2.658 0.402 3.878 0.392 1.266 1.031 2.431 1.863 3.433s1.86 1.843 3.033 2.461c1.13 0.595 2.392 0.982 3.739 1.106s2.659-0.025 3.878-0.403c1.266-0.392 2.431-1.031 3.433-1.863s1.843-1.86 2.461-3.033c0.595-1.13 0.982-2.392 1.106-3.739zM19.567 14.674c-0.126 0.351-0.276 0.689-0.447 1.014-0.493 0.937-1.166 1.76-1.969 2.427s-1.735 1.178-2.747 1.491c-0.973 0.302-2.021 0.421-3.102 0.321s-2.089-0.41-2.99-0.884c-0.937-0.493-1.76-1.166-2.427-1.969s-1.178-1.735-1.491-2.747c-0.302-0.973-0.421-2.021-0.321-3.102 0.092-1 0.365-1.938 0.782-2.786 0.43-0.878 1.018-1.661 1.725-2.319 0.64-0.595 1.377-1.086 2.183-1.449 0.179-0.081 0.362-0.155 0.548-0.223-0.092 0.257-0.171 0.516-0.236 0.778-0.256 1.029-0.302 2.091-0.147 3.121s0.51 2.032 1.056 2.941c0.527 0.875 1.23 1.663 2.1 2.306 0.775 0.573 1.622 0.986 2.5 1.243 0.907 0.266 1.846 0.364 2.772 0.302 0.752-0.050 1.496-0.207 2.21-0.465z"></path>\ </svg>'); --icon-moon-filter: invert(0.75); --background: #efefef; --text-color: #141414; --button-icon: var(--icon-moon); --button-icon-filter: var(--icon-moon-filter); --button-background: var(--color-dark); --button-color: var(--color-light); --border-color: var(--color-dark-alpha);}

There’s a big chunk in there, so let’s break it down a bit:

We define the --color-mode variable and set it to 'light' by default. This is used to communicate to the JavaScript what the user’s preference is
We’re defining some SVG icons in CSS (I know, cool, right?). I probably wouldn’t do this on a production site, but it’s a pretty cool trick, and ever since I saw on Twitter that Lea Verou was demoing this technique in her talk, I really wanted to have a go

The rest is pretty self explanatory theme colours and the default application of the light theme.

Dealing with the `prefers-color-scheme` media query

We’ve got all of our base code in place now, so let’s deal with the user’s preference for prefers-color-scheme. We’re also going to deal with the JavaScript controlled preference, too, while we’re at it.

body { background: var(--background); color: var(--text-color); transition: background 500ms ease-in-out, color 200ms ease;}@media (prefers-color-scheme: dark) { :root { --color-mode: 'dark'; } :root:not([data-user-color-scheme]) { --background: var(--color-dark); --text-color: var(--color-light); --button-icon: var(--icon-sun); --button-icon-filter: var(--icon-sun-filter); --button-background: var(--color-light); --button-color: var(--color-dark); --border-color: var(--color-light-alpha); }}[data-user-color-scheme='dark'] { --background: var(--color-dark); --text-color: var(--color-light); --button-icon: var(--icon-sun); --button-icon-filter: var(--icon-sun-filter); --button-background: var(--color-light-alpha); --button-color: var(--color-dark); --border-color: var(--color-light-alpha);}

Let’s cover some key bits:

If the user prefers dark mode, inside of the media query we’re making the relevant theme changes
In that same media query, we’re also setting the --color-mode, which JavaScript can hook on to
Notice how the CSS is applied if the <html> (:root) element doesn’t have a data-user-color-scheme attribute. This is to prevent the default overriding the user preference
Under the media query, we’re using this attribute selector to look for a data-user-color-scheme attribute with the value of dark. We set this with JavaScript later in this tutorial, but notice how this does the same thing as the media query. This could be refactored with a Sass mixin, but for this tutorial, we’ll wear the mild repetition

Adding the toggle styles

The last bit of CSS is making the toggle button look cool. We interchange a sun and moon icon, as well as colouring it in the inverse of the current theme.

Add this CSS:

.no-js .user-toggle { display: none;}.user-toggle { margin: 2rem auto 0 auto; padding-top: 2.5rem; max-width: 20rem; border-top: 1px solid var(--border-color); text-align: center;}.toggle-button { display: inline-flex; background: var(--button-background); color: var(--button-color); border: none; font: inherit; font-size: 1.5rem; padding: 0.5rem 1rem; transition: background 500ms ease-in-out, color 200ms ease;}.toggle-button__icon { background: var(--button-icon); width: 1.2em; height: 1.2em; margin: 0 0 0 0.5em; filter: var(--button-icon-filter); transform: translateY(1px); /* Optical adjustment */ transition: filter 500ms ease-in-out;}.toggle-button:focus { outline: 1px solid var(--button-background); outline-offset: 0.5rem;}

It’s all mostly presentational CSS, but there’s a couple of bits I need to explain:

By default, because the <html> element has a class of no-js, we hide the .user-toggle element, because everything in it requires JavaScript. This means that if a user has no JavaScript available, they’ll still get dark mode if that’s their system preference—they just won’t be able to change it
Because we’re using CSS to render icons, we’re going to use filter to colour them. Check out this handy explainer article for how that works

Now that we’ve added all of the CSS, let’s do the JavaScript bit!

Adding the interaction

We’ve got our minimum viable experience working, so let’s wire up some JavaScript to enhance it and give the user more control.

Add the following to your JavaScript file (or JS panel in CodePen):

document.documentElement.classList.remove('no-js');

We’re removing the no-js class from the <html> element because we have JavaScript available. You’ll have probably noticed that the user toggle control has suddenly appeared.

Let’s set up some constants. Add the following:

const STORAGE_KEY = 'user-color-scheme';const COLOR_MODE_KEY = '--color-mode';const modeToggleButton = document.querySelector('.js-mode-toggle');const modeToggleText = document.querySelector('.js-mode-toggle-text');const modeStatusElement = document.querySelector('.js-mode-status');

The two shouty constants are as follows:

STORAGE_KEY is what we use to store the user’s preference in localStorage
COLOR_MODE_KEY is what we use to extract the current CSS Custom Property value, --color-mode

The rest of this section is us grabbing the relevant HTML elements for later.

Next up, let’s add a function to extract the --color-mode value:

const getCSSCustomProp = propKey => { let response = getComputedStyle(document.documentElement).getPropertyValue(propKey); if (response.length) { response = response.replace(/\"/g, '').trim(); } return response;};

This is a condensed version of the function we use in this tutorial, which is worth reading if you’re interesting in how this function works. The end result in this tutorial is a string of either 'light' or 'dark', depending on the media query situation.

Next, let’s add a function that applies the user preference that’s either set in local storage or passed in:

const applySetting = passedSetting => { let currentSetting = passedSetting || localStorage.getItem(STORAGE_KEY); if (currentSetting) { document.documentElement.setAttribute('data-user-color-scheme', currentSetting); setButtonLabelAndStatus(currentSetting); } else { setButtonLabelAndStatus(getCSSCustomProp(COLOR_MODE_KEY)); }};

This function has one job: it tries to load a setting that’s either passed in or from local storage as a fallback—then, depending wether a setting was loaded or not, the function applies the data-user-color-scheme attribute if necessary. It then updates the button label and the status text with another function, which we’ll add now.

const setButtonLabelAndStatus = currentSetting => { modeToggleText.innerText = `Enable ${currentSetting === 'dark' ? 'light' : 'dark'} mode`; modeStatusElement.innerText = `Color mode is now "${currentSetting}"`;};

As you can see, we set the text depending on what the current colour mode is. Because we’ll have a 'dark' or 'light' value, either from local storage or the CSS property, we can safely set the button to be the inverse, and the status to announce what the colour mode currently is.

Next, let’s add the code that toggles the colour mode:

const toggleSetting = () => { let currentSetting = localStorage.getItem(STORAGE_KEY); switch (currentSetting) { case null: currentSetting = getCSSCustomProp(COLOR_MODE_KEY) === 'dark' ? 'light' : 'dark'; break; case 'light': currentSetting = 'dark'; break; case 'dark': currentSetting = 'light'; break; } localStorage.setItem(STORAGE_KEY, currentSetting); return currentSetting;};

The first thing that this function does is try to load the current setting from local storage. It then runs what it got through a switch. If the setting is found, we invert it. If not, we load from CSS, then invert that instead.

The last thing this function does is return the setting that it calculated.

The last thing we do in this tutorial is add an event to the button, then apply the setting by default, and then we are done!

modeToggleButton.addEventListener('click', evt => { evt.preventDefault(); applySetting(toggleSetting());});applySetting();

In the click handler, we pass the value that was returned by toggleSetting() straight into applySetting(). Job done. We run applySetting() by default to make sure that the user’s preference is applied on page load.

Here’s a demo of the final, working system:

See the Pen PiccalilliIssue#10 — User controlled dark mode by Andy Bell (@andybelldesign) on CodePen.

Wrapping up

This little tutorial gets you going in the right direction, but there’s plenty of work to do to get it up to speed on your website. The most important thing that you need to do is make sure that both your light and dark themes are fully accessible—especially in terms of colour contrast. There are many tools you can use for this. I prefer to use tota11y.

You can also improve this system further. A couple of quick ideas are:

Observe changes to the user’s dark/light mode setting, probably via the prefers-color-scheme media query and update the default state accordingly
Refactor the CSS theming to not repeat itself as much. I personally would roll out some Sass for this situation

DEV Community: Andy Bell

A Modern CSS Reset

A reset of sensible defaults

Breaking it down

Wrapping up

What do you find the most difficult with CSS?

Create a semantic “breakout” button to make an entire element clickable

What we’re making

Getting started with markup

Base CSS styles

Creating the breakout button component

Core component styles

Interactive styles

Improving our breakout button with progressive enhancement

Wrapping up

Bite Sized Basics: Box Sizing

Padding and borders

Wrapping up

Keeping it simple with CSS that scales

Let’s talk about scale

Four key things

Don’t panic

The current state of CSS

Sass for the win!

Communicate

Dev #1 - Lucrecia

Lucrecia to Dev #2, Isabella

Isabella to Lucrecia

Lucrecia

Documentation is everything

Consistency

Cascade

Block

Element

Utility

Token

Simplification

Slow down

Create a user controlled dark or light mode

What we are building

Laying the foundations

Dealing with the prefers-color-scheme media query

Adding the toggle styles

Adding the interaction

Wrapping up

Dealing with the `prefers-color-scheme` media query