Home / Newsletters /

#239: New CSS Tricks and Design Engineers

First up this week, Andy Bell wrote this fantastic piece where he dives into a ton of new CSS features that we can use today:

CSS is great and getting better all the time. Over recent years, especially, it has evolved really fast, too. Understandably, some of the really handy powers CSS gives you might have slipped you by because of this, so in this article, I’m going to show you some really handy stuff you can do with modern CSS today, and also share some stuff that we can look forward to in the future.

This is a shocking post to me because there’s just so much stuff that’s been going on in the world of CSS. Here’s a quick list of new-ish features from Andy’s post (I’ve added links that dive into each of these features if you’d like more info):

That’s a lot of new features to keep up with. Most of these I have a pretty good handle on, I think, although I’m probably unaware of the coolest tricks we can pull off with min, max, and clamp. The main thing I was unaware of here was the ex unit, which Andy describes like this:

The ex unit is equal to the height of the lowercase x character — also known as the “x-height” in more traditional typography. This is really useful for working accurately and responsively with the vertical axis of your typography. One really handy use case for this is making an SVG icon the same height as your text.

All of these new abilities that have been added to the CSS language over the past year or so feel like small but important improvements. The way I tend to think of CSS is a language with these big gaps in some places—for example, layout was one of those enormous gaps until CSS Grid shipped and filled it in.

What does the future of CSS look like and where are those gaps today? Well, I think CSS needs container queries but it looks like the hard work of folks like Miriam Suzanne is starting to pay off there; container queries are on the horizon, and I think they’ll change my job as a front-end developer more than any other thing in the next couple of years.

Speaking of front-end development though…

…we’re talking job titles again! Typing “front-end developer” felt pretty weird just then because there’s an enormous part of the front-end that I don’t have experience with.

Brad Frost identified this split in our work when he called the two sides: “front-of-the-front-end and back-of-the-front-end web development”—I’m certainly in the first camp there. I know HTML and CSS and can be dangerous enough with JavaScript and web app frameworks. But am I going to build a compiler or anything? Nope. That’s just not where my interest lies.

Yet I’ve worked with a ton of extremely talented “back-of-the-front-end folks” who can do that and are experts in JavaScript, but their skills are limited when it comes to interface design and caring for accessibility and markup. And that’s okay because that’s where I can step up.

But we need both of these roles and both of these specializations, to create beautiful websites. And yet I feel like we don’t fully recognize this as an industry yet.

The very first sentence in Chris’s essay The Great Divide identifies this problem perfectly:

Two front-end developers are sitting at a bar. They have nothing to talk about.

I’ve experienced this problem! There’s lots of smallish CSS and HTML stiff that I love talking about, and when I bump into another front-end developer, I sometimes have this odd moment where the stuff they love talking about is framework optimization and bundle sizes. That’s the kind of conversations that I can’t really contribute to.

This split between front-of-the-front and back-of-the-front doesn’t just cause awkward silences though. Jeremy Keith wrote that focusing on the front-of-the-front-end was a good business decision for his web design agency:

This division of roles and responsibilities reminds me of a decision we made in the founding days of Clearleft. Would we attempt to be a full-service agency, delivering everything from design to launch? Or would we specialise? We decided to specialise, doubling down on UX design, which was at the time an under-served area. But we still decided to do front-end development. We felt that working with the materials of the web would allow us to deliver better UX.

Specializing in these roles is good for business because when folks at a company can focus on what they’re good at then wonderful things happen; more focus means better websites.

Not only that but making these two separate roles is key to making a healthy organization and a healthy team. Trys Mudford argues that by ignoring this split between front-of-the-front and front-of-the-back we create all sorts of problems in an organization:

[…] it’s becoming increasingly more common for organisations to jump straight from “design” to “engineering”, missing out the front-of-the-front-end altogether. After all, the engineer codes, and the phase after design is code, so why not let the engineers build the UI?

Well, by jumping straight between the colossal gulf spanning the two functions, a huge wealth of design intention can disappear out of sight.

This is what I was trying to say in “Systems, Mistakes and the Sea” when I made a few notes about why our front-end codebase was in such utter shambles:

Water was rushing into the hull from every angle: h3s were bigger than h2s and h5s were bigger than h4s. I discovered elements without focus or hover states and form inputs without labels, as well as an illegible and unpredictable foundation of css where thousands of lines were being overwritten or not loaded at all. In fact, many styles were loaded in the wrong order and with duplicate files galore! That’s not to mention the wildly inconsistent illustration styles and the four separate typefaces we were loading in six different weights.

Even though the design of our interface was always praised for its high quality, deep down in the front-end all hell was breaking loose.

The problem (which I didn’t realize at the time) was that the organization I worked for was ignoring this front-of-the-front-end work and painted everything with the same brush—treating everything as “engineering.”

But when you don’t break up the team into these specialist groups, then that’s how these problems in the front-end begin.

One last side note here. I’ve heard a lot from friends and colleagues struggling to pick a side. Am I a designer or an engineer? feel like this struggle is really a problem with the organization, more so than it is the person asking those questions.

