The CSS Cascade (2020)(wattenberger.com)
wattenberger.com
The CSS Cascade (2020)
https://wattenberger.com/blog/css-cascade
35 comments
having hard time to think of any default browser rules that use !important, any ideas?
Fullscreen iframes definitely don’t have a border in Firefox, among others.
https://searchfox.org/mozilla-central/source/layout/style/re...
https://searchfox.org/mozilla-central/source/layout/style/re...
[deleted]
Huh, I always thought the cascade referred to the fact that certain properties apply to child elements (like font size) and others don't (like borders). There are cascading and non-cascading properties. What is described here I would call the specifity (which is actually only one part of it).
The funny thing is that I even implemented a CSS parser and evaluator without knowing the official terms.
The funny thing is that I even implemented a CSS parser and evaluator without knowing the official terms.
I had the same thought. Property inheritance could be a more specific description though?
https://every-layout.dev remains, hands-down, the best resource on CSS I've ever encountered since I started working in webdev 24 years ago.
See also this recent post by Josh Comeau, which does a good job explaining layout modes: https://www.joshwcomeau.com/css/understanding-layout-algorit...
See also this recent post by Josh Comeau, which does a good job explaining layout modes: https://www.joshwcomeau.com/css/understanding-layout-algorit...
I second https://every-layout.dev. I was amazed to find out how straightforward the CSS is to accomplish the common layouts we see across the web. CSS is always a tricky one for me but every time I learn about modern CSS I get excited about how you can accomplish more and more while writing less and less CSS/
Article a reminder of why CSS is so difficult to work with.
Turns out I knew all these precedence rules, however when time comes to look at an element and figure out how to make it, say, wider, figuring out WHERE to add that rule is a challenge.
I find her website to be difficult to skim and overview, something which is essential for technical reading, because more often than not you will want to return to a document you have previously read to remind yourself of a detail that you remember there, somewhere.
It's probably not only related to the wacky sidebar, but more related to the main content style, headlines being too large and an overuse of colors and emphasis in each section of text. Choosing to alternate dark and light scheme in the A/B code blocks doesn't seem right either.
Which in a way is neither here nor there, since it's not related to her content. Personally I find the "Funky fact alert! The hierarchy here is actually reversed for..." style of writing to be offputting, but I'm sure some others like it.
It's probably not only related to the wacky sidebar, but more related to the main content style, headlines being too large and an overuse of colors and emphasis in each section of text. Choosing to alternate dark and light scheme in the A/B code blocks doesn't seem right either.
Which in a way is neither here nor there, since it's not related to her content. Personally I find the "Funky fact alert! The hierarchy here is actually reversed for..." style of writing to be offputting, but I'm sure some others like it.
I do and I enjoyed her other articles as well, partly because of how it is worded and designed.
I'm all for utility but in this instance that sidebar really makes me appreciate the care and effort that went into it.
Can anyone explain how deep use of the CSS cascade is any different to OOP inheritance over composition? This is usually discouraged in OOP languages now because it quickly gets confusing and hard to maintain.
Multiple inheritance is also usually discouraged for similar reasons, but not in CSS in the way you can combine classes together without restriction (with `!important` and specificity on top of this).
And is CSS cascading actually a good approach that scales to complex UIs and designs? Is this approach successful anywhere else or is there a way to do styling that's closer to regular programming? CSS seems to be in its own world with lots of debates about best practices.
Multiple inheritance is also usually discouraged for similar reasons, but not in CSS in the way you can combine classes together without restriction (with `!important` and specificity on top of this).
And is CSS cascading actually a good approach that scales to complex UIs and designs? Is this approach successful anywhere else or is there a way to do styling that's closer to regular programming? CSS seems to be in its own world with lots of debates about best practices.
The CSS cascade, leveraged properly, is perfectly compatible with the principle of favoring composition over inheritance. See https://every-layout.dev/rudiments/composition/
A good approach that scales will use the cascade instead of fighting it. That means global rules and carefully-applied exceptions, with rules' specificity inversely proportional to their reach:
> Sensible CSS architecture has “reach” (how many elements are affected) inversely proportional to specificity (how complex the selectors are). This was formalized by Harry Roberts as ITCSS, with IT standing for Inverted Triangle. ^ https://every-layout.dev/rudiments/global-and-local-styling/
A good approach that scales will use the cascade instead of fighting it. That means global rules and carefully-applied exceptions, with rules' specificity inversely proportional to their reach:
> Sensible CSS architecture has “reach” (how many elements are affected) inversely proportional to specificity (how complex the selectors are). This was formalized by Harry Roberts as ITCSS, with IT standing for Inverted Triangle. ^ https://every-layout.dev/rudiments/global-and-local-styling/
[deleted]
> is perfectly compatible with the principle of favoring composition over inheritance
I understand you can use composition over inheritance (like in say Java) but by only using the cascade in limited ways (e.g. global styles), doesn't this demonstrate that the cascade doesn't scale and should generally be avoided?
I understand you can use composition over inheritance (like in say Java) but by only using the cascade in limited ways (e.g. global styles), doesn't this demonstrate that the cascade doesn't scale and should generally be avoided?
I guess it depends on your definitions for "limited", "global styles", or "scale". :)
https://every-layout.dev prescribes use of a robust global .css stylesheet with global and element selectors, paired with a brilliant and flexible typography-based scale, custom properties (think "design tokens"), and dedicated layout primitives, that combine to do nearly all the styling work a site could need. There's a place for utility classes as needed. By embracing the cascade and leveraging it properly -- ie, its exception-based paradigm -- it hugely reduces the amount of CSS you need to write (which is otherwise so typically bloated, radically over-specified, and brittle). It's hard to overstate how profoundly different and better our use of CSS can be, when it's based on the axioms so beautifully illustrated by https://every-layout.dev.
FTR I'm not affiliated in any way, just a huge fan of their imho singular work.
https://every-layout.dev prescribes use of a robust global .css stylesheet with global and element selectors, paired with a brilliant and flexible typography-based scale, custom properties (think "design tokens"), and dedicated layout primitives, that combine to do nearly all the styling work a site could need. There's a place for utility classes as needed. By embracing the cascade and leveraging it properly -- ie, its exception-based paradigm -- it hugely reduces the amount of CSS you need to write (which is otherwise so typically bloated, radically over-specified, and brittle). It's hard to overstate how profoundly different and better our use of CSS can be, when it's based on the axioms so beautifully illustrated by https://every-layout.dev.
FTR I'm not affiliated in any way, just a huge fan of their imho singular work.
If only there was a way to generate a minimal cascade from a given set of styles. Sort of automatically detect properties that can be moved to a common parent.
One would necessarily have to generate the HTML, too, otherwise there are no guarantees, and even then the CSS—browser interplay might lead to broken styles.
One would necessarily have to generate the HTML, too, otherwise there are no guarantees, and even then the CSS—browser interplay might lead to broken styles.
Remix^1 has an interesting approach here; they encourage use of traditional CSS (vs CSS-in-JS), but the styles for a given route are scoped to the component.
1. https://remix.run/docs/en/v1/guides/styling
1. https://remix.run/docs/en/v1/guides/styling
That’s a good fit when each route needs a lot of custom styles and each one is developed by a separate team.
However, it doesn’t really fit well if a brand-themed app is developed by a single team. Consistency is easier to maintain when styles can be reused across the application, and things like styled-components don’t work that well there since they tightly couple components to styles, so you need a theming system on top of them… which is silly, because CSS itself is a theming system.
CSS modules is a bit better, but even that encourages encapsulation which is necessarily broken if the styles need to be shared between components.
However, it doesn’t really fit well if a brand-themed app is developed by a single team. Consistency is easier to maintain when styles can be reused across the application, and things like styled-components don’t work that well there since they tightly couple components to styles, so you need a theming system on top of them… which is silly, because CSS itself is a theming system.
CSS modules is a bit better, but even that encourages encapsulation which is necessarily broken if the styles need to be shared between components.
You seem to have misunderstood; Remix promotes the use of bog-standard CSS. Literally nothing about it in any way inhibits reuse of styles across the app.
Not sure where you're going in critiquing styled-components.
Well, does it keep the styles with the components, or does it expect devs to create a separate folder for shared styles? If there are lots of shared styles, that equates to having two sets of components: one React, the other CSS.
It is the same in CSS as in OOP.
Inheritance is good and nice but...
You should not build 20 layers of it. You can build really nice CSS layout where components are separated and that is idea of component frameworks. There you have maybe 2 layers of cascade and that is it.
So it is people building castles in the sand thinking they are smart, until water comes in and all is washed away.
Inheritance is good and nice but...
You should not build 20 layers of it. You can build really nice CSS layout where components are separated and that is idea of component frameworks. There you have maybe 2 layers of cascade and that is it.
So it is people building castles in the sand thinking they are smart, until water comes in and all is washed away.
> When we add !important to the end of our declaration, it jumps to this level of the Cascade. Ideally, you reserve this level for Hail Marys, which are needed to override styles from third-party libraries
Or when you write Stylus[0] themes to create custom skins for your favorite sites. Sometimes the Stylus theme doesn't honor what you've coded, and you have to manually over-ride with an !important
[0] https://addons.mozilla.org/en-US/firefox/addon/styl-us/
Or when you write Stylus[0] themes to create custom skins for your favorite sites. Sometimes the Stylus theme doesn't honor what you've coded, and you have to manually over-ride with an !important
[0] https://addons.mozilla.org/en-US/firefox/addon/styl-us/
Which rules wins is the rule that is the most specific. This article explains it as having 'the most hits'. Whatever that means.
Not just most specific, though. IDs are weighted higher than classes, so if there's a tie between 2 rules, an ID wins over a class, even if it comes first. If 2 classes (or things weighted the same as classes) tie, the later rule wins.
https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
Class specificity can be artificially increased to work around this.
.foo.foo { color: blue; }
.bar { color: red; }
<div class=”foo bar”>
I’m blue
</div>shouldn't that be foo.bar?
No, the idea is that .foo.foo increases the specificity of .foo over .bar
Ok, and checking it I can see that foo.foo.foo increases specificity yet again and so on infinitum I suppose.
I suppose this behavior is specified somewhere and you've read that part of the spec thus explaining how you know it, however as the class declaration is not 'foo foo bar' I think if I were to read it I would conclude that I disagreed with whatever logic was given.
In fact this really seems to take away part of the argument for important, why not just make your rule be foo.foo.foo.foo.foo.foo when you really want to override something. Add enough foos you're sure to win out.
on edit: why I would find foo.foo acceptable if the class declaration was 'foo foo bar' is because, while I find 'foo foo bar' silly I can see why someone would specify what happens when it occurs. I would also have accepted if the spec said 'foo foo bar' is reduced down to 'foo bar' and foo.foo does not make any sense. I guess I find foo.foo not making sense as being my preferred behavior.
I suppose this behavior is specified somewhere and you've read that part of the spec thus explaining how you know it, however as the class declaration is not 'foo foo bar' I think if I were to read it I would conclude that I disagreed with whatever logic was given.
In fact this really seems to take away part of the argument for important, why not just make your rule be foo.foo.foo.foo.foo.foo when you really want to override something. Add enough foos you're sure to win out.
on edit: why I would find foo.foo acceptable if the class declaration was 'foo foo bar' is because, while I find 'foo foo bar' silly I can see why someone would specify what happens when it occurs. I would also have accepted if the spec said 'foo foo bar' is reduced down to 'foo bar' and foo.foo does not make any sense. I guess I find foo.foo not making sense as being my preferred behavior.
Here’s the thing: while the doubled-class ”.foo.foo” trick increases specifity over a single class, it doesn’t completely override selector specificity like !important does: you can still override anything set by ”.foo.foo” with a more specific selector like ”div.foo” or even ”.quux .foo” without having to use the duplicate classname everywhere.
sure, but foo.foo.foo overrides foo.foo or foo.bar etc. It seems sort of ridiculous.
It’s not meant to be used that way. Think more like this:
Theme and color theme set layout and colors
We could use !important, but that’s just asking for trouble.
However, .foo.foo saves the day:
Theme and color theme set layout and colors
.theme—-national
.color-theme—-green
article.content-theme—-education
We could use !important, but that’s just asking for trouble.
However, .foo.foo saves the day:
.color-theme—-a11y.color-theme—-a11y article
.theme—-national.color-theme—-green article.content-theme—-educationI have to also say with the introduction of variables this starts to look crazy
:root { --main-color: brown; } .foo.bar { --main-color: red; } .foo.foo { --main-color: blue; } .bar { --main-color: red; color: var(--main-color); }
anyone actually use this foo.foo method of increasing specificity? Because I think difficult to debug.
:root { --main-color: brown; } .foo.bar { --main-color: red; } .foo.foo { --main-color: blue; } .bar { --main-color: red; color: var(--main-color); }
anyone actually use this foo.foo method of increasing specificity? Because I think difficult to debug.
It is useful when writing multi-theme, multi-color-palette design systems, for example to override colors in a specific component on a specific part of the site but only in a specific theme.
Bad way of framing this, the navigation and phrasing makes it sound like we're going from least to most specific as we scroll down the page but we're not.
> The hierarchy here is actually reversed for !important rules, meaning that an !important browser default rule wins over an !important website rule
I think this would be difficult for a beginner or even intermediate to understand. This chart does a much clearer jobs including every layer of specificity (including with @layer): https://webkit.org/wp-content/uploads/cascade-layers-2048x11...
I appreciate going for an approachable fun way to deliver a dry, complicated topic. Maybe look at how MDN writes about this stuff and get some of the specifics/technicals nailed down a little more.
https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_...