[734129837261]

Tailwind is the weirdest thing I've ever ran across. It's basically inline CSS.

Personally, I write CSS this way:

1. Select based on cascaded semantic HTML elements; 2. Don't repeat yourself; 3. No unnecessary classnames; 4. No style-descriptions in classnames.

Only when you have troubles selecting an element based on its position in your DOM you should choose a classname. It should not be ".text-gray-500" (like Tailwind does) but it should be "p.author-role".

In my case the classname is semantically descriptive whereas Tailwind is not. In my case you just need to update the CSS and in the case of Tailwind you need to change your HTML and then probably also create a new CSS class.

But still, ideally, you'd simply select it like this:

The author name:

    figure.author figcaption h5 { ... }

The author role:

    figure.author figcaption h6 { ... }

And even the .author selector would be optional, depending on whether that figure elements needs custom styling that is exclusive to the author or not.

[mike1o1]

This comes up almost every time, but it's not "basically inline CSS". The best thing about Tailwind (and utility classes in general) is that it forces you to use consistent measurements across your app.

"Shoot, was this 13px padding or 14px padding on the other page?" Don't worry about it, just use "p-4, p-6, etc.". Thinking in these terms becomes really powerful.

Another great thing as that you just simply don't have to think about what to name things! I find that so liberating, to be honest, and I don't have to keep switching back and forth between my markup and my css. I don't have to worry about coming up with semantically descriptive names. I just use "text-gray-500". Was this .authorrole? Or was it .authoremail? Hmm, now I want to display an author nickname. Do I just repeat "authorname" class? I find it so freeing to basically not have to worry about this stuff at all.

[BigJono]

Who uses 13px for anything? I literally don't get this. Just remember to use a multiple of 4px? Or 0.25rem? Or whatever your designer is desinging to? This is solved with a 5 second conversation at the start of a project. Why the fuck do you need a library?

Legitimate question. How do you remember not to use "p-4.25" without npm installing tailwind-default-constraints or whatever the fuck?

[deergomoo]

> How do you remember not to use "p-4.25" without npm installing tailwind-default-constraints or whatever the fuck

Because "p-4.25" isn't an available class.

The whole point is that you have a fixed list of sensible options. You can extend it and customise it, but out of the box your design system is sensible and predictable. "p-8" is double "p-4"; "p-6" is half way between. It's like an enum case vs just using a raw integer.

Sure you can replicate it by creating some Sass variables and sticking to them but then you're on your way to re-implementing a utility-first framework.

[dmt0]

"Shoot, was this p-4 or p-6 on the other page?"

[idkwhoiam]

Checkmate!

[nailer]

so thinking of names like ‘author-nickname’ is difficult but learning an entire new syntax for css is easy?

[monkey_monkey]

Yes, "learning" the tailwind syntax was really quite easy.

In addition, most editors and IDE's now have plugins for autocompletion

And as an incentive to learning – once you're familiar with Tailwind's syntax, you get to use that learning on all your future Tailwind projects.

[nailer]

As a tailwind user I find it a hassle. There's quote of lot of CSS values, and having to remember small things like...

- 'grid-auto-flow: row' is 'grid-flow-row'

- 'grid-auto-flow: column' is not 'grid-flow-column' but rather 'grid-flow-col'

...is annoying.

[welder]

There's a better way to get consistent measurements without having to remember class names:

Use withStyles[1] and have a spacings namespace in your theme. Use the spacing in your component like spacing.button, which applies an Object containing the correct CSS padding, or spacing.padding.medium for the raw number.

[1] https://github.com/airbnb/react-with-styles

[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.

[vehemenz]

Tailwind is not "basically" inline styles.

Tailwind and other functional frameworks use classes for abstraction, which unlocks media queries, pseudo selectors, and many other CSS features.

Plus Tailwind's build system generates styles according to your config, which is sort of what distinguishes it from other functional frameworks.

"Semantically" descriptive could mean any number of things. In this case, it seems to mean: name your class according to what it's supposed to do, which is nice in theory, except that it hides the relationship between the markup and CSS. A well-prepared stylesheet is nice, except when the markup doesn't match what it expects.

In Tailwind, the class names themselves are "semantically" descriptive because they do exactly what they are supposed to do. There are no hidden abstractions.

[ahuth]

> It's basically inline CSS.

It's not, because there's a system to it. With Tailwind you pick specific values. Inline styles let you specify any value.

> It should not be ".text-gray-500" (like Tailwind does)

This is fair. I'd never considered that specifying the actual color in the class name would be problematic, but another thread pointed out that it makes theming (such as dark mode) difficult.

> 1. Select based on cascaded semantic HTML elements; 2. Don't repeat yourself; 3. No unnecessary classnames; 4. No style-descriptions in classnames.

I'm sure this works great when there are a small number of people working on styles. When there are many, however, I've found that the cascade often results in styles overriding one another, and needing to introduce more specificity to fight it, in an endless cycle.

Obviously people should write better CSS to avoid that. Which is actually what Tailwind is, I think.

[sbacic]

> It's not, because there's a system to it.

I think what bothers people isn't _what_ it is but _where_ it is. I for one, don't want long sausages in my HTML elements, regardless of whether they are classes or CSS styles.

[tomc1985]

Pretty much every CSS framework under the sun relies on a pile of classnames for each element? Even the most mimimal frameworks from 10 years ago worked this way...

[extra88]

Bootstrap and the like don’t have one property per class name as Tailwind does.

[aniforprez]

The bootstrap comparison is awful as they both do COMPLETELY different things

[extra88]

I agree Bootstrap and Tailwind are very different, that’s what I was pointing out. Your problem is with tomc1985, not me.

[mpalmer]

The semantically descriptive unit for most Tailwind users is the React/Vue/Angular component. For vanilla web development it definitely makes less sense, especially since it has a "compile" step.