What if HTML had “tabs”? That would be cool, says I. Dave has been spending some of his time and energy, along with a group of “Tabvengers” from OpenUI, on this. A lot of research leads to a bit of a plot twist:
Our research showed there are a lot of variations for what makes up a tab control. There’s a lot of variations in markup patterns as well. There’s variations written in operating systems, video games, jQuery, React components, and web components. But we think we’ve boiled some of this ocean and have come to a decent consensus on what might make for a good <tabs> element… and it isn’t <tabs>!!!
It kinda comes down to design affordances. Sure, the type of UI that looks like literal paper manilla folders is one kind of design affordance. But it’s functionally similar to a one-at-a-time accordion. And accordions are fairly similar to <details>/<summary> elements — so maybe the most helpful thing HTML could do is allow us to use different design affordances, and perhaps even switch between them as needed (say, at different widths).
Then the question is, what HTML would support all those different designs? That actually has a pretty satisfying answer: regular ol’ header-based semantic HTML, so like:
The base HTML is sound and can render just fine as one design choice
The headers can become a “tab” it that particular design
The headers can become a “summary” in that particular design
This is the base of what the Tabvengers are calling <spicy-sections>. Just wrap that semantic HTML in the web component, and then use CSS to control which type of design kicks in when.
spicy-sections { --const-mq-affordances: [screen and (max-width: 40em) ] collapse | [screen and (min-width: 60em) ] tab-bar; display: block; }
Brian Kardell made up an example:
I made one as well to get a feel for it:
Here’s a video in case you’re in a place you can’t easily pop over and resize a browser window to get a feel yourself:
This is a totally hand-built Web Component for now, but maybe it can ignite all the right conversations at the spec-writing and browser-implementing levels such that we get something along these lines in “real” HTML and CSS one day. I’d be happy about that, as that means fewer developers (including me) having to code “tabs” from scratch, and probably screw up the accessibility along the way. The more of that, the better.
If you’d like to hear more about all this, check out ShopTalk 486 at 15:17. And if you’re interested in more about Web Components and how they can be gosh-darned useful, not only for things like this, but much more in Dave’s recent talk HTML with Superpowers.
There is a huge and ever-widening gap between the devices we use to make the web and the devices most people use to consume it. It’s also no secret that the average size of a website is huge, and it’s only going to get larger.
What can you do about this? Get your hands on a craptop and try to use your website or web app.
Craptops are cheap devices with lower power internals. They oftentimes come with all sorts of third-party apps preinstalled as a way to offset its cost—apps like virus scanners that are resource-intensive and difficult to remove. They’re everywhere, and they’re not going away anytime soon.
My son just got his school district-issued Chromebook that he’s expected to use for the next 10 years until he graduates high school…
Makes me think there’s gonna be (if there isn’t already now) a somewhat large market for web-based software that works on old hardware.
As you work your way through your website or web app, take note of:
what loads slowly,
what loads so slowly that it’s unusable, and
what doesn’t even bother to load at all.
After that, formulate a plan about what to do about it.
The industry average
At the time of this post, the most common devices used to read CSS-Tricks are powerful, modern desktops, laptops, tablets, and phones with up-to-date operating systems and plenty of computational power.
Granted, not everyone who makes websites and web apps reads CSS-Tricks, but it is a very popular industry website, and I’m willing to bet its visitors are indicative of the greater whole.
In terms of performance, the qualities we can note from these devices are:
powerful processors,
generous amounts of RAM,
lots of storage space,
high-quality displays, and most likely a
high-speed internet connection
Unfortunately, these qualities are not always found in the devices people use to access your content.
Survivor bias
British soldiers in World War I were equipped with a Brodie helmet, a steel hat designed to protect its wearer from overhead blasts and shrapnel while conducting trench warfare. After its deployment, field hospitals saw an uptick in soldiers with severe head injuries.
Because of the rise in injuries, British command considered going back to the drawing board with the helmet’s design. Fortunately, a statistician pointed out that the dramatic rise in hospital cases was because people were surviving injuries that previously would have killed them—before the introduction of steel the British Army used felt or leather as headwear material.
Survivor bias is the logical error that focuses on those who made it past a selection process. In the case of the helmet, it’s whether you’re alive or not. In the case of websites and web apps, it’s if a person can load and use your content.
When looking at your site's analytics, remember that if you don't see many users on lower end phones or from more remote areas, it's not because they aren't a target for your product or service. It is because your mobile experience sucks.
People who can’t load your website or web app don’t show up as visitors in your analytics suite. This is straightforward enough.
However, the “use” part of “load and use your content” is the important bit here. There’s a certain percentage of devices who try to access your product that will be able to load enough of it to register a hit, but then bounce because the experience is so terrible it is effectively unusable.
Yes, I know analytics can be more sophisticated than this. But through the lens of survivor bias, is this behavior something your data is accommodating?
Blame
It’s easy to go out and get a cheap craptop and feel bad about a slow website you have no control over. The two real problems here are:
Third-party assets, such as the very analytics and CRM packages you use to determine who is using your product and how they go about it. There’s no real control over the quality or amount of code they add to your site, and setting up the logic to block them loading their own third-party resources is difficult to do.
The people who tell you to add these third-party assets. These people typically aren’t aware of the performance issues caused by the ask, or don’t care because it’s not part of the results they’re judged by.
What can we do about these two issues? Tie abstract, one-off business requests into something more holistic and personal.
Bear witness
I know of organizations who do things like “Testing Tuesdays,” where moderated usability testing is conducted every Tuesday. You could do the same for performance, even thread this idea into existing usability testing plans—slow websites aren’t usable, after all.
The point is to construct a regular cadence of seeing how real people actually use your website or web app, using real world devices. And when I say real world, make sure it’s not just the average version of whatever your analytics reports says.
Then make sure everyone is aware of these sessions. It’s a powerful thing to show a manager someone trying to get what they need, but can’t because of the choices your organization has made.
Craptop duty
There are roughly 260 work days in a year. That’s 260 chances to build some empathy by having someone on your development, design, marketing, or leadership team use the craptop for a day.
You can run Linux from a Windows subsystem to run most development tooling. Most other apps I’m aware of in the web-making space have a Windows installer, or can run from a browser. That should be enough to do what you need to do. And if you can’t, or it’s too slow to get done at the pace you’re accustomed to, well, that’s sort of the point.
Craptop duty, combined with usability testing with a low power device, should hopefully be enough to have those difficult conversations about what your website or web app really needs to load and why.
Don’t tokenize
The final thing I’d like to say is that it’s easy to think that the presence of a lower power device equals the presence of an economically disadvantaged person. That’s not true. Powerful devices can become circumstantially slowed by multiple factors. Wealthy individuals can, and do, use lower-power technology.
Perhaps the most important takeaway is poor people don’t deserve an inferior experience, regardless of what they are trying to do. Performant, intuitive, accessible experiences on the web are for everyone, regardless of device, ability, or circumstance.
I’ve built WordPress websites for I don’t know how long now, but suffice to say I’ve relied on it for a bulk of the work I do as a freelance front-ender. And in that time, I’ve used Jetpack on a good number of them for things like site backups, real-time monitoring, and security scans, among other awesome things.
I love Jetpack, but darn it if it’s time-consuming to manage those services (plus the licenses!) in multiple accounts that I have to keep track of (and get invoices for!).
The Jetpack team took a major step to make it easier to manage its services with a new licensing plan that’s designed specifically for agencies and individuals like myself who manage a portfolio of clients. Instead of littering my 1Password account with a bunch of different logins for different sites to do something like backing up a site, I can now do it all from the convenience of one account: my own.
Sure sure, you say. Plenty of plugins offer developer licenses that can be used on multiple sites. But how many of them allow you to manage those sites all at once? Not many as far as I know. But Jetpack now has this great big, handy dashboard that gives you a nice overview of all the sites you manage in one place.
Ah, now I can see all the services, how many licenses are assigned to them, and—this is the kicker—one price to pay for the month.
OK, so the new Jetpack agency dashboard does administrative stuff for licensing and payments. But there’s also the ability to manage all of your Jetpack-driven sites from here as well. Tab over to the site manager and you get to work on all those sites at once. Imagine you have to run a site backup each month for 20 sites. Ugh. It’s really one task, but it’s also sort of like doing the same task 20 times. This way, that can all be done together directly from the dashboard—no hopping accounts and repeating the same task over and again.
Jetpack’s agency licensing is a program you sign up for. Once you’re a member, you not only get the dashboard and a single automated bill each month, but a slew of other perks, including a 25% discount on all Jetpack products and early access to new site management features. This is just the first iteration of the dashboard and site manager, and there’s plenty in the pipeline for more goodness to come. Heck, you can even request a feature if you’d like.
There’s just one requirement: you’ve gotta issue at least five licenses within 90 days. That’s fair considering this is an agency sort of thing and agencies are bound to reach that threshold pretty quickly.
This is definitely the sort of thing that excites me because it saves a lot of time on overhead so more time can be spent, you know, working. So, give it a look and see how it can streamline the way you manage Jetpack on multiple sites.
I’ve mentioned two categories of tools for web development. I still don’t know quite what to call these categories. Internal and external? Developer-facing and user-facing?
The first category covers things like build tools, version control, transpilers, pre-processers, and linters. These are tools that live on your machine—or on the server—taking what you’ve written and transforming it into the raw materials of the web: HTML, CSS, and JavaScript.
The second category of tools are those that are made of the raw materials of the web: CSS frameworks and JavaScript libraries.
It’s a good way to think about things. There is nuance though, naturally. Sass is the first category since Sass never goes to users, it only makes CSS that goes to users. But it can still affect users because it could make CSS that is larger or smaller based on how you use it.
Jeremy mentions Svelte as a library where the goal is essentially compiling as much of itself away as it can before code goes to users. Some JavaScript is still there, but it doesn’t include the overhead of a developer-facing API. The nuance here is that Svelte can be used in such a way that all JavaScript is removed entirely. For example, SvelteKit can turn off it’s hydration entirely and do pre-rendering of pages, making a site that entirely JavaScript-free (or at least only opting in to it where you ask for it).
On React:
I know there are ways of getting React to behave more like a category one tool, but it is most definitely not the default behaviour. And default behaviour really, really matters. For React, the default behaviour is to assume all the code you write—and the tool you use to write it—will be sent over the wire to end users.
I think that’s fair to say, but it also seems like the story is slowly starting to change. I would think widespread usage is far off, but Server Components seem notable here because they are coming from the React team itself, just like SvelteKit is from the Svelte team itself.
[…] unlike Svelte, Astro allows you to use the same syntax as the incumbent, React. So if you’ve learned React—because that’s what you needed to learn to get a job—you don’t have to learn a new syntax in order to use Astro.
I know you probably can’t take an existing React site and convert it to Astro with the flip of a switch, but at least there’s a clear upgrade path.
This isn’t just theoretically true, it’s demonstrably true!
I just converted our little serverless microsite from Gatsby to Astro. Gastby is React-based, so all the componentry is already built as React components. The Pull Request is messy but it’s here. I converted some of it to .astro files, but left a lot of the componentry largely untouched as .jsx React components. But React does not ship on the site to users. JavaScript is almost entirely removed from the site, save for some hand-written vanilla JavaScript for very light interactivity.
So there is some coin-flipping stuff happening here. Coin merging? Astro to me feels very much like a developer-facing tool. It helps me. It uses the Vite compiler and is super fast and pleasant to work with (Astro has rough edges, for sure, as it’s pre 1.0, but the DX is largely there). It scopes my styles. It lets me write SCSS. It lets me write components (in many different frameworks). But it also helps the user here. No more JavaScript bundle on the site at all.
I guess that means Astro doesn’t change the categories—it’s a developer-facing tool. It just happens to take what would be a user-facing tool (even Svelte) and makes them almost entirely developer-facing.
And just because I’ve had a couple of other Astro links burning a hole in my pocket, Flavio has a good intro tutorial and here’s Drew McLellan and Matthew Phillips chatting Astro on a recent Smashing Podcast.
I was just going on about how many awesome little helper sites there are out there, and now I’ve ran across another wonderful little hive of them. Sébastien Noël, under the name fffuel, has created a whole bunch of great ones like:
I recently started university and, before buying a MacBook Air (the M1 chips are amazing by the way), I had to use an iPad Pro for class. However, being a Computer Science student meant I had to find a way to use it for programming. Therefore, I started my quest to find the best way to program using an iPad.
The first options I found were good, but not great, as I couldn’t run any code or program I want, due to lack of command-line or root access. I could’ve used platforms like Coder, Gitpod, GitHub Codespaces or even Replit, but they were not what I was searching for.
But then, I found the perfect program. It is free, open-source, and self-hostable. It’s also the base for Coder, a platform I found while searching. It’s called code-server and it’s basically a hosted VS Code, with full file-system access to your server.
At first, my use case was for Java programming (it’s the language we’re learning in class), but I soon realized that I could also use it for other programming tasks, namely, WordPress theme development!
Requirements
You’ll need two things to get started:
A Linux server with root access. I personally use a VPS from OVH. A Raspberry Pi will work, but the steps are more involved and are beyond the scope of this article.
An iPad, or any other device that usually can’t be used for programming (e.g. Chromebook).
I’ll assume you’re working on the same server as your WordPress website. Also, as a note, this guide was written using Ubuntu 20.04.2 LTS.
Installation
We’ll first need to SSH into our server. If you’re using an iPad, I suggest Termius, as it works really well for our needs. Once we’re logged in to our server, we’ll install code-server, which requires root/sudo access.
Installing it is really simple; in fact, it’s only a single terminal command. It’s also the same command when upgrading it:
curl -fsSL https://code-server.dev/install.sh | sh
Configuration
Once code-server is installed, there’s a couple of ways we could go about configuring it. We could just run code-server and it would work—but it would also lack HTTPS and only offer basic authentication. I always want HTTPS enabled and, besides, my domain requires it anyway.
To enable HTTPS, there’s, again, a couple of ways of doing it. The first one in code-server’s docs uses Let’s Encrypt with a reverse proxy, such as NGINX or Caddy. While this works great, it requires a lot more manual configuration and I didn’t want to bother with that. However, code-server also provides another option, --link, which works great, despite it being in beta. This flag steps up a TLS certificate, GitHub authentication and a dedicated cdr.co URL! All without any configuration on our side! How cool is that‽ To set it up, run this command (no need for root/sudo access for this, any regular user works):
code-server --link
That creates a URL for us to login to your GitHub account, so that it knows which account to authorize. Once that’s done, we’ll get a dedicated URL and we’re good to go! Each user has their own configuration and GitHub account, so I think it might be technically possible to run multiple instances at the same time for multiple people. However, I have not tested it.
Once the GitHub account has been configured, we’ll press Ctrl+C to stop the process.
Running code-server --link gives us a login URL.
Tapping the URL in Termius enables us to open it in Safari.
GitHub authorizes your account after logging in.
Once the app is authorized, it should drop you right into a familiar interface!
Going back to our SSH session, we can see that the permanent URL is now available! Keep in mind it’ll only work when code-server is running.
Setting up WordPress theme dependencies
There’s a lot of ways to go about developing a WordPress theme, but I really like the way Automattic’s underscores (_s) is done, so we’ll use that as a starting point.
To start using _s, let’s install Composer. Since I am assuming you’re on the same server as your WordPress website, PHP is already installed. While I could list the steps here, Composer’s website already has them laid out better than I possibly could.
Once Composer is installed, we need to install Node.js by running these commands in terminal:
These commands add the updated Node PPA—since Ubuntu’s included one is really outdated (Node 10!)—then installs Node, and gets its version.
The last command should have returned something like v16.6.1, which means we’re all set!
Setting up the theme
To setup the _stheme, we run npx degit automattic/_s my-cool-theme. This downloads the _scode to a folder called my-cool-theme. If you want the theme directly in your WordPress themes directory, you can either move that folder, make a symlink to it, or give the full path to the folder in the previous command instead. I personally prefer zipping my files by running npm run bundle and then unzipping them manually in my themes folder.
Once all that’s done, let’s run code-server --link, open up our browser and navigate to our URL!
In our VS Code instance, we can open the folder containing our theme and follow the quick start steps for _s, to name our theme correctly. Then, in the integrated terminal, we run composer install and npm install. This installs all the required packages for the theme. I won’t explain the way a WordPress theme works, since a lot of more experienced people have already done that.
And… that’s it! Our server now has everything we need to develop some sick WordPress themes using an iPad or any other device that has a browser and a keyboard. We could probably even use an Xbox, once their new browser releases.
What development looks like
Everything we talked about sounds great in theory, right? What you’re probably wondering, though, is what it’s actually like to develop on an iPad with this configuration. I recorded the following video to show what it’s like for me. It’s a few minutes long, but gives what I think is a good reflection of the sorts of things that come up in WordPress development.
A few notes on this setup
Since code-server is using the open-source VS Code—not Microsoft’s version—some things are missing. It’s also not using Microsoft’s marketplace for extensions, which means that not all extensions are available. We cannot login to our Microsoft or GitHub account to sync our settings, but we can also use the Settings Sync extension, though I personally had trouble using it to sync my extensions. Each Linux user has their own settings and extensions, saved in this folder: ~/.local/share/code-server. It’s a similar folder structure as a regular VS Code install.
There are also ways to run code-server as a service instead of directly in the SSH session, so that it always run, but I prefer to open it when I need it.
Some iPad-specific tips
If you’re planning on using an iPad like me, here are some tips to make your experience more enjoyable!
Activate the location tracking feature in Termius, as it enables the SSH connection to be kept alive, even with the app running in the background.
Open the website using Safari, then open the Share Sheet to add it to your home screen! PWAs for the win
Safari caches stuff very aggressively and clearing it is really annoying. The only way that I found is basically clearing the history of the browser, which is not ideal. There’s no “hard refresh” like there is on any other desktop browser. Chrome might handle it better though.
Buy yourself a Bluetooth keyboard, or even a case (Brydge is a good one), because it makes it feel more like a laptop than a tablet. A physical keyboard makes the experience 1000× more enjoyable than an on-screen keyboard!
iPad sometimes “loses focus” of the editor, especially when switching between apps, which makes it impossible to type. I usually fix that by tapping on the sidebar, then in the editor.
Perhaps the most basic and obvious use of CSS custom properties is design tokens. Colors, fonts, spacings, timings, and other atomic bits of design that you can pull from as you design a site. If you pretty much only pull values from design tokens, you’ll be headed toward clean design and that consistent professional look that is typically the goal in web design. In fact, I’ve written that I think it’s exactly this that contributes to the popularity of utility class frameworks:
I’d argue some of that popularity is driven by the fact that if you choose from these pre-configured classes, that the design ends up fairly nice. You can’t go off the rails. You’re choosing from a limited selection of values that have been designed to look good.
I’m saying this (with a stylesheet that defines these classes as one-styling-job tokens):
<h1 class="color-primary size-large">Header<h1>
…is a similar value proposition as this:
html { --color-primary: green; --size-large: 3rem; /* ... and a whole set of tokens */ } h1 { color: var(--color-primary); font-size: var(--size-large); }
There are zero-build versions of both. For example, Tachyons is an it-is-what-it is stylesheet with a slew of utility classes you just use, while Windi is a whole fancy thing with a just-in-time compiler and such. Pollen is an it-is-what-it is library of custom properties you just use, while the brand new Open Props has a just-in-time compiler to only deliver the custom properties that are used.
The entire thing is literally just a whole pile of CSS custom properties you can use to design stuff. It’s like a massive starting point for your styles. It’s saying custom property all the things, but in the way that we’re already used to with design tokens where they are a limited pre-determined number of choices.
The analogies are clear to people:
Open Props: A new CSS library by the amazing @argyleink.
What it doesn’t do is prevent you from having to name things, which is something I know utility-class lovers really enjoy. Here, you’ll need to continue to use regular ol’ CSS selectors (like with named classes) to select things and style them as you “normally” would. But rather than hand-crafting your own values, you’re plucking values from these custom properties.
The whole base thing (you can view the source here) rolls in at 4.4kb across the wire (that’s what my DevTools showed, anyway). That doesn’t include the CSS you write to use the custom properties, but it’s a pretty tiny amount of overhead. There are additional PropPacks that increase the size (but thye are also super tiny), and if you’re worried about size, that’s what the whole just-in-time thing is about. You can play with that on StackBlitz.
Seems pretty sweet to me! I’d use it. I like that it’s ultimately just regular CSS, so there is nothing you can’t do. You’ll stay in good shape as CSS evolves.
As I write this, world leaders are gathering in Glasgow for COP26, the international climate change conference, in the attempt to halt (or at least slow down) catastrophic climate change by pledging to end their countries’ dependence on fossil fuels. Only time will tell whether they will succeed (spoiler: it’s not looking good), but one thing that’s increasingly clear is that we in the tech industry can no longer bury our heads in the sand. We all have a responsibility to ensure our planet is habitable for future generations.
It’s all too easy to disassociate climate change from the web. After all, most of us are sitting at our desks day in, day out. We don’t physically see the emissions the web is producing. But according to a report by the BBC in 2020, the internet accounts for 3.7% of carbon emissions worldwide — and rising. That puts our industry on level with the entire air travel industry. So, when I think of what we can do to make our websites “better” I immediately think of how we can make them better for the planet. Because, like it or not, the carbon emissions produced by our websites not only impact our own users, but all the people who don’t use our websites too. We certainly have a lot of work to do.
It’s no secret that web pages have been becoming increasingly bloated. The average web page size now stands at around 2MB. This is terrible news for users, whose experience of browsing such bloated sites will be very poor on slow connections, but it’s also terrible for the planet. Poor performance and energy intensity often go hand in hand. But happily, it means that fixing one will go a long way towards fixing the other — it’s a win-win. So what’s one thing we can do to improve the environmental impact of our websites (and, by extension, improve performance for our users too)?
My suggestion is that we need to set our websites a carbon budget.
Performance budgets in web development are not a new idea, and in many respects go hand-in-hand with carbon budgets. Optimizing for performance should generally have a positive impact on your website’s energy efficiency. But a quantifiable carbon budget as well helps us look at every aspect of our website through the lens of sustainability, and may help us consider aspects that a performance budget alone wouldn’t cover.
How can we begin to calculate a carbon budget for our site? Calculating the amount of carbon produced by a web page is difficult due to the many factors to consider: there’s the power used during development, the data centers that host our files, the data transfer itself, the power consumed by the devices of our end users, and more. It would be virtually impossible to perform our own calculations every time we build a website. But Wholegrain Digital’s Website Carbon Calculator tool, which estimates the carbon footprint of a given website, gives us a good jumping-off point from which to start thinking about this stuff.
Let’s take the COP26 website as an example. Running this site through the Carbon Calculator reveals some fairly shocking results: The site is dirtier (i.e. more carbon intensive) than 94% of web pages tested by the tool. Inspecting the homepage in DevTools, we can see that entire page weighs in at around 6.4MB of transferred data — way about average, but sadly not unusual. Further inspection reveals that JavaScript from social media embeds (including YouTube video embeds) are among the worst offenders on the homepage, contributing significantly to the page weight. Fershad Irani has written this detailed analysis of the areas where the site falls short, and what can be done about it. (Up until a few days ago, the total size was 8.8MB, including a 3MB PNG image. Thanks to the Fershad’s work in highlighting this to the COP26 team, the image has now been replaced with a much smaller version.)
By understanding which elements of our design have the greatest impact on performance, we can gain an understanding of where some of our biggest carbon savings could lie, and begin to make trade-offs. The carbon budget might need to be different for every site — sites that require a lot of motion and interactive content, for instance, may inevitably use more resources. But perhaps for a simple web page like this we could aim for under 1g of carbon per page view? When we think about how many page views a site like COP26 would accumulate over the period of the conference, this could amount to significant savings.
Once we can identify where possible carbon savings lie, we can do something about them. Wholegrain Digital’s article “17 Ways to Make your Website More Energy Efficient” is a good place to start. I also recommend reading Sustainable Web Design by Tom Greenwood for a practical guide to holistically reducing the environmental impact of the sites we build. The website Sustainable Web Design has some excellent development resources.
As for convincing clients to buy into the idea of a carbon budget, using Core Web Vitals to kick off that conversation is a good place to start. Using tools like Lighthouse, we can see which aspects of our site have the most impact on performance and how Core Web Vitals are affected. Seeing the impact of that code on your clients’ site performance score (which can affect Google’s search ranking) might just be enough to convince them.
It would be great to see Google (and other industry-leading companies) lead the way on this and build carbon calculations into tools like Lighthouse. By putting that information front and center they could play an important role in empowering developers to make more environmentally-conscious decisions — and show that they’re putting their money where their mouth is. (There’s actually an open GitHub issue for this.) Perhaps we also need some kind of industry-wide certification, as explored in this article by Mike Gifford.
There’s much more we can do to improve the carbon footprint of our sites. It’s time for the web industry to heed this wake-up call. In the words of Greta Thunberg:
