SoatDev IT Consulting
SoatDev IT Consulting
  • About us
  • Expertise
  • Services
  • How it works
  • Contact Us
  • News
  • December 2, 2024
  • Rss Fetcher

We’ve been using Cascade Layers in our CSS here at CodePen quite a bit lately. A pretty clear non-complicated use case is that we tend to apply one class to stuff. That includes a “library” component. So imagine the prototypical Button, which would have a .button selector applying styling to it. But this library component also accepts a class so that usage of the component can apply it’s own styles if needed.

Like this:

<button class="library-button usage-class-button">

Since we’re building React components, it expresses like:

<Button className={classNames(styles.root, props.className)}>

So now we’ve got two selectors that are exactly the same in specificity. Which one wins? It will come down to source order. And to be quite honest, I’m not really sure how that will play out in every single scenario the component could be used on CodePen. The styles might be bundled, sometimes by different build processes, and placed into combined CSS files or even sometimes loaded dynamically. That has led to the occasional situation where we artificially increased the specificity of the class selector we’re passing in just so it for sure wins. .myClass.myClass, for instance. That’s dumb.

Instead, we can force our library components to have intentionally less powerful styles via Cascade Layers. So our “root” style can be like:

@layer library {
  .root {

  }
}

Alone, that works. That means the .myClass stuff will always win, as unlayered styles are always stronger than layered styles. But to keep us honest we have setup the order such that we can slot things in in an expected way going forward:

@layer library, root, page, component;

That’s in our global CSS such that we have those levels to poke in at, when we want to use layering but at a specific level of strength.

Layers is a nice enough API that we can also do sub-layering. Meaning rather than just @layer library { } wrapping all library components, we’d actually do something like this for Button:

@layer library.Button {

}

That means it’s still slotted in at the library level, but if we needed to at some point, we could declare the order of components such that one could beat another. We haven’t needed it yet, but it feels like the right move.

I can absolutely see how people can think Cascade Layers are useless. (Manuel Matuzović doesn’t actually think this, but he makes some points with code on how people could.) They didn’t strike me as terrible useful right away as something you could “sprinkle in” to a project until I came across out own use case here. Mostly I thought of it as “put Bootstrap in a layer, unlayer your own styles” as the #1 use case. But now I’m starting to think “keep specifically generally flat, and when they are conflicts use layers instead of increased specificity” as a pretty big use case as well.


Let’s do some bonus CSS links because we can:

  • Andy Bell: How we’re approaching theming with modern CSS. It’s heavy on custom properties and allowing a “theme” over override a limited set of them (in a “flair” layer) to have maximum impact.
  • Andrew Walpole: Opinions for Writing Good CSS. Essentially a list of best practices. I really like the last one: “Don’t. Paste. CSS.”
  • Hristiyan Dodov: CSS Can Get You in Jail. Spoiler, it’s about how browser render counters on nested lists. In a legal document, you just can’t risk potential browser rendering differences, and should hard-code the numbers.
  • Josh Comeau: The Secret Mechanisms of CSS. Just one great quote: “the layout algorithms are kind of like functions and the CSS that we write are the arguments that we pass to those functions”.
  • (Anonymous?) Use CSS’ `only-child` instead of `if/else` logic. Sometimes I feel like if/else logic for views makes more sense at the HTML level than the CSS level. But because they are using Tailwind here, it kinda does put that logic at the HTML level.
  • Adam Argyle: Headless, boneless, skinless & lifeless UI. Like Adam says, these aren’t really terms that anyone is actively using to describe UI frameworks, but maybe we should be, because these are pretty major distinctions that you’d chose for very different reasons.
Previous Post
Next Post

Recent Posts

  • Build, don’t bind: Accel’s Sonali De Rycker on Europe’s AI crossroads
  • OpenAI’s planned data center in Abu Dhabi would be bigger than Monaco
  • Google I/O 2025: What to expect, including updates to Gemini and Android 16
  • Thousands of people have embarked on a virtual road trip via Google Street View
  • How Silicon Valley’s influence in Washington benefits the tech elite

Categories

  • Industry News
  • Programming
  • RSS Fetched Articles
  • Uncategorized

Archives

  • May 2025
  • April 2025
  • February 2025
  • January 2025
  • December 2024
  • November 2024
  • October 2024
  • September 2024
  • August 2024
  • July 2024
  • June 2024
  • May 2024
  • April 2024
  • March 2024
  • February 2024
  • January 2024
  • December 2023
  • November 2023
  • October 2023
  • September 2023
  • August 2023
  • July 2023
  • June 2023
  • May 2023
  • April 2023

Tap into the power of Microservices, MVC Architecture, Cloud, Containers, UML, and Scrum methodologies to bolster your project planning, execution, and application development processes.

Solutions

  • IT Consultation
  • Agile Transformation
  • Software Development
  • DevOps & CI/CD

Regions Covered

  • Montreal
  • New York
  • Paris
  • Mauritius
  • Abidjan
  • Dakar

Subscribe to Newsletter

Join our monthly newsletter subscribers to get the latest news and insights.

© Copyright 2023. All Rights Reserved by Soatdev IT Consulting Inc.