A little thing happened on the way to publishing the CSS :has() selector to the ol’ Almanac. I had originally described :has() as a “forgiving” selector, the idea being that anything in its argument is evaluated, even if one or more of the items is invalid.
/* Example: Do not use! */
article:has(h2, ul, ::-scoobydoo) { }
See ::scoobydoo in there? That’s totally invalid. A forgiving selector list ignores that bogus selector and proceeds to evaluate the rest of the items as if it were written like this:
So, our previous example? The entire selector list is invalid because the bogus selector is invalid. But the other two forgiving selectors, :is() and :where(), are left unchanged.
There’s a bit of a workaround for this. Remember, :is() and :where()are forgiving, even if :has() is not. That means we can nest either of the those selectors in :has() to get more forgiving behavior:
article:has(:where(h2, ul, ::-scoobydoo)) { }
Which one you use might matter because the specificity of :is() is determined by the most specific item in its list. So, if you need to something less specific you’d do better reaching for :where() since it does not add to the specificity score.
We updated a few of our posts to reflect the latest info. I’m seeing plenty of others in the wild that need to be updated, so just a little PSA for anyone who needs to do the same.
BEM. Like seemingly all techniques in the world of front-end development, writing CSS in a BEM format can be polarizing. But it is – at least in my Twitter bubble – one of the better-liked CSS methodologies.
Personally, I think BEM is good, and I think you should use it. But I also get why you might not.
Regardless of your opinion on BEM, it offers several benefits, the biggest being that it helps avoid specificity clashes in the CSS Cascade. That’s because, if used properly, any selectors written in a BEM format should have the same specificity score (0,1,0). I’ve architected the CSS for plenty of large-scale websites over the years (think government, universities, and banks), and it’s on these larger projects where I’ve found that BEM really shines. Writing CSS is much more fun when you have confidence that the styles you’re writing or editing aren’t affecting some other part of the site.
There are actually exceptions where it is deemed totally acceptable to add specificity. For instance: the :hover and :focus pseudo classes. Those have a specificity score of 0,2,0. Another is pseudo elements — like ::before and ::after — which have a specificity score of 0,1,1. For the rest of this article though, let’s assume we don’t want any other specificity creep. 🤓
But I’m not really here to sell you on BEM. Instead, I want to talk about how we can use it alongside modern CSS selectors — think :is(), :has(), :where(), etc. — to gain even more control of the Cascade.
What’s this about modern CSS selectors?
The CSS Selectors Level 4 spec gives us some powerful new(ish) ways to select elements. Some of my favorites include :is(), :where(), and :not(), each of which is supported by all modern browsers and is safe to use on almost any project nowadays.
:is() and :where() are basically the same thing except for how they impact specificity. Specifically, :where() always has a specificity score of 0,0,0. Yep, even :where(button#widget.some-class) has no specificity. Meanwhile, the specificity of :is() is the element in its argument list with the highest specificity. So, already we have a Cascade-wrangling distinction between two modern selectors that we can work with.
The incredibly powerful :has() relational pseudo-class is also rapidly gaining browser support (and is the biggest new feature of CSS since Grid, in my humble opinion). However, at time of writing, browser support for :has() isn’t quite good enough for use in production just yet.
Lemme stick one of those pseudo-classes in my BEM and…
/* ❌ specificity score: 0,2,0 */
.something:not(.something--special) {
/* styles for all somethings, except for the special somethings */
}
Whoops! See that specificity score? Remember, with BEM we ideally want our selectors to all have a specificity score of 0,1,0. Why is 0,2,0 bad? Consider this same example, expanded:
Even though the second selector is last in the source order, the first selector’s higher specificity (0,2,0) wins, and the color of .something--special elements will be set to red. That is, assuming your BEM is written properly and the selected element has both the .something base class and .something--special modifier class applied to it in the HTML.
Used carelessly, these pseudo-classes can impact the Cascade in unexpected ways. And it’s these sorts of inconsistencies that can create headaches down the line, especially on larger and more complex codebases.
Dang. So now what?
Remember what I was saying about :where() and the fact that its specificity is zero? We can use that to our advantage:
The first part of this selector (.something) gets its usual specificity score of 0,1,0. But :where() — and everything inside it — has a specificity of 0, which does not increase the specificity of the selector any further.
:where() allows us to nest
Folks who don’t care as much as me about specificity (and that’s probably a lot of people, to be fair) have had it pretty good when it comes to nesting. With some carefree keyboard strokes, we may wind up with CSS like this (note that I’m using Sass for brevity):
In this example, we have a .card component. When it’s a “featured” card (using the .card--featured class), the card’s title and image needs to be styled differently. But, as we now know, the code above results in a specificity score that is inconsistent with the rest of our system.
A die-hard specificity nerd might have done this instead:
That’s not so bad, right? Frankly, this is beautiful CSS.
There is a downside in the HTML though. Seasoned BEM authors are probably painfully aware of the clunky template logic that’s required to conditionally apply modifier classes to multiple elements. In this example, the HTML template needs to conditionally add the --featured modifier class to three elements (.card, .card__title, and .card__img) though probably even more in a real-world example. That’s a lot of if statements.
The :where() selector can help us write a lot less template logic — and fewer BEM classes to boot — without adding to the level of specificity.
Whether or not you should opt for this approach over applying modifier classes to the various child elements is a matter of personal preference. But at least :where() gives us the choice now!
What about non-BEM HTML?
We don’t live in a perfect world. Sometimes you need to deal with HTML that is outside of your control. For instance, a third-party script that injects HTML that you need to style. That markup often isn’t written with BEM class names. In some cases those styles don’t use classes at all but IDs!
Once again, :where() has our back. This solution is slightly hacky, as we need to reference the class of an element somewhere further up the DOM tree that we know exists.
Referencing a parent element feels a little risky and restrictive though. What if that parent class changes or isn’t there for some reason? A better (but perhaps equally hacky) solution would be to use :is() instead. Remember, the specificity of :is() is equal to the most specific selector in its selector list.
So, instead of referencing a class we know (or hope!) exists with :where(), as in the above example, we could reference a made up class and the <body> tag.
The ever-present body will help us select our #widget element, and the presence of the .dummy-class class inside the same :is() gives the body selector the same specificity score as a class (0,1,0)… and the use of :where() ensures the selector doesn’t get any more specific than that.
That’s it!
That’s how we can leverage the modern specificity-managing features of the :is() and :where() pseudo-classes alongside the specificity collision prevention that we get when writing CSS in a BEM format. And in the not too distant future, once :has() gains Firefox support (it’s currently supported behind a flag at the time of writing) we’ll likely want to pair it with :where() to undo its specificity.
Whether you go all-in on BEM naming or not, I hope we can agree that having consistency in selector specificity is a good thing!
If you’re disciplined and make use of the inheritance that the CSS cascade provides, you’ll end up writing less CSS. But because our styles often comes from all kinds of sources — and can be a pain to structure and maintain—the cascade can be a source of frustration, and the reason we end up with more CSS than necessary.
Some years ago, Harry Roberts came up with ITCSS and it’s a clever way of structuring CSS.
Mixed with BEM, ITCSS has become a popular way that people write and organize CSS.
However, even with ITCSS and BEM, there are still times where we still struggle with the cascade. For example, I’m sure you’ve had to @import external CSS components at a specific location to prevent breaking things, or reach for the dreaded !important at some point in time.
Recently, some new tools were added to our CSS toolbox, and they allow us to finally control the cascade. Let’s look at them.
O cascade, :where art thou?
Using the :where pseudo-selector allows us to remove specificity to “just after the user-agent default styles,” no matter where or when the CSS is loaded into the document. That means the specificity of the whole thing is literally zero — totally wiped out. This is handy for generic components, which we’ll look into in a moment.
First, imagine some generic <table> styles, using :where:
:where(table) {
background-color: tan;
}
Now, if you add some other table styles before the :where selector, like this:
…the table background becomes hotpink, even though the table selector is specified before the :where selector in the cascade. That’s the beauty of :where, and why it’s already being used for CSS resets.
:where has a sibling, which has almost the exact opposite effect: the :is selector.
The specificity of the :is() pseudo-class is replaced by the specificity of its most specific argument. Thus, a selector written with :is() does not necessarily have equivalent specificity to the equivalent selector written without :is(). Selectors Level 4 specification
The <table class="c-tbl"> background color will be tan because the specificity of :is is less specific than table.
However, if we were to change it to this:
:is(table, .c-tbl) {
--tbl-bgc: orange;
}
…the background color will be orange, since :is has the weight of it’s heaviest selector, which is .c-tbl.
Example: A configurable table component
Now, let’s see how we can use :where in our components. We’ll be building a table component, starting with the HTML:
Let’s wrap .c-tbl in a :where-selector and, just for fun, add rounded corners to the table. That means we need border-collapse: separate, as we can’t use border-radius on table cells when the table is using border-collapse: collapse:
And, because of our rounded corners and the missing border-collapse: collapse, we need to add some extra styles, specifically for the table borders and a hover state on the cells:
Now we can create variations of our table component by injecting other styles before or after our generic styles (courtesy of the specificity-stripping powers of :where), either by overwriting the .c-tbl element or by adding a BEM-style modifier-class (e.g. c-tbl--purple):
Cool! But notice how we keep repeating colors? And what if we want to change the border-radius or the border-width? That would end up with a lot of repeated CSS.
Let’s move all of these to CSS custom properties and, while we’re at it, we can move all configurable properties to the top of the component’s “scope“ — which is the table element itself — so we can easily play around with them later.
CSS Custom Properties
I’m going to switch things up in the HTML and use a data-component attribute on the table element that can be targeted for styling.
<table data-component="table" id="table">
That data-component will hold the generic styles that we can use on any instance of the component, i.e. the styles the table needs no matter what color variation we apply. The styles for a specific table component instance will be contained in a regular class, using custom properties from the generic component.
[data-component="table"] {
/* Styles needed for all table variations */
}
.c-tbl--purple {
/* Styles for the purple variation */
}
If we place all the generic styles in a data-attribute, we can use whatever naming convention we want. This way, we don’t have to worry if your boss insists on naming the table’s classes something like .BIGCORP__TABLE, .table-component or something else.
In the generic component, each CSS property points to a custom property. Properties, that have to work on child-elements, like border-color, are specified at the root of the generic component:
:where([data-component="table"]) {
/* These will will be used multiple times, and in other selectors */
--tbl-hue: 200;
--tbl-sat: 50%;
--tbl-bdc: hsl(var(--tbl-hue), var(--tbl-sat), 80%);
}
/* Here, it's used on a child-node: */
:where([data-component="table"] td) {
border-color: var(--tbl-bdc);
}
For other properties, decide whether it should have a static value, or be configurable with its own custom property. If you’re using custom properties, remember to define a default value that the table can fall back to in the event that a variation class is missing.
:where([data-component="table"]) {
/* These are optional, with fallbacks */
background-color: var(--tbl-bgc, transparent);
border-collapse: var(--tbl-bdcl, separate);
}
If you’re wondering how I’m naming the custom properties, I’m using a component-prefix (e.g. --tbl) followed by an Emmett-abbreviation (e.g. -bgc). In this case, --tbl is the component-prefix, -bgc is the background color, and -bdcl is the border collapse. So, for example, --tbl-bgc is the table component’s background color. I only use this naming convention when working with component properties, as opposed to global properties which I tend to keep more general.
Now, if we open up DevTools, we can play around with the custom properties. For example, We can change --tbl-hue to a different hue value in the HSL color, set --tbl-bdrs: 0 to remove border-radius, and so on.
When working with your own components, this is the point in time you’ll discover which parameters (i.e. the custom property values) the component needs to make things look just right.
We can also use custom properties to control column alignment and width:
:where[data-component="table"] tr > *:nth-of-type(1)) {
text-align: var(--ca1, initial);
width: var(--cw1, initial);
/* repeat for column 2 and 3, or use a SCSS-loop ... */
}
In DevTools, select the table and add these to the element.styles selector:
element.style {
--ca2: center; /* Align second column center */
--ca3: right; /* Align third column right */
}
Now, let’s create our specific component styles, using a regular class, .c-tbl (which stands for “component-table” in BEM parlance). Let’s toss that class in the table markup.
Now, let’s change the --tbl-hue value in the CSS just to see how this works before we start messing around with all of the property values:
.c-tbl {
--tbl-hue: 330;
}
Notice, that we only need to update properties rather than writing entirely new CSS! Changing one little property updates the table’s color — no new classes or overriding properties lower in the cascade.
Notice how the border colors change as well. That’s because all the colors in the table inherit from the --tbl-hue variable
We can write a more complex selector, but still update a single property, to get something like zebra-striping:
And remember: It doesn’t matter where you load the class. Because our generic styles are using :where, the specificity is wiped out, and any custom styles for a specific variation will be applied no matter where they are used. That’s the beauty of using :where to take control of the cascade!
And best of all, we can create all kinds of table components from the generic styles with a few lines of CSS.
Purple table with zebra-striped columnsLight table with a “noinlineborder” parameter… which we’ll cover next
Adding parameters with another data-attribute
So far, so good! The generic table component is very simple. But what if it requires something more akin to real parameters? Perhaps for things like:
zebra-striped rows and columns
a sticky header and sticky column
hover-state options, such as hover row, hover cell, hover column
We could simply add BEM-style modifier classes, but we can actually accomplish it more efficiently by adding another data-attribute to the mix. Perhaps a data-param that holds the parameters like this:
I know my data-attribute way of styling and configuring generic components is very opinionated. That’s just how I roll, so please feel free to stick with whatever method you’re most comfortable working with, whether it’s a BEM modifier class or something else.
The bottom line is this: embrace :where and :is and the cascade-controlling powers they provide. And, if possible, construct the CSS in such a way that you wind up writing as little new CSS as possible when creating new component variations!
Cascade Layers
The last cascade-busting tool I want to look at is “Cascade Layers.” At the time of this writing, it’s an experimental feature defined in the CSS Cascading and Inheritance Level 5 specification that you can access in Safari or Chrome by enabling the #enable-cascade-layers flag.
The true power of Cascade Layers comes from its unique position in the Cascade: before Selector Specificity and Order Of Appearance. Because of that we don’t need to worry about the Selector Specificity of the CSS that is used in other Layers, nor about the order in which we load CSS into these Layers — something that will come in very handy for larger teams or when loading in third-party CSS.
Perhaps even nicer is his illustration showing where Cascade Layers fall in the cascade:
Credit: Bramus Van Damme
At the beginning of this article, I mentioned ITCSS — a way of taming the cascade by specifying the load-order of generic styles, components etc. Cascade Layers allow us to inject a stylesheet at a given location. So a simplified version of this structure in Cascade Layers looks like this:
@layer generic, components;
With this single line, we’ve decided the order of our layers. First come the generic styles, followed by the component-specific ones.
Let’s pretend that we’re loading our generic styles somewhere much later than our component styles:
@layer components {
body {
background-color: lightseagreen;
}
}
/* MUCH, much later... */
@layer generic {
body {
background-color: tomato;
}
}
The background-color will be lightseagreen because our component styles layer is set after the generic styles layer. So, the styles in the components layer “win” even if they are written before the generic layer styles.
Again, just another tool for controlling how the CSS cascade applies styles, allowing us more flexibility to organize things logically rather than wrestling with specificity.
Now you’re in control!
The whole point here is that the CSS cascade is becoming a lot easier to wrangle, thanks to new features. We saw how the :where and :is pseudo-selectors allows us to control specificity, either by stripping out the specificity of an entire ruleset or taking on the specificity of the most specific argument, respectively. Then we used CSS Custom Properties to override styles without writing a new class to override another. From there, we took a slight detour down data-attribute lane to help us add more flexibility to create component variations merely by adding arguments to the HTML. And, finally, we poked at Cascade Layers which should prove handy for specifying the loading order or styles using @layer.
If you leave with only one takeaway from this article, I hope it’s that the CSS cascade is no longer the enemy it’s often made to be. We are gaining the tools to stop fighting it and start leaning into even more.
I don’t know about you, but I write these three declarations many times in my CSS:
ul {
padding: 0;
margin: 0;
list-style-type: none;
}
You might yell at me and say I can just put those in my CSS resets. I wish I could, but I don‘t want to and I’ll tell you why in a second.
User agents set values to those properties in a list for a purpose, and that is to make lists more readable. These are the default styles in chromium browsers for a <ul> element:
So, without adding any class in HTML or style in CSS, we get those for free. That‘s a nice thing and I don‘t want to lose it. But I would appreciate it if I could make the browser understand that there is very high chance I don’t want that default feature in cases where I add a class to the element.
So here is a quick solution to reset a <ul> element that has a class:
If you are OK adding more weight to the selector, you are good to go. But I’m not OK with it, personally. For example, I don’t want to put the element’s name in my CSS most of the times due to a separation of concerns principle. Or, if you are following BEM methodology, problems will most certainly arise as this conflicts with it.
So what can we do?
The solution
A few months ago, I learned about some hot selectors, including :is() and :where(). One thing about these two functional pseudo selectors, is that they can change specificity, giving us the power to nullify or increase that specificity.
The key about :where() is that it always has 0 specificity. So we can get rid of our problem very easily like this:
:where(ul[class]) {
list-style: none;
}
.list {
list-style: square; /* Now this works like a charm! */
}
With the power of this selector, libraries can give us style with no specificity. So there would be no specificity to compete with when we as authors write CSS.
Demo
In the following demo, you can remove :where() to see what we talked about in action:
Šime Vidas with the lowdown on what these pseudo-selectors are and why they will be useful:
:is() is to reduce repetition¹ of parts of comma-separated selectors.
:where() is the same, but nothing inside it affects specificity. The example of wrapping :where(:not()) is really great, as now there is a way to use :not() without bumping up the selector weight in a way you very likely don’t want.
This is something that CSS preprocessors are good at (via nesting). Another nice little example of community-built tech pushing forward and native tech coming up later to help once the idea is fleshed out.
