Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tailwind CSS v4.0 Beta 1

tailwindcss.com

Post reply on HN
Print view View original

91–100 of 135 posts

Re: Tailwind CSS v4.0 Beta 1

#91

Post by emmacharp »

throwup238 wrote: post #24
bryanrasmussen wrote: post #22

Earlier quoted context omitted.

How does Tailwind handle responsive design issues better than CSS? Assuming of course CSS where the devs know how to use clamp.

YMMV but I find ‘lg:…’ to be much better than ‘@media (min-width: 992px) { … }’ at the expense of repeating ‘lg:’ every class. Since most components don’t need too many responsive classes per breakpoint, this is a net benefit most of the time (and nothing is stopping devs from combining utility classes and custom css with media queries). Like GP said, this kind of specificity is impossible in inline styles altogether…

The clamp() CSS function (and auto-adapting grids) can reduce media query usage to a really loooow minimum. Nowadays I use media queries only for mobile nav and maybe layout grid adaptation. Like 2 to 4-5 media queries per project maximum.

I think that's what the comment you're responding to meant.

Re: Tailwind CSS v4.0 Beta 1

#92

Post by emmacharp »

I invite (for fun and learning!) anyone here still thinking native CSS provides no efficient solution to the problems Tailwind may have solved 5 years ago to challenge me:

Bring up any said problem and I'll give you an efficient, robust, fast, simple and maintainable way to solve it in pure, native CSS (maybe even with further advantages!).

The time has come to embrace good ol' CSS again! Heheh.

Re: Tailwind CSS v4.0 Beta 1

#93

Post by Vinnl »

emmacharp wrote: post #92

I invite (for fun and learning!) anyone here still thinking native CSS provides no efficient solution to the problems Tailwind may have solved 5 years ago to challenge me: Bring up any said problem and I'll give you an efficient, robust, fast, simple and maintainable way to solve it in pure, native CSS (maybe even with further advantages!). The time has come to embrace good ol' CSS again! Heheh.

Ok, my problem is that I don't know just by reading the styles that other contributors wrote, whether they are still relevant, or if the HTML they applied to was changed or removed. They didn't write clean atomic commit, and I can't get them to adhere to some sort of convention.

The other problem is that I don't have a designer and tend to make things ugly given full freedom, but I do want things to have their own visual identity.

Re: Tailwind CSS v4.0 Beta 1

#94

Post by emmacharp »

Vinnl wrote: post #93
emmacharp wrote: post #92

I invite (for fun and learning!) anyone here still thinking native CSS provides no efficient solution to the problems Tailwind may have solved 5 years ago to challenge me: Bring up any said problem and I'll give you an efficient, robust, fast, simple and maintainable way to solve it in pure, native CSS (maybe even with further advantages!). The time has come to embrace good ol' CSS again! Heheh.

Ok, my problem is that I don't know just by reading the styles that other contributors wrote, whether they are still relevant, or if the HTML they applied to was changed or removed. They didn't write clean atomic commit, and I can't get them to adhere to some sort of convention. The other problem is that I don't have a designer and tend to make things ugly given full freedom, but I do want things to have their own vi…

Great questions/problems!

1. I address the problem of relevance by inserting the CSS right into the component with a link tag. If the component is not used, the CSS isn't either. A positive side effect of this technique is that you always have an easy access to the CSS by following the link in your editor of choice. As for the relevance of the rules inside the component, the said component should be light/simple enough that this isn't harder that glancing a minute (max!) at both files.

2. You can use Stylelint to ensure adherence to specific rules. I have developed a config aiming to prevent these kinds of problems. You can find rules, guidelines and a link to the Stylelint config (still beta) at https://ecss.info.

3. A CSS theme file with custom property design tokens is sufficient. As I understand, Tailwind 4.0 made the switch to CSS tokens. You can thus use the same naming convention for your tokens in native CSS.

