Should we NEVER use non-logical properties?

Chris Coyier Chris Coyier on

CSS has “logical properties” which have the unique ability to follow the flow of language. You might be working on an website in English, which is left-to-right and top-to-bottom, but other languages might flip either or both of those. In English, we know what margin-right does, but can quickly become the wrong choice if the direction of a web page is flipped, perhaps during translation.

So instead of margin-right, more and more CSS authors are writing margin-inline-end, which matches our intention better. Should the flow of the site change, our intention, and the design, holds.

You probably already knew that.

So, what, then?

Are we to absolutely never use a “physical” property again, like margin-right? Knowing that there is a better property available?

My take: yes, just use logical properties all the time.

If you need an answer with zero nuance, there it is. You’ll be better off and make better websites for people if you just entirely switch as often as you can.

There is some nuance, though, and plenty of pushback. People say things like:

No, why should I unlearn the old ways? I don’t write websites that are translated into different languages with different reading directions.

That’s not a reasonable opinion when you can just straight up see that Google Translate has 29 million users, and you don’t even need it installed to translate sites as it’s just built into Chrome and other browsers. Your website is being translated. Whether flow direction is flipped during that translation is less clear (it appears that is not a default behavior of Google Translate, but sites may do it anyway, and other translators might work differently.)

So, when should you not use logical properties?

When you can’t

  • Media queries. There is @media (width < 30rem) { } but not @media (inline-size < 30rem) { }
  • Transform function. There is translateX() but not translateInline(). This is similar with the Y version, and across other functions like scaleX and skewX.
  • Background position. There is background-position-x but not background-position-inline. (Likewise with y)
  • Gradients. There is linear-gradient(to top, black, white) but not linear-gradient(to block start, black, white);

It’s just missing a few properties, as sometimes it was clearly thought of. We have overflow-inline, for example, as a logical replacement of overflow-x. Jeremy Keith notes some others, like how the JavaScript API getBoundingClientRect doesn’t return things in logical values.

When you can’t, but you actually need to, you’ll need to check the directions to handle it likely.

.hero-graphic {
  background: 
    url(hero.jpg),
    linear-gradient(to top, black, transparent);
  color: white;
  place-items: end start;
}

.vertical-writing-mode .hero-graphic {
background: 
    url(hero.jpg),
    linear-gradient(to left, black, transparent);
}
Code language: CSS (css)

When it doesn’t make sense

I always think of images in this cateogry. Just because text starts flowing top-to-bottom in some languages, doesn’t mean we flip images 90 degrees. Like if there is an image in the middle of a blog post in Japanese, the image is still shown as-taken.

So if we’re setting the size of that image, we’d still use width to constrain it not inline-size, probably. Although it might make sense to constrain the maximums in both directions, in which case using logical properties or not is fine.

Roma Komarov says:

While it might be a good idea to approach CSS with logical keywords first, there are cases where we could want to use physical properties and values. For example, when we want to match something with the positions on an image, which won’t change based on the writing mode.

When you’re matching the intent

Miriam once wrote:

It’s not bad to use the physical properties sometimes, when they best express the design intent, but they shouldn’t be encouraged as the default choice.

A long-term plan for logical properties?

The intent could be, for example, place this chat widget on the bottom right of the page. The language perhaps doesn’t matter here, it’s adhering to where feels right in the browser and has become something of a defacto standard.

When positioning that, we could set the bottom and right values, as they match the intent, rather than swapping them out for inset-block-end and inset-inline-end.

This may be the case when you’re doing things like anchor positioning and fallbacks, where the physical nature of the browser window might be of more consequence than the language direction.

Cheat Sheet

From Adrian Roselli:

Wanna learn CSS from a course?

Frontend Masters logo

FYI, we have a full CSS learning path with multiple courses depending on how you want to approach it.

7-Day Free Trial

2 responses to “Should we NEVER use non-logical properties?”

  1. Lanny Heidbreder says:

    Is there an existing, non-theoretical, real-world example of logical properties being useful in this way? I don’t think I believe that a real website of any complexity can switch to a different writing mode and automatically have a sensible, thoughtful design for readers of the new language merely by swapping the axes around. It seems implausible to me that such a blind rearrangement would yield anywhere close to as good a result as something bespoke by a designer fluent in the second language.

    I do use -inline and -block, as a convenient way of setting two sides in one rule without respecifying the other two sides. Beyond that I’m going to need some evidence.

    • Chris Coyier says:

      Once I was researching logical properties, and I took an article page from a magazine website, and I popped it through Google Translate and had a friend of mine who read Arabic check it out. They said it was fine. About what they expected from a translated site. Then I replaced all the CSS on the page with logical property values and again translated it, and they said it was, surprisingly to them, much better. There were things that felt/read/looked better that they didn’t expect, like the header/navigation/logo aligning itself in a way that felt better to them. So it it the biggest deal in the world? Maybe not, but it fixes little things and it’s a net gain, so that’s enough for me.

Leave a Reply

Your email address will not be published. Required fields are marked *

$839,000

Frontend Masters donates to open source projects through thanks.dev and Open Collective, as well as donates to non-profits like The Last Mile, Annie Canons, and Vets Who Code.