I like to think of CSS as a conditional design language.
Yes! This is exactly what I’m talking about with declarative design!
Read on for some fantastic examples. And also, Ahmad makes a comparison between CSS and Figma, pointing out that the conditional, declarative possibilities currently aren’t available in graphic design tools.
A good ol’ rant by Vasilis on our design tools for the web.
I wrote recently about making the switch to logical properties over on The Session.
Initially I tried ripping the band-aid off and swapping out all the directional properties for logical properties. After all, support for logical properties is green across the board.
But then I got some reports of people seeing formating issues. These people were using Safari on devices that could no longer update their operating system. Because versions of Safari are tied to versions of the operating system, there was nothing they could do other than switch to using a different browser.
I’ve said it before and I’ll say it again, but as long as this situation continues, Safari is not an evergreen browser. (I also understand that problem lies with the OS architecture—it must be incredibly frustrating for the folks working on WebKit and/or Safari.)
So I needed to add fallbacks for older browsers that don’t support logical properties. Or, to put it another way, I needed to add logical properties as a progressive enhancement.
“No problem!” I thought. “The way that CSS works, I can just put the logical version right after the directional version.”
element {
margin-left: 1em;
margin-inline-start: 1em;
}
But that’s not true in this case. I’m not over-riding a value, I’m setting two different properties.
In a left-to-right language like English it’s true that margin-inline-start will over-ride margin-left. But in a right-to-left language, I’ve just set margin-left and margin-inline-start (which happens to be on the right).
This is a job for @supports!
element {
margin-left: 1em;
}
@supports (margin-inline-start: 1em) {
element {
margin-left: unset;
margin-inline-start: 1em;
}
}
I’m doing two things inside the @supports block. I’m applying the logical property I’ve just tested for. I’m also undoing the previously declared directional property.
A value of unset is perfect for this:
The
unsetCSS keyword resets a property to its inherited value if the property naturally inherits from its parent, and to its initial value if not. In other words, it behaves like theinheritkeyword in the first case, when the property is an inherited property, and like theinitialkeyword in the second case, when the property is a non-inherited property.
Now I’ve got three CSS features working very nicely together:
@supports (also known as feature queries),unset keyword.For anyone using an up-to-date browser, none of this will make any difference. But for anyone who can’t update their Safari browser because they can’t update their operating system, because they don’t want to throw out their perfectly functional Apple device, they’ll continue to get the older directional properties:
I discovered that my Mom’s iPad was a 1st generation iPad Air. Apple stopped supporting that device in iOS 12, which means it was stuck with whatever version of Safari last shipped with iOS 12.
Well, now I’m really glad I wrote that post about logical properties!
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!
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.
An account of the mother of all demos, written by Steven Johnson.
I really, really enjoyed this deep dive into practical HTML semantics. Sit back and enjoy!
The problem I’ve regularly encountered in my work is that I don’t get to do my job the way I think is best for both me and my employer or client. The employer, who isn’t the web development expert, almost always has a clear idea of what real web development is supposed to look like: Single-Page-Apps and React (or React-like frameworks).
An intimation that it wouldn’t be the right solution for this particular problem is taken as an admission of incompetence.
I’ve experienced this. And I think this observation is even more true when it comes to recruitment.
Do you like the ideas behind Utopia? Do you use Figma?
If the answer to both those questions is “yes”, then James has made a very handy Figma community file for you:
This work-in-progress is intended as a starting point for designers to start exploring the Utopia approach, thinking about type and space in fluid scales rather than device-based breakpoints.
No matter how fancy your Figma file is or how beautiful and lovingly well organized that Storybook documentation is; the front-end is always your source of truth. You can hate it as much as you like—all those weird buttons, variables, inaccessible form inputs—but that right there is your design system.
Some tough design system love from Robin.
Here’s my advice: take all that aspirational stuff out of your Figma design system file. Put it somewhere else. Your Figma docs should be a mirror of the front-end (because that’s really the source of truth).
This is a wonderful piece of writing by Marcin, ostensibly about bug-fixing but really an almost existential examination of the nature of coding.
Bugs are, by definition, a look backward—at past behavior, at code that already exists, at the old work of engineers whom you’ve never met. It can feel more fun to write new code, chart new territories, add new functionality.
But the past can be fun, too. A good bug is a puzzle. A mystery. A whodunit. To solve a bug, sometimes you have to be a scientist: observe and measure, chart out the logic, follow the math. But then, two minutes later, you need to wear a hat of a very particular detective—take your flip notepad and interview different pieces of code to understand not what they claim they do, but what they actually do.
There’s a really interesting discussion here, kicked off by Lea, about balancing long-term standards with short-term pragmatism. Specifically, it’s about naming things.
Naming things is hard. Naming things in standards, doubly so.
I spend most of my time in the application layers—HTML, CSS, and JavaScript—so I fascinating to dive below the surface and learn about the upcoming HTTP/3. Sounds like it’s really more of a change to how things have always worked with the TCP protocol, still chugging away since it was created by Bob Kahn and Vint Cerf.
The opening paragraphs of this article should be a mantra recited by every web developer before they begin their working day:
Things on the web can break — the odds are stacked against us. Lots can go wrong: a network request fails, a third-party library breaks, a JavaScript feature is unsupported (assuming JavaScript is even available), a CDN goes down, a user behaves unexpectedly (they double-click a submit button), the list goes on.
Fortunately, we as engineers can avoid, or at least mitigate the impact of breakages in the web apps we build. This however requires a conscious effort and mindset shift towards thinking about unhappy scenarios just as much as happy ones.
I love, love, love the emphasis on reducing assumptions:
Taking a more defensive approach when writing code helps reduce programmer errors arising from making assumptions. Pessimism over optimism favours resilience.
Hell, yeah!
Accepting the fragility of the web is a necessary step towards building resilient systems. A more reliable user experience is synonymous with happy customers. Being equipped for the worst (proactive) is better than putting out fires (reactive) from a business, customer, and developer standpoint (less bugs!).
Wearing today’s shirt for #UXfest (home edition). 👕
Always refreshing to see some long-term thinking applied to the web.
An excellent explainer from Trys and James of their supersmart Utopia approach:
Utopia encourages the curation of a system small enough to be held in short-term memory, rather than one so sprawling it must be constantly referred to.
Vitaly has rounded up a whole load of accessibility posts. I think I’ve linked to most of them at some point, but it’s great to have them all gathered together in one place.
I really like the approach that Carie takes here. Instead of pointing to specific patterns to use, she provides a framework for evaluating technology. Solutions come and go but this kind of critical thinking is a long-lasting skill.
You catch more flies with honey than Tailwind.