Tailwindcss: Border behaviour

[lamberttraccard]

Hey,

I've got more a question than an issue about the border utilities behaviour.

<nav class="border-t-2 lg:border-t-0 lg:border-r-2 border-smoke-dark lg:border-smoke-dark"></nav>

Do I necessarily have to include the border color again for the specific screens ?

Because if I don't it shows to the default border color.

Thanks a lot.

[adamwathan]

Hey @lamberttraccard! Yeah you do need to re-specify the color, but maybe this is something we can think about improving.

Right now utilities like border-t-2 actually just set the border shorthand, like this:

border-top: 2px solid [defaultColor];

We might be able to switch to rendering each property separately to preserve the color across breakpoints; I'll just have to test it out and make sure there's no unintended consequences.

[lamberttraccard]

Thanks for enlightening me. Thought I was doing something wrong :)

[HellPat]

There shouln't be any consequences.

The only "consequence" I can think of is the discussion about filesize.

Many (older) posts on the web suggest using the shorthand syntax. e.g. https://catalin.red/css-shorthand-tips/
But I think the declaration of separate properties has only a tiny effect on file size and gzips very (very) well. So the benefits outweigh the problems introduced by this optimization by far.

Usability (DX included) > filesize

There is also an article from Harry Roberts CSS Shorthand Syntax Considered an Anti-Pattern

This is the exact case he's describing.

I'm 👍👍👍👍👍 for separating the properties.
Extra benefit. DIFFs look nicer if you made a mistake ;-)

[HellPat]

Aaah, only Problem.
This is a BC break if you defined BC as "when someone relies on a bug and we change it it's a BC" ;-)

[adamwathan]

Yeah I think it's probably best to save any changes here for 0.2.0 👍🏻 Going to mess around with it on the weekend though.

[adamwathan]

Thinking about this more and playing with it, even switching to separate properties doesn’t help here because now .sm:border-2 would just be overriding the color in a separate property instead of as part of the shorthand.

The only way I can think to resolve this is to not set a color at all when using those helpers, forcing you to specify the color with a separate utility. I don’t hate this approach but it begs the question should we be doing that for border style too? Because otherwise you’re in the same boat with border style as we are with color now, where it has to be redeclared at each breakpoint.

It doesn’t really bother me as much with border style since it’s pretty uncommon to use non-solid borders in general and even less common to tweak those types of borders responsively, so if you have to declare it again it feels like a fair trade off for making the solid border cases simpler. But either way it is a bit of an odd inconsistency.

How would people feel if there was no default border color anymore, and you always had to specify it?

So needing to do:

<div class=“border border-grey”></div>

Instead of just:

<div class=“border”></div>

I’m inclined to make this change because I feel like I’m setting the border color explicitly over 50% of the time already, but curious what others think. I’m sure there’s plenty of sites out there where almost every border is the same color and this change would be disappointing in those cases.

[LostKobrakai]

If people would set border-gray on the body, wouldn't this result in having the default color set to all borders within the page? So it's not like one would need to set it explicitly on every element with a border, but rather just explicitly set the color as default by putting the class on the body.

[tlgreg]

@LostKobrakai No, the border-color is not inherited from the parent element. It's initial value is actually the element's text color (currentColor).

https://codepen.io/tlgreg/full/bYeaxm/

[adamwathan]

So I've merged a change for 0.2.0 that fixes this, can read more about it here:

https://github.com/tailwindcss/tailwindcss/pull/116

Closing this now that a fix is merged; going to try and tag 0.2.0 this week.