Use left/right instead of inline-start/end for space/divide utilities #2644
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR reverts the changes in #1883 and switches back to using left/right instead of inline-start/inline-end for the space/divide utilities. Spent literally the last 8 hours deliberating on this and working through the problem for multiple hours at a time with three trusted colleagues, so not a change I am making lightly.
The primary reason is that space-x is not a good name for a utility that adds a gap on the inline axis. The letter
x
means "horizontal", andinline-start
andinline-end
apply on the inline axis which is not always horizontal — it's only horizontal in horizontal writing modes.Switching these utilities to use these logical properties means that in vertical writing modes,
space-x
andspace-y
actually both apply along the vertical axis, which is weird and inconsistent.The better solution here is utilities like
space-i
anddivide-i
for adding space/border on the inline axis explicitly. Adding these though would increase the default file size considerably, and open the floodgates to requests for adding at a bare minimumspace-b
anddivide-b
utilities for the block axis, and likelymis-4
,pbe-6
, etc. for full-blown logical properties support.I'm not quite prepared to tackle that project yet, and it feels wrong to change the implementation of
space-x
anddivide-x
to something that no longer matches the name as a half-measure, so I've decided to keep things as is.The other reason is that this is technically a breaking change, as users building RTL sites are likely already working around the behavior this was trying to fix by adding
space-x-reverse
to their HTML. This would break those sites, which is a bit annoying even though the experience for those users would admittedly be better after they went through the upgrade process.Since I am convinced that proper logical property support is the better way to solve this problem, I'm going to avoid changing this implementation and saving that project either for later, or for the community to handle.
There are already plugins in the wild like this one that add most of these utilities:
https://github.com/stevecochrane/tailwindcss-logical
...and using Tailwind's
corePlugins
config, it is easy to disable any built-in plugins that are based on literal directions like left/right/top/bottom and use the logical property versions instead.Sorry for the back and forth on this, it's been very hard to make this decision but ultimately I think it's always better to do nothing than to do something we may regret later ❤️