> What a wonderful way to add massive complexity to font rendering while delivering spectacularly little value.
I'll attempt to explain the value, because I don't think this demo is doing a good job of showing that. parametric and variable fonts might seem like "pointless sugar," but it's the combination of mostly two things that make this a huge deal: responsive typography for better legibility, and reducing the number and size of font files served over the web.
let's say I have four font files being used on my website -- regular, bold, italic, bold italic. let's say that's 50k per file, so 200k for four network requests. with a variable font, it's maybe ~70k for a single request. that's a huge improvement, but it's not even all that these fonts offer.
responsive typography (adjusting for the right font weight and characteristics depending on the size of the display) is very important for legibility.[1] The slick ultrathin fonts that look good on a 27" 5k display are unreadable on a smaller display. fonts optimized for body text look terrible when used at large sizes, hence the existence of "display" typefaces. there is so much bloat in having tons of different files for this, when the libraries that interpolate fonts in font creation software[2] can be used on the fly instead of during a compilation step.
font rendering is cheap, sending fonts over the wire is not -- so when you frame this new font tech as something that is just as much about speeding up the web as it is about speeding up the design process, it's a little less pointless.
You can look at it from two ways. It might save some network bandwidth when designers want multiple fonts, but is it worth adding even more complexity to browsers?
Does the average user really care about fonts? I would say definitely not. Most people don't even notice the font.
> Does the average user really care about fonts? I would say definitely not. Most people don't even notice the font.
most people don't think consciously about the font, but that doesn't mean they don't notice or that their experience will be the same reading in one font vs another. some companies spend a lot of money on this. facebook and google, for example, do a/b testing on fonts to see which perform best in ads.
but users also care when a font becomes illegible on the wrong size display, and/or wrong pixel density. the less pixel dense a display is, for example, the bolder a font needs to be. this new tech makes it super easy for developers to actually execute these best practices, eliminates multiple steps from the asset pipeline, reduces network requests, and reduces file size. check out the google fonts analytics page[1] for an idea of how many trillions of fonts served that this will affect.
Making use of the fonts on the users machine requires even less bandwidth while allowing the user to view things in whatever font they find easiest on their eyes. Including fonts on web sites has always been about designers getting their way. This is just more of the same.
Besides, the OP clearly described the benefits in being able to adjust the font according to screen density. Using system fonts doesn't magically solve that issue.
I would, if the user's machine came with a preinstalled set of images that were a close match to the need. I don't think the web browser exposes the user's standard icon sets on the web, but it absolutely should.
> Besides, the OP clearly described the benefits in being able to adjust the font according to screen density. Using system fonts doesn't magically solve that issue.
Using any font made in the last 20 years solves that issue. Vector fonts scale to any screen density just fine.
On top of that, if you don't shove a webfont down the user's throat, a user can even pick their favorite font size and density to match their screen and viewing preferences.
I'll attempt to explain the value, because I don't think this demo is doing a good job of showing that. parametric and variable fonts might seem like "pointless sugar," but it's the combination of mostly two things that make this a huge deal: responsive typography for better legibility, and reducing the number and size of font files served over the web.
let's say I have four font files being used on my website -- regular, bold, italic, bold italic. let's say that's 50k per file, so 200k for four network requests. with a variable font, it's maybe ~70k for a single request. that's a huge improvement, but it's not even all that these fonts offer.
responsive typography (adjusting for the right font weight and characteristics depending on the size of the display) is very important for legibility.[1] The slick ultrathin fonts that look good on a 27" 5k display are unreadable on a smaller display. fonts optimized for body text look terrible when used at large sizes, hence the existence of "display" typefaces. there is so much bloat in having tons of different files for this, when the libraries that interpolate fonts in font creation software[2] can be used on the fly instead of during a compilation step.
font rendering is cheap, sending fonts over the wire is not -- so when you frame this new font tech as something that is just as much about speeding up the web as it is about speeding up the design process, it's a little less pointless.
1. https://alistapart.com/blog/post/variable-fonts-for-responsi...
2. https://github.com/LettError/MutatorMath