[Feature]: Attributify

[yob-yob]

Attributify A new feature coming to WindiCss that I think tailwindCSS should also have...

[tirthGajjar]

This can certainly makes things more manageable.

[woldtwerk]

Attributify improves readability so much. Tailwind markup tends to become very cluttered and hard to read.
I would love to see this feature in Tailwind

[NovusOpus]

@yob-yob @tirthGajjar @woldtwerk. Not the same as Attributify, but variant-grouping was/is in development, but comes with it's trade-offs(Bigger HTML/CSS file size in production) but still promising because of the DX(Developer Experience) side. You can Read more about it from this Tweets by @adamwathan.

So hopefully in the future we may see some short of implementation of Class Name Grouping.

[woldtwerk]

This is a different approach than windis grouping. In windi groups get compiled into normal non grouped syntax. Of course this only works if you compile your templates.
Attributify doesn't require compiling templates. That's why I had high hopes for it.

[NovusOpus]

@woldtwerk Of course it's not the same, I even stated it in my previous commend:

"Not the same as Attributify"

But it's the only approach that the Tailwind CSS Team had made public to be working on, They may be working on something or at least considering an approach like Attributify, but we don't know that yet. But even if it's not the same as Attributify at least it's something that's going to improve the DX even if they end up releasing it as a plugin for VS Code or a Tailwind CSS Plugin that generates normal non grouped syntax.

[akvadrako]

This is also supported by UnoCSS, another tailwind competitor: https://blog.logrocket.com/new-features-unocss-tailwind-css-alternative/

I'm a fan of the new attributify syntax; it makes the HTML much more readable.

[woldtwerk]

Alternatively we could compile templates with attribute syntax into regular tailwind syntax.

[pqt]

I would only (personally) accept this if it was possible to be driven via data-* attributes. Otherwise I'm certainly not opposed to this being a configurable option.

If that became the case I'd probably consider using this myself.

There is some added benefit to this being a path towards incremental adoption without conflicts (above and beyond class prefixes)

[Sweet-KK]

How long is this feature expected to be developed?

[seonglae]

Windi CSS is no more maintained

Attributify mode is a great way to attract those users

[Alexandre-Fernandez]

UnoCSS

[mybearworld]

1. This wouldn't work with JIT. One of the great things with Tailwind is how easy it is to parse (there's a page in the docs on that), and therefore how it works with every templating language. With something like that, every language would need to be parsed separately.
2. The CSS would be bigger. Compare .text-sm to [text="sm"], [text^="sm "], [text$=" sm"], [text~=" sm "]

[vadolasi]

UnoCSS does this and seems to have none of these issues

[mybearworld]

Problem 1 is very much a problem with Attributify in UnoCSS. https://unocss.dev/presets/attributify

[developomp]

Maybe we can have "ghost attributes" where tw-* attributes are first converted to tailwind classes before going through the JIT compiler.

disclaimer: I don't know how tailwind JIT works under the hood yet and am just throwing ideas.

[FrazeColder]

Push

[ryoppippi]

push

[andreibade]

PUSH

[Rocketpilot]

Well gee if you're so insistent on downvoting reasoned and non-emotive arguments, why don't you explain the benefits of this idea in an objective and rational way?

[Rocketpilot]

No thanks!

[developomp]

Mind elaborating why you are against it?

[Rocketpilot]

Well sure.

In brief: Tailwind already has an extremely straightforward way to author CSS and compose specific style patterns through class names; it might seem clunky but it's immediately obvious how it works to anyone with basic HTML and CSS under their belt. This adds an additional level of complexity to the authoring experience for what seems like minimal gain.

Tailwind is straightforward, but it's also very complex under the hood. Adding this approach will inevitably involve trade-offs that may degrade the overall experience of using the tool.

Tailwind's devs have just shipped a major change to the parser and might not have an appetite for further complexity right now.

Other devs have raised technical objections above, so let me conclude by suggesting the specific authoring experience you might want out of this would be better provided by a well-designed set of components in the templating system of choice. You potentially have the advantage of full type-safety (constraining a "fonts" prop to only offer options pre-set in configuration) if you do it right.