Let’s get logical

I was refactoring some CSS on The Session over the weekend. I thought it would be good to switch over to using logical properties exclusively. I did this partly to make the site more easily translatable into languages with different writing modes, but mostly as an exercise to help train me in thinking with logical properties by default.

All in all, it went pretty smoothly. You can kick the tyres by opening up dev tools on The Session and adding a writing-mode declaration to the body or html element.

For the most part, the switchover was smooth. It mostly involved swapping out property names with left, right, top, and bottom for inline-start, inline-end, block-start, and block-end.

The border-radius properties tripped me up a little. You have to use shorthand like border-start-end-radius, not border-block-start-inline-end-radius (that doesn’t exist). So you have to keep the order of the properties in mind:

border-{{block direction}}-{{inline-direction}}-radius

Speaking of shorthand, I also had to kiss some shorthand declarations goodbye. Let’s say I use this shorthand for something like margin or padding:

margin: 1em 1.5em 2em 0.5em;

Those values get applied to margin-top, margin-right, margin-bottom, and margin-left, not the logical equivalents (block-start, inline-end, block-end, and inline-start). So separate declarations are needed instead:

margin-block-start: 1em;
margin-inline-end: 1.5em;
margin-block-end: 2em;
margin-inline-start: 0.5em;

Same goes for shorthand like this:

margin: 1em 2em;

That needs to be written as two declarations:

margin-block: 1em;
margin-inline: 2em;

Now I’ve said it before and I’ll say it again: it feels really weird that you can’t use logical properties in media queries. Although as I said:

Now you could rightly argue that in this instance we’re talking about the physical dimensions of the viewport. So maybe width and height make more sense than inline and block.

But along comes the new kid on the block (or inline), container queries, ready to roll with container-type values like inline-size. I hope it’s just a matter of time until we can use logical properties in all our conditional queries.

The other place where there’s still a cognitive mismatch is in transforms and animations. We’ve got a translateX() function but no translate-inline(). We’ve got translateY() but no translate-block().

On The Session I’m using some JavaScript to figure out the details of some animation effects. I’m using methods like getBoundingClientRect(). It doesn’t return logical properties. So if I ever want to adjust my animations based on writing direction, I’ll need to fork my JavaScript code.

Oh, and one other thing: the aspect-ratio property takes values in the form of width/height, not inline/block. That makes sense if you’re dealing with images, videos, or other embedded content but it makes it really tricky to use aspect-ratio on elements that contain text. I mean, it works fine as long as the text is in a language using a top-to-bottom writing mode, but not for any other languages.

Have you published a response to this? :

Responses

Miriam Eric Suzanne

CSS has historically revolved around physical directions: width, height, top, right, bottom, and left. Those make sense in a world where what you see is what you get – but that’s fundamentally not how the web works.

Over time, new layout methods like flexbox and grid have started to introduce ‘flow-relative’ or ‘logical’ directions: inline-size, block-size, inline-start, inline-end, block-start, and block-end.

That allows more meaningful and resilient design in the face of translation – both for multi-lingual sites, and for a web that supports more and more automatic translation.

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.

So the goal in my mind is that it should be simple to write an entire site without reference to physical coordinates. And doing that should be encouraged by the language.

For example, we currently have a margin shorthand that defines physical margin properties. We could add a margin-logical shorthand, but it feels like a second-class citizen of the language. If the physical property feels like the ‘default’, then the language is encouraging authors to stick with physical dimensions.

Yesterday, Jeremy Keith wrote a great article – Let’s get logical – about his attempts to refactor a site using only flow-relative properties, and the limitations he ran intro with existing CSS. It’s a great run down of what works already, and what’s still missing.

We’re not there yet. So how do we get there?

Well, I don’t know for sure – but articles like this are very helpful as we try to work it out!

Fantasai and I did spend some time working on this last year, and came up with a multi-year and multi-step proposal. Maybe there are other approaches we should consider as well?

We’re discussing all of that today at W3C’s annual TPAC conference, in a joint meeting between the CSS Working Group and the Internationalization Working Group. Maybe we’ll have something new to report later today?

If you have ideas, or additional issues that we should have in mind – let us know!

toheeb

Same here, values for border-radius trips me off too. By the way, should you explain a static mockup with physical or logical property terms? With code, logical terms ask the way! But mock-ups?

# Posted by toheeb on Sunday, September 18th, 2022 at 9:08pm

Dana Byerly

A couple of weeks ago Jeremy Keith had a post on refactoring an existing site to use logical properties. Not entirely sure about logical properties? web.dev has a nice summation

Logical, flow relative properties and values are linked to the flow of text, rather than the physical shape of the screen.

Instead of using margin-top: 1rem; it would be margin-block-start: 1rem;, using a relative “start” instead of physical “top” to indicate direction. Using relative direction better supports language translation and multi-lingual sites. The post at web.dev has a good overview that includes examples. MDN also has a good overview that includes links to all the properties.

Jeremy’s refactor seemed to go well, including some interesting observations. He had a nice follow-up post on browser support and progressive enhancement using feature queries that should be noted, especially for the how-to on using @supports.

