Add logical properties support for inline direction

[adamwathan]

This PR introduces support for logical properties in the inline direction for all relevant existing utilities, making it easier to build sites that support LTR and RTL layouts without having to use the rtl: variant when you simply need to mirror the styles.

New class	Properties	Physical counterpart (LTR)
start-*	inset-inline-start	left-*
end-*	inset-inline-end	right-*
ms-*	margin-inline-start	ml-*
me-*	margin-inline-end	mr-*
ps-*	padding-inline-start	pl-*
pe-*	padding-inline-end	pr-*
rounded-s-*	border-start-start-radius border-end-start-radius	rounded-l-*
rounded-e-*	border-start-end-radius border-end-end-radius	rounded-l-*
rounded-ss-*	border-start-start-radius	rounded-tl-*
rounded-se-*	border-start-end-radius	rounded-tr-*
rounded-ee-*	border-end-end-radius	rounded-br-*
rounded-es-*	border-end-start-radius	rounded-bl-*
border-s-*	border-inline-start-width	border-l-*
border-e-*	border-inline-end-width	border-r-*
border-s-*	border-inline-start-color	border-l-*
border-e-*	border-inline-end-color	border-r-*
scroll-ms-*	scroll-margin-inline-start	scroll-ml-*
scroll-me-*	scroll-margin-inline-end	scroll-mr-*
scroll-ps-*	scroll-padding-inline-start	scroll-pl-*
scroll-pe-*	scroll-padding-inline-end	scroll-pr-*

Considerations

This PR is limited to supporting the inline direction only, as supporting the block direction introduces potential naming collisions that make the API design more challenging, for example is mb-2 for margin-bottom or margin-block?

After a bunch of research and talking to people in the community, I'm convinced that in practice supporting the block direction has far fewer benefits than supporting the inline direction, so I've opted to support just the inline direction for now to avoid being blocked on the API and get this feature shipped so people can start benefitting from it today. We can always introduce support for the block direction separately in the future — no need for them to be introduced together and slow down the process.

Right now we are using the shortest names possible like ps-* but if we eventually add block support and feel like that's too ambiguous, we can always support a more verbose version like p-is-* so that the block direction equivalent can be p-bs-*. My gut is that the block direction stuff will be needed so infrequently that simply making the block direction more verbose and keeping the inline ones terse is actually going to be the better trade-off though.

This PR does not include support for the logical values of clear or float, as browser support is currently poor. We can of course revisit this in the future and add them another day when support is better.

[salzhrani]

For projects that use the existing plugin, it would be nice if there is syntax compatibility

[myeljoud]

Great to see this, it was a bit of a challenge to support RTL

[adamwathan]

Note for future Adam, maybe go with start-0 and end-0 instead of inset-s/e-0?

[crswll]

Cross referencing and wanted to point these out just in case.

• https://stevecochrane.github.io/tailwindcss-logical/#divide-width
• https://stevecochrane.github.io/tailwindcss-logical/#space-between

[thibaudcolas]

Woo! This doesn’t include documentation changes so the only thing I’m left wondering is how the still-recent browser support for this will be stated in the documentation. I see :focus-visible gets a special mention, it might make sense for logical properties and values to get the same treatment.

And again on browser support – worth mentioning flow-relative float and clear are apparently getting support in Safari TP 158 (caveat: this is only based on MDN’s browser feature detection, there is no mention in the TP 158 release notes). That’s a very positive sign considering Chrome already has this behind a feature flag. So this could be worth revisiting in 6-12 months assuming this ships to Safari stable.

[adamwathan]

Note to self — merge oxide into master and rebase before merging this, and consider implementing divide-x and space-x using inline-start only when running the oxide engine, since it's a breaking change.

[ivanchenhz]

Cool, 👍

I was just reading this: https://rtlstyling.com/posts/rtl-styling#css-logical-properties And realise how convenient these properties could be,

I think we are going to use text-start, ms-, ps- ... It would be better if space-x- also support RTL, And if translate-x- ( that would be great 😄 )

Please release it ( We are going to support RLT, very soon, thanks )

[adamwathan]

Pushed a change that also uses logical properties for space-x-* and divide-x-* when using the new experimental Oxide engine, which we intend to be a preview release for v4 which will ship sometime later this year.

I deleted the previous oxide.test.js file because it was just a copy of our kitchen sink test, and the kitchen sink test already tests against both engines. This way oxide.test.js can be specifically for differences in behavior between the two engines, which will be a helpful way for us to keep track of small breaking changes like this one.

[LexSwed]

My gut is that the block direction stuff will be needed so infrequently that simply making the block direction more verbose and keeping the inline ones terse is actually going to be the better trade-off though

Any chance this can be configurable? I understand the purpose of backward compatibility, but I wish my teams to use logical CSS properties always, unless, in some weird rare cases they need non-logical ones.

