.page-wrap {
  max-width: 800px;
  margin: 0 auto;
}

That could still touch the edges of a parent container though, so if need to enforce some spacing, we’d probably do that on a parent.

body {
  padding: 0 1rem;
}

There is no real problem with that, but we can smash it all into a one-liner now if you’re feeling it:

.page-wrap {
  margin-inline: max(1.5rem, ((100% - 800px) / 2));
}

The 1.5rem is the space on the outside (which could be 0), and the 500px is the max-width (or rather max-inline-size as we’re using logical properties here).

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);
}

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:

Anybody can translate the website though. There are a variety of site translation tools. I don’t have any data on popularity, but I gotta imagine Google Translate is up there, which is a website and Chrome Extension and, to some degree, automatic translation is just built into Chrome (and other browsers).

So let’s say I translate my website from English to Arabic, a right-to-left language (RTL). Here’s what I get:

It’s the exact same layout, it’s just the words are in Arabic now. Which is not terribly surprising, I guess? But even the alignments have stayed the same, so this RTL language is still being show in an LTR way.

Google Translate, aside from the text node translation, makes a few other changes that are notable here. What used to be:

<html lang="en">

Becomes:

<html lang="ar" class="translated-rtl">

Those changes do not actually change the direction to RTL. It could have, like:

<html 
  lang="ar" 
  class="translated-rtl" 
  dir="rtl"
>

Or it could have injected CSS like:

.translated-rtl {
  direction: rtl;
}

/* or */

[lang="ar"] {
  direction: rtl;
}

But it doesn’t. I don’t know for sure, but my guess is that it intentionally doesn’t do that, because it jacks up more layouts than it helps.

But let’s say you’re me (perfect, handsome) and you’ve changed your muscle memory for writing a lot of CSS properties to using logical properties. That is, stuff like padding-inline-start instead of padding-left, and the like. That, plus using layout like flexbox and grid, will reflow naturally with direction changes. So if you change the direction to rtl on my site, you get:

So the question is:

Is that “better”?

Meaning: does it read better for native Arabic speakers? Does it generally feel better or more native? Or is it worse, in that it’s unexpected or unnatural somehow?

I have a friend who speaks/reads Arabic, just for one anecdotal bit of data. I showed them a site and translated it, and they were like “it’s fine”. But then I showed them a tweaked one where things like the header and hero text and stuff was actually flipped, and they thought it was better. They were like “I never actually see this done, but it’s better this way.”

It’s likely that this no One True Answer here. Even if you’ve done a good job with a layout that flips and looks sensible. Alda Vigdís told me:

As someone who has worked on bi-lingual content, dir=”rtl” should of course be indicated for textual content, but the layout question depends on a lot more factors.

Arabic and Hebrew speaking power users often prefer to have a ltr-oriented layout, while some other groups prefer rtl-oriented layout.

So it may just be a matter of preference of individuals, which is more evidence for why Google Translate doesn’t go there (for layout). Perhaps they should be trying to find more fine-grained text nodes and flipping the dir there, but they don’t do that either.

If you land on “leave the layout alone, but flip the dir for text”, like Alda suggests, it would be a bring-your-own-CSS situation. You could use Google Translate’s class and flip just the text you need to, like:

.translated-rtl {
  p, li, dt, dd, td, th, h1, h2, h3 {
    direction: rtl;
  }
}

That feels a little 😬 to me, like you’ll miss some and make it worse instead of better or something. (I just picked those selectors randomly quick, to illustrate.) So much testing needed.

A flipped layout can be preferable even here though, as Naman told me:

There are somethings that work both ways. The sidebar can be on either side and it makes sense.

But something like the search bar makes a lot more sense with the layout flipped. [Also: headings in the sidebar are also a lot better with the layout flipped]

On balance, I think yes, flipping has an overall better result.

So if you’re looking for a straight answer, I’m afraid I can’t give you one. Except, ya know, do a good job.