Organizing Design System Element Patterns With CSS Cascade Layers

I’m attempting to provide you with methods to make elements extra customizable, extra environment friendly, and simpler to make use of and perceive, and I need to describe a sample I’ve been leaning into utilizing CSS Cascade Layers.

I take pleasure in organizing code and discover cascade layers a implausible technique to arrange code explicitly because the cascade seems to be at it. The neat half is, that as a lot because it helps with “top-level” group, cascade layers may be nested, which permits us to creator extra exact kinds primarily based on the cascade.

The one draw back right here is your creativeness, nothing stops us from over-engineering CSS. And to be clear, it’s possible you’ll very nicely think about what I’m about to point out you as a type of over-engineering. I believe I’ve discovered a steadiness although, conserving issues easy but organized, and I’d wish to share my findings.

The anatomy of a CSS part sample

Let’s discover a sample for writing elements in CSS utilizing a button for instance. Buttons are one of many extra widespread elements present in nearly each part library. There’s good cause for that recognition as a result of buttons can be utilized for quite a lot of use circumstances, together with:

• performing actions, like opening a drawer,
• navigating to totally different sections of the UI, and
• holding some type of state, comparable to focus or hover.

And buttons are available a number of totally different flavors of markup, like <button>, enter[type="button"], and <a category="button">. There are much more methods to make buttons than that, for those who can consider it.

On high of that, totally different buttons carry out totally different capabilities and are sometimes styled accordingly so {that a} button for one kind of motion is distinguished from one other. Buttons additionally reply to state modifications, comparable to when they’re hovered, energetic, and targeted. When you have ever written CSS with the BEM syntax, we will form of suppose alongside these traces throughout the context of cascade layers.

.button {}
.button-primary {}
.button-secondary {}
.button-warning {}
/* and so on. */

Okay, now, let’s write some code. Particularly, let’s create a number of various kinds of buttons. We’ll begin with a .button class that we will set on any aspect that we need to be styled as, nicely, a button! We already know that buttons come in numerous flavors of markup, so a generic .button class is essentially the most reusable and extensible technique to choose one or all of them.

.button {
  /* Types widespread to all buttons */
}

Utilizing a cascade layer

That is the place we will insert our very first cascade layer! Keep in mind, the explanation we would like a cascade layer within the first place is that it permits us to set the CSS Cascade’s studying order when evaluating our kinds. We are able to inform CSS to guage one layer first, adopted by one other layer, then one other — all in keeping with the order we would like. That is an unimaginable characteristic that grants us superpower management over which kinds “win” when utilized by the browser.

We’ll name this layer elements as a result of, nicely, buttons are a sort of part. What I like about this naming is that it’s generic sufficient to assist different elements sooner or later as we resolve to increase our design system. It scales with us whereas sustaining a pleasant separation of considerations with different kinds we write down the street that possibly aren’t particular to elements.

/* Elements top-level layer */
@layer elements {
  .button {
    /* Types widespread to all buttons */
  }
}

Nesting cascade layers

Right here is the place issues get slightly bizarre. Do you know you possibly can nest cascade layers inside courses? That’s completely a factor. So, verify this out, we will introduce a brand new layer contained in the .button class that’s already inside its personal layer. Right here’s what I imply:

/* Elements top-level layer */
@layer elements {

  .button {
    /* Element parts layer */
    @layer parts {
      /* Types */
    }
  }
}

That is how the browser interprets that layer inside a layer on the finish of the day:

@layer elements {
  @layer parts {
    .button {
      /* button kinds... */
    }
  }
}

This isn’t a submit simply on nesting kinds, so I’ll simply say that your mileage could fluctuate while you do it. Try Andy Bell’s latest article about utilizing warning with nested kinds.

Structuring kinds

To this point, we’ve established a .button class within a cascade layer that’s designed to carry any kind of part in our design system. Inside that .button is one other cascade layer, this one for choosing the various kinds of buttons we would encounter within the markup. We talked earlier about buttons being <button>, <enter>, or <a> and that is how we will individually choose fashion every kind.

We are able to use the :is() pseudo-selector operate as that’s akin to saying, “If this .button is an <a> aspect, then apply these kinds.”

/* Elements top-level layer */
@layer elements {
  .button {
    /* Element parts layer */
    @layer parts {
      /* kinds widespread to all buttons */

      &:is(a) {
        /* <a> particular kinds */
      }

      &:is(button) {
        /* <button> particular kinds */
      }

      /* and so on. */
    }
  }
}

