Live data from Hacker News

The CSS Cascade (2020)

wattenberger.com

11–20 of 36 posts

Re: The CSS Cascade (2020)

#11

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

Class specificity can be artificially increased to work around this.

    .foo.foo { color: blue; }
    .bar { color: red; }

    
      I’m blue
    

Re: The CSS Cascade (2020)

#12

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 e…

I'm all for utility but in this instance that sidebar really makes me appreciate the care and effort that went into it.

Re: The CSS Cascade (2020)

#13
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.

Re: The CSS Cascade (2020)

#14

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 CS…

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.

Re: The CSS Cascade (2020)

#15

> Let’s take a look at the different tiers of the Cascade 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 int…

having hard time to think of any default browser rules that use !important, any ideas?

Re: The CSS Cascade (2020)

#16
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...

Re: The CSS Cascade (2020)

#17

> Let’s take a look at the different tiers of the Cascade 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 int…

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...

Re: The CSS Cascade (2020)

#18

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 CS…

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/

Re: The CSS Cascade (2020)

#19

Earlier quoted context omitted.

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

Class specificity can be artificially increased to work around this. .foo.foo { color: blue; } .bar { color: red; } I’m blue

shouldn't that be foo.bar?

Re: The CSS Cascade (2020)

#20

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 CS…

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.

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

Post reply on HN