[Feature Proposal] CSS Logical Properties (margin-inline-start...)

[Yiddishe-Kop]

[Feature Proposal]

First of all - Thank you! Love Tailwindcss! 😍

For margin, padding, borders etc:

I think it would be great to add utilities for margin-inline-start & margin-inline-end [same for padding & borders], which will help greatly with layouts of all directions.

This approach will make building bi-directional layouts much easier, let us write less code: write only one class that will handle both directions.

Or at least can somebody point out how to add it myself, with tailwind.config.js.
Thanks!

[ahmadalfy]

You don't actually need that in Tailwind, this can be done using PostCSS plugins.

[myeljoud]

How ?

[mina-adibe]

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

[Yiddishe-Kop]

@ahmadalfy can you explain?
Why not have it built into Tailwind (just like mr-1, maybe have ms-1 for margin-inline-start), without adding another build process?

[Yiddishe-Kop]

I would even go as far to say that maybe the default ml-1 should use margin-inline-start etc., as most of the time that's what you really need.
Although there are cases when you do want to use a direction agnostic margin, most of the time you want the margins to be according to the writing direction.
Maybe there could be a way to opt out of this behaviour in the config file.
At least there should be away to extend Tailwind yourself through the config.

[20lives]

Hi, check out this plugin: tailwindcss-rtl which is probably what you are looking for.

[RaviHamidov]

@20lives Thanks.

[HapLifeMan]

@20lives love your plugin, why don't you use margin-inline-* properties?
I think that's what we're looking for, instead of prefixing every class by [dir=*] 😊

[20lives]

thank you @HapLifeMan
Logical properties only available for Padding, Margin, and Borders while we have few more utilities (floats, text alignment ...) and I guess I wanted consistency.

[HapLifeMan]

In that way, do you think it would be possible to add an option in your plugin to decide whether we want to work with parent direction or CSS logic? 😊

[20lives]

I don't really mind changing it :)

[Yiddishe-Kop]

I don't really mind changing it :)

Can I offer some help?

[MathGeniusJodie]

I would much prefer if I could use "start" and "end" instead of "right" and "left", it matches with flexbox's naming, and it doesn't assume a writing direction

[MathGeniusJodie]

tailwindcss-rtl should just be part of tailwind imo

[HapLifeMan]

@MathGeniusJodie I found tailwindcss-logical and it does the job very well!
Also using sometimes tailwindcss-dir for right-[x]/left-[x] things 😊

It's working very well without having to deal with [dir=rtl] everywhere so I'm happy with that but totally agree that Tailwind should have these utilities built-in to be RTL/LTR compatible.

[Noitidart]

These packages are great thanks for them.

[MathGeniusJodie]

logical properties are supported in edge now, so no more technical reason why this can't be done

[20lives]

@HapLifeMan @MathGeniusJodie tailwindcss-rtl already implemented logical properties (with support for legacy browsers)

[0proboy0]

+1

[mnr73]

hi.

please add CSS Logical Properties. its very useful for RTL.

you can use that in "Space Between" and "Divide" that now have problems with RTL direction.

and even add some new padding and margin class like

pi -> padding-inline
pis -> padding-inline-start
pie -> padding-inline-end

and more same classes for margin and border

it's very useful and support by all new browsers

[adamwathan]

This is something we've looked into a bunch of times but ends up being a bit more complicated than it sounds. Not closed to it, definitely will explore it again at some point.

Biggest naming challenge is is pb-4 padding bottom or padding block? So ends up really being a hard naming problem overall. I think we'll get there, but have a bunch of things to work through that are a bit higher on the list right now 👍🏻

[mnr73]

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

[thibaudcolas]

It’s pretty cool to see RTL support in Tailwind 3.0, even if experimental, but looking at the example given (ltr:ml-3 rtl:mr-3) I’ve got to say it feels strange logical properties aren’t used for this. At least with vanilla CSS, relying on this type of override feels dated now that browser support for logical properties is pretty good.

Re naming clashes – as far as I understand it’s much more common for people to create layouts that can be mirrored horizontally (RTL <-> LTR) with "inline" properties, than to create layouts that can be mirrored vertically or turned 90 degrees. So the "block" vs "bottom" clash doesn’t seem that concerning to me – since padding-block would be much rarer, it could have a longer pbl prefix.

[adamwathan]

