Uppestcase and Lowestcase Letters: Advances in Derp Learning
A genuinely interesting (and droll) deep dive into derp learning …for typography!
A genuinely interesting (and droll) deep dive into derp learning …for typography!
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.
Type and space are linked, so if you’re going to have a fluid type calculator, it makes sense to have a fluid space calculator too. More great work from Trys and James!
This could give a big boost to web performance!
You don’t have to use web fonts—there are some pretty nice options if you stick to system fonts (like Georgia, Charter, and Palatino).
Oh, nice! A version of the classic Proxima Nova that’s a variable font that allows you to vary weight, width, and slant.
Sounds like some convergent thinking with the ideas behind Utopia.
I think that the idea that that any typographic attribute (including variable font parameters) can be a function (linear, exponential, stepped, Bezier, random, or otherwise) of any given input variable (user preference, screen dimensions, connection speed, time of day, display language, or whatever else) is an incredibly powerful one, and worth exploring as an aesthetic as well as a technical proposition.
Here’s a demo you can play with.
A terrific in-depth look at improving the performance of web fonts.
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.
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.
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.
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.
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.
Using ligatures to create a s*** font that f***ing censors bad language automatically.
I’d watch this game show:
Welcome to the first installment of a new series on Typewolf, where I’ll be identifying the fonts used in popular things. The focus here is on anything you might encounter in contemporary visual culture—movie posters, TV shows, book covers, etc.
Ever wanted to set some text in 70% Times New Roman and 30% Arial? Me neither. But now, thanks to variable fonts, you can!
A treasure trove of case studies and interviews.