For example, we have a filter with checkboxes. We pass the style of the active one and then display the checkbox filling. Most of the components in Tailwind use their implementation based on JS frameworks.
Also, we will be able to change the set of classes inside the components for example we have 5 variants of a button in the form of a component for different sizes. As far as I remember now in components you can’t change the set of classes, and each variant is an additional class.
When using Tailwind, you won’t be locked in the TW mode.
You want to achieve that kind of functionality the current way, nothing changes.
Tailwind is not able to do that. There is no class chaining, etc.
If it’s a pure HTML solution, you can achieve it with TW and pseudo states natively, e.g. checkboxes, etc.
For the interactive (JS/interaction based) part, Relative Styling and Interactions is the way to go.
Hello @Mykyta,
As @Marius said, some applications will still need CSS styling that is outside the scope of Tailwind for the moment.
This will also apply to several Cwicly blocks that currently rely on multiple elements (we will bring Tailwind support to those in the future).
Cheers,
Hey @Louis.
Wouldn’t manipulating data-* attribute values via Interactions be a possibility to address the Relative Styling requirement with Tailwind - at least for a lot of basic things?
Just some thoughts for the Interactions overhaul.
You hinted that yesterday in the live, thank you for confirming here. This is great news!