A seasonal variable font demo

Ha. I meant bloat more in the sense that a paragraph stack could be created (or coppied) with a full array of the possible VF axes, etc…

Edit mode bloat is now more or a good thing than ever, becasue it can be added to the list of reasons to justify buying a new MBP.

Animation is a bit of a red-herring here. Where VF animation will fly is in hero panels and call-outs etc., where it can work very well and bring text to the moving image party. Gary’s example is a case in point — it works very well as a seasonal banner. Many users enjoy and expect elements of movement on the page and — unless their purpose in browsing is driven by a serious intent — find a static site a dull affair. But now animation is catered for in many different ways, and is not the rationale for variable fonts. They just bring additional possibilities to it.

When it comes to UX, subtle and appropriate use of transformation, transition and movement can greatly enhance users’ pleasure in browsing. These days does anyone not use CSS transitions to give polish to a change of state? The era of jumpy interfaces is thankfully past. We like menus to ease onto the screen, drawers to glide open, elements to move with initial delay and subsequent acceleration. But the problem in RW is that there is no easy way for Weavers to implement behaviours on click — hover is easy enough to anyone who can write some CSS (or apply a swatch), but it’s a bit of an irrelevance given that it doesn’t work on mobile. The much more important stuff is what happens when something is pressed (like getting a hamburger to change into a close button on a menu modal). But unless you can code that yourself, you’re unlikely to find a stack that is going to do it for you, the way you want it done.

Then again… ;-)

https://www.typearture.com/variable-fonts/

Completely agree - that is why I’ve specifically only criticised its use in buttons and menus on this thread.

Yes, absolutely and all fine again as it is low impact both in terms of code and processing power.

No problem with this either as again it is just a bit of CSS and has been around for years without issue.


My only response was to the use of enormous JS animation libraries within the RW context. Users have no clue what they are adding to their page in order to produce a small effect that they think is “cool” for whatever justifiable, other otherwise, reason.

An example can be found in two comparable stacks. One uses a <8kB custom JS file to control its effects, the other uses something that is approximately 80kB (10x as big) to produce the same feature set.

I can produce many other examples of similar scope and it is obviously much easier for vendors to use an off the shelf gargantuan library than it is to write their own. RW users do not know how to check these things (nor should they have to) and so believe everything that their heroes tell them. As with all marketing, a balanced view is not a productive sales tool.

My comments were, therefore, not anti animation per se at all but rather aimed to dampen enthusiasm for people to unwittingly make their pages more an more loaded with unused code. I offer exhibit A: