How ?

if you want to do padding on the left when it is ltr :
class = ltr:pl-8
and padding on the right when it is rtl :
class = rtl:pr-8

@20lives Thanks.

These packages are great thanks for them.

you can use L as Logic in first of all these names for example

lpi -> padding-inline
lpis -> padding-inline-start
lpie -> padding-inline-end

lpb -> padding-block
lpbs -> padding-block-start
lpbe -> padding-block-end

even can disable it as default and just user that need, enable it

Thanks! My favorite here, because I'm supporting up to some older browsers is the tailwind-dir lib. But would be nicer if rtl and ltr detection was abstracted and we can just do ps for padding-left when ltr and padding-right when rtl.

I’ve been working on this lately for a plugin I’m building, here’s a comparison of the naming conventions of the two major "CSS logical properties and values" plugins, vs. Tailwind (note tailwindcss-rtl is from @20lives who mentioned it a few messages ago):

To summarise:

• RTL-only tailwindcss-rtl uses s (start) in place of l (left), e (end) in place of r (right).
• Since tailwindcss-logical supports logical properties and values for everything, it uses is (inline-start) and ie (inline-end) to avoid ambiguities.
• border-radius utilities follow a different pattern, since the CSS properties follow a different pattern (border-start-start-radius, doesn’t mention which start is block and which is inline).

Other utilities

There are other properties worth being aware of, but I believe they set the same values left and right, so wouldn’t necessarily need a "logical properties and values" equivalent for RTL support:

To summarise:

• The x is replaced by i (inline), to match the CSS terminology.
• tailwindcss-logical uses li for e.g. mli-0 / margin-inline, because it also supports margin-block. Using mi and mb would conflict with margin-bottom – so mlb, mli.

Float is absent from this list because browser support for the inline-start and end values is very poor. It would be straightforward to add them further down the line though. tailwindcss-rtl has a float plugin, which uses physical properties and [dir] attribute selectors.

Back to Tailwind

Back to Tailwind’s potential support for this – to me the first question should be whether to aim for RTL mirroring support only, or RTL and TTB (Top-To-Bottom – occasionally used in Traditional Chinese, Simplified Chinese, Japanese, Korean). I have yet to actually see people out there trying to have the same UI component / page layout work across LTR, RTL, TTB, but I guess that’s technically possible.

Full logical properties support would require more sweeping changes, because the x and y utilities would also need their i and b equivalents – which is where the biggest conflict arises (b for block vs bottom). Or alternatively, retain the existing x and y utility names, but use logical properties under the hood (so pb keeps on being padding-bottom, and it’s py that becomes padding-block.

Or go with RTL support only, which has no conflicts.

Browser support

Just a note on this since it’s definitely still a concern – most properties from this list have good support from Safari 12.1 onwards. There are four notable exceptions only supported in very recent browsers:

• left / right positioning – Safari 14.1 2021-04-26 and up
• border-radius – Safari 15 (2021-09-21) and up
• scroll-margin – Safari 14.1 (2021-04-26) and up
• scroll-padding – Safari 15, 2021-09-21 and up
• (and float and clear only work in Firefox)

I’ve just updated the table above to note text-end and text-start will be a thing in the next version of Tailwind according to the CHANGELOG. Also should mention I’d happily make a PR for some or all of the above if there’s agreement on what to do!

Depends a bit on how much use users care about a breaking change. Here are my two cents:

1. Breaking change - v4

pb-1  //padding-block: 1
p-bottom-1  //padding-bottom: 1
 
py-1  //padding-block: 1
//remove shorthand alternative for padding-top: 1; padding-bottom: 1;

2. Non-breaking - v3.x (just adding block and inline to everything)

pb-1  //padding-bottom: 1
p-block-e-1  //padding-block-end: 1

py-1  //padding-top: 1; padding-bottom: 1;
p-block-1 //padding-block-1

In a perfect world I'd like the #1 solution but I suspect there are a lot of Tailwind users that don't want to migrate their codebases because of a breaking change that doesn't result in anything more meaningful than logical props.

What's the thought process here? Are you even considering breaking changes or trying to work around it?

Great to see movement on this :)

Also worth mentioning that translate / transform values are physical in nature and would benefit from an abstraction to make them work like logical values, though that’s not a thing even in CSS itself (w3c/csswg-drafts#1544) so I appreciate this might not feel relevant at all for the time being.

Reading your PR, the padding-inline and margin-inline properties (similar to px-* or mx-*, but also work with vertical text-orientation) haven't been included. Would it make sense to include those as pi-* and mi-* ?

This worked for us #5792 (comment)