As complementary advantages you get future-proof code, no build step, and a lot less unused CSS (for instance, Tailwind's own homepage sports 85% unused CSS!).

I'm happy to elaborate further or respond to any subsequent questions you may have!

Re: Tailwind CSS v4.0 Beta 1

#95

Post by [deleted] »

emmacharp wrote: post #91
throwup238 wrote: post #24

Earlier quoted context omitted.

YMMV but I find ‘lg:…’ to be much better than ‘@media (min-width: 992px) { … }’ at the expense of repeating ‘lg:’ every class. Since most components don’t need too many responsive classes per breakpoint, this is a net benefit most of the time (and nothing is stopping devs from combining utility classes and custom css with media queries). Like GP said, this kind of specificity is impossible in inline styles altogether…

The clamp() CSS function (and auto-adapting grids) can reduce media query usage to a really loooow minimum. Nowadays I use media queries only for mobile nav and maybe layout grid adaptation. Like 2 to 4-5 media queries per project maximum. I think that's what the comment you're responding to meant.

[deleted]

Re: Tailwind CSS v4.0 Beta 1

#96

Post by [deleted] »

that_guy_iain wrote: post #23
ripley12 wrote: post #15

Earlier quoted context omitted.

1. Tailwind is just 1 part of a build system, and it all adds up 2. Watch Inventing on Principle if you haven't already. Pushing build times into milliseconds or sub-milliseconds enables new capabilities

If you want to try new things out and move fast with your CSS, you're not building the entire system. It's a partial build and that was already faster than you would even be able to react. Your browser refreshing would take longer.

[deleted]

Re: Tailwind CSS v4.0 Beta 1

#97

Post by seanwilson »

chrismorgan wrote: post #60
atsjie wrote: post #6

They are switching from sRGB to OKLCH. First time I heard of OKLCH tbh. Anyone know if that is part of a wider adoption trend or is Tailwind pioneering here? Looking at the examples it does seem to offer some advantages; but was primarily surprised that they now use it as a default.

Oklch is a polar colour space corresponding to the rectangular Oklab, designed as a perceptual colour space, matching how people see things, rather than how display technology works. There are three things to consider here: 1. Colour interpolation , as used in things like linear-gradient() and color-mix(). The default of sRGB is not particularly good; choosing Oklab or Oklch instead will normally improve things. Oklc…

Any thoughts on what color space you'd prefer to use? I'm working on a Tailwind palette creator (https://www.inclusivecolors.com/, it's based around letting you visualise the curves you mentioned), which uses HSLuv right now to avoid problem 2 in your list. HSLuv has perceptual uniformity as well (which is great at helping you pick colors that contrast) but it doesn't support P3 unfortunately, similar to Google's HCT color space.

I'm not seeing much demand for P3 at the moment though. Most designers I've spoke to don't know it exists.

Re: Tailwind CSS v4.0 Beta 1

#98

Post by renerick »

After some experimenting I found that Tailwind works best with hybrid approach. The essay[1] is correct, that often you have one-of-a-kind blocks, like headers, footers, etc. that you can just fully implement with TW utilities, reducing cognitive load for class naming and structuring. But for more reusable elements, like buttons, links, inputs, popups, it's just much nicer to have them (and their variations) behind simple `btn btn-blue btn-small`. Even when using component-based approach, it's just much simpler to manage all those various states as explicit classes, rather than re-implementing CSS cascade in JS to determine how to combine corresponding TW utilities. I feel like if Tailwind Labs would be less radical in their marketing strategy, it'd receive a bit less of a backlash. Maybe :)

And I do agree, that moving to better integration with native CSS is a step in the right direction, very curious about future of v4

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

Re: Tailwind CSS v4.0 Beta 1

#99

Post by thiht »

emmacharp wrote: post #92

I invite (for fun and learning!) anyone here still thinking native CSS provides no efficient solution to the problems Tailwind may have solved 5 years ago to challenge me: Bring up any said problem and I'll give you an efficient, robust, fast, simple and maintainable way to solve it in pure, native CSS (maybe even with further advantages!). The time has come to embrace good ol' CSS again! Heheh.

I'm a new user of Tailwind, but there are 5 points where I believe Tailwind is wayyy more efficient than CSS:

- layout: flex and grid are great solutions, Tailwind just makes them extremely easy to use. Flex and grid are barely unusable without first defining at least 4 or 5 helper classes, more likely a dozen. Tailwind just provides them and makes them easy to use. I never could remember the flex properties, I learned the Tailwind classes I needed in like half a day of practice

- mobile first design: Tailwind strongly encourages mobile first design if you want to do responsive design. It scared me at first because media queries are hard to manipulate in CSS. I've never made a responsive design page faster than with Tailwind, it's insane how easy it is

- dark mode: as simple as `dark:xxx`. The default and dark properties being close together is awesome. As with responsive design, Tailwind prefixes make it so easy to do what's painful in plain CSS

- defaults: having sane, overridable defaults for everything (sizes, colors, whatever) makes the code infinitely more consistent. You barely even need to think about real values, just how it looks, and you have less risk of defining slightly different classes for no reason

- no cascading: CSS cascading makes it hard to reason about styles, and easy to break unrelated components by mistake. It's solved with CSS modules (or even with BEM), but Tailwind just eliminates the problem

CSS has the solutions, it just doesn't make them easy to use.

Re: Tailwind CSS v4.0 Beta 1

#100

Post by notRobot »

yieldcrv wrote: post #28
notRobot wrote: post #26

I've never had as much fun doing front-end web stuff as I've had since I've picked up tailwind.

this is the honeymoon phase, wait until your package manager and transpiler is out of date, and your progressive web app framework is out of date, and your typescript version isnt compatible with the upgrade yet, and tailwinds isnt either or it is but none of the documentation is yet, but you have to upgrade because your CI/CD cant run your version of node anymore and now you have 100 flags across 5 configuration fil…

I've been using it for a long time now and the honeymoon period hasn't ended. I do understand what you're saying, but luckily I keep it pretty simple with a standalone tw executable and no node.js or complicated frameworks, so I have been able to avoid these pitfalls.

https://tailwindcss.com/blog/standalone-cli

Post reply on HN