I created this demo to see how animated variable fonts would behave when both the weight and slant are both animated.
The demo uses a subsetted variable font reduced down to 3Kb in size, in a Source page. The font animates smoothly from 100 to 900 weight and also from upright (normal) to a slant of 10 degrees (italic).
The RW side of using Variable Fonts is not too difficult and after some perseverence with Source it only takes a few lines of code to integrate VF’s into an existing Source project. I think a stack to control all features available to VF’s could end up being a monster.
The much bigger issue I think ,is getting hold of, or creating a suitable and also carefully subsetted VF, and there is lots of scope to unknowingly use huge fonts. Also, with the power of VF’s there is further opportunity to ruin a good font just because it has a parameter that can be adjusted. To use VF’s you relly need an good appreciation of typography.
That’s the key issue, in my opinion. I bet, people will be creating some crazy monstrosities—just because it will be possible—without regard for good taste and good design. Personally, I am not going to use variable fonts in a foreseeable future – even if that would be easy to do from the technical point of view.
Yes, but some people will always create monstrosities, even if they only have Verdana, or tiny grey Arial. (Remembering those days still makes me shudder — typographically, the web is now a much better place!)
The biggest reason for embracing variable fonts is that they are becoming standard in the type industry, and for good reasons. Most type designers have been interpolating the weights of the fonts they’ve designed for decades (i.e. designing a light and a heavy weight, and creating the intermediate weights mechanically), so it’s an easy move to create variable versions for them. And for the most sophisticated type families, starting with Adobe Originals more than twenty years ago, designers didn’t just create multiple weights but also different versions for use at different sizes (caption, text, subheading, display, poster). By the time you multiply weights by optical sizes, you get 20 or more individual fonts. Variable fonts replace all these with just one, which is super-efficient for downloads, and also allows infinite gradations rather than fixed increments. This is why Apple have moved to variable versions of San Francisco and New York for their interface design (SF had nine weights and three optical variants, resulting in 27 fonts, before ‘variablisation’).
Nobody can really justify having more than four or five fonts on a website (and I suspect most make do with less than that), which is why the web has been held back, typographically, compared to what is normal in print these days. And, anyway, why would we complain? Our little typographic two-stroke lawnmower engine has just been replaced with a turbo-charged V8.
It isn’t something that you have to do or are being forced into doing like having a Smart Meter fitted (in the UK).
Over time however, I think it will be seen as a very progressive stage of web design. I predict in the future, that we will refer to designs as being created before variable fonts (BVF). For a long time general web design has followed the rigid path of choosing a heavy weight serif upright font for all headings and a 400 sans serif upright font for all text, links, navigation and buttons and avoiding using italic or strong text. It is similar to what happened when Font Awesome 4 symbols were overused (and still are IMHO).
A web page that uses well chosen variable fonts and no FA symbols looks like a current design to me and much closer to professional DTP layouts. If you look at a well laid out DTP print page, it is usually very difficult to age the document without a date, because it isn’t limited to the same limits that were there for web design without resorting to loading multiple and often large font files.
Another benefit, if you create lots of web sites, is that you can use just 1 good font for everything, yet adjust each to make each one unique. Anyone who is interested in fonts will very likely have an enormous collection fonts, amassed in the pursuit of chasing the ideal font.
As they said in the film White Chicks, “Once you go variable, you can’t go back” or something along those lines.
Oh dear, Font Awesome really is the Comic Sans of 2021! (And JQuery its Java).
But, yeah, Gary, you’ve nailed it. Variable fonts are a breakthrough technology (even if, actually, they’re really just a reworking of Adobe’s Multiple Masters and Apple’s GX fonts from the 90s). To my mind the three big game-changers of the moment are CSS grid, variable fonts, and CSS variables (which, from another point of view, are ‘swatches’). Already they seem to be giving us a radically different looking web.
Font weight is the animatable property and has no reliance on variable fonts.
The fact is that loading the weights to animate between is more efficient with variable fonts as per all the previous discussions.
Never the less, even with variable fonts, it remains a nice touch IF the weights are already to be loaded. Loading fonts just to animate hover effects seems counter to efficient practices. Animating an SVG stroke width would be a lot cleaner way to go.
Yes, but with font-variation-settings all axes are animatable, not just font weight (which is how Gary can animate the slant axis on his buttons). This opens up interesting new possibilities for UX, such as using a condensed variant for menu items which becomes expanded for the currently selected item. Loading a variable font just to do this would be, as you say, counter productive (for me the compelling argument for variable fonts is to tweak font styles for optimal reading experience at different sizes). But variable fonts are efficient in their own right, just to replace two or three weights of a static type family. And having done so, we suddenly have a toolkit with innumerable variations which we can use for different purposes.
It’s weight (100 to 900) and also slant (0deg to 10deg) that are both being animated in this demo. The main large SPOOKY text looks to me like a pretty smooth animation created with what I assume to be multiple frames of weights and slants.
It’s really just a demo of capability rather than something that every Weaver should add to their existing sump of fonts. It you are using a variable font, then this is an added bonus for no additional downloads required and a couple of lines of CSS.
I understand the increased number of animation opportunities but I really do question how much it adds to the UX in the context of menus and buttons. Most such effects really only work on hover which is not going to work on touch devices.
I have long championed variable fonts and was until recently going to release a stack for them but I am cautious about getting users excited about animation effects which will get overdone and misused in the RW context.
“I have long championed variable fonts and was until recently going to release a stack for them but I am cautious about getting users excited about animation effects which will get overdone and misused in the RW context.”
I’m keen to see RW users have access to the professional-level sophistication of contemporary OpenType and Variable features, and CSS grid. I’d also like to help them understand how to use these features to produce professional quality type on the web. It’s not everybody’s cup of tea, but when Adobe and Affinity have been putting these features into the hands of users for years, and support them with excellent tutorials, there is no reason why RW users have to stay stuck in the world of ‘styled text’. Animation, too, is coming of age on the web — and into users’ hands. Lottie makes it really easy, and now Michael has produced a stack to make Lottie really easy. But there is also Hype, After Effects, SVG animation etc.
RW will get left behind if it doesn’t move quickly to embrace the things that people are doing elsewhere on the web.
The problem with these things is that people will over use them. Animation libraries, relatively speaking, are huge, Hype, GSAP etc etc are great tools but if people are using them to make a few small animations (which will be the case with RW/stacks) then they are huge overkill.
It is now common to see RW produced pages with coverage values of less than 5% which is atrocious. I think people should spend more time in the chrome coverage dev tool and less on doing things for the sake of it.
Variable fonts are a great solution to increase the coverage and efficiency. I think that fact and better typography should be the focus of their promotion.
I can only echo what Tav says. I am not at all a fan of animation. I’m not entirely sure if that’s a personal choice from the off, or if tav has just drummed it into me years ago!
But the fact remains, in most instances the end-user never sees this stuff as it’s either removed on their device or they simply never register it.
I’m thru a proposal at the moment for a new potential client who wants his site rebuilt, and he wants a lot of hover effects, as a template he saw in Wordpress has it and he really likes it. I tried to explain it’s mostly pointless, but no. I even checked his analytics and almost 90% of his traffic is mobile, but he still insists. I doubt I’ll take the project on.
On my web design business website I have something along the lines of “most designers produce websites that showcase their own skill, not the clients”. By that I mean they are visually stunning but do nothing to turn a site visitor into a client. Often “designers” lose sight of the point of a website. IMO.
That’s good caution. This VF animation is just a demo of what VF’s can do when animation is applied and you can see the different weights and styles being generated. I can’t however, see many, if any, applications where a SPOOKY type of animation would be valuable. However, I can’t imagine now building a new site that won’t use 1 single relatively small VF and my use of different weights and style has grown beyond the basic 2 that I was using until recently.
The challenge I think is how to implement VF’s using Stacks in RW, so that it doesn’t add additional edit mode bloat or confusion or additional drag and drop mental agility. IMHO it makes sense to add a framework setup level choice of using either VF’s or normal fonts, but not both. Then from a framework level, gain access to the various to various VF configurations such as what and how this is implemented in Source. I.e. if you select italic in a Header, Paragraph, button, nav, accordion, etc, the VF defined italic gets used.
I don’t think VF animation is a good fit for a stack function unless the VF stack is fully packaged with a subsetted royalty free selection of VFs in preconfigured setups. I.e. choose a VF between 1 and 10 and that’s what you get without any further thoughts required. There’s a great idea for someone to sell such a $49 stack and if Comic Sans is included, it will fly off the shelves.
I have no problem with your nice lightweight CSS implementation. I was in no way digging at that. My only point was that we should not encourage people to load more fonts just so that they can then animate them.
I agree, my little stack was specifically aimed at this also that additional axes can be added when required.
On that subject though, while edit mode bloat was everyones prime concern a couple of years ago, it’s surprising how it has come back again without users being bothered now that there is less discussion of it on forums. Turn on the stacks dev render mode timing and you’ll see.