Defining default button kinds

I’m going to fill in our code with the widespread kinds that apply to all buttons. These kinds sit on the high of the parts layer in order that they’re utilized to any and all buttons, whatever the markup. Take into account them default button kinds, so to talk.

/* Elements top-level layer */
@layer elements {
  .button {
    /* Element parts layer */
    @layer parts {
      background-color: darkslateblue;
      border: 0;
      coloration: white;
      cursor: pointer;
      show: grid;
      font-size: 1rem;
      font-family: inherit;
      line-height: 1;
      margin: 0;
      padding-block: 0.65rem;
      padding-inline: 1rem;
      place-content: middle;
      width: fit-content;
    }
  }
}

Defining button state kinds

What ought to our default buttons do when they’re hovered, clicked, or in focus? These are the totally different states that the button would possibly take when the consumer interacts with them, and we have to fashion these accordingly.

I’m going to create a brand new cascade sub-layer straight below the parts sub-layer referred to as, creatively, states:

/* Elements top-level layer */
@layer elements {
  .button {
    /* Element parts layer */
    @layer parts {
      /* Types widespread to all buttons */
    }

    /* Element states layer */
    @layer states {
      /* Types for particular button states */
    }
  }
}

Pause and mirror right here. What states ought to we goal? What will we need to change for every of those states?

Some states could share comparable property modifications, comparable to :hover and :focus having the identical background coloration. Fortunately, CSS provides us the instruments we have to sort out such issues, utilizing the :the place() operate to group property modifications primarily based on the state. Why :the place() as a substitute of :is()? :the place() comes with zero specificity, which means it’s rather a lot simpler to override than :is(), which takes the specificity of the aspect with the very best specificity rating in its arguments. Sustaining low specificity is a advantage with regards to writing scalable, maintainable CSS.

/* Element states layer */
@layer states {
  &:the place(:hover, :focus-visible) {
    /* button hover and focus state kinds */
  }
}

However how will we replace the button’s kinds in a significant means? What I imply by that’s how will we make it possible for the button seems to be prefer it’s hovered or in focus? We might simply slap a brand new background coloration on it, however ideally, the colour ought to be associated to the background-color set within the parts layer.

So, let’s refactor issues a bit. Earlier, I set the .button aspect’s background-color to darkslateblue. I need to reuse that coloration, so it behooves us to make that right into a CSS variable so we will replace it as soon as and have it apply all over the place. Counting on variables is yet one more advantage of writing scalable and maintainable CSS.

I’ll create a brand new variable referred to as --button-background-color that’s initially set to darkslateblue after which set it on the default button kinds:

/* Element parts layer */
@layer parts {
  --button-background-color: darkslateblue;

  background-color: var(--button-background-color);
  border: 0;
  coloration: white;
  cursor: pointer;
  show: grid;
  font-size: 1rem;
  font-family: inherit;
  line-height: 1;
  margin: 0;
  padding-block: 0.65rem;
  padding-inline: 1rem;
  place-content: middle;
  width: fit-content;
}

Now that we’ve got a coloration saved in a variable, we will set that very same variable on the button’s hovered and targeted states in our different layer, utilizing the comparatively new color-mix() operate to transform darkslateblue to a lighter coloration when the button is hovered or in focus.

Again to our states layer! We’ll first combine the colour in a brand new CSS variable referred to as --state-background-color:

/* Element states layer */
@layer states {
  &:the place(:hover, :focus-visible) {
    /* customized property solely utilized in state */
    --state-background-color: color-mix(
      in srgb, 
      var(--button-background-color), 
      white 10%
    );
  }
}

We are able to then apply that coloration because the background coloration by updating the background-color property.

/* Element states layer */
@layer states {
  &:the place(:hover, :focus-visible) {
    /* customized property solely utilized in state */
    --state-background-color: color-mix(
      in srgb, 
      var(--button-background-color), 
      white 10%
    );

    /* making use of the state background-color */
    background-color: var(--state-background-color);
  }
}

Defining modified button kinds

Together with parts and states layers, it’s possible you’ll be in search of some form of variation in your elements, comparable to modifiers. That’s as a result of not all buttons are going to seem like your default button. You may want one with a inexperienced background coloration for the consumer to substantiate a choice. Or maybe you desire a pink one to point hazard when clicked. So, we will take our present default button kinds and modify them for these particular use circumstances