If an organization doesn’t believe in front-of-the-front-end, then that’s going to cause all sorts of anxiety for the people who naturally fit into that role but can’t. So, if you’re feeling that you need to pick a side between design and engineering, then perhaps you’re a “design engineer.”

We need engineers, we need designers, and we absolutely need design engineers to make that connection across the great divide between the front-of-the-front-end and the back-of-the-front-end. It’s only then that we can make truly great things together.

Let’s create a custom audio player

Idorenyin Udoh writes about how to get started designing our very own audio players:

Did you know it’s possible to create a custom audio player? Of course we can! While the default <audio> player is great in many cases, having a custom player might suit you better, like if you run a podcast and an audio player is the key element on a website for the podcast. Check out the sweet custom player Chris and Dave set up over at the ShopTalk Show website.

What I really like about this post is how Udoh connects this piece with a previous article he wrote about animating SVGs with Lottie. He applies the lessons he learned there to this pause/play button in this tutorial about designing custom audio elements:

Pretty neat. I have an idea though: what if the border of the audio player acted as the progress bar? I could imagine a rather lovely border gradient changing and shifting as a song played or something.

Choosing between Netlify, Vercel and Digital Ocean

There are a lot of different hosting options out there and the differences between them can be pretty hard to distinguish. Thankfully though, Zell dives into the fray and wrote about his experience using all three and then he hits us with his takeaway:

If you have a small project: Go with Netlify.

If you have a larger project: Use Digital Ocean.

I can’t say much here for the other options except that I love hosting things with Netlify right now (and, no, this is not an ad). In fact, I think this is my favorite flow for making a website right now:

  1. Prototype a design in CodePen
  2. Export it as a zip file
  3. Unzip that file and drag and drop that into Netlify
  4. Get a domain name from Hover and sync it up with Netlify
  5. Boom, website complete!

Chris wrote up some hosting advice last week as well. the bottom line: take the happy path.

Here’s a website we like

I stumbled on Penguin Little Black Classics by Mathieu Triay. The site has a scrollable UI with a list of books that you can read small quotes from:

The goal of the site is to sell this collection of books, but I like how simple the interface is and, within half a second, I had a big smile on my face. Most websites aren’t memorable or remarkable but tI still remember this after many years.

Whenever the content matches the design, that’s when a website can truly sing.

Fauna

Jamstack needs a serverless database! Fauna helps you simplify code, reduce costs, and ship faster, by delivering powerful database capabilities as a data API with support for GraphQL and custom business logic. Learn more at fauna.com/jamstack.

[Chris]: I’m still pretty bullish on GraphQL. I can’t pretend to know what all the downsides of it are (e.g. it’s easy to write an inefficient query!), but to me, the upsides are what matter, and the downsides will get sorted out. When a technology has clear benefits, is demonstrably easier for the people that use it, and has a more obvious mental model, then it seems to me it will eventually dominate its predecessor. The mental model for GraphQL is like “look at a menu of data, select what you need, and get it.” That’s so easy, that it makes front-end developers better at what they do, which has massive untold spoils. And if you can imagine getting data in that way, you can imagine asking for it to be changed.

In WordPress-land, GraphQL might even mean a fresh start in people’s mental model of the data structure. You don’t have to care about where and how things are stored, which has it’s fair share of legacy technical debt. Leonardo Losoviz:

[…] we don’t need to worry too much about the database diagram when creating the GraphQL schema for WordPress. That means that we can produce a GraphQL schema that fixes some of the technical debt from the WordPress data model.

Leonardo makes a thing called GraphQL API for WordPress. The name’s a bit of an awkward. It’s clear, but the “for WordPress” is weird in a name. then again, “GraphQL API” isn’t specific enough. Not to mention that if WordPress eventually offers a GraphQL API like it does for REST, then this is like squatting on that naming. I hope it doesn’t disincentivize WordPress from doing it themselves (and I really hope they do since that’s kind of my whole point here).

A seemingly more popular project is WPGraphQL. I usually think of competition as good, but this is such a straightforward open source technical endeavor that I wonder if the world would benefit more from cooperation indtead. But anyway, the WPGraphQL effort is lead by Jason Bahl, and was popular enough that Gatsby snatched him up at one point, presumably to strengthen the Gatsby<—>WordPress connection. Jason is kicking off from Gatsby and joining WP Engine.

Within a few weeks of having conversations about needing to start focusing less on WPGraphQL at Gatsby, I discovered that WP Engine was building a headless WordPress framework and was hiring engineers to focus on headless WordPress. The job description felt like it was describing me, almost perfectly. Serendipity.

Seems like GraphQL + WordPress will benefit from this. I don’t think a PHP-powered front-end is going anywhere, but front-end development is more and more headed toward components, and JavaScript rules at components. Being able to leverage that and GraphQL and continue to use WordPress as the CMS is pretty cool and I suspect we’ll see more and more of it.

I’m tempted to make a bet on when the official WordPress project will pick up GraphQL, but I’d hate to be five years late on whatever date I pick. Well, I guess just two years.