21–30 of 36 posts
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
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 el…
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...
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 el…
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?
Earlier quoted context omitted.
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
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.
Earlier quoted context omitted.
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
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…
Earlier quoted context omitted.
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 el…
> 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?
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.
Earlier quoted context omitted.
shouldn't that be foo.bar?
No, the idea is that .foo.foo increases the specificity of .foo over .bar
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.