I expect we'll revisit this one again this year for sure, last time I looked into it the browser support for certain things like inset-inline-start was quite poor, but that was in 2020 and it looks like things are much better now.

Hardest part is for sure the naming conventions, so keep sharing your suggestions, it'll be helpful to refer to when I do decide to jump on this feature again.

[Noitidart]

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.

[thibaudcolas]

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):

Tailwind CSS v3.0	tailwindcss-rtl	tailwindcss-logical
Margin
mr-0	me-0	mie-0
ml-0	ms-0	mis-0
Padding
pr-0	pe-0	pie-0
pl-0	ps-0	pis-0
Inset
right-0	end-0	inline-end-0
left-0	start-0	inline-start-0
Scroll Margin
scroll-mr-0	N/A	N/A
scroll-ml-0	N/A	N/A
Scroll Padding
scroll-pr-0	N/A	N/A
scroll-pl-0	N/A	N/A
Border Radius
rounded-r-0	rounded-e-0	rounded-ie-0
rounded-l-0	rounded-s-0	rounded-is-0
rounded-tl-0	rounded-ts-0	rounded-ss-0
rounded-tr-0	rounded-te-0	rounded-se-0
rounded-br-0	rounded-be-0	rounded-ee-0
rounded-bl-0	rounded-bs-0	rounded-es-0
Border Width
border-r-0	border-e-0	border-ie-0
border-l-0	border-s-0	border-is-0
Border Color
border-r-black	N/A	border-ie-black
border-l-black	N/A	border-is-black
Text Align
text-right (text-end in v3.1)	text-end	text-end
text-left (text-start in v3.1)	text-start	text-start

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:

Tailwind CSS v3.0	tailwindcss-rtl	tailwindcss-logical
mx-0	N/A	mli-0
px-0	N/A	pli-0
inset-0	N/A	N/A
inset-x-0	N/A	inset-inline-0
scroll-mx-0	N/A	N/A
scroll-px-0	N/A	N/A
rounded-t-0	N/A	rounded-bs-0
rounded-b-0	N/A	rounded-be-0
space-x-0	N/A	space-i-0
divide-x-0	N/A	divide-i-0
border-x-0	N/A	border-li-0
border-x-black	N/A	border-li-black

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)

[thibaudcolas]

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!

[felix-bohlin]

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?

[thibaudcolas]

Thought I’d share another approach as a plugin in case it helps others: tailwindcss-vanilla-rtl. This overrides all Tailwind core left/right utilities, so they output logical properties and values instead. The utility names are unchanged.

We put this together for a large project, choosing this approach to sidestep the naming conventions dilemma, and so people don’t have to constantly remember whether they are using Tailwind on a project that needs RTL support or not.

[adamwathan]

Just wanted to follow up again here — I really like the overall idea @thibaudcolas proposed, where we just worry about logical properties in the inline direction and ignore the block direction, since the block direction is the only place where there are naming collisions to be concerned about. This lets us make some forward progress and solve the block problem down the road if there is actually demand for it.

Going to hack on this for v3.3, probably have something people can play with in January some time 👍

[thibaudcolas]

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.

[adamwathan]

Opened a PR with support for logical properties in the inline direction:

#10166

Thanks for all the input here everyone!

[alexismo]

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-* ?

[vltansky]

Guess this discussion can be closed as v3.3 is out with logical properties support 🎉

[Yiddishe-Kop]

v3.3 is great!

Some utilities missing:
divide-s
space-s

There might be more.

[thibaudcolas]

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

[thekevdiaper]

I'm building my first project which required ltr and rtl. The in-house support in 3.4.3 is great in most areas but space-x-# still uses left / right rather than inline-start / end.

Is there an easy way to change this without having to update all of my classes?

[meirroth]

This worked for us #5792 (comment)

[miragecraft]

I suggest using k for block.

Therefore:

• margin-inline -> mi
• margin-block -> mk
• margin-inline-start -> mis
• margin-inline-end -> mie
• margin-block-start -> mks
• margin-block-end -> mke

As ms and me already exists for the inline direction, I thought about providing single letter directions for the block direction as well:

• margin-block-start -> mf (f as in "fore")
• margin-block-end -> ma (a as in "aft")

However this could create confusion when s and e are already used for both directions in class names such as rounded-ss-*, so sticking with s and e for both directions is probably for the best.