Tailwindcss: [Feature Proposal] Support CSS Logical Properties

[simonhermann]

Directions like right, left, bottom, top, used in properties like margin, padding or border only make sense in left-to-right + top-to-bottom (horizontal-tb) writing mode.

Now we have new way of writing these, independently of writing mode.

Quote from caniuse.com:

Logical properties and values provide control of layout through logical, rather than physical, direction and dimension mappings. These properties are writing-mode relative equivalents of their corresponding physical properties.

The logical directions become more and more common, for example are they used with flexbox or grid, so applying them to all CSS properties totally makes sense and will surely become the new standard.

Details how it works can be found in the W3 Spec.

TLDR:
vertical direction = inline flow
horizontal direction = block flow
start = where you start writing
end = where you end writing

so in default writing mode horizontal-tb:

text-align: left; becomes text-align: start;
float: right; becomes text-align: end;
margin-right becomes margin-inline-end
padding-top becomes padding-inline-start
border-bottom becomes border-block-start
and so on.

Following the tailwind naming scheme, the functional tailwind classes could be:

m{i|b}{s|e}-{size} --> e.g. mis-1 (better known as ml-1)

text-{i|b}{s|e} or text-{inline|block}-{start|end} 🤔

Since this is not as intuitive to many users I and and the physical directions are not going to be depreciated soon, guess these just be an additional set of classes instead of replacing the current ones.

What do you think?

[hacknug]

Please! Agree this is is something core should do something about. I vaguely mentioned it in #807 and #876. Interested on reading everyone else's thoughts on this (especially, people building things for non ltr-ttb languages).

[tlgreg]

I had almost the same naming convention with a plugin experiment I had. The only issue with it is the vertical margin/padding which would be the same as the bottom margin/padding. mb-{size}
I eventually went with two letters for the short form of the axes (bl and il).

There is also a conflict with insets, as from v1 there is an actual inset class, there is no difference in naming with logical/physical dimensions.

[Moeriki]

Two more options to avoid conflicting margin-bottom and margin-block acronyms.

Revert the acronym. 🚀

• im: Inline Margin
• ism: Inline Start Margin
• iem: Inline End Margin
• bm: Block Margin
• bsm: Block Start Margin
• bem: Block End Margin

Prefix with l for logical. 🎉

• lmi: Logical Margin Inline
• lmis: Logical Margin Inline Start
• lmie: Logical Margin Inline End
• lmb: Logical Margin Block
• lmbs: Logical Margin Block Start
• lmbe: Logical Margin Block End

[adamwathan]

I'd rather this be developed as a plugin first and if it gets enough traction we can explore adding it to core. Hopefully by then the Chromium version of Edge will have replaced the current version so the browser support will be better as well.

[omarkhatibco]

Hi eveyone,

as Adam (@adamwathan) recommended I made this proposal as a plugin, your feedback and review is appreciated!

Github - NPM

I tried to explain everything in the documentation.