They are just better than their non-logical counterparts. Because:
- They are more, ahem, logical. They make CSS into a more coherent and interrelated system that is easier to learn and reason about.
- They ready websites for language translation.
So since they are better and support is green across the board, why aren’t they taking over all usage?
- Old dog; new tricks. — People gotta know about them and understand them. Then come to their own conclusion that they are better.
- Legacy projects. — Most people work on old/existing things. Changing all these properties over at once doesn’t feel like a particularly good use of time on most projects. That work will be error-prone. The alternative to an all-at-once move is to slowly move usage. That puts you in a tweener stage of using both syntaxes, which feels sloppy and extra error-prone, because the properties aren’t one-to-one (e.g.
margin-inline-endwill overridemargin-rightin LTR, but as soon as you’re in RTL, they become different). - Conflicts feel weird. — A property like
padding-inlinedoesn’t exist in non-logical-land. So will the value set inpadding-inlineoverride apadding-left, say? Or willpadding-leftwin over what is happening inpadding-inline? I don’t know, lemme test… it appears that whichever is declared later in a block wins. I guess that makes sense in the same waypaddingwould overridepadding-left, it just feels weird as they aren’t one-to-one. I suppose, like logical properties themselves, you just have to wrap your mind around how it works: if a non-logical and a logical property currently affect the same thing, it’s a specificity (including source order) game. - The rollout doesn’t feel totally done. — Not all directional things in CSS are ready. For example, you might be setting a gradient in which to set text over top of, but directional linear gradients don’t have any logical values yet, it’s still
to leftandto bottomand all that still. Jeremey noted several more:translateis still an X/Y thing.getBoundingClientRect()doesn’t return logical properties.aspect-ratiois width/height not inline/block.- … and also that you can’t use a lot of comfortable shorthand because they map to non-logical values.
I don’t know that I have any killer advice here. I know that my own brain has done OK in flipping modes and making me think in logical properties now. And yet, I don’t have any production sites that are 100% logical properties. Despite it feeling weird to have tweener CSS, that’s probably reality for some years. Except for sites that are heavily translated — all y’all should be all-in.
No4 for me, Chris. The benefits aren’t immediately tangible in existing projects were things already ‘work’ but the problems of them not being fully supported are.
In a couple of years, I’m my world at least, they will have taken over though as new components replace existing.
Yeah it is sad no one uses them, that I know.
I personally do try to use them as much as possible.
And also I don’t understand why people use rtlcss or other tools,
if 90% kan be fixed with just pure CSS and the rest with some checks if the dir is set.
If I would work on an internationalproject with the need for RTL-languages I would definitely consider swithcing to logical properties. But I don’t and probably never will. So why should I use them?
Sometimes I use margin-inline: auto because it is handy. But that’s all.
Being new is no qualification, there should be a need.
Just because you don’t offer translation as a feature that you built into your website doesn’t mean people that read RTL languages don’t translate your website with their own tool.
Do you (anyone) have reliable data about these scenarios? May be hard to come by, but would help any professional and business case around logical properties.
Also, doesn’t this look like a tool issue, or one that can be solved on a tool level? A translation tool that changes website directionality could as well overwrite any “non-logical” declarations. (Not trivial, but possible.) That would lead to a better user experience—and would actually be scalable.
Personally, I wish only a fraction of the attention that logical properties get would go towards conformant output.
Jens agreeing with Jens. There seems to be no need for logical properties outside of projects that are multi-directional. With a large portion of our field that never works on a single one of them, knowing logical properties exist is probably enough for most web developers.
We have a bigger problem right now with posts not being clear about this.
The pushback on this is AMAZING to me.
People translate websites on their own. They need information off a website that isn’t in the language they know, so they translate it.
If you use logical properties, which is not some crazy stretch of knowledge, it just helps that a little bit.
The pushback to me feels like saying “people with bad vision don’t use my website, that’s not something we need to worry about” which people have been convincing themselves of for ages but feels like mostly we know better.
It’s a slightly different mental model. This in my view is 99% of the reason why it’s not widely adopted already. The cognitive overhead of switching mental models (in any context, not just web dev) is prohibitive, and for good reason. Cognitive work takes energy, and at a biological level we are incentivized to conserve energy for evolutionary / survival reasons. Furthermore, physical-dimensional based mental models are likely always going to be preferred over more semantical ones (like inline/block) because they more closely mirror the way we actually interact with the physical world (left right up down infront behind) — again taking less cognitive effort up front to reproduce in digital ‘space’. People may say things like “I’m not going to use it because I’m not concerned with accessibility”, but really I think this comes simply from a place of “laziness” – i.e. conservation of cognitive effort/energy.
The more immediately intuitive methods will always be more popular.