To kick things off this week, here’s a beautiful website all about a new typeface for coding called Recursive Sans and Mono. The nifty thing about this typeface is that it’s also a rather intricately made variable font, which means that it has a ton of customizable options to best suit our needs.

So effectively this is actually two separate typefaces in one font file. That means you can animate between the two easily if needs be! In the type specimen website there’s a great example of how to switch between these different options, or “axes”, with the CSS font-variation-settings property:

What does this mean? Well, it means we have all this control now that was previously impossible, we can maybe have more performant sites since we don’t need to download multiple resources, and we can animate text like so:

The example on the left is of a regular spaced font that’s switching between regular and bold, but the example on the right shows how since Recursive is a monospaced variable font there’s no need for that jarrring text jump. Interesting stuff!

📝 How to tell the difference between a React component and a design pattern

[Robin:] The odd thing about design systems and front-end development is that not everything in a system can be turned into a component or a variable or a design token. Ethan Marcotte mentioned this just the other day:

A design I change, a pattern I build: they’re not just artifacts, but threads in a larger web. The results of my work—of our work—ripple throughout the rest of the system, and a systems worker strives to understand that.

Jina Anne described this in detail when she wrote about how a design system is much more than just the deliverables:

So in the design systems work we do, you often think of a style guide. Or a component library. Or a Sketch UI Kit. And there are arguments on whether either of those things can be called a design system if it doesn’t include this other thing or that other thing. We even talk about whether design systems are products or are more of a service. My take? The word “design” and “system” used in combination together literally just means to systemize your design (and in my world view that is more about the overall experience). And so if for you that means a Sketch UI Library, then you do you! My point is I think there is too much focus on the deliverables in the first place.

This leads into an area of design systems work that’s taken me years to figure out: there’s an enormous difference between a React component and a design pattern. Also, feel free to replace “React” with any other framework here — that’s just what I’m most familiar with today.

Many problems in my design systems career have been caused by mistaking a pattern for a component, and vice versa — so let’s begin with The Tale of IconLink: Once upon a time, we had a component called Icon that looked like this:

<Icon name="pencil">Edit</Icon>

This would render a pencil icon next to some text that said “Edit.” In the mockups, however, designers would constantly place icons within links and so a new component was born: IconLink and it worked like this:

<IconLink linkSrc="http://gusto.com" iconName="pencil" linkText="Edit" /> 

This made sense at the time. We’re using this pattern everywhere, so let’s make it a component. But! Under the hood of this component it was effectively made up of the following two components that already existed:

<Link href="http://gusto.com"> <Icon name="pencil">Edit</Icon> </Link>

It took me a long time to realize that IconLink should never have existed in the first place and we should just use Links with Icons embedded within them because it was always confusing why we needed the linkText prop or the linkSrc prop. iconName is also pretty confusing if you’re familiar with the Icon component, too.

(This was when I realized every component API in your library should teach you how all the other components work, so if iconName is the prop for adding an icon to one component, then that should be the case for the lot of them.)

Now, the problem here is that not only is the API more confusing and named differently from other components, but that the API is now much larger. You have to remember that things are different for this one component, as it becomes one edge case. And not only that, but if we want to add a new prop to Icon, then we probably will forget to update IconLink in the process. This makes things generally much harder to maintain as time passes.

So the fewer relationships between components that need to be maintained in a library, the better. This also means that any components like this — that just passe props down to another component — is pretty much always a bad idea. Icons inside links is a design pattern (a common agreement between everyone in the org that this is okay) but it shouldn’t be a component for this very reason.

My point with all this is that it’s easy to see every problem or design as a new component or a mix of currently existing components. But instead, we should make components that can slot into each other neatly, rather just continue to make more components. Now, after about two weeks of refactoring, we’ve deprecated and deleted IconLink, making our library of components a little bit easier to understand.

Things are 1% less confusing today, and that’s enough for me.

A couple of weeks ago, Chris jotted down his thoughts about whether web design has gotten easier in the past 10 years. Are the languages improving? Is front-end development becoming more specialized and is it getting easier for new folks to join the field? Well, on that front he had the following to say about the CSS language:

CSS has gotten easier. We use way fewer “hacks” all the time. I can literally feel it. The CSS we write today feels so intentional and direct. 10 years ago I feel like every other element had some kind of weird hack on it, and today, almost none. If CSS feels any harder, I’d wager it’s because the sites we’re building are bigger and more complex so the styling systems for them need to be all the more robust and the dangers of getting it wrong more stark.

I was talking to a front-end developer a year ago and I realized that they didn’t know what the float property was or how it worked… and they didn’t need to know! They didn’t know what a clearfix was or why it was useful, they didn’t have to know about all these whacky browser bugs that have been neatly catalogued in my brain after a decade of working in the field. Now they can start a project with flexbox and CSS Grid and make much more powerful, flexible, and user-friendly designs.

This is absolutely worthy of celebration, as Robin Sloan mentioned just this week:

For all that is Bad with web development in 2020, the steady stream of powerful new CSS capabilities is Very Good

But! The one area of front-end development that I would argue has been almost entirely ignored since 2008 is the HTML language itself. Chris writes:

HTML5 was the only big HTML change in the last decade, and it wasn’t particularly dramatic. It’s cool it’s the looser variant (instead of getting XHTML3 or something). More compatible this way. Maybe I’ll close my <br /> and maybe I <br> won’t. Having better semantic tags (e.g.<article>) is great. Input types are wonderful. But none of this pushes HTML to be significantly easier or harder.

I would argue that, yes, HTML has not gotten any easier or harder since then — and that leads into some unforeseen difficulty for us developers. Although sure, we’ve had some big improvements, like the support for responsive images, but besides that, I can’t think of anything that improves my daily life as a web developer.

I have a hunch that because HTML hasn’t been developed much over the last decade it means that we’ve had to rely on complex frameworks and libraries to do the work the browsers should be doing for us. Dave Rupert wrote about this very thing recently when it comes to accordions and the details element:

At the risk of being a broken record; HTML really needs <accordion>, <tabs>, <dialog>, <dropdown>, and <tooltip> elements. Not more “low-level primitives” but good ol’ fashioned, difficult-to-get-consensus-on elements. A new set of accessible controls for a modern era… except that these things have been in-use on nearly every major website and application for the last two decades and exist in every major design system.

I couldn’t agree with this more and I’m pretty sure this is why it’s so hard to make websites accessible these days. We’re asking browsers to do something that they just don’t want to do and that requires a ton of JavaScript and framework magic or npm install react-accordion or whatever.

So here’s what I would like to see in 2020: I want our community to take all these react-whatever libraries and to use that as the beginning of a new set of standards for us to build into HTML itself, and with accessibility in mind from the ground up. And then we need to collect a bunch of these new elements under a single umbrella to get everyone — browser makers, developers, and users — enthusiastic about it all.

We could call it 2 Fast 2 HTML. Or HTML: Next Generation. Or perhaps HTML: Reloaded. Or maybe we could just call it HTML6? That would be fine too, I guess.