Edit: I think I might achieve it through custom plugin, disabling the core one to avoid both properties set. I think mb case is interesting, as I expect devs to keep reading it as margin-bottom, but with logical properties, margin-block might fit better. Then, it should be mbe-2 to replace mb-2 🤔

[ivanchenhz]

@RobinMalfait Hey Robin, any chance we could release this soon ( like in a week ? )

We are working on the coding rules for supporting RTL, this feature would definitely help 👍

[ws-rush]

Thank you Adam for this I wrote plugin today to support this, I found tailwind-logical is confusing when using pis- so I start one, I used ph (head) and pf (foot) for for padding-block-{start,end} I dont think this great but for me it is less confusing than use pis and pbs

finally, I wish to see px and py to use padding-inline: value padding-block: value directly instead of padding-right: value; padding-left: value;

[irajsuhail]

Thank you for adding this ❤️

Hey @RobinMalfait. Do you have any update on when this will be released?

[ivanchenhz]

Thanks for all the cool stuffs 👍

And for those who also waiting for this to be released 😂, Here is our short term workaround:

    plugin(function ({ matchUtilities, theme }) {
      matchUtilities(
        {
          ms: (value) => ({
            'margin-inline-start': value,
          }),
          me: (value) => ({
            'margin-inline-end': value,
          }),
          ps: (value) => ({
            'padding-inline-start': value,
          }),
          pe: (value) => ({
            'padding-inline-end': value,
          }),
          start: (value) => ({
            'inset-inline-start': value,
          }),
          end: (value) => ({
            'inset-inline-end': value,
          }),
        },
        { values: theme('spacing') }
     );
    }),

For space-x, I also tried to put it here; but:

• It would generate both the 'margin-left' & 'margin-inline-start' style ( which actually not a big deal )
• And it somehow breaking the arbitrary value feature like space-x-[3px] ( not sure why ... )

[kentcdodds]

I've been unable to find docs for this feature and I'm not getting autocomplete for it either with the vscode extension. GitHub is saying this PR first appeared in v3.2.5 (I'm on 3.2.7). Has this not actually been released yet?

[RobinMalfait]

Hey @kentcdodds, indeed the feature is not yet released (https://github.com/tailwindlabs/tailwindcss/blob/master/CHANGELOG.md#added) you could play with the insiders version if you want to play with it:

npm install tailwindcss@insiders

[JRFiorini]

How about using k or bl for block? So it would be pk-1 or pbl-1 for padding block, and pks-1 or pbls-1 for padding block start. I think I would prefer k over bl. Right now there are some places where they wouldn't be conflict for using b for block, but it could create confusion on whether the b is bottom or block though.

I'm not really a fan of pis or pie for inline start and end, but I suppose if block is going to get the same thing it makes sense.

[LexSwed]

I wonder what are the use cases to prefer padding-left over padding-inline-start? I think pl should still make sense for RTL language natives as well? Same for pt and padding-block-start. Ideally, I could see it being enabled for path:

config: {
  cssLogicalProperties: {
    'src/pages/[id]': true
  }
}

I understand it's too much effort, but we, as a community should be moving to a better inclusive technology. Even if many US start-ups don't care about RTL languages, they might eventually, with 0 cost, if started right.

[brandonmcconnell]

I think just prefixing the s/e with b would be a simple and recognizable implementation, so…

New class	Properties	Physical counterpart (LTR)
block-start-*	inset-block-start	top-*
block-end-*	inset-block-end	bottom-*
mbs-*	margin-block-start	mt-*
mbe-*	margin-block-end	mb-*
pbs-*	padding-block-start	pt-*
pbe-*	padding-block-end	pb-*
rounded-bs-*	border-start-start-radius border-end-start-radius	rounded-t-*
rounded-be-*	border-start-end-radius border-end-end-radius	rounded-t-*
rounded-bss-*	border-start-start-radius	rounded-tl-*
rounded-bse-*	border-start-end-radius	rounded-tr-*
rounded-ebe-*	border-end-end-radius	rounded-br-*
rounded-ebs-*	border-end-start-radius	rounded-bl-*
border-bs-*	border-block-start-width	border-t-*
border-be-*	border-block-end-width	border-b-*
border-bs-*	border-block-start-color	border-t-*
border-be-*	border-block-end-color	border-b-*
scroll-mbs-*	scroll-margin-block-start	scroll-mt-*
scroll-mbe-*	scroll-margin-block-end	scroll-mb-*
scroll-pbs-*	scroll-padding-block-start	scroll-pt-*
scroll-pbe-*	scroll-padding-block-end	scroll-pb-*

I think that should be naming collision-free, but if you still don't want to use b, I agree with @JRFiorini that k is a fine second choice as well.

[thibaudcolas]

👋 browser support now feels good enough for flow-relative float and clear. I’ve opened #12469 to request support in Tailwind.

[alexismo]

The 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

Update: Here's a discussion for this topic: https://github.com/tailwindlabs/tailwindcss/discussions/13690