Around these parts I went (almost!) all in on logical properties for my new blog thingie, affectionately known as the Junk Drawer. Initially I wrote all the styles using logical properties, but after reading Jeremy’s posts I realized that the styles from my Eleventy starter needed to be converted. Feel free to take a peak at Github.

The one thing I didn’t convert were units, they were mentioned in the web.dev post but upon further investigation vi (view inline) and vb (view block) are not yet as widely supported as sizing, spacing and borders.

Overall it was easier than I thought to remap my mind to write logical properties, at least for spacing. No doubt using flexbox and grid made the mental leap easier. In the flurry of new CSS things to keep up with I missed sizing, borders and text-align start end.

Borders and text-align were easy enough to absorb, but something about sizing (width and height) didn’t easily fit in my head. It’s like when you meet someone and get their name slightly wrong, and then they’re always the wrong name to you. My mind wants to type max-size-inline or size-block instead of the correct max-inline-size or block-size. I regret even typing the incorrect examples! But I’m sure I can make them mental muscle memory in good time.

Another thing I noticed is that the shorthand for “start” and “end” can be used within the spacing logical shorthand. Let’s say your original padding is this…

/* shorthand order is top right bottom left */.my-class { padding: 1rem 2rem 3rem .5rem;}

According to the examples at MDN you can use the shorthand to include both the start and end values within the overall logical shorthand. Making your original example…

/* shorthand order is start end */.my-class { padding-block: 1rem 3rem; padding-inline: .5rem 2rem;}

I made a quick Pen to validate this example because I tripped up on the order for inline. I was looking at the physical example while typing and initially put the “end” value first, but the logical shorthand order is “start end”.

Back to Jeremy’s second post about browser support. The Junk Drawer is a very, very low traffic personal site, which makes for a great low stakes way to get used to using logical properties. I checked my stats to see if I’ve had any visitors using browsers that don’t support the logical properties I used, and I haven’t had any yet.

The current version of the new DuckDuckGo Mac browser doesn’t support yet them, and the only visitor I’ve had using it was me while doing my test. I sent feedback about it! None of the DuckDuckGo browsers are listed at Can I Use but my test of the iOS version shows support, at least for spacing, sizing and borders. Best guess is that the Android versions support it too?

At any rate, I found logical properties easy to use and am look forward to using them more in the future. And speaking of the future, Miriam Suzanne had a good reply post to Jeremy’s original post to discuss longer terms plans from the CSS and Internationalization working groups. If you have any opinions on the matter you should let them know.

# Posted by Dana Byerly on Sunday, October 2nd, 2022 at 12:00am

Related posts

Displaying HTML web components

You might want to use `display: contents` …maybe.

Speedier tunes

Improving performance with containment.

Workaround

Browsers and bugs.

Culture and style

Styling a document about The Culture novels of Iain M Banks.

Alternative stylesheets

Why do browsers that don’t implement stylesheet switching still download alternative stylesheets?

Related links

Printing music with CSS grid

Laying out sheet music with CSS grid—sounds extreme until you see it abstracted into a web component.

We need fluid and responsive music rendering for the web!

Tagged with

How would you build Wordle with just HTML and CSS? | Scott Jehl, Web Designer/Developer

This is a great thought exercise in progressive enhancement …that Scott then turns into a real exercise!

Tagged with

Retrofitting fluid typography | Clagnut by Richard Rutter

Here’s a taste of what Rich will be delivering at Patterns Day on Thursday—can’t wait!

Tagged with

What is Utility-First CSS?: HeydonWorks

Heydon does a very good job of explaining why throwing away the power of selectors makes no sense.

Utility-first detractors complain a lot about how verbose this is and, consequently, how ugly. And it is indeed. But you’d forgive it that if it actually solved a problem, which it doesn’t. It is unequivocally an inferior way of making things which are alike look alike, as you should. It is and can only be useful for reproducing inconsistent design, wherein all those repeated values would instead differ.

He’s also right on the nose in explaining why something as awful at Tailwind could get so popular:

But CSS isn’t new, it’s only good. And in this backwards, bullshit-optimized economy of garbage and nonsense, good isn’t bad enough.

Tagged with

Bill Oddie taught me how to make web sites - Hicks.design

I remember Jon telling me this lovely story when we first met in person. I love the idea that we had already met in a style sheet.

I also love the idea of hosting your own little internet archive—that Bill Oddie site still looks pretty great to me!

It’s a lot like an embarrassing family photo, but I’m owning it!

Tagged with

Previously on this day

3 years ago I wrote Design engineering on the Clearleft podcast

If you like the sound of being a design engineer, come and join us at Clearleft.

4 years ago I wrote A declarative Web Share API

button type=”share”

11 years ago I wrote Parsing webmentions

Hell has frozen over …you can now comment on my site. But there’s a catch.

12 years ago I wrote Listen to Brighton SF

The audio (and transcript) is available for your listening (and reading) pleasure.

13 years ago I wrote Boston Global Scope

This. This is how we should build for the web.

15 years ago I wrote The devil in the details

The HTML5 spec has been updated again.

15 years ago I wrote Wayfinders keepers

I want you to show me the way.

16 years ago I wrote Self loathing for Sumo

I’m a cheap and dirty little blogslut.

22 years ago I wrote Adactizilla

It’s time for a new CSS theme ‘round here.