[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?
Making accessible tables and grids
Earlier in the week, I caught this great post from Sarah Higley where she digs into the differences between tables and grids. She focuses on a lot of the usability and accessibility problems caused by these two types of component. But it’s important to note here that when Sarah says “grids” she means UIs like Excel spreadsheets — where you can tab between cell items, or select multiple rows.
It’s a great post and I’m thoroughly interested to read the follow ups.
Animating the 1 Million Developers Microsite
In this post, Sarah Drasner documents how she built the 1 Million Developers microsite for Netlify which has a rather nice collection of animations that are worth checking out:
The whole site is a timeline of Netlify, from when the company started and all the way through their major product launches. The site is effectively one big beautiful SVG and I’ve scrolled up and down multiple times to spot all the details. It’s so great and reminds me that I should spend more time investigating how to use animation on a project to make it really pop.
Using GitHub Actions to Optimize Images
Chris gets very excited about GitHub Actions in this post and why they’re so dang helpful. In particular, he writes about how to use image-actions to optimize images.
With this process, and each time you make a pull request, GitHub will automatically fire the action and optimize your images which means you can remove a lot of the complex logic that once existed with the help of tools like Gulp and Grunt.
Once you’ve successfully added this GitHub Action, it’ll add a comment to your PR and show you just how much your images were compressed. Not only that, but I think moving these actions into GitHub or Netlify is extraordinarily helpful because it means our builds are potentially less complex. No need to fuss with a configuration file on our local machines; we can just tell some service how to process our files and do smart things with them.
Animating underlines on wrapping lines of text
Here’s a nifty design where Nicky Meuleman, inspired by Cassie Evans’s website, recreates this CSS-only, animated, wrapping underline:
This lovely animation is done by transitioning the background-size and background-position CSS properties. Very smart.
Making a Vue-powered calendar
Mateusz Rybczonek made this fantastic Vue-powered calendar:
Making a calendar is no joke. There are lots of little UI details and important things to remember, which Mateusz illustrates by outlining just a few of the requirements for this particular demo:
- Create a month view grid that displays the days of the current month
- Display dates from the previous and next months to so the grid is always full
- Indicate the current date
- Show the name of the currently selected month
- Navigate to the previous and next month
- Allow the user to navigate back to the current month with a single click
Mozilla Talent Directory
You might’ve heard about the tragic layoffs at Mozilla and, if you happen to be hiring for engineers, there’s a talent directory that they’ve set up so that you can help folks out.
The leading-trim CSS property
The other day I spotted this fabulous post by Ethan Wang about the leading-trim CSS property and the future of digital typesetting. This is just a proposal and so doesn’t work in browsers yet, but it could look something like this in CSS:
h1 {
text-edge: cap alphabetic;
leading-trim: both;
}And that would cut off all the extra spacing around the letters that Ethan describes:
In a standard text box, there’s almost always extra space above and below the actual text. Because of this, when you use a text box to measure and implement spacing, it ends up larger than you intended. The bigger the line height, the bigger the problem. The example below shows distances between text boxes set to 32px. As you can see, all the vertical spacing is visually much bigger than 32px, even though you set them all to the same value.
This stuff is all part of the Inline Layout Module Level 3 spec and folks like Microsoft are proposing this CSS property because removing the extra space above and below the letters in a block of text lets us position things more predictably on the page.
Let’s say that you want to place the text within a button precisely in the center, or let’s say you want to control the margins and line spacing between each bit of text. That is possible today but we have to tame the line-height as Caleb Williams wrote about not so long ago.
Anyway, I’m very excited for this CSS property to gain traction because it’s going to make it much easier to control vertical spacing in future websites.
Sponsor
Online Workshops on Front-End & UX
Boost your design skills online and learn practical insights from experts in the industry, live. That’s Smashing Online Workshops, broken into 2.5h live sessions, spanning across weeks. With tangible takeaways, exercises, access to experts, slides, recordings and a friendly Q&A. E.g. Vue.js: The Practical Guide with Natalia Tepluhina or Smart Interface Design Patterns with Vitaly Friedman. Ah, use a friendly link to save $50 off the price! Meow!
Pure CSS Magic
Lynn Fisher made this spectacular animation that uses only a single div and I can’t stop looking at it:
As Lynn mentions in the code there, this is a recreation of these animated book covers by Henning Lederer. Each one of them is striking and shows just how a tiny bit of animation can make a big difference to a design:
Ohm and speaking fantastical recreations in CSS, Sarah Fossheim made this excellent CSS illustration of the Roland MC-500:
These buttons look so real that I desperately want to click them and hear the clunking sounds of plastic. Or the beeps! I bet this sweet little plastic machine had the greatest, softest little beeps.
Sponsor
Build a site. Sell your stuff. Start a blog. And so much more.
That’s the power and flexibility of WordPress.com. 38% of the web is built on WordPress. More bloggers, small businesses, and Fortune 500 companies use WordPress than all other options combined. Join the millions of people that call WordPress.com home.
[Chris]: So much happening with Mozilla. Another huge round of layoffs, this last one being 25% of their employees, around 250 people. The reporting and speculation at the time was that it was because their contract with Google is nearing a renewal, and maybe they won’t get it or don’t want it and need to downsize to deal with that. Turns out that wasn’t the case, the contract was renewed, accounts for 90% of Mozilla’s income. The Register reported it’s worth some $400-450 million a year. You can straight up look at their income taxes and report to get a look at somewhat recent financials. They list revenue at ~$20m and salary expenses at ~$10m, which is far too low for a 1,000 person company, so I’m not sure how to make sense of any of that.
Anyway. I think it’s weird that Mozilla exists nearly entirely off money from Google, and then uses that money to compete with Google and nip at them about all sorts of things like not being privacy-focused. I wonder if Google would face backlash if they discontinued the contract. Like they would be beheading one of the last-two-standing browser engine competitors.
I also speculated:
… you don’t fire the people that they fired and then remain a relevant alternative browser engine. It will either stagnate or go Chromium.
I’m told that wasn’t nice and they definitely aren’t going Chromium.
I’m just confused because they specifically fired people developing the platform. Look: David Baron is gone. He’s the fella everyone points to and says: this guy knows Firefox like no other. He’s the guy that holds the keys to unlocking powerful things we need, like container queries. We were all waiting with bated breath for David to push his ideas forward with container queries. Now? Who knows. I don’t think you fire someone like that if the plan is pushing the platform forward.
Everybody is also super worried about MDN, who’s team was also gutted. They tried to reassure us, but that post doesn’t have a single word of action in it as to how. Some people think the fact that it is volunteer-run means it will be fine, and some people think exactly the opposite. Such weird timing with Caniuse too, having recently started sucking data out of MDN. (I’m a fan of the new beta though!)
Confusion is all we have right now. Is Firefox going to continue to have it’s own open-source engines or not? Will those engines change in relevancy? What is Mozilla going to build to make money? We just have no idea what the plan is or how likely they are to achieve it. We do know they have a bunch of money in the bank, so here’s hoping whatever happens benefits the web.