Tailwind CSS v3.2 – Introducing Container Queries, Multiple Configs and More | Hacker News Reader

Tailwind CSS v3.2 – Introducing Container Queries, Multiple Configs and More

tailwindcss.com

19 pointsjoshmanders5 comments

To the Tailwind team: Thanks!

You have done an amazing job, and you keep on moving things forward! I have bought everything you offer, and love the business model.

1. Question: Is there a way to support has() in all browsers? Is it on the roadmap?

2. Comment: Requiring compilation definitely allowed Tailwind to offer lots of stuff, but I'll bet it has cost many casual devs from trying and getting hooked.

3. Shameless plug: `tailwind-children`[1] adds support for `child:`, `peer:` and `descendant:`. Spread the word ;)

(Can be done with arbitrary selectors, eg. `[&>*]:` but this is more explicit and handles overrides on the child.)

[1]: https://www.npmjs.com/package/tailwind-children

I haven't used Tailwind, but from what I have seen it looks just like the old school way of writing inline CSS. But then it extracts it to a css file, no? Except that I read that it's great for writing, but a nightmare for reading. So just the same as inline CSS.

Would be interested to hear some opinions from people who have used it.

Not sure if you’re read Adam’s original post[0] detailing the thinking behind the Tailwind approach, but I found it pretty thought-provoking at least.

Basically we just admit to ourselves that we don’t have true separation of concerns anyway, so stacking utility classes lets us keep the styling of components near the components where the styles are actually used (no more flipping back and forth between HTML and CSS to tell what a component will look like). You can always extract and refactor later if you find yourself writing the same thing over and over. It’s bizarre and uncomfortable to start, but I’ve found it has quite a bit more upside than downside.

[0]: https://adamwathan.me/css-utility-classes-and-separation-of-...

> Except that I read that it's great for writing, but a nightmare for reading.

This is true at first. I can see it being pretty daunting to come into an existing project and trying to understand the styling of components. Starting from scratch and easing it into an existing project is much easier imo. That's what I did for a personal website. Now that I understand it and have converted the entire website to Tailwind, I don't want to switch to anything else going forward.

Here's a Prettier plugin that sort the classes to keep everything consistent across components: https://github.com/tailwindlabs/prettier-plugin-tailwindcss

Tailwind combined with classnames (https://github.com/JedWatson/classnames) makes it really easy to have conditional styling based on component state.

> but from what I have seen it looks just like the old school way of writing inline CSS.

Sure if you think of it that way because you only added say the `rounded` class to an element, which just adds `border-radius` to it. But once you start composing with more the comparison starts breaking down, and then once you introduce variants it's like comparing apples to trains.

Reply on news.ycombinator.com