A handy tool for getting an overview of your site’s CSS:
CSS Stats provides analytics and visualizations for your stylesheets. This information can be used to improve consistency in your design, track performance of your app, and diagnose complex areas before it snowballs out of control.
What you see is the big map of a sea of literature, one where each island represents a single author, and each city represents a book. The map represents a selection of 113 008 authors and 145 162 books.
This is a poetic experiment where we hope you will get lost for a while.
Cassie pointed me to this very nifty tool (that she plans to use in your SVG animation workshop): choose font from Google Fonts, type some text, and get the glyphs immediately translated into an SVG!
If you’re using web fonts, there are good performance (and privacy) reasons for hosting your own font files. And fortunately, Google Fonts gives you that option. There’s a “Download family” button on every specimen page.
But if you go ahead and download a font family from Google Fonts, you’ll notice something a bit odd. The .zip file only contains .ttf files. You can serve those on the web, but it’s far from the best choice. Woff2 is far leaner in file size.
This means you need to manually convert the downloaded .ttf files into .woff or .woff2 files using something like Font Squirrel’s generator. That’s fine, but I’m curious as to why this step is necessary. Why doesn’t Google Fonts provide .woff or .woff2 files in the downloaded folder? After all, if you choose to use Google Fonts as a third-party hosting service for your fonts, it most definitely serves up the appropriate file formats.
I thought maybe it was something to do with the licensing. Maybe some licenses only allow for unmodified truetype files to be distributed? But I’ve looked at fonts with different licenses—some have Apache 2 licensing, some have Open Font licensing—and they’re all quite permissive and definitely allow for modification.
Maybe the thinking is that, if you’re hosting your own font files, then you know what you’re doing and you should be able to do your own file conversion and subsetting. But I’ve come across more than one website in the wild serving up .ttf files. And who can blame them? They want to host their own font files. They downloaded those files from Google Fonts. Why shouldn’t they assume that they’re good to go?
It’s all a bit strange. If anyone knows why Google Fonts only provides .ttf files for download, please let me know. In a pinch, I will also accept rampant speculation.
Trys also pointed out some weird default behaviour if you do let Google Fonts do the hosting for you. Specifically if it’s a variable font. Let’s say it’s a font with weight as a variable axis. You specify in advance which weights you’ll be using, and then it generates separate font files to serve for each different weight.
Doesn’t that defeat the whole point of using a variable font? I mean, I can see how it could result in smaller file sizes if you’re just using one or two weights, but isn’t half the fun of having a weight axis that you can go crazy with as many weights as you want and it’s all still one font file?
Like I said, it’s all very strange.
Trys has been investigating how to incorporate CSS clamp() into the brilliant Utopia project. I won’t pretend to understand all the maths here—this is a very deep dive!
He’s also created a CSS generator Mark 2 if you want to use clamp() in your fluid type.
A timeline of city maps, from 1524 to 1930.
An excellent explanation of the new leading-trim and text-edge properties in CSS, complete with an in-depth history of leading in typography.
(I’m very happy to finally have a permanent link to point to about this, rather than a post on Ev’s blog.)
The latest edition in this wonderful series of science-fictional typography has some truly twisty turbolift tangents.
Episode three of the Clearleft podcast is here!
This one is a bit different. Whereas previous episodes focused on specific topics—design systems, service design—this one is a case study. And, wow, what a case study! The whole time I was putting the episode together, I kept thinking “The team really did some excellent work here.”
I’m not sure what makes more sense: listen to the podcast episode first and then visit the site in question …or the other way around? Maybe the other way around. In which case, be sure to visit the website for Wildlife Photographer Of The Year.
That’s right—Clearleft got to work with London’s Natural History Museum! A real treat.
This episode of the podcast ended up being half an hour long. It should probably be shorter but I just couldn’t bring myself to cut any of the insights that Helen, James, Chris, and Trys were sharing. I’m probably too close to the subject matter to be objective about it. I’m hoping that others will find it equally fascinating to hear about the process of the project. Research! Design! Dev! This has got it all.
I had a lot of fun with the opening of the episode. I wanted to create a montage effect like the scene-setting opening of a film that has overlapping news reports. I probably spent far too long doing it but I’m really happy with the final result.
And with this episode, we’re halfway through the first season of the podcast already! I figured a nice short run of six episodes is enough to cover a fair bit of ground and give a taste of what the podcast is aiming for, without it turning into an overwhelming number of episodes in a backlog for you to catch up with. Three down and three to go. Seems manageable, right?
Anyway, enough of the backstory. If you haven’t already subscribed to the Clearleft podcast, you should do that. Then do these three things in whichever order you think works best:
The World Ocean is as close as you can get to outer space without leaving Earth. It’s an entirely different universe, nothing like the life we have on land.
These wonderfully realistic photo effects from Lynn are quite lovely!
How do we tell our visitors our sites work offline? How do we tell our visitors that they don’t need an app because it’s no more capable than the URL they’re on right now?
Remy expands on his call for ideas on branding websites that work offline with a universal symbol, along the lines of what we had with RSS.
What I’d personally like to see as an outcome: some simple iconography that I can use on my own site and other projects that can offer ambient badging to reassure my visitor that the URL they’re visiting will work offline.
This is an interesting push by Remy to try to figure out a way we can collectively indicate to users that a site works offline.
Well, seeing as browsers have completely dropped the ball on any kind of ambient badging, it’s fair enough that we take matters into our own hands.
Robin Hawkes has made a lovely website to go with his newsletter all about maps and spatial goodies.
A forthcoming documentary about Stewart Brand (with music by Brian Eno).
I wrote a while back about one of my favourite photographs but this might just give it a run for its money.
It was only near the end of the 19th century that shutter speeds improved, as did emulsions, meaning that spontaneous moments could be captured. Still, smiling was not part of many cultures. It could be seen as unseemly or undignified, and many people rarely sat for photos anyway.
This is a lovely new project from Mark that gets very meta, cataloging specimens of type specimens:
This project will dig into specimens from these three perspectives: as artefacts made by and for font designers to evolve type culture; as tools for font users to make decisions about choosing and using type; and as effective marketing tools.
Do you have a favourite non-personal photograph?
By non-personal, I mean one that isn’t directly related to your life; photographs of family members, friends, travel (remember travel?).
Even discounting those photographs, there’s still a vast pool of candidates. There are all the amazing pictures taken by photojournalists like Lee Miller. There’s all the awe-inspiring wildlife photography out there. Then there are the kind of posters that end up on bedroom walls, like Robert Doisneau’s The Kiss.
One of my favourite photographs of all time has music as its subject matter. No, not Johnny Cash flipping the bird, although I believe this picture to be just as rock’n’roll.
This is a photograph of Séamus Ennis and Jean Ritchie. It was probably taken around 1952 or 1953 by Ritchie’s husband, George Pickow, when Jean Ritchie and Alan Lomax were in Ireland to do field recordings.
I love everything about it.
Séamus Ennis looks genuinely larger than life (which, by all accounts, he was). And just look at the length of those fingers! Meanwhile Jean Ritchie is equally indominatable, just as much as part of the story as the musician she’s there to record.
Both of them have expressions that convey how intent they are on their machines—Ennis’s uilleann pipes and Ritchie’s tape recorder. It’s positively steampunk!
What a perfect snapshot of tradition and technology meeting slap bang in the middle of the twentieth century.
Maybe that’s why I love it so much. One single photograph is filled with so much that’s dear to me—traditional Irish music meets long-term archival preservation.
CSS got some pretty nifty features recently. There’s the min() and max() functions. If you use them for, say, width you can use one rule where previously you would’ve needed to use two (a width declaration followed by either min-width or max-width). But they can also be applied to font-size! That’s very nifty—we’ve never had min-font-size or max-font-size properties.
There’s also the clamp() function. That allows you to set a minimum size, a default size, and a maximum size. Again, it can be used for lengths, like width, or for font-size.
Over on thesession.org, I’ve had some media queries in place for a while now that would increase the font-size for larger screens. It’s nothing crucial, just a nice-to-have so that on wide screens, the font is bumped up accordingly. I realised I could replace all those media queries with one clamp() statement, thanks to the vw (viewport width) unit:
font-size: clamp(1rem, 1.333vw, 1.5rem);
By default, the font-size is 1.333vw (1.333% of the viewport width), but it will never get smaller than 1rem and it will never get larger than 1.5rem.
That works, but there’s a bit of an issue with using raw vw units like that. If someone is on a wide screen and they try to adjust the font size, nothing will happen. The viewport width doesn’t change when you bump the font size up or down.
The solution is to mix in some kind of unit that does respond to the font size being bumped up or down (like, say, the rem unit). Handily, clamp() allows you to combine units, just like calc(). So I can do this:
font-size: clamp(1rem, 0.5rem + 0.666vw, 1.5rem);
The result is much the same as my previous rule, but now—thanks to the presence of that 0.5rem value—the font size responds to being adjusted by the user.
You could use a full 1rem in that default value:
font-size: clamp(1rem, 1rem + 0.333vw, 1.5rem);
…but if you do that, the minimum size (1rem) will never be reached—the default value will always be larger. So in effect it’s no different than saying:
font-size: min(1.rem + 0.333vw, 1.5rem);
I mentioned this to Chris just the other day.
Anyway, I got the result I wanted. I wanted the font size to stay at the browser default size (usually 16 pixels) until the screen was larger than around 1200 pixels. From there, the font size gets gradually bigger, until it hits one and a half times the browser default (which would be 24 pixels if the default size started at 16). I decided to apply it to the :root element (which is html) using percentages:
:root {
font-size: clamp(100%, 50% + 0.666vw, 150%);
}
(My thinking goes like this: if we take a screen width of 1200 pixels, then 1vw would be 12 pixels: 1200 divided by 100. So for a font size of 16 pixels, that would be 1.333vw. But because I’m combining it with half of the default font size—50% of 16 pixels = 8 pixels—I need to cut the vw value in half as well: 50% of 1.333vw = 0.666vw.)
So I’ve got the CSS rule I want. I dropped it in to the top of my file and…
I got an error.
There was nothing wrong with my CSS. The problem was that I was dropping it into a Sass file (.scss).
Perhaps I am showing my age. Do people even use Sass any more? I hear that post-processors usurped Sass’s dominance (although no-one’s ever been able to explain to me why they’re different to pre-processers like Sass; they both process something you’ve written into something else). Or maybe everyone’s just writing their CSS in JS now. I hear that’s a thing.
The Session is a looooong-term project so I’m very hesitant to use any technology that won’t stand the test of time. When I added Sass into the mix, back in—I think—2012 or so, I wasn’t sure whether it was the right thing to do, from a long-term perspective. But it did offer some useful functionality so I went ahead and used it.
Now, eight years later, it was having a hard time dealing with the new clamp() function. Specifically, it didn’t like the values being calculated through the addition of multiple units. I think it was clashing with Sass’s in-built ability to add units together.
I started to ask myself whether I should still be using Sass. I looked at which features I was using…
Variables. Well, now we’ve got CSS custom properties, which are even more powerful than Sass variables because they can be updated in real time. Sass variables are like const. CSS custom properties are like let.
Mixins. These can be very useful, but now there’s a lot that you can do just in CSS with calc(). The built-in darken() and lighten() mixins are handy though when it comes to colours.
Nesting. I’ve never been a fan. I know it can make the source files look tidier but I find it can sometimes obfuscate what you’re final selectors are going to look like. So this wasn’t something I was using much any way.
Multiple files. Ah! This is the thing I would miss most. Having separate .scss files for separate interface elements is very handy!
But globbing a bunch of separate .scss files into one .css file isn’t really a Sass task. That’s what build tools are for. In fact, that’s what I was already doing with my JavaScript files; I write them as individual .js files that then get concatenated into one .js file using Grunt.
(Yes, this project uses Grunt. I told you I was showing my age. But, you know what? It works. Though seeing as I’m mostly using it for concatenation, I could probably replace it with a makefile. If I’m going to use old technology, I might as well go all the way.)
I swapped out Sass variables for CSS custom properties, mixins for calc(), and removed what little nesting I was doing. Then I stripped the Sass parts out of my Grunt file and replaced them with some concatenation and minification tasks. All of this makes no difference to the actual website, but it means I’ve got one less dependency …and I can use clamp()!
Remember a little while back when I was making a dark mode for my site? I made this observation:
Let’s just take a moment here to pause and reflect on the fact that we can now use CSS to create all sorts of effects that previously required a graphic design tool like Photoshop.
It feels like something similar has happened with tools like Sass. Sass was the hare. CSS is the tortoise. Sass blazed the trail, but now native CSS can achieve much the same result.
It’s like when we used to need something like jQuery to do DOM Scripting succinctly using CSS selectors. Then we got things like querySelector() in JavaScript so we no longer needed the trailblazer.
I’ve said it before and I’ll say it again, the goal of any good library should be to get so successful as to make itself redundant. That is, the ideas and functionality provided by the tool are so useful and widely adopted that the native technologies—HTML, CSS, and JavaScript—take their cue from those tools.
You could argue that this is what happened with Flash. It certainly happened with jQuery and Sass. I’m pretty sure we’ll see the same cycle play out with frameworks like React.