📝 CSS-Tricks 234: Design v18 and Responsive HTML Videos

View this newsletter on the web.

Design v18

I don’t think we’ve linked to this in the newsletter yet, but Chris wrote a fantastic post about the latest design of CSS-Tricks and there’s an awful lot to dig into here. Chris compares the previous version to the latest when it comes to visual design, typography, CSS, and the overall performance of the site. He also uses Project Wallace to analyze the CSS and see what improvements could be made in the future, too.

I particularly like what Chris has to say about design and systems:

Maybe in a perfect world, a perfect site would have a perfect content strategy such that every single article has a perfect featured image. A matching color scheme, exact dimensions, very predictable. But this is no perfect world. I prefer systems that allow for sloppiness.

This idea of a design system that can be moved and pushed is making me nod furiously as I read all this.

📝 CSS-Tricks 233: CSS as a content API? No. But also sort of yes.

View this newsletter on the web.

CSS as a content API

Okay, this is a neat idea but also probably highly foolish: using CSS as a content API. We’ll get to that. But first: in Custom Properties as State, Chris writes about Seasonal.css which “supplies a seasonal colour scheme based on the day of the year.”

You can import the CSS file…

<link rel="stylesheet" type="text/css" href="https://seasonal-css.incoherency.co.uk/seasonal.css"&gt;

And then use the variables within this CSS file to style your site. All of the variables in that file are then updated for every day of the year as they show on the example website:

Chris looks at all this and then writes:

This makes me think that a CDN-hosted CSS file like this could have other useful stuff, like today’s date for usage in pseudo content, or other special time-sensitive stuff. Maybe the phase of the moon? Sports scores?! Soup of the day?!

It’s almost like a data API that is tremendously easy to use. Pseudo content is even accessible content these days — but you can’t select the text of pseudo-elements, so don’t read this as an actual endorsement of using CSS as a content API.

Simon Willison took that idea and ran (caveating it all as a very weird idea) building an API for arbitrary database queries that return the results as… CSS custom properties. 🤯

Super interesting stuff here. I wrote not so long ago that CSS variables will soon be like the checkbox hack: they’re remarkable and extremely flexible. And I believe that this “CSS as content API” stuff proves me right. Just wait until we get Higher Level Custom Properties, things will get even weirder.

📝 CSS-Tricks 232: Scroll Story

View this newsletter on the web.

[Robin]: Over the past week I’ve been working on fun side project that I’m calling a Scroll Story—an elaborate blog post where I rant about a thing. The most exciting part about this little website is that it uses scroll-snap from section to section. Here, a screenshot of one of the sections or “slides”:

The idea is to tell a comic book story with the text/illustration pairing whilst each of these “slides” snap into place. To build this thing, first we need a wrapper for all of the slides which looks something like this:

<div class="slide-container"> <div class="slide">...</div> <div class="slide">...</div> <div class="slide">...</div> </div>

And our .slide-container has the styles to make each slide click into place on scroll:

.slide-container { scroll-snap-type: y mandatory; overflow-y: scroll; height: 100vh; }

And each slide needs to have a height, too:

.slide { height: 100vh; }

100vh tells the browser that we always want the slide to be 100% of the browser’s height—that way each slide takes up the whole screen.

Now, the nifty thing about Firefox is that you can then use the up/down directional keys to jump to each section and it clacks just as you’d expect. And I really wish other browsers implemented this because it’s amazing that you can get the browser to do that with just CSS.

But! The problem here is that mobile browsers disagree about viewport units which is extremely annoying and odd to me. Heck, even Firefox on iOS—which still uses Webkit under the hood—appears to calculate viewport units differently from Safari on iOS.

Thankfully, Louis Hoebregts wrote about this very problem not so long ago:

Viewport units have always been controversial and some of that is because of how mobile browsers have made things more complicated by having their own opinions about how to implement them.

