3 ms·

I can see this argument both ways. On the one hand, logically you'd expect the last assignment to take precedence, like the style attribute. On the other, confl

I can see this argument both ways. On the one hand, logically you'd expect the last assignment to take precedence, like the style attribute. On the other, conflicting styles don't make sense. The random outcome, entirely dependent on the Tailwind generation internals, is the worst of all worlds though, it's just an unfortunate side-effect of relying on cascading sheets to drive atomic styles.

yurishimo 2mo ago
It’s random sure, but it’s also reliably random. This is one of the few footguns that exist in tailwind and luckily it’s super easy to catch. The IDE plugins will give you a warning if you apply multiple classes that manipulate the same attribute and there is no reason you also can’t catch it in CI. Is it ideal? I guess not, but there are a lot of weird gotchas and footguns in CSS too. Just because they’re in the language doesn’t make them magically more or less of a problem. For a similar weird mental shift, consider adding @starting-style and the native popover open attribute. All the good tutorials online have a warning about cascade order because as a human reading it, it can seem wrong or backwards. Kevin Powell’s most recent video about animating display: none covers it if you want a concrete example.
andrewingram 2mo ago
> conflicting styles don't make sense Sometimes true, but one issue here is that because Tailwind utility classes vary from being a 1:1 mapping to a single underlying style rule, to mapping to several, it's not always obvious which classes will conflict.
9dev 2mo ago
Note that we're talking about an edge case for an authoring error - applying two conflicting styles to an element does not make sense, it has no defined behaviour, and is correctly flagged by linting tools as such. Should Tailwind really go out of its way to pay a compile time tax, just to make this case resolve predictably? Or should people rather use code editors that point out invalid duplicated styles, which are always added in error?

yurishimo 2mo ago

It’s random sure, but it’s also reliably random. This is one of the few footguns that exist in tailwind and luckily it’s super easy to catch. The IDE plugins will give you a warning if you apply multiple classes that manipulate the same attribute and there is no reason you also can’t catch it in CI. Is it ideal? I guess not, but there are a lot of weird gotchas and footguns in CSS too. Just because they’re in the language doesn’t make them magically more or less of a problem. For a similar weird mental shift, consider adding @starting-style and the native popover open attribute. All the good tutorials online have a warning about cascade order because as a human reading it, it can seem wrong or backwards. Kevin Powell’s most recent video about animating display: none covers it if you want a concrete example.

andrewingram 2mo ago

> conflicting styles don't make sense Sometimes true, but one issue here is that because Tailwind utility classes vary from being a 1:1 mapping to a single underlying style rule, to mapping to several, it's not always obvious which classes will conflict.

9dev 2mo ago

Note that we're talking about an edge case for an authoring error - applying two conflicting styles to an element does not make sense, it has no defined behaviour, and is correctly flagged by linting tools as such. Should Tailwind really go out of its way to pay a compile time tax, just to make this case resolve predictably? Or should people rather use code editors that point out invalid duplicated styles, which are always added in error?