Comment by locallost
2 years ago
The list reminds me of when people refactor code and then just rename things. Ok, foo should've been called bar, but is that really a design mistake? The biggest design mistake for me is that it contains the letter C - it never should've been cascading. There's probably a need to resolve conflicting rules but it never should've been THE feature around which the language is designed. The precedence algorithm, the specificity etc. has been a source of endless bugs because you almost never know if somewhere somehow an outdated selector is messing everything up in a hidden place far away from what you're actually doing.
Instead the core features should've been simple ways to, well, style. From the beginning you should've been able to e.g. position vertically. There's a huge list of these issues where for a long time the simplest things were difficult and involved too much thought to get anything done. Granted things have improved, but the main issue I have is that standards like CSS should be more practice driven, e.g. what are the things I want to get done and how do I do that. Instead this is how you will override a selector as if that's the most important thing.
This is interesting because my first reaction was to recoil in horror at the idea of CSS without the cascade, but my second reaction was to realie you're actually describing approximately how Tailwind works eg small classes that you can use to apply an aspect of styling to a specific element, and use to build up to a design. Utility classes would be the obvious choice if you couldn't rely on the cascade any more.
Tailwind styles still cascade but in a far more manageable and override-able way. Perhaps you're on to something.
Which is better or correct is a question of basically how do you organize code. It's not irrelevant, but at the core should've been how to style content in a way that people actually want to style content. Instead a lot of time was spent on making up rules about cascading and specificity, which the vast majority of developers don't truly know. I knew them 15 years ago well, and realized also in horror as I wrote that I don't really know them so well. And turns out it's not so important. CSS gave us a bunch of primitive things to do, and we were supposed to figure it out, but the primitive things were not that well designed either. It was always a bunch of trickery, but at least the separation of concerns was taken care of.
Usually one does not need to know all the rules of specificity in a project with sane style sheets. Often it is enough to know what styling applies to a parent element and then make the selector more specific by addressing the child element, or if element at the same level, make the selector more specific by adding more detail to where that element is located in the DOM to the selector. Then one automatically has something more specific.
In other cases one can look up how it values id selector for example, or watch the immediate result in the browser, as one adds such a selector.
I am guessing, that over time people, who deal a lot with CSS, will learn the specificity rules automatically.
Interesting to think about the implications of a non-cascading system.
First that comes to mind, is how in OOP we have this idea of "composition over inheritance". Would composable style sheets be better? IDK.
Second issue I see is that, by all definitions, browsers come with a default style. What would "No style" even be? Invisible? Or maybe a very basic default? And would that be readable at all? And how do we the override these defaults? Would the existence of any custom styles immediately disable any base styles?
Lots of issues that are mostly "solved" with cascading. But which would need (a) solution(s) without cascading.
I still like exploring the idea, but the more I dive down that rabbit hole, the more I think that actually cascading is a rather elegant solution.
And, as with OOP inheritance, it's up to us to keep it sane. I've always managed to keep my cascading max three levels: browser, basis.css, custom.css. and in neither basis nor custom, do I have inheritance (cascading) chains.
I've even used a Linter to enforce this, years ago. Cannot find it anymore, sadly.
Tailwind-style selectorless approach is essentially a shorter form of inline style attributes. Surely there are better solutions?
Yes, I don't understand the modern trend towards utility classes. I wonder if many of the people who reinvent them were not around when HTML 4 was the markup language of the day and the <FONT> tag reigned supreme.
In my experience, it’s because people fail to learn core CSS properties and principles but can remember which classnames to jam into an element to get it to align correctly (not realizing the sacrifice is duplicate CSS—and sometimes things only rendering because of specificity in the order of the classnames they jammed in—I.e. a lot of extraneous ones).
Tailwind and utility classes make things bloated. Source: been writing HTML and CSS for 20+ years and working with a lot of devs who just don’t get CSS.
Originally the „cascade“ referres to the ability for both the browser, and the the user, and the website to define styles for a single website. With the browsers styling being the weakest, the users styles the strongest and the websites own styles being in the middle of the cascads