I have a terrible confession to make. Send me to jail and lock away the key because, despite how much I rant about variable fonts, I’ve never really used them. I’ve read tutorials and demos and I love seeing what’s possible with this new font format, but I’ve never used any of them in a website of my own.
So this weekend I wanted to fix that. I started looking around for variable fonts to play with and, well, did you know that test fonts are a thing? A lot of type foundries will offer fonts that are free to download and play around with in your local environments before you buy them. They’re super handy and that’s just what I did the other day.
First, I headed over to David Jonathan Ross’s website where I discovered the ever-so-good Job Clarendon that he designed alongside Bethany Heck:
Welp! Also, Job Clarendon has a great variable font version available and you can download it for free (so long as you’re being a cool chap and only using it on your computer).
So, first things first: how do we load Job Clarendon as a variable font and make it accessible from our CSS? The first thing to note is that we have to support both the new syntax and the old syntax for variable fonts:
@font-face {
font-family: "JobClarendon";
src: url("job-clarendon.woff2") format("woff2 supports variations"),
url("job-clarendon.woff2") format("woff2-variations");
font-weight: 100 1000;
}We’re pointing to the same variable font file here (which note is a regular ol’ .woff2 file) but we have to tell the browser that it supports “variations.” woff2 supports variations is the future syntax for telling the browser it’s a variable font and woff2-variations is the deprecated way.
You see that weird part underneath where we’ve said font-weight: 100 1000? That’s not a mistake, we’re telling the browser that this font supports a range of font-weights from the light weight 100, all the way up to the heaviest weight of 1000.
We can then use our variable font just like we can any other, but whilst I was working on adding these demo font, I realized that I could use CSS custom properties to set the fallback font if for whatever reason this one can’t load:
:root {
--font-fallback: BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu",
"Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", sans-sans;
}
h1, h2 {
font-family: "JobClarendon", var(--font-fallback);
}Now that’s pretty handy. I could even set different fallbacks for my display and body text font. From here we can then set an element to use one of those ranges between 100 and 1000:
h1 {
font-weight: 600;
}
h2 {
font-weight: 250;
}Right now it looks like there are five “common axes” that fonts let us change variably. So that’s stuff like font-weight and font-stretch which lets you make letters more or less condensed. This all depends on what the specific font supports though, so make sure you know what features the font has before you buy it (this is why test fonts rule).
Another place to check out is Variable Fonts, which I know I’ve mentioned in every human conversation I’ve had the past year, but still, it’s a great place to find cool new variable fonts.
With variable fonts, we can do wild things with animations. So now that I can change any font-weight between 100 and 1000, I can also animate between those properties, too. Why is that a good idea? Well, most of the time it’s probably not a good idea. But you could set really big and beautiful headlines like this:
@keyframes scale {
0% {
font-weight: 100;
}
100% {
font-weight: 1000;
}
}
.element {
font-size: 15vw;
animation: 4s ease-out scale alternate infinite;
}
That said, I don’t think animations are what that excite me most about variable fonts. Instead, the most exciting thing about variable fonts is the ability to making really small changes to text because, the more you look at type on the web, the more you realize it’s either way too thin or way too bold.
But now with variable fonts we can get it just right.
A Look at Building Astro
Here’s an interesting look at Astro where Chris describes his experience of building a website with this fancy new tool and what he learned along the way. Chris writes:
I really like the idea of static site generators—I think they make a lot of sense in a lot of situations. Sending HTML over-the-wire is just a good move for resiliency, CDN-efficiency, SEO, accessibility, you name it. But in the past a lot of the options were either:
• A JavaScript powered static site generator, that does generate a “static” site, but also ships a JavaScript bundle (e.g. Next or Gatsby)
• A static site generator that is more focused on HTML and has its own templating/formats that aren’t JavaScript components (e.g. Eleventy or Jekyll)
But I want both!
• I want to craft sites from JavaScript-components, because the syntax and tooling around them is just better than any other component system we have right now.
• I want static output that is actually zero-JavaScript (unless I manually opt-in to things).
I just started my own side project with Astro and this is exactly how I’d describe it, too: it feels like having the best of both worlds. You have all the options of bigger and more powerful JavaScript frameworks if you want but also the best stuff from static site generators where you don’t send all that JavaScript over the wire.
There’s another point that Chris brings up here that I find interesting. Astro has a lot of extremely smart defaults. Do we want hot reloading? Of course! Do we want simple routing without having to deal with it out of the box? Yep! And do we like CSS modules where all our CSS doesn’t leak into other components? Yes, yes, and yes.
SVG Favicons
Great piece here by Philippe Bernard about how to make SVG favicons. This is just the sort of post I’m going to return to over and over again in the future. But wait, why would we want to make SVG favicons in the first place?
Dark mode! Here’s an example of the favicon on Codepen where it switches depending on the theme you’ve selected:
Which is a nice touch and makes things certainly stand out more. But I definitely agree with Philippe here:
Beyond coolness, SVG favicons actually solve a problem that its PNG counterpart cannot. It’s only been about a year since we’ve had the ability to use SVG this way at all, but so far, it seems seldom used. With intentional purpose and tooling, maybe SVG favivons will rise and find its place among the favicon classics.
I’m excited about a world where we don’t have to add a million favicon files to a website just to get things working across all browsers and devices.
The Large, Small, and Dynamic Viewports
Bramus made some notes about potential upcoming changes to viewport units. You know, like today where we have the ever-so-useful 100vh or 100vw and we can set the size of an element based on the width of the viewport.
This is the proposal, a new unit called svh:
vh units would only apply to the whole screen without browser UI, whereas svh would apply when there’s browser UI like tabs or the URL top bar.
I feel like viewport units were always half-baked across browsers. Louis Hoebregts wrote about them a while back and described all the problems, such as: should the scrollbar be taken into account when you set an element’s width to 100vw? This division that Bramus describes between “small” and “large” viewport units should resolve that problem.
Elephant SVG Animation
Here’s a lovely animation from Lea Rosema:
Animating web pages with <marquee>
Miriam Suzanne lives up to her “TerribleMia” Twitter handle when she creates a web page that animates from side to side with the marquee tag. This an old, ancient, long forgotten HTML element that I thought had stopped being supported by browsers but, alas, Miriam brings it back from the brink to show us how not to make an animation.
I’m kidding, of course. I think this is a cool and weird idea!
Alex Riviere then takes this bonkers idea even further and makes another demo where you can click on links to navigate between pages. He uses the IntersectionObserver to stop the animation on certain pages:
Bananas. But also cool. But also go straight to jail.
Sponsor
ImageKit.io
CSS is powerful for creating overlay effects but has a few drawbacks. The same code doesn’t work across devices, or the overlay effect is lost when a user downloads the image! How do we overcome this? Read on to understand how we solve this problem.
Sponsor
Jetpack from Anywhere: The Mobile App is Here
This robust app brings all of your favorite essential Jetpack features to your mobile device. Receive important notifications, keep tabs on site activity, restore a backup if necessary, scan for malware, view valuable site stats, and access other Jetpack features you love, anytime and anywhere.
[Chris]: “The data model behind Notion’s flexibility” from Jake Teton-Landis is an interesting read. Notion is one of those apps where you can feel the data model at work as you use it.
We built Notion on a framework that allows information to stand on its own, free from any constraint or container, instead putting the power in the hands of the user at a granular level. That framework is built on blocks.
Everything you see in Notion is a block. Text, images, lists, a row in a database, even pages themselves — these are all blocks, dynamic units of information that can be transformed into other block types or moved freely within Notion. They’re the LEGOs we use to build and model information.
Having literally every bit of data be a “block” from a paragraph to a Kanban card, from a list bullet to the pages themselves, and have them be able to somewhat effortlessly switch types, is pretty darn smart.
