Should Tailwind Adopt New CSS Features Faster?

[mdtaufiquekhan]

Nowadays, every application needs CSS. Writing raw CSS is fine, but using frameworks makes development faster. Personally, I find utility-first frameworks (like Tailwind or WindiCSS) much more practical than class-based ones (like Bootstrap).

Tailwind is my go-to framework because of its huge community and ecosystem. But there’s one drawback I keep noticing:

👉 Tailwind updates very slowly when it comes to adopting new CSS features.

Modern CSS evolves quickly—container queries, subgrid, cascade layers, new pseudo-classes, etc. Many of these are not yet in Tailwind. The common argument is that some of these features are not fully supported by all browsers.

But here’s my opinion:

• Tailwind is a CSS framework, not a browser compatibility checker.
• It should give developers the choice: either use the latest CSS or stick to stable features.
• Even experimental support (flags or plugins) would be better than waiting months or years.

Question to the community:

• Do you think Tailwind should adopt new CSS features faster?
• Or do you prefer their current “wait until safe” approach?
• How do you personally handle cases where Tailwind doesn’t yet support a new CSS feature?

Would love to hear your thoughts 👇

[wongjn]

How do you personally handle cases where Tailwind doesn’t yet support a new CSS feature?

Use @utility or @custom-variant to add aspects of any new CSS features. Or, if not possible, one can always fork the repo.

I don't have any opinion about the other questions.

[mdtaufiquekhan]

Yes, Tailwind provides @Utility and @custom-variant so developers can extend it—but at the same time, the Tailwind team encourages us to rely on existing utilities and even discourages heavy use of @apply. If developers constantly have to create custom utilities for new CSS features, we end up cluttering our configs or CSS files—defeating one of Tailwind’s main advantages: simplicity and consistency.

Also, most applications today are built for modern users with up-to-date browsers. As a CSS framework, I think Tailwind should aim to stay closely aligned with the latest CSS releases. Even if support is experimental or opt-in, having first-class utilities for modern CSS would give developers the choice, instead of pushing everyone to reinvent the wheel with custom utilities.

[rozsazoltan]

I don't think you need so many utilities or custom variants in a single project that you can't keep track of them. If that's the case, you can split them up to separate files too.

[rozsazoltan]

It depends on your project how large an audience you want to attract. Especially for legacy or corporate projects, it's not advisable to limit the project exclusively to the latest modern versions. You could lose potential buyers, clients, or users just because the site looks broken or doesn't display as it should.

Similar problems arose when v4 was introduced, where many features already available in Baseline 2023 required fallback values to ensure the content remained readable, even if not perfect. For example:

• Improve compatibility with Safari 15 #17435

Now, we could say that everyone should just use the latest versions, and that would be great - I'd like that too - but if they don't, there's nothing you can do about it.

If TailwindCSS offers utilities for many new functions by default, developers won't always know which utilities work properly with which baselines. And for TailwindCSS browser support, you could only write "latest versions", which is a very strict requirement.

For example, light-dark() is a very nice CSS function, but it comes with minimum requirements - you either live with them and accept them, or you don't.

• How can I safely introduce the use of light-dark() without increasing the minimum browser version requirement?
• How to use custom color themes in TailwindCSS v4 (Solution 2: light-dark() and Alternative)
• How to use custom color themes in TailwindCSS v4 (Solution 3: extended var(--tw-light, ...) var(--tw-dark, ...))

Then there's anchor positioning, which is in a Limited status because Firefox doesn't support it, and Safari requires at least the latest version. That's quite strict. You can use it and add support manually, but for most projects and developers, that's not acceptable. In a few years, it might become part of Baseline 2025-26, and in 4-5 years, anchor usage may become standard enough that TailwindCSS will ship default utilities for it. Until then, it's a future feature, but you can supplement it manually if you accept its limitations. See more:

• How to make a pseudo-element span full width of grid container but align with specific grid item in Tailwind CSS?

By the way, I'm working on a baseline-based plugin where I ship my own utilities tailored to specific baselines, so you can immediately load many new utilities for personal use while maintaining compatibility with the chosen baseline. This is still a work in progress.

Some related:

• Add min-size-[...] & max-size-[...] too #18589 (comment)
• https://play.tailwindcss.com/2yoeWyjHxu?file=css
• https://play.tailwindcss.com/QWAfIT1CsM
• Additional SVG properties #6089 (comment)
• etc.

[rozsazoltan]

Do you think Tailwind should adopt new CSS features faster?

I think GitHub Discussions and Stack Overflow are the two best places to discover or discuss these new utilities. There's no need to implement them into the TailwindCSS system - thanks to functional utilities, you can immediately use them alongside TailwindCSS's default utilities in your project. I believe it's best if the default utilities rely on widely supported, well-documented CSS properties rather than properties that are experimental or just recently introduced.

Or do you prefer their current "wait until safe" approach?

I wouldn't make such utilities available by default until they are not "safe", meaning they should fall within or below the minimum baseline of the given TailwindCSS version to be considered reliable. Otherwise, I always think it's important to highlight the risk of raising the minimum browser version - which, by the way, is also noted by the developers in the docs under the browser support section.

Developers are generally not fully aware of their latest minimum browser versions; they use autoprefixer or similar plugins to specify what they want to support. LightningCSS - which v4 relies on - also has this functionality.

How do you personally handle cases where Tailwind doesn’t yet support a new CSS feature?

Same: #18925 (comment)

[mdtaufiquekhan]

First of all, thanks for sharing that example — it’s really amazing, especially this one: https://play.tailwindcss.com/QWAfIT1CsM.

I understand that adopting every new CSS feature right away could create confusion between developers and end users, especially with browser compatibility. But still, I feel that as a CSS framework, Tailwind should aim to support all new CSS features as they are released.

Of course, I also understand that not every developer (including myself) always knows which features are supported in which browser versions. That part is tricky. But I think the framework could still expose these features, maybe with clear documentation or experimental flags, so developers can decide whether to use them or not.

But your point is valid.

[philipp-spiess]

@mdtaufiquekhan Hey! Thanks for this writeup.

I do agree that there's certainly features that we are missing (e.g. anchor positioning was called out specifically) however the features you mentioned in your initial message are, in fact, already in Tailwind CSS. So just for reference:

container queries, subgrid, cascade layers, new pseudo-classes, etc. Many of these are not yet in Tailwind.

• https://tailwindcss.com/docs/responsive-design#container-queries
• https://tailwindcss.com/docs/grid-template-rows#implementing-a-subgrid
• https://github.com/tailwindlabs/tailwindcss/blob/main/CHANGELOG.md#added-6
• @layer in Tailwind CSS is using native cascade layers as of v4.

[mdtaufiquekhan]

Okay, I totally missed that—my bad 😅. I’m still pretty new to Tailwind, but in just a week I’ve already fallen in love with it, especially because of the JIT compiler—it’s really awesome.

Over the past few days, I’ve been reading lots of discussions and articles about Tailwind. At least one feature I really wish existed is grouping for pseudo-elements. I even started a discussion about it, but later (thanks to @rozsazoltan) I realized it was actually a duplicate of this one:
👉 #8337

I do understand there might be challenges with compiling classes that come from programming languages, but this feature would be super useful for many of us.

My main concern is just that the acceptance of new classes/features sometimes feels a bit slow in Tailwind.

Thank you so much for taking the time to reply 🙏.