In my experience trying to do semantic CSS just adds a lot of extra cognitive overhead and breaks down in the inevitable requirements churn every project goes through.
I was skeptical of Tailwind too until I actually tried it. It’s one of those things like JSX that defies received wisdom but in real use is very nice.
Sure in a 4 line example it's fine. On a real site with 5 different kinds of hero elements, with some styles in common but a lot of small variations and each with its own responsive behavior it's not so easy anymore. Coming up with good names for things is one of the hardest jobs in programming and this style forces you to name everything.
I've been building sites the way you suggest for 20 years. I also had a negative knee jerk reaction to tailwind. But I had enough of an open mind to try it and now I have no interesting in going back.
> Coming up with good names for things is one of the hardest jobs in programming and this style forces you to name everything.
People say that. If you build stuff in components like you are supposed to you almost always have a server side component or component logic that you will have to name. So you are going to have to start naming things properly somewhere.
You are simply kicking the can down the road.
> I've been building sites the way you suggest for 20 years. I also had a negative knee jerk reaction to tailwind.
It isn't a negative kneejerk reaction. I've worked with sites where they have done similar things to tailwind and it is a nightmare to understand what is going on with the page.
> But I had enough of an open mind to try it and now I have no interesting in going back.
The markup is almost unreadable, it completely defeats the point of what CSS is supposed to do and it creates considerable mental overhead for someone who isn't familiar with it.
But I suppose I shouldn't really expect anything else from other web developers that over the last 20 odd years somehow manage to not understand the tech they are given.
And despite your crude last jibe at web developers attracted to Tailwind's model, most competent web developers will be able to quite easily pickup this very sane CSS utility framework :)
>And despite your crude last jibe at web developers attracted to Tailwind's model,
No my jibe was at web developers in general. CSS and HTML are quite simple really. If you actually keep things semantic and build your document properly with appropriate markup ... lo and behold things just work properly.
I can understand the divistush of the past when CSS 1 and 2 were quite limited. However today there is simply no excuse.
> most competent web developers will be able to quite easily pickup this very sane CSS utility framework :)
Sure I can read it. The problem is with things like this is that you are learning how to work with their model that basically doesn't work like CSS is supposed to work.
So you it essentially nullifies your existing skillset and forces you into using their framework. I bothered to actually learn CSS properly and understand the technology and then I have to work with something which basically throws that all out the window and forces me to work how they want me to build stuff. No thanks.
If you think that is a "sane" way of working, I really don't know what to say.
People say that. If you build stuff in components like you are supposed to you almost always have a server side component or component logic that you will have to name. So you are going to have to start naming things properly somewhere.
Sure, so you can do it once and use functional css to define the styles that go with that component right alongside the markup instead of having to maintain another css class name for that component in a separate file, mostly likely with arbitrary and inconsistent padding and margin and font-size values.
If you actually think ahead i.e. don't just start coding straight away you can avoid that. All you are doing is making excuses for not doing your job properly.
It's easier to parse but what does "hero" actually do? You need to go digging around in all your stylesheets to figure it out and in most cases actually load up the page and inspect it. That overhead is gone in a functional approach.
If you build things as components as you are supposed to (every backend and frontend framework has been geared around since the late 90s) Your CSS styling should correspond directly to your components (whether they are JS or a MVC partial view). So it should be obvious.
> You need to go digging around in all your stylesheets to figure it out and in most cases actually load up the page and inspect it.
When are you changing CSS and not inspecting the page at the same time? You are going to have to check your work. This doesn't happen if you keep things tidy as you go along. Working in a large team and/or scrum is no excuse for checking-in poor code.
You could however the problem is that the comment will invariably will be left after thing have changed and will just cause confusion.
Generally what the code is doing should be fairly obvious and should not need comments. Comments should be reserved where things aren't obvious.
I don't think it is a good idea to create code where it isnt obvious what it does. CSS is relatively simple tbh things really shouldn't be complicated.
It might not work in very large teams without an agreed on working style, but I don't see how it would be a problem in smaller teams or for individuals agreeing on using comments to their advantage.
I was skeptical of Tailwind too until I actually tried it. It’s one of those things like JSX that defies received wisdom but in real use is very nice.