[Robin]: My day job is at Sentry and I’ve never worked at a place where everyone cares so intensely about the quality of the codebase and the design. But one thing that I think could be improved is our CSS and so each Friday afternoon I focus just on that. It’s a couple of hours where I try to make a difference, scour through the codebase looking for things I don’t understand, but this tiny amount of time is already starting to prove how valuable small changes in the right direction can be.

So long as you’re patient and so long as you have a list.

At Sentry, we use the CSS-in-JS library Emotion to help us style our React components but we also used to have Bootstrap styles in Less that are then loaded in the head of the HTML. I noticed that as I was navigating the app that we had duplicate styles loading all over the place. We also had a ton of custom components in React that we really didn’t need — we could let the cascade in our app provide the base styles for lots of things instead. And so after rummaging about looking at a component I realized that there were all sorts of places where our styles were coming from: there was no single source of truth.

So! Instead of panicking, the first thing I did was make a list of every problem I could see with our styles. Then, the more spelunking into our codebase that I did, I started to refine that list into tasks. What files needed to be deleted? Which should we keep?

There are a lot more steps to this refactor than just this stuff, but it’s a start. This list of tasks isn’t really meant to be added to a Jira board or anything, it’s really just to inspire me to break up my pull requests into tiny chunks and then ship code every Friday afternoon. Each list item should ideally be one shippable chunk of code.

The end goal is a consistent and easily-understandable base of core styles: CSS declarations that affect every single page in our app whether or not that’s been refactored into Emotion yet. And I guess I don’t have any big advice here or anything other than it’s sometimes important to slow down on work like this. This project isn’t urgent, it’s not going to make the company a ton of money tomorrow, but once it’s complete in several months time, it’ll make our lives a tiny bit easier.

AVIF has Landed!

Big news this week: a wild new image format appears! And, as Jake Archibald writes, it’s called AVIF and it just launched in Chrome, so you can use it today with the help of the picture element:

Why would you want to use this new format though? Well, that’s because AVIF is remarkably tiny. In Jake’s post he shows how AVIF can be under half the size of a WebP image, which is about half the size of the common JPEG. However! As with all things when it comes to images on the web, there are a few caveats that are worth reading about.

[Chris]: I love seeing innovation here. HTML and browsers are ready for new technology like this and give us the tools to take advantage of resonsibly. But be extra careful! This isn’t necessarily an “if support, then use it” technology. I’ve seen AVIF images that are double the size of the original, there are situations where it’s lossless encoding doesn’t look great, and other cases where WebP is smaller. So this really complicates image equations and provides a lot of opportunity for image CDNs to step in and help us make better choices without every image being a manual job.

[Robin]: In a post the other day about text stroke and CSS, Chris wrote:

Whenever I think of stroked text on the web I think: nope.

This is interesting to me because whenever someone asks me about a new design that they want to implement that’s the first thing that goes through my head: is this possible to make on the web? And by possible I mean a lot of different things I guess. Have I built something like this before? Is it technically possible? Will I need to learn something new in order to build it? Will it require a ton of hacks? Is it worth doing all that work and is the effort worthy of the payoff?

I feel like at this point I have a fairly decent grasp of the limits of my knowledge when it comes to web design and development and a good understanding of what’s technically possible, too.

But most of those things have changed over time! There used to be a ton of things I’d say “nope” to today. There are so many gaps in the web platform that have been filled in with things like CSS Grid and Flexbox—I remember my first web design gig more than a decade ago and needing something like subgrid desperately.

In the end, I told the designer “nope.” This design is too much of a pain in the ass, the web cannot do this, please go back and make it less stressful. Sorry, thank you, you’re welcome.

The same can be said for images, there are plenty of times where I would simply avoid adding images to a website because of the performance concerns but now with response images that gap has been filled in, too.

So, my question: what gaps are there left to be filled in? Where on the web is that work left to do? I reckon that by looking at different design systems we can see what’s lacking in CSS and HTML, where most of the gaps can be found. I have opinions!

This reminds me: the other day I read this great post by Dave Rupert all about his concerns with browser diversity:

I think the Web platform’s most frustrating aspect is also it’s greatest asset: it’s slow. It’s not just slow, it’s “it took 10 years to ship the <main> element which is just a spicy div” kind of slow. It’s glacial.

This can be agonizing while you wait for a much needed feature to roll out in all browsers, only to find out five years in the process one browser refuses the entire premise of the feature (RIP HTML Imports). The big tradeoff is that web platform features have to run the gauntlet and more thinking is applied over time: robustness, naming, internationalization, accessibility, security, etc. all have proper time for consideration and aren’t rushed through like it’s a product sprint.

Dave hits the nail on the head here: the most frustrating thing about the web as a developer is its slowness. But, strangely enough, I think that as a user it is a feature and not a bug. The fact that all browsers have to communicate and garner consensus from the whole web platform before just doing a kickflip and introducing is vital for the health of the web.

So, let me re-frame my question then: where are the gaps in the web platform? And then, most importantly, how do we gather the consensus required to build them?

CSS transforms and perspective

One thing I don’t see enough on the web are experiments with CSS transforms and I was reminded of this the other day when I saw this great example from Meng To:

I think transforms and changing perspective in this way can be used in a lot of places, and not just on splashy marketing sites.

Speaking of which—ztext.js is a lil JavaScript library that lets you apply perspective and transforms to text. And the great thing about this is just how dosh garn easy it is to apply very fancy typographic techniques to whatever typeface you’re using on your site and even add animations to them, too:

Stay tuned to the blog in the coming weeks as we have a dedicated article to CSS perspective coming out soon that is more of a hands-on walkthrough rather than just our reference in the Almanac.

[Robin]: Over the weekend I read this post by Jim Nielsen about web technologies and syntax that I really enjoyed. The gist of the post is that the latest technical achievement is not always the answer to our problems, but rather a better understanding of the problem itself.

For example, CSS-in-JS is a way to solve the conflicts that plain old CSS can cause in a codebase of dozens of components and custom styles. However, in my experience at least, those problems are really just moved around rather than actually solved. We now have new problems, like what do we do with our global styles? Sure, we might have less CSS floating about the place and messing up our global scope, so to speak, but now we have dozens of custom styled components that we have to manage and maintain.

Anyway, back to Nielsen. He writes about this sort of complexity:

Think about it: HTML seems “simple” on the surface. It’s “just” a markup language, some text wrapped in tags. But if you go deeper than that, if you examine the grain of HTML, how it wants to be used, how it was designed to be used, you’ll see its proper usage is steeped in nuance and expertise. Entire books have been written on how to use HTML as the base grammar of the web, and to enhance from there. Same with CSS and JS.

So while that new blog post detailing the latest syntax or language additions appear to present a resolution to decades-long problems, the working knowledge of these languages are less about syntax and more about how things work.

That said, I think there are some new technical achievements that do more than just move the problem around. Instead, they go back to the beginning, understand the problem, and then start fresh with a solution. I think many improvements that have been made to the CSS language are like that. Some of them sure are nice additions to have, like filters and blend modes and what not. But CSS Grid and flexbox are two obvious examples where they’re making complex things really simple.

This reminds me of another post I read this weekend, this time from Tom MacWright where he describes a clean start for the web. One of the quotes that Tom mentions is from Richard O’Keefe, where he once said that “you cannot get a simple system by adding simplicity to a complex system.”

This is pretty good advice for building a design system and it’s extremely good advice for building things on the web.

Tom continues by re-imagining what web browsers could do if they started from scratch and became more restrictive and less burdened by legacy ideas of what the web should be:

Social networks are universally more restrictive than web pages but also more fun in significant ways, chief amongst them being that more people can participate. What if the rest of the web have that simplicity and immediacy, but without the centralization? What if we could start over?

It’s a super interesting post and I love reading things that push me to think about these sorts of things, although I’m not sure that I agree with everything Tom says — and that’s okay! The more important question that both of these posts bring up is this: are we really solving problems when we introduce a new framework or a new solution to a problem?

Or are we merely moving problems around?