Mona Sans & Hubot Sans
Two new lovely open source variable fonts from Github.
Two new lovely open source variable fonts from Github.
A whole lotta nice fonts—most of them variable fonts—from Indian Type Foundry.
This version of Roboto from Font Bureau is a very variable font indeed.
Prompted by Utopia, Piper shares her methodology for fluid type in Sass.
This font is a crossover of different font types: it is semi-condensed, semi-rounded, semi-geometric, semi-din, semi-grotesque. It employs minimal stoke thickness variations and a semi-closed aperture.
Marvin has some competition! Here’s another beautiful sci-fi variable font:
MD Nichrome is a display typeface based on the typography of paperback science fiction from the 70s and early 80s.
Oh, this is smart! You can’t target pseudo-elements in JavaScript, but you can use custom properties as a proxy instead.
Robin makes a good point here about using dark mode thinking as a way to uncover any assumptions you might have unwittingly baked into your design:
Given its recent popularity, you might believe dark mode is a fad. But from a design perspective, dark mode is exceptionally useful. That’s because a big part of design is about building relationships between colors. And so implementing dark mode essentially forced everyone on the team to think long, hard, and consistently about our front-end design components. In short, dark mode helped our design system not only look good, but make sense.
So even if you don’t actually implement dark mode, acting as though it’s there will give you a solid base to build in.
I did something similar with the back end of Huffduffer and The Session—from day one, I built them as though the interface would be available in multiple languages. I never implemented multi-language support, but just the awareness of it saved me from baking in any shortcuts or assumptions, and enforced a good model/view/controller separation.
For most front-end codebases, the design of your color system shows you where your radioactive styles are. It shows you how things are tied together, and what depends on what.
Oh, nice! A version of the classic Proxima Nova that’s a variable font that allows you to vary weight, width, and slant.
A reminder that the contens of custom properties don’t have to be valid property values:
From a syntax perspective, CSS variables are “extremely permissive”.
Ever wanted to set some text in 70% Times New Roman and 30% Arial? Me neither. But now, thanks to variable fonts, you can!
This is such a clever use of variable fonts!
We can use a lighter font weight to make the text easier to read whenever dark mode is active.
A history of typesetting from movable type to variable fonts.
Everything you ever wanted to know about variable fonts, gathered together into one excellent website.
In this interview, Biance Berning says:
Cassie Evans from Clearleft is an interesting person to follow as she combines web animation with variable font technology, essentially exploring the technology’s practicality and expression.
Hells yeah!
We’re only just scratching the surface of what variable fonts can do within more interactive and immersive spaces. I think we’ll see a lot more progress and experimentation with that as time goes on.
Play around with this variable font available soon from Google Fonts in monospaced and sans-serif versions.
A showcase of fun experiments with variable fonts, courtesy of Mandy.
Don’t write
fopen
when you can writeopenFile
. WritethrowValidationError
and notthrowVE
. Call that namefunction
and notfct
. That’s German naming convention. Do this and your readers will appreciate it.
Heydon cracks me up—his Patterns Day is going to have you crying with laughter; guaranteed!
Here he is talking about custom properties in CSS as part of his Making Future Interfaces video series.
Here’s a tiny lesson that I picked up from Trys that I’d like to share with you…
I was working on some upcoming changes to the Clearleft site recently. One particular component needed some SVG background images. I decided I’d inline the SVGs in the CSS to avoid extra network requests. It’s pretty straightforward:
.myComponent {
background-image: url('data:image/svg+xml;utf8,<svg> ... </svg>');
}
You can basically paste your SVG in there, although you need to a little bit of URL encoding: I found that converting #
to %23
to was enough for my needs.
But here’s the thing. My component had some variations. One of the variations had multiple background images. There was a second background image in addition to the first. There’s no way in CSS to add an additional background image without writing a whole background-image
declaration:
.myComponent--variant {
background-image: url('data:image/svg+xml;utf8,<svg> ... </svg>'), url('data:image/svg+xml;utf8,<svg> ... </svg>');
}
So now I’ve got the same SVG source inlined in two places. That negates any performance benefits I was getting from inlining in the first place.
That’s where Trys comes in. He shared a nifty technique he uses in this exact situation: put the SVG source into a custom property!
:root {
--firstSVG: url('data:image/svg+xml;utf8,<svg> ... </svg>');
--secondSVG: url('data:image/svg+xml;utf8,<svg> ... </svg>');
}
Then you can reference those in your background-image
declarations:
.myComponent {
background-image: var(--firstSVG);
}
.myComponent--variant {
background-image: var(--firstSVG), var(--secondSVG);
}
Brilliant! Not only does this remove any duplication of the SVG source, it also makes your CSS nice and readable: no more big blobs of SVG source code in the middle of your style sheet.
You might be wondering what will happen in older browsers that don’t support CSS custom properties (that would be Internet Explorer 11). Those browsers won’t get any background image. Which is fine. It’s a background image. Therefore it’s decoration. If it were an important image, it wouldn’t be in the background.
Progressive enhancement, innit?