.border trumps .border-[size]

[TheDutchCoder]

Howdy!

Would it be possible to have the default .border class be defined before any of the individual widths? Currently this doesn't work: <div class="border border-2"> which is unfortunate, because I dynamically insert certain classes to "override" the defaults.

I can currently get away by also dynamically assigning the default border, but I think it would be consistent to not having to do so.

Cheers!

[adamwathan]

No plans to change this behavior unfortunately as it would be quite a complex change (#1015), so instead I would recommend not adding two classes that target the same property, and only have either border or border-2 present, not both at the same time.

If you can share more about the tech you are using to build your project I'm happy to help come up with a solution for doing this that doesn't feel too cumbersome.

[TheDutchCoder]

No worries, I can make do with doing some ternary assignments in this case.

I'm running into it with some PHP templates/views where, depending on certain variables, I add classes to elements.

To give you an example:

<input class="bg-white border rounded w-full p-4 pt-6 pb-2 font-bold' . ($autoFocus ? ' border-2 border-blue-500 ' : '')

But that's easily converted to

<input class="bg-white rounded w-full p-4 pt-6 pb-2 font-bold' . ($autoFocus ? ' border-2 border-blue-500 ' : 'border')

So it was more a "cascade" question than a necessity on my end ;)

The only issue I see is when you extract a component (i.e. .input), where border is applied, which wouldn't work and makes extracting components a little less nice, because now you have to manually add border everywhere you would use the .input component.

[TheDutchCoder]

Going through #1015 I'm wondering if you couldn't just hoist the default key out of the object first and then loop through the remaining keys?

Disclaimer: I haven't looked at the source, so I'm just spit-balling.

[AlexVipond]

@TheDutchCoder Definitely possible to do that! I was giving that solution some thought, but realized that in the end it just imposes a different cascade order on the user (default always first, and after that, cascade is controlled by JavaScript weirdness) instead of allowing the user to fully control their own cascade.

It would also lead to some inconsistency with other plugins, specifically borderRadius. Right now, the default borderRadius config produces a nice, intuitive cascade where larger border radiuses (radii?) always override smaller ones, and the default rounded class falls into that order perfectly:

https://github.com/tailwindcss/tailwindcss/blob/c9bba9d1b16179b99c762e41ab84f67188aecd05/__tests__/fixtures/tailwind-output.css#L2987-L3005

If we hoist out default keys, borderWidth classes would nicely cascade from smallest to largest, but borderRadius would have a funky order.

[TheDutchCoder]

@AlexVipond I understand what you're saying. However since default is, well, the default, I would assume as a user that I could override the default with a different class from the same group.

Not trying to introduce breaking changes of course, but it would be more consistent when it comes to 'defaults' I would think.

The borderRadius one is also a bit due to the fact that it doesn't follow a (typical) default, 0, 1, 2, etc. pattern, but uses words (none, sm) instead. Changing that to how borders (and other utilities) work would make it behave the same.

Anyway, it's a bit of a minor issue, I understand, but it did throw me off quite a bit as I didn't expect the behaviour (as I find Tailwind to be extremely predictable in a very, very good way).

Food for thought! ;)