Tailwindcss: [Feature proposal] Normalize align/justify utilities

Created on 29 Apr 2020 · 2Comments · Source: tailwindlabs/tailwindcss

The align-* and justify-* related utilities currently use a short representation, e.g. items-center for align-items: center. This makes sense for flex, since you can get most things done with align-items and justify-content.

With grid being part of Tailwind now, additional align-* and justify-* properties became more prevalent. Some are missing, and some current utilities become ambiguous when filling the missing gaps. E.g. is justify-items utilities were to be added, it wouldn't be obvious anymore that items-center relate to align-items. Then there's also the place-* properties which will probably be added at some point too.

We could normalize the properties in a non-breaking way in 1.x by adding more utilities, and removing the old ones in 2.x.

| Property | Current | Future |
|--------------|--------------|--------------|
| align-items | items-* | align-items-* |
| align-content | content-* | align-content-* |
| align-self | self-* | align-self-* |
| justify-items | - | justify-items-* |
| justify-content | justify-* | justify-content-* |
| justify-self | - | justify-self-* |

Source

sebastiandedeyne

👍5

Most helpful comment

Hey @sebastiandedeyne thanks for the thoughtful proposal!

I totally see the rationale behind this idea but personally I would be more inclined to leave the existing ones unchanged, and only use the more verbose naming for the new ones to disambiguate them from the existing ones, so:

| Property | Current | Future |
|--------------|--------------|--------------|
| align-items | items-* | items-* |
| align-content | content-* | content-* |
| align-self | self-* | self-* |
| justify-items | - | justify-items-* |
| justify-content | justify-* | justify-* |
| justify-self | - | justify-self-* |

Two reasons I would prefer this approach:

It's not a breaking change. The impact and friction introduced by breaking changes are generally extremely underestimated by project maintainers and I think we should avoid breaking changes unless they fix a very painful problem that cannot otherwise be solved.
It optimizes for the common use case. Both justify-items and justify-self do nothing in Flexbox layouts, so they are inherently far less used than justify-content and the align-items/content/self properties. Trying to normalize all of the naming means we all have to type class names that are 1.5x as long for stuff we use 99% of the time just to make things feel consistent with classes we will rarely use in comparison.

I'd rather optimize for the common use case (which also has the benefit of not being a breaking change) and have people use longer class names for the less used properties personally. We made a similar decision when introducing the delay-*, duration-*, and ease-* classes, optimizing for the most common use case (transitions) with the plan to add qualified animation-delay-*, animation-duration-*, etc. classes if/when we add utilities for animation properties.

adamwathan on 29 Apr 2020

👍10

All 2 comments

Hey @sebastiandedeyne thanks for the thoughtful proposal!

Two reasons I would prefer this approach:

It's not a breaking change. The impact and friction introduced by breaking changes are generally extremely underestimated by project maintainers and I think we should avoid breaking changes unless they fix a very painful problem that cannot otherwise be solved.
It optimizes for the common use case. Both justify-items and justify-self do nothing in Flexbox layouts, so they are inherently far less used than justify-content and the align-items/content/self properties. Trying to normalize all of the naming means we all have to type class names that are 1.5x as long for stuff we use 99% of the time just to make things feel consistent with classes we will rarely use in comparison.