> How many of your Tailwind-using apps ALSO have meaningful class names and IDs in your markup?
The markup doesn't need meaningful class names because CSS is encapsulated in reusable HTML fragments that have meaningful names. Your approach to structuring markup is simply unnecessarily more repetitive.
Poorly defined "design" principles have a cost, and where they conflict with concrete principles with a proven track record, like "reusable abstractions", then the poorly defined principles are wrong.
> The markup doesn't need meaningful class names because CSS is encapsulated in reusable HTML fragments that have meaningful names.
They have meaningful names... where? In React (or whatever). They don't in the web inspector (so just use the React dev tools! Yes, more complexity). They don't for testing tools like playwright, cypress, or capybara (so just use data-test-id! Yes, now you have to name something FOR TESTING PURPOSES ONLY, which is a clear sign of failure).
> Poorly defined "design" principles have a cost, and where they conflict with concrete principles with a proven track record, like "reusable abstractions", then the poorly defined principles are wrong.
I'm not sure that attempting to redefine design into something that you can ignore will do you much good, in the long run. If you think that "reusable abstractions" are a problem, then it's highly unlikely that there is a fraction of a square inch of common ground between us and any further conversation will just lead to frustration.
> They have meaningful names... where? In React (or whatever). They don't in the web inspector (so just use the React dev tools! Yes, more complexity).
They have meaningful names in the locations where people actually need to care about meaningful names: in the template language or the component model used to generate the final markup. If you're suggesting that class names should be meaningful for people who want to read the generated markup and they can only make sense of it because of class names, you're penalizing all front-end development for an absurdly small niche.
If you need identifiable names for testing purposes, that's what other queryable HTML attributes are for (id and name in particular). In your template language you already have the component name available, so just assign a queryable attribute using that where necessary. Nothing wrong with that.
The markup doesn't need meaningful class names because CSS is encapsulated in reusable HTML fragments that have meaningful names. Your approach to structuring markup is simply unnecessarily more repetitive.
Poorly defined "design" principles have a cost, and where they conflict with concrete principles with a proven track record, like "reusable abstractions", then the poorly defined principles are wrong.