If we take into consideration the order of the cascade — at all times flowing from high to backside — we don’t need the modified kinds to have an effect on the kinds within the states layer we simply made. So, let’s add a brand new modifiers layer in between parts and states:

/* Elements top-level layer */
@layer elements {

  .button {
  /* Element parts layer */
  @layer parts {
    /* and so on. */
  }

  /* Element modifiers layer */
  @layer modifiers {
    /* new layer! */
  }

  /* Element states layer */
  @layer states {
    /* and so on. */
  }
}

Much like how we dealt with states, we will now replace the --button-background-color variable for every button modifier. We might modify the kinds additional, in fact, however we’re conserving issues pretty simple to reveal how this method works.

We’ll create a brand new class that modifies the background-color of the default button from darkslateblue to darkgreen. Once more, we will depend on the :is() selector as a result of we would like the added specificity on this case. That means, we override the default button fashion with the modifier class. We’ll name this class .success (inexperienced is a “profitable” coloration) and feed it to :is():

/* Element modifiers layer */
@layer modifiers {
  &:is(.success) {
    --button-background-color: darkgreen;
  }
}

If we add the .success class to certainly one of our buttons, it turns into darkgreen as a substitute darkslateblue which is precisely what we would like. And since we already do some color-mix()-ing within the states layer, we’ll mechanically inherit these hover and focus kinds, which means darkgreen is lightened in these states.

/* Elements top-level layer */
@layer elements {
  .button {
    /* Element parts layer */
    @layer parts {
      --button-background-color: darkslateblue;

      background-color: var(--button-background-color);
      /* and so on. */

    /* Element modifiers layer */
    @layer modifiers {
      &:is(.success) {
        --button-background-color: darkgreen;
      }
    }

    /* Element states layer */
    @layer states {
      &:the place(:hover, :focus) {
        --state-background-color: color-mix(
          in srgb,
          var(--button-background-color),
          white 10%
        );

        background-color: var(--state-background-color);
      }
    }
  }
}

Placing all of it collectively

We are able to refactor any CSS property we have to modify right into a CSS customized property, which supplies us numerous room for personalization.

/* Elements top-level layer */
@layer elements {
  .button {
    /* Element parts layer */
    @layer parts {
      --button-background-color: darkslateblue;

      --button-border-width: 1px;
      --button-border-style: strong;
      --button-border-color: clear;
      --button-border-radius: 0.65rem;

      --button-text-color: white;

      --button-padding-inline: 1rem;
      --button-padding-block: 0.65rem;

      background-color: var(--button-background-color);
      border: 
        var(--button-border-width) 
        var(--button-border-style) 
        var(--button-border-color);
      border-radius: var(--button-border-radius);
      coloration: var(--button-text-color);
      cursor: pointer;
      show: grid;
      font-size: 1rem;
      font-family: inherit;
      line-height: 1;
      margin: 0;
      padding-block: var(--button-padding-block);
      padding-inline: var(--button-padding-inline);
      place-content: middle;
      width: fit-content;
    }

    /* Element modifiers layer */
    @layer modifiers {
      &:is(.success) {
        --button-background-color: darkgreen;
      }

      &:is(.ghost) {
        --button-background-color: clear;
        --button-text-color: black;
        --button-border-color: darkslategray;
        --button-border-width: 3px;
      }
    }

    /* Element states layer */
    @layer states {
      &:the place(:hover, :focus) {
        --state-background-color: color-mix(
          in srgb,
          var(--button-background-color),
          white 10%
        );

        background-color: var(--state-background-color);
      }
    }
  }
}

P.S. Look nearer at that demo and take a look at how I’m adjusting the button’s background utilizing light-dark() — then go learn Sara Pleasure’s “Come to the light-dark() Facet” for an intensive rundown of how that works!

---

What do you suppose? Is that this one thing you’d use to arrange your kinds? I can see how making a system of cascade layers could possibly be overkill for a small challenge with few elements. However even slightly toe-dipping into issues like we simply did illustrates how a lot energy we’ve got with regards to managing — and even taming — the CSS Cascade. Buttons are deceptively advanced however we noticed how few kinds it takes to deal with every little thing from the default kinds to writing the kinds for his or her states and modified variations.

---

Organizing Design System Element Patterns With CSS Cascade Layers initially revealed on CSS-Methods, which is a part of the DigitalOcean household. It’s best to get the e-newsletter.