[themarkn]

If you see it as just inline CSS, then tailwind can be avoided for all the same reasons that we avoid writing inline CSS. It’s considerably more than inline CSS imo but that’s a different story.

That said, I’m surprised by this:

“Only when you have troubles selecting an element based on its position in your DOM you should choose a classname”

Certainly if you have knowledge of the exact DOM structure in advance, and high confidence that it will never be substantially changed, this is workable. But in many cases, having the CSS care about the DOM structure produces way more pain than the ergonomics of tailwind do. At least in the kind of code I’ve worked on where components are reused all over the place and sometimes rearranged by authors directly in a CMS. Or just having DOM reorganized because something is added that requires an extra wrapper & then all the CSS selectors are nested wrong. Or whatever.

Anyhoo. I don’t love tailwind, but I think it’s fine. Far worse things have happened to web dev. It seems like you have a problem with utility CSS, which tailwind takes to the extreme for sure.

Also, side note - having headings in a figcaption like that seems semantically incorrect.

[vehemenz]

> having headings in a figcaption like that seems semantically incorrect.

I genuinely wonder what the payoff is for semantic correctness.

Web browsers don't care, screen readers aren't nearly as particular as they used to be, and the web certainly isn't returning to some XML/XSLT universal document ideal.

[themarkn]

A screenreader user cares if they are navigating between headings and the headings are not actually headings - and it’s always _better_ if the nature and structure of the content is expressed in the HTML so that the screened can announce things correctly. Keyboard users also care a lot about semantic HTML because they are so so many interfaces out there that are not keyboard navigable as divs are used for everything including buttons. So they just can’t reach parts of the interface, or even perceive them.

It’s not about a pristine ideal. Though I’d argue semantic HTML is not only the foundation of good accessibility, it also makes for more readable code because the intention behind the elements is exposed to the next person reading it. It nudges you to do better work because you actually have to understand the nature of what you are building, which means you might see how it reflects an existing pattern that can be copied, not duct tape together a half working tab interface with JS event listeners on divs and spans.