Case in point: should the scrollbar be taken into account for the vw unit? What about a site’s navigation or page controls — should those count in the calculation? Then there are physical attributes of the devices themselves (hello, notch!) that can’t be overlooked.

This was the very problem I was experiencing. To fix the way that browsers calculate vh or vw units correctly we need to use a tiny bit of JavaScript and combine that with CSS custom properties, as Louis writes here:

In JavaScript, you can always get the value of the current viewport by using the global variable window.innerHeight. This value takes the browser’s interface into account and is updated when its visibility changes. The trick is to store the viewport value in a CSS variable and apply that to the element instead of the vh unit.

So from what I understand, whenever we use vh units we need to use this which is sort of annoying and makes my eye twitch. But in terms of work, it’s not too much bother at all. First, we need to write the following JavaScript:

// Get the viewport height and multiple it by 1% to get a value for a vh unit let vh = window.innerHeight * 0.01; // Then we set the value in the --vh custom property to the root of the document document.documentElement.style.setProperty('--vh', `${vh}px`);

So if the browser height is 600px then we’ll now have a value of 6 to work with. We can then pass this variable into our CSS:

.slide { height: 100vh; /* Fallback */ height: calc(var(--vh, 1vh) * 100); }

6 * 100 = 600 which happens to be the height of our browser window.

As I said, it’s a bit annoying to me that browsers don’t all agree with how to calculate vh or vw units but it’s not too difficult to get this working. And to get this nifty effect it’s certainly worth the tiny bit of effort to ensure that browsers aren’t being weird.

📝 CSS-Tricks 231: Notes on Hotwire

View this newsletter on the web.

A Utility Class for Covering Elements

Earlier this month Michelle Barker looked into how to cover elements with CSS and had this interesting tip that I’ve never seen before:

.original-element { position: relative; } .covering-element { position: absolute; inset: 0; }

Here’s a tiny demo of that. What interests me most here is that inset: 0 bit, which is part of the Logical Properties spec. Adam Argyle summarized it all not so long ago in a neat post where he writes that:

…a logical property is one that references a side, corner, or axis of the box model in context of the applicable language direction. It’s akin to referencing someone’s strong arm, rather than assuming it’s their right arm. “Right” is a physical arm reference, “strong” is a logical arm reference, contextual to the individual.

📝 CSS-Tricks 230: Animate Everything by 1%

View this newsletter on the web.

[Robin]: Animations are important, but deadly. They can focus our attention on certain bits of information at just the right time, they can be for fun when you’ve hit a button, and animations can also be used to make you trust a website, app, video game, or bit of software even more than if they weren’t there are at all.

When the animations are smooth and don’t get in the way, that’s the sign of a truly outstanding website (to me).

But! When I use a site with too many animations I feel like it slows me down and I start to distrust it all. Video games do this too—the character crouches to pick up an item, reaches out to grab it, then they look at it, then stash it away. It’s exhausting! Just let me have fun!

Web designers like us can learn a lot about animations from video games, especially because a lot of these animations are unnecessary and feel just like load screens to me. As I’ve been thinking about all this, it’s sort of led me to this completely un-researched and un-scientific conclusion: I feel like we should animate absolutely everything, but only by 1%.

Take big swooshy animations that pop up when a page loads. Those are extremely distracting to me—I begin to notice the animation instead of the content—and it feels like a barrier to entry. But a tiny swoosh that animates in or out quickly? That’s extremely elegant and my attention is drawn to the content more so than how cool the developer was when they wrote that complex SVG animation.

Subtlety is important when it comes to animation design because otherwise they can get in the way and frustrate folks. It only takes a tiny bit of movement for your eye to notice it too, and just because we can animate everything on a webpage in and out, doesn’t necessarily mean we should.

(Except by 1%.)

Animation is like typography in that way: you can make a big and bold declaration with a flash of something interesting but you can’t keep doing it over and over again. It gets both boring and annoying. So I’ve been trying to keep this in mind whenever I crack open my text editor and jump into @keyframes and the like.

When it comes to animations, subtlety is the key.