8 ms·

Nobody calls it this, but cascading styles in CSS is just like inheritance and I think should be avoided for all the same reasons. I feel it's a big part of why

Nobody calls it this, but cascading styles in CSS is just like inheritance and I think should be avoided for all the same reasons. I feel it's a big part of why CSS at scale becomes unmaintainable. There isn't even a built-in way to compose two classes together if you want to avoid cascading/inheritance. It looks like composition over inheritance has caught on as the better default in other languages, but in the CSS world people still cling to the cascade as a best practice for some reason.

ethanbond 3y ago
Obligatory: Tailwind
- seanwilson 3y ago
  I tried to avoid mentioning that, but Tailwind is showcasing how to write CSS using composition from inheritance. But it can't overcome the knee-jerk reaction from many CSS developers that don't see the problems that comes with CSS cascade/inheritance. I think this is mostly because leaning on cascading rules is seen as a best practice and most aren't going to question best practices much.
  - Fauntleroy 3y ago
    Tailwind is not a panacea—it has its own problems which withhold adoption, "kneejerk reactions" notwithstanding.
  - danielvaughn 3y ago
    I'll never understand why a lot of CSS devs are opposed to it. I can understand the initial gut reaction, but I've been writing CSS for 14 years and I love Tailwind. The cascade is a wonderful idea that has unfortunately not played out well in practice. Anyone who thinks it's just a skill issue is deluding themselves. In all my years, I've never seen CSS that (a) leverages the cascade, and (b) scales elegantly. It all breaks down past a certain point. Tailwind has it's flaws, but it doesn't have the scaling problem.
    - explaininjs 3y ago
      Mainly because nobody is a "CSS Dev". If someone's entire job was developing CSS, you might expect that they would be willing to learn one new slightly different way of doing it. But in reality the pushback comes from full stack developers who already have a million other things to worry about, such that relearning all the basic CSS they already know, to achieve benefits that are rather minuscule in the grand scheme of things, is a low priority. I personally am working on a Tailwind product that is fairly small (~10k lines, perhaps), and the Tailwind isn't an annoyance per-say, but it's definitely less ergonomically friendly than the well-engineered enterprise application I was working on before, which was 100x the size and used exclusively pure CSS. Personally, my dream would be if inline styles supported the full CSS gamut of pseudo selectors and the child element selector. Then you'd have the admitted benefits of not needing to synchronize the two files, along with the benefit of not needing to relearn all of CSS. Edit: it's funny, in a way, that all these developers complaining about how CSS "doesn't scale" are likely writing their Tailwind in an large scale application styled entirely via CSS. https://github.com/search?q=repo%3Amicrosoft%2Fvscode++language%3ACSS&type=code https://github.com/search?q=repo%3Amicrosoft%2Fvscode++langu...
      - danielvaughn 3y ago
        On the contrary, Tailwind's ergonomics are what attract me to it. With the autocomplete features via the VSCode intellisense plugin, I'm able to create UIs at a pretty extraordinary pace. As a trivial example, let's imagine we need to apply a border radius to an element. Without Tailwind, it looks like this: 1. I find the element I need to style 2. I look at which class it's using 3. I navigate to my CSS file 4. I scroll down until I find the selector 5. I type "border-r", then tab on the auto-complete to fill in "border-radius" 6. I type the colon character, then space 7. I think about what unit is appropriate - rems, ems, pixels, percentage 8. I think about what value is needed for the design 9. I also look around to see if this style is used elsewhere 10. If the style is used elsewhere, I think about whether I need to refactor 11. I type in the desired value 12. I type a semicolon to mark the end of the statement 13. I type cmd+s to save the css file Here's the same example, with Tailwind: 1. I find the element I need to style 2. I type `round` and wait for the autocomplete to present my options 3. I use my arrow key to select which one I want 4. I type enter to add the desired tailwind class 5. I type cmd+s to save the html file The Tailwind interaction path takes less than half of the concrete steps to complete. But it's even more dramatic than that, because several of the steps taken in the first example require enough thought that it breaks your workflow and takes you out of your flow state. Then you have to get back into that flow state to keep working. But this keeps happening, so you're constantly stopping and restarting. With Tailwind, I tend to find myself staying in that flow state, because as I demonstrated above, there's very little getting in my way.
- gentleman11 3y ago
  Explain?
deleted 3y ago
[deleted]
danShumway 3y ago
I'm inclined to semi-agree with this, although I'm not sure I'd be quite as adamant about it myself. But I do generally think that CSS is taught in a way that encourages some bad practice around cascade/inheritance. I will point out though that (at least in my experience), BEM solved the majority of these problems for me even without a preprocessor. The language is definitely oriented towards inheritance/cascade, but I think there are ways to avoid it. There's some movement towards ::part as a proposal to grant some mixin behaviors (https://developer.mozilla.org/en-US/docs/Web/CSS/::part https://developer.mozilla.org/en-US/docs/Web/CSS/::part) but I've never messed with it, and it's applicable only to shadow DOM. But mixins haven't been a huge issue for me in even enterprise-scale styling that I've done. Opinion me, everyone has their own opinions on this, use whatever CSS style works for you. This is not me saying that BEM is the best for everyone, just giving a perspective that as someone who tends to stick to vanilla CSS and who generally kind of hates working with technologies like Tailwind or CSS-in-JS, BEM-style vanilla CSS made CSS pretty pleasant for me to work with; I have a lot more appreciation for the language now than I used to. So if you're annoyed by CSS but also get annoyed by pre-processors or think that Tailwind is just inline CSS under a different name[0], you still don't need to be bound to the cascade -- potentially look into BEM. No technology or compilation or dependencies, it's literally just a naming convention and style guide. ---- [0]: yes, I have used it extensively, please don't comment that if I used it more something would magically click, I already understand the points in its favor that you're going to comment and I've already heard the style/framework suggestions you're going to offer. It's fine if you like Tailwind, it's great if it helps you write CSS, you don't need to convince me.
- seanwilson 3y ago
  > But I do generally think that CSS is taught in a way that encourages some bad practice around cascade/inheritance. I will point out though that (at least in my experience), BEM solved the majority of these problems for me even without a preprocessor. I think cascading is just a bad default, and I think methodologies like BEM agrees with this by teaching you ways to write CSS in ways that stops cascading from getting in the way. Cascading styles are fine for styling how basic document content is shown (e.g. h2, p, a, li etc. tags) but outside of this, you generally don't want the styles of parent elements leaking into the styles of child elements. Cascading/inheritance styles is a useful tool to have, but not as the default. I'm not saying Tailwind is perfect, but it's closer to "prefer composition over inheritance", where you can sprinkle in some cascading/inheritance where it makes sense.
vram22 3y ago
>It looks like composition over inheritance has caught on as the better default in other languages "Prefer composition over inheritance" was mentioned in an early page of the GoF book (the Design Patterns book) - in 1994. https://en.m.wikipedia.org/wiki/Design_Patterns https://en.m.wikipedia.org/wiki/Design_Patterns
no_wizard 3y ago
>It looks like composition over inheritance has caught on as the better default in other languages, but in the CSS world people still cling to the cascade as a best practice for some reason I find this falls into generally two camps, those who want to fight the browser and those who don’t. Those that tend to hate the cascade tend to fight the browser a lot, whether they realize it or not. Generally speaking, they want things to work a certain way (IE everything in isolation) and prefer to think of styles isolated bits. The second camp tends to not fight the browser and embrace the browsers methodology. They embrace the cascade because it’s easier than fighting it, but it requires a more sophisticated approach and seeing styles in a wholistic manner, not isolated purely into components (though may be organized in a way that co-located them with relevant components) Both work, ultimately, and modern tooling and approaches allow both to exist, but I will say, the second group often has a better grasp on keeping project maintainability over time in my experience.
- coldtea 3y ago
  >Those that tend to hate the cascade tend to fight the browser a lot, whether they realize it or not. Generally speaking, they want things to work a certain way (IE everything in isolation) and prefer to think of styles isolated bits. So, wouldn't that be the browser fighting them, then? They want something specific, and the broswer forces a paradigm upon them that they don't want. They are the humans and the browser (well, the styling language of the browser) is the tool that should accomondate them, not the other way around.
  - no_wizard 3y ago
    This is a sane argument. I have no objection to it. Both things are true, in a sense. It really depends on how you view the browser, IE should browsers be more adaptive to certain paradigms or should it set a reasonable paradigm and enforce it? I don’t know that there is a 100% right answer in this case, though they have moved to create better hooks for some forms of isolation (e.g. layers, scoping) but they fundamentally haven’t walked away from the cascade aspect. It’s converging the two paradigms, for sure, but as I said, I don’t think either is wholly incorrect or correct. Now if you wanted my opinion on the whole thing, I think the cascade is a fundamental element to be leveraged not avoided, but that’s me.
layer8 3y ago
It’s not only inheritance, it’s also lack of encapsulation and of separation of concerns, which leads to attack vectors like: https://news.ycombinator.com/item?id=39928558 https://news.ycombinator.com/item?id=39928558
ramijames 3y ago
I really agree with this. There was a company that I worked at 10ish years ago with a SaaS built around Drupal. They had one monolithic css file that was 25000 lines. It was a nightmare. When I took over the front-end rebuild, went through it line by tedious line and broke it out into discrete components. I think about that from time to time when building logic or other functionality. I'd much rather have a self-contained bit of code than a big thing that is so intertwined I'm terrified to touch anything.
cjpearson 3y ago
CSS does actually call it inheritance[0], but it's commonly mixed up with the cascade. Inheritance applies to certain properties, so that when they are not specified on an element, an element inherits the value of the parent. The cascade[1] determines how rules from multiple sources are merged. [0]: https://developer.mozilla.org/en-US/docs/Web/CSS/Inheritance https://developer.mozilla.org/en-US/docs/Web/CSS/Inheritance [1]: https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade
- pwdisswordfishc 3y ago
  CSS calls something completely different "inheritance". There is no class inheritance in CSS, because CSS classes are not OOP classes.
spankalee 3y ago
The cascade is not much like inheritance at all. If anything it's more like composition because the styles can come from multiple sources, eg user styles vs author styles, multiple layers. The cascade is so much not like inheritance that I wonder if you meant either the concept of selectors in general, or inherited properties?
- seanwilson 3y ago
  Yeah, the other poster pointed out https://developer.mozilla.org/en-US/docs/Web/CSS/Inheritance https://developer.mozilla.org/en-US/docs/Web/CSS/Inheritance and https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade. I meant the concept that when you e.g. apply the style "color: blue;" to an element, all child elements get the same style unless you override it. I'm not saying it's identical to inheritance, but it's similar in that changes and additions at the top-level ripple down to lower levels, which I find causes most of the problems when writing maintainable code.
  - danShumway 3y ago
    > I meant the concept that when you e.g. apply the style "color: blue;" to an element, all child elements get the same style unless you override it. This is the first thing you've said so far that I would push back against. Neither BEM nor Tailwind removes this behavior that I'm aware of. I thought when talking about the cascade you meant generic styles on elements like "p", "ul", etc... getting applied across separate components, or specificity of child selectors, or something similar. If you really dislike styles being applied to children in the DOM that don't override those styles, I don't think there is a way around that other than web-based components and shadow DOM with isolated styles. Or I guess use a bunch of style resets beforehand I guess? Neither Tailwind nor BEM gets rid of child inheritance of applied styles; you can use @layer I guess, but that doesn't get rid of that behavior either, it just allows you a bit more control over style order. If you're using Tailwind and you write: <div class="text-red-400"> <p>Some text</p> </div> that text will be red. If you're using BEM and you write: <div class="Container"> <p>Some text</p> </div> .Container { color: red; } same deal.
pointlessone 3y ago
It's because people don't understand cascade we end up with pages that have text in 18 different font sizes. Cascade was a brilliantly simple idea and gave great consistency of design easily. At the time it was great. I believe the only reason most people are mad at CSS is because specificity is hard to grasp and order-dependent resolution and you don't control it when you bundle 500 packages. You get scores of megabytes of CSS that can randomly change order. Since then we've got more tools to control cascade: layers, scopes, inherit/initial/revert/revert-layer/unset for every property, etc. But people still insist on inline styling. I get it, it's much simpler. But they will keep being unhappy until they learn cascade and stop fighting tools. Yes, learning takes effort but so does resistance.
- fcpk 3y ago
  And not to forget that this also comes from a discrepancy between the fact a lot of people start with a design and want a CSS that matches that design, when CSS was made more as a theme system where you make a theme and let it handle placement and design. The result is clunky complex CSS to fight the browser into placing things an exact way and giving each element a different look. In my opinion, this was a failure of communication from the beginning, with a huge divide between "I want my website to look like this because I drew it on paper with my designer friend" and "css is a cool new way of doing decent programmatic ux/ui.
- seanwilson 3y ago
  > It's because people don't understand cascade we end up with pages that have text in 18 different font sizes. Variables and/or utility classes mostly solve this so not sure how it's related. > Since then we've got more tools to control cascade: layers, scopes, inherit/initial/revert/revert-layer/unset for every property, etc. But people still insist on inline styling. I get it, it's much simpler. But they will keep being unhappy until they learn cascade and stop fighting tools. Yes, learning takes effort but so does resistance. Similar to inheritance-like features in other languages, I have learned it and find composition is the better default. It's too complex for too little benefit so I avoid it wherever possible. I find maintainable CSS approaches are all about reducing the blast radius of style inheritance. So people are writing maintainable in sprite of cascading, not because cascading helps. > specificity is hard to grasp and order-dependent resolution Specificity is another foot-gun to avoid for me. It's learnable, yet easy to forget later. When you're tempted to rely on specificity there's usually a more readable way to do it that's not going to bite you later. Do you doubt the developers behind Tailwind library understand specificity and the cascade? They clearly must understand it, use it where it helps, and avoid it where it doesn't.
butlike 3y ago
The cascade was born from a time when the hope was to apply your own styles independently of the site's style, without overriding theirs completely. I think the standard languished and fell out of favor, but that was the hope. I'm having trouble finding the original video, but Jacob Thorton (@fat) did an insightful talk on the whole affair called "Cascading Shit Show"
pwdisswordfishc 3y ago
Nobody calls it this, because it is not. CSS classes have nothing to do with OOP other than the word "class".

ethanbond 3y ago

Obligatory: Tailwind

seanwilson 3y ago
I tried to avoid mentioning that, but Tailwind is showcasing how to write CSS using composition from inheritance. But it can't overcome the knee-jerk reaction from many CSS developers that don't see the problems that comes with CSS cascade/inheritance. I think this is mostly because leaning on cascading rules is seen as a best practice and most aren't going to question best practices much.
- Fauntleroy 3y ago
  Tailwind is not a panacea—it has its own problems which withhold adoption, "kneejerk reactions" notwithstanding.
- danielvaughn 3y ago
  I'll never understand why a lot of CSS devs are opposed to it. I can understand the initial gut reaction, but I've been writing CSS for 14 years and I love Tailwind. The cascade is a wonderful idea that has unfortunately not played out well in practice. Anyone who thinks it's just a skill issue is deluding themselves. In all my years, I've never seen CSS that (a) leverages the cascade, and (b) scales elegantly. It all breaks down past a certain point. Tailwind has it's flaws, but it doesn't have the scaling problem.
  - explaininjs 3y ago
    Mainly because nobody is a "CSS Dev". If someone's entire job was developing CSS, you might expect that they would be willing to learn one new slightly different way of doing it. But in reality the pushback comes from full stack developers who already have a million other things to worry about, such that relearning all the basic CSS they already know, to achieve benefits that are rather minuscule in the grand scheme of things, is a low priority. I personally am working on a Tailwind product that is fairly small (~10k lines, perhaps), and the Tailwind isn't an annoyance per-say, but it's definitely less ergonomically friendly than the well-engineered enterprise application I was working on before, which was 100x the size and used exclusively pure CSS. Personally, my dream would be if inline styles supported the full CSS gamut of pseudo selectors and the child element selector. Then you'd have the admitted benefits of not needing to synchronize the two files, along with the benefit of not needing to relearn all of CSS. Edit: it's funny, in a way, that all these developers complaining about how CSS "doesn't scale" are likely writing their Tailwind in an large scale application styled entirely via CSS. https://github.com/search?q=repo%3Amicrosoft%2Fvscode++language%3ACSS&type=code https://github.com/search?q=repo%3Amicrosoft%2Fvscode++langu...
    - danielvaughn 3y ago
      On the contrary, Tailwind's ergonomics are what attract me to it. With the autocomplete features via the VSCode intellisense plugin, I'm able to create UIs at a pretty extraordinary pace. As a trivial example, let's imagine we need to apply a border radius to an element. Without Tailwind, it looks like this: 1. I find the element I need to style 2. I look at which class it's using 3. I navigate to my CSS file 4. I scroll down until I find the selector 5. I type "border-r", then tab on the auto-complete to fill in "border-radius" 6. I type the colon character, then space 7. I think about what unit is appropriate - rems, ems, pixels, percentage 8. I think about what value is needed for the design 9. I also look around to see if this style is used elsewhere 10. If the style is used elsewhere, I think about whether I need to refactor 11. I type in the desired value 12. I type a semicolon to mark the end of the statement 13. I type cmd+s to save the css file Here's the same example, with Tailwind: 1. I find the element I need to style 2. I type `round` and wait for the autocomplete to present my options 3. I use my arrow key to select which one I want 4. I type enter to add the desired tailwind class 5. I type cmd+s to save the html file The Tailwind interaction path takes less than half of the concrete steps to complete. But it's even more dramatic than that, because several of the steps taken in the first example require enough thought that it breaks your workflow and takes you out of your flow state. Then you have to get back into that flow state to keep working. But this keeps happening, so you're constantly stopping and restarting. With Tailwind, I tend to find myself staying in that flow state, because as I demonstrated above, there's very little getting in my way.
gentleman11 3y ago
Explain?

deleted 3y ago

[deleted]

danShumway 3y ago

I'm inclined to semi-agree with this, although I'm not sure I'd be quite as adamant about it myself. But I do generally think that CSS is taught in a way that encourages some bad practice around cascade/inheritance. I will point out though that (at least in my experience), BEM solved the majority of these problems for me even without a preprocessor. The language is definitely oriented towards inheritance/cascade, but I think there are ways to avoid it. There's some movement towards ::part as a proposal to grant some mixin behaviors (https://developer.mozilla.org/en-US/docs/Web/CSS/::part https://developer.mozilla.org/en-US/docs/Web/CSS/::part) but I've never messed with it, and it's applicable only to shadow DOM. But mixins haven't been a huge issue for me in even enterprise-scale styling that I've done. Opinion me, everyone has their own opinions on this, use whatever CSS style works for you. This is not me saying that BEM is the best for everyone, just giving a perspective that as someone who tends to stick to vanilla CSS and who generally kind of hates working with technologies like Tailwind or CSS-in-JS, BEM-style vanilla CSS made CSS pretty pleasant for me to work with; I have a lot more appreciation for the language now than I used to. So if you're annoyed by CSS but also get annoyed by pre-processors or think that Tailwind is just inline CSS under a different name[0], you still don't need to be bound to the cascade -- potentially look into BEM. No technology or compilation or dependencies, it's literally just a naming convention and style guide. ---- [0]: yes, I have used it extensively, please don't comment that if I used it more something would magically click, I already understand the points in its favor that you're going to comment and I've already heard the style/framework suggestions you're going to offer. It's fine if you like Tailwind, it's great if it helps you write CSS, you don't need to convince me.

seanwilson 3y ago
> But I do generally think that CSS is taught in a way that encourages some bad practice around cascade/inheritance. I will point out though that (at least in my experience), BEM solved the majority of these problems for me even without a preprocessor. I think cascading is just a bad default, and I think methodologies like BEM agrees with this by teaching you ways to write CSS in ways that stops cascading from getting in the way. Cascading styles are fine for styling how basic document content is shown (e.g. h2, p, a, li etc. tags) but outside of this, you generally don't want the styles of parent elements leaking into the styles of child elements. Cascading/inheritance styles is a useful tool to have, but not as the default. I'm not saying Tailwind is perfect, but it's closer to "prefer composition over inheritance", where you can sprinkle in some cascading/inheritance where it makes sense.

vram22 3y ago

>It looks like composition over inheritance has caught on as the better default in other languages "Prefer composition over inheritance" was mentioned in an early page of the GoF book (the Design Patterns book) - in 1994. https://en.m.wikipedia.org/wiki/Design_Patterns https://en.m.wikipedia.org/wiki/Design_Patterns

no_wizard 3y ago

>It looks like composition over inheritance has caught on as the better default in other languages, but in the CSS world people still cling to the cascade as a best practice for some reason I find this falls into generally two camps, those who want to fight the browser and those who don’t. Those that tend to hate the cascade tend to fight the browser a lot, whether they realize it or not. Generally speaking, they want things to work a certain way (IE everything in isolation) and prefer to think of styles isolated bits. The second camp tends to not fight the browser and embrace the browsers methodology. They embrace the cascade because it’s easier than fighting it, but it requires a more sophisticated approach and seeing styles in a wholistic manner, not isolated purely into components (though may be organized in a way that co-located them with relevant components) Both work, ultimately, and modern tooling and approaches allow both to exist, but I will say, the second group often has a better grasp on keeping project maintainability over time in my experience.

coldtea 3y ago
>Those that tend to hate the cascade tend to fight the browser a lot, whether they realize it or not. Generally speaking, they want things to work a certain way (IE everything in isolation) and prefer to think of styles isolated bits. So, wouldn't that be the browser fighting them, then? They want something specific, and the broswer forces a paradigm upon them that they don't want. They are the humans and the browser (well, the styling language of the browser) is the tool that should accomondate them, not the other way around.
- no_wizard 3y ago
  This is a sane argument. I have no objection to it. Both things are true, in a sense. It really depends on how you view the browser, IE should browsers be more adaptive to certain paradigms or should it set a reasonable paradigm and enforce it? I don’t know that there is a 100% right answer in this case, though they have moved to create better hooks for some forms of isolation (e.g. layers, scoping) but they fundamentally haven’t walked away from the cascade aspect. It’s converging the two paradigms, for sure, but as I said, I don’t think either is wholly incorrect or correct. Now if you wanted my opinion on the whole thing, I think the cascade is a fundamental element to be leveraged not avoided, but that’s me.

layer8 3y ago

It’s not only inheritance, it’s also lack of encapsulation and of separation of concerns, which leads to attack vectors like: https://news.ycombinator.com/item?id=39928558 https://news.ycombinator.com/item?id=39928558

ramijames 3y ago

I really agree with this. There was a company that I worked at 10ish years ago with a SaaS built around Drupal. They had one monolithic css file that was 25000 lines. It was a nightmare. When I took over the front-end rebuild, went through it line by tedious line and broke it out into discrete components. I think about that from time to time when building logic or other functionality. I'd much rather have a self-contained bit of code than a big thing that is so intertwined I'm terrified to touch anything.

cjpearson 3y ago

CSS does actually call it inheritance[0], but it's commonly mixed up with the cascade. Inheritance applies to certain properties, so that when they are not specified on an element, an element inherits the value of the parent. The cascade[1] determines how rules from multiple sources are merged. [0]: https://developer.mozilla.org/en-US/docs/Web/CSS/Inheritance https://developer.mozilla.org/en-US/docs/Web/CSS/Inheritance [1]: https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade

pwdisswordfishc 3y ago
CSS calls something completely different "inheritance". There is no class inheritance in CSS, because CSS classes are not OOP classes.

spankalee 3y ago

The cascade is not much like inheritance at all. If anything it's more like composition because the styles can come from multiple sources, eg user styles vs author styles, multiple layers. The cascade is so much not like inheritance that I wonder if you meant either the concept of selectors in general, or inherited properties?

seanwilson 3y ago
Yeah, the other poster pointed out https://developer.mozilla.org/en-US/docs/Web/CSS/Inheritance https://developer.mozilla.org/en-US/docs/Web/CSS/Inheritance and https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade. I meant the concept that when you e.g. apply the style "color: blue;" to an element, all child elements get the same style unless you override it. I'm not saying it's identical to inheritance, but it's similar in that changes and additions at the top-level ripple down to lower levels, which I find causes most of the problems when writing maintainable code.
- danShumway 3y ago
  > I meant the concept that when you e.g. apply the style "color: blue;" to an element, all child elements get the same style unless you override it. This is the first thing you've said so far that I would push back against. Neither BEM nor Tailwind removes this behavior that I'm aware of. I thought when talking about the cascade you meant generic styles on elements like "p", "ul", etc... getting applied across separate components, or specificity of child selectors, or something similar. If you really dislike styles being applied to children in the DOM that don't override those styles, I don't think there is a way around that other than web-based components and shadow DOM with isolated styles. Or I guess use a bunch of style resets beforehand I guess? Neither Tailwind nor BEM gets rid of child inheritance of applied styles; you can use @layer I guess, but that doesn't get rid of that behavior either, it just allows you a bit more control over style order. If you're using Tailwind and you write: <div class="text-red-400"> <p>Some text</p> </div> that text will be red. If you're using BEM and you write: <div class="Container"> <p>Some text</p> </div> .Container { color: red; } same deal.

pointlessone 3y ago

It's because people don't understand cascade we end up with pages that have text in 18 different font sizes. Cascade was a brilliantly simple idea and gave great consistency of design easily. At the time it was great. I believe the only reason most people are mad at CSS is because specificity is hard to grasp and order-dependent resolution and you don't control it when you bundle 500 packages. You get scores of megabytes of CSS that can randomly change order. Since then we've got more tools to control cascade: layers, scopes, inherit/initial/revert/revert-layer/unset for every property, etc. But people still insist on inline styling. I get it, it's much simpler. But they will keep being unhappy until they learn cascade and stop fighting tools. Yes, learning takes effort but so does resistance.

fcpk 3y ago
And not to forget that this also comes from a discrepancy between the fact a lot of people start with a design and want a CSS that matches that design, when CSS was made more as a theme system where you make a theme and let it handle placement and design. The result is clunky complex CSS to fight the browser into placing things an exact way and giving each element a different look. In my opinion, this was a failure of communication from the beginning, with a huge divide between "I want my website to look like this because I drew it on paper with my designer friend" and "css is a cool new way of doing decent programmatic ux/ui.
seanwilson 3y ago
> It's because people don't understand cascade we end up with pages that have text in 18 different font sizes. Variables and/or utility classes mostly solve this so not sure how it's related. > Since then we've got more tools to control cascade: layers, scopes, inherit/initial/revert/revert-layer/unset for every property, etc. But people still insist on inline styling. I get it, it's much simpler. But they will keep being unhappy until they learn cascade and stop fighting tools. Yes, learning takes effort but so does resistance. Similar to inheritance-like features in other languages, I have learned it and find composition is the better default. It's too complex for too little benefit so I avoid it wherever possible. I find maintainable CSS approaches are all about reducing the blast radius of style inheritance. So people are writing maintainable in sprite of cascading, not because cascading helps. > specificity is hard to grasp and order-dependent resolution Specificity is another foot-gun to avoid for me. It's learnable, yet easy to forget later. When you're tempted to rely on specificity there's usually a more readable way to do it that's not going to bite you later. Do you doubt the developers behind Tailwind library understand specificity and the cascade? They clearly must understand it, use it where it helps, and avoid it where it doesn't.

butlike 3y ago

The cascade was born from a time when the hope was to apply your own styles independently of the site's style, without overriding theirs completely. I think the standard languished and fell out of favor, but that was the hope. I'm having trouble finding the original video, but Jacob Thorton (@fat) did an insightful talk on the whole affair called "Cascading Shit Show"

pwdisswordfishc 3y ago

Nobody calls it this, because it is not. CSS classes have nothing to do with OOP other than the word "class".