Should we NEVER use non-logical properties?

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: