Posted by mpweiher 6 days ago
pico.classless.css is 2458 lines long.
I love the focus on semantic HTML, because it matches how I write CSS. The HTML should be as pure and as style-agnostic as possible.
Me neither!
> you can simply remove or add classes as you need
That sounds like exactly what I was thinking when you said class soup.
> you don't have to dig through loads of CSS files to figure out where the CSS is
The CSS should be in your components, or in a .css file beside your components at worst. React having bad defaults doesn't need you need to change to adding 20 classes to every HTML element.
<!-- Like his --> <div class="px-4 py-2 bg-blue-500 text-white rounded shadow-md hover:bg-blue-600">
<!-- Instead of this --> <div class="btn-primary">
You get used to reading any code the more you read it.
Good class and ID names should be semantic, just like the markup. Don't describe what the CSS does; describe what the element is.
Not only that, but it introduces useless abstractions that could've been avoided by just writing CSS directly. How is `.content-center` better than `align-content: center`?
Tailwind and its ilk are one of the worst trends to have ever happened in web development. It's making people forget how to use CSS, while being useless in the process. I truly don't understand it. And, yes, I've worked on projects that used it extensively. It's awful.
Quick iteration and good relative spacing for margins, paddings, dimensions etc.
A lot of people combine Tailwind with something like Vite so they're getting instant previews and don't need to swap focus to a style sheet to style their component. I swapped to Tailwind and honestly could never swap back.
You're raising a bunch of meyerweb talking points from 2003, except why? WHY does markup need to be "semantic" in the sense that you mean? Actually, WHY? Provide a supporting argument that it makes a difference to developers or end users. Remember, we've all been doing it that way for years, and we switched to Tailwind. You need to have something more compelling to developers who have already made up their minds.
> Not only that, but it introduces useless abstractions that could've been avoided by just writing CSS directly. How is `.content-center` better than `align-content: center`?
There are several reasons, but media queries would be reason 1. Why is it useless, again? Remember, we can't tell what your high-level abstractions do without opening at least two files, plus we have to understand any inherited/cascading rules on top of that. If that complexity doesn't matter, then it's argument time again.
> It's making people forget how to use CSS
Tailwind relies on CSS for its class names. How would one use it without knowing CSS in the first place? Secondly, why would it be bad (argument time again)?
The reasons for Tailwind are well understood. It's way faster, trivial to pick up, and easier to maintain longterm, especially in a team environment, than bespoke CSS/DOM abstractions that have layers of hidden complexity. Now, what does your way of doing CSS offer? Remember, tons of people switched from older methodologies to Tailwind and have already priced in the benefits, small as they were.
If you've been hearing about this since 2003, then I shouldn't have to repeat the reasons here. You can look up countless articles that explain exactly why semantic HTML and CSS are a good thing much better than I can do justice here.
> There are several reasons, but media queries would be reason 1.
That still doesn't explain why e.g. `class="w-16 h-48 md:w-32 lg:w-48"` would be preferable over a single class that describes what the element is and defines how it should look like and behave.
I mean, to steel man your argument, I get the appeal of getting predefined and consistent breakpoints, and being able to prefix or suffix classes with sizes. But that doesn't seem like a worthy tradeoff for losing legibility, and polluting the markup with this noise. It's the same as declaring all CSS inline, except using classes.
> Remember, we can't tell what your high-level abstractions do without opening at least two files
A good class name will tell you what the element is, not what it should look like. For that, you look at the CSS. Whether that CSS is defined in the same file or in another file, is up to you.
> plus we have to understand any inherited/cascading rules on top of that
Yes, that is what the "C" in CSS stands for, and it's a useful feature for propagating and combining rules without having to redefine them on every element.
If you want to avoid this "complexity", there are numerous ways to scope rules to a specific element or component. Most modern frameworks can scope styles per component for you. And with cascade layers, you now have more control over how and when rules are applied.
> Tailwind relies on CSS for its class names. How would one use it without knowing CSS in the first place?
Some class names are straightforward to understand and use, but others, like the example I posted above, require knowledge about Tailwind itself. Users can become proficient with this syntax without ever understanding what's happening underneath, thus degrading their CSS knowledge. You said it yourself—you want to avoid looking at CSS files altogether. How long would it take for you to not be able to write CSS directly?
> It's way faster, trivial to pick up, and easier to maintain longterm, especially in a team environment
Those are highly subjective, and I would argue against it being easier to maintain. When all your elements use dozens of utility classes, how do you ensure that the styles are consistent throughout the app? One typo in any of the class names can cause inconsistencies that are difficult to spot in a code review.
Oh, use reusable components, I hear you say. Well, why don't you just define the CSS in the component itself then?
Or, no, you use another abstraction on top of Tailwind like daisyUI, which is an insane attempt to bring back sanity into this workflow.
> than bespoke CSS/DOM abstractions that have layers of hidden complexity.
What abstractions?? It's literally a group of rules with a descriptive name that tells you a) what the element represents in the context of the app, and b) how it looks and behaves. There are no abstractions there.
The reason the classes are "bespoke" is because every app will be different. You might want to share some common rules between apps, and we've been doing that for decades just fine. I don't see how grouping utility class names inline makes you any faster or more productive than grouping rules in CSS declarations in the same or external file, and giving them a descriptive name.
> Remember, tons of people switched from older methodologies to Tailwind and have already priced in the benefits, small as they were.
Tons of people use and swear by bloated and complicated frontend web frameworks too, so the popularity of Tailwind doesn't surprise me. I can still have the opinion that it's all wrong, which you're free to disagree with.
As I understand it, the main point of semantic web is making the web machine readable, often using languages specifically designed for that task that are not HTML.
Semantic HTML is more concerned with writing standardized HTML that leverages browser capabilities and respects users who use assistive technology to browse the web.
Frankly, I don't see what this framework has to do with either. I was curious about how they implemented the dropdown menus, and they're specially styled <details> elements, which are normally used for accordions. That seems a bit strange to me, because the obvious choice for a dropdown is the <select> element.
Here’s a uBlock Origin style I use for hackernews, for example:
news.ycombinator.com##.comment:style(max-width: 40em !important;)Instead of if you'd just given them all the same semantic class ".config-button" or ".sidebar-button" or ".btn-hero" or whatever, you could make that change in a single place.
If your CSS has turned into soup, I have to be blunt: you're doing it wrong. And you should never have to "dig through loads of CSS files to figure out where the CSS is", it's 1) literally in your browser inspector when you select the element and 2) your CSS files should be organized so it would be easy anyways. Finding a class is as easy as finding a function definition.
Utility classes are for people who want to throw away all the benefits of semantic naming because they don't want to go to the trouble of actually organizing their user interface, even though they see the value in organizing the rest of their code. I honestly don't get it.