Support for missing logical properties padding-inline & margin-inline

[alexismo]

Per #10166, logical property support for padding and margin has been added.
Support for the properties padding-inline and margin-inline properties (similar to px-* or mx-*, but also work with vertical writing-mode) haven't been included. Would it make sense to include those as pi-* and mi-* ?

New class	Properties	Physical counterpart (LTR)
pi-*	padding-inline	padding-right + padding-left
mi-*	margin-inline	margin-right + margin-left

padding-block and margin-block as pb-* and mb-* would conflict with existing properties. Without wanting to go down that path, they could be pbl-* and mbl-*.

[adamwathan]

Hey! Can you share an example of something you are building where you needed to use padding-inline over the existing px-* utilities?

[alexismo]

The px-* utilities do the job just fine for most usecases, the same way pl-* and pr-* do, yet ps-* and pe-* exist. padding-inline is nice to use because it is a single css property which achieves the same result without generating 2 properties in output code. Not having full logical property support in Tailwind causes disjointed expectations.

pi-*/mi-* would enable usecases where pages go from horizontal to vertical writing modes with a class single declaration.

[adamwathan]

Yeah that's what I'm wondering — are you working on a site where pages need to adapt between horizontal and vertical writing modes? I've been looking for an example of this forever but still haven't met anyone who has built one of those sites.

[alexismo]

Not a site I'm actively working on, but padding-inline / pi-* could have been used here: https://21.ixda.org/ on the main navigation which is presented vertically on desktop and horizontally on mobile.

[dgonzalezr]

@adamwathan Perhaps we can think of the projects that build components library with Tailwind (for a Design System for example) where, usually, it is unknown where the components will be used, and in which context. Adding support for all the missing logical properties will reduce the hassle of writing custom utilities or styles to guarantee that the components get adapted accordingly.

[ngdangtu-vn]

I think we can use other letter such as:

• block → vertical
• inline → horizontal

I understand the block and inline was meant for text direction but since we don't have any letter left and have 3 letters constantly appear in the view could be an sore eyes problems.

• padding-inline → ph vs pi
• padding-block → pv vs pbl

But this is still not cover the case where we want to use start and end conditions. And since these logical properties were made for relieve the pain on replying @media. I suggest we should replace pt, pr, pb and pl with block-start, inline-end, block-end and inline-start by set true on a tailwind config useLogicPropertyInstead. It will be super helpful for the old site want to do migration to support different language. What do you guy think?

[alexismo]

The logical properties block and inline are specifically designed to to orientation-agnostic. Calling them vertical and horizontal defeats that purpose.

In my opinion,
i for inline,
bl for block
are acceptable abbreviations. I'm open to alternatives, but let's at least try to respect the intent of the original CSS properties.

[ngdangtu-vn]

Are you the type who only read the first 6 lines and start to comment?

What about these?

And since these logical properties were made for relieve the pain on replying @media. I suggest we should replace pt, pr, pb and pl with block-start, inline-end, block-end and inline-start by set true on a tailwind config useLogicPropertyInstead. It will be super helpful for the old site want to do migration to support different language.