#226: Websites Can Be Weird

[Robin]: The first thing that caught my eye this week is this fabulous tutorial by Alex Trost where he walks us through how to make this rather nifty design:

This design is the work of Andy Barefoot, who’s really pushing forward the weirdness and pure magic of what’s possible with CSS Grid. Just check out his personal website, that happens to look something like this:

Andy has a ton of amazing Pens that he’s created over the years, including this eye-catching sneaker website:

I love work like this, it’s just the sort of stuff to remind me that we don’t always have to build things the way that we have. Websites can be weird! And peculiar! And that’s just what I love about Barefoot’s work.


Conic Gradients have pretty darn good browser support now

Firefox 83 just landed and with it support for Conic Gradients. This lets us make all sorts of new things with CSS, like the sort of pattern you might see in a color picker, or a loading spinner, or pie charts!

Support is so good for this type of gradient now that it’s worth checking out our brand new and complete guide to CSS Gradients where we walk through the three types: linear, radial, and, yes, conic.

Also—tricks! There’s so many fancy gradient tricks where you can make everything from graph paper:

To funky border gradients:

And even beautiful gradients like the one that Lynn Fisher made for A Single Div:

It’s worth getting to grips with what gradients can do these days. It’s pretty remarkable and I always tend to need a reminder.

Speaking of which, here’s a great website called CSS Background Patterns which gives you this great library of background gradients to choose from and then customize:


Upptime

Chris wrote this smart bit about GitHub Actions and noted how they’re basically like free computers:

GitHub Actions are computers, so you can have them run whatever code you like. (I’m sure there is EULA stuff you are bound to, but you know what I mean.) Just like everybody’s favorite, serverless functions, GitHub Actions can do that same stuff. Wanna run a build process? Hit an API? Optimize images? Screenshot a URL? Do it up. Most actions are tied to specific events, like “run this code when I commit to a branch” or “run this code against this pull request.” But you can also schedule them on a cron schedule.

He then linked to this great GitHub Action called Upptime which is, just as it says on the tin, an uptime monitor and status page. Every few minutes it’ll visit your website to make sure it’s still standing and it’ll create graphs of all those response times.

At work we use a custom GitHub Action to make visual diffs across all of the pages and components that might’ve changed and then we store all those images so we can contrast and compare them. Super neat stuff.


How to detect when a sticky element gets pinned

position:sticky is a very useful CSS trick, but how do we know when it’s active and pinned? Well, David Walsh has written about just that very thing. He argues that we need a CSS native way of doing this without JavaScript, with something like this:

.element {
  position: sticky;
}

/* Wouldn't THIS be nice?? */
.element:stuck {
 /* styles for when the element is stuck */
}

I really like this idea. But as David explains in that post, what we need to do today is add a class to element with some JavaScript and the IntersectionObserver API, like in this simple demo.


Measuring Core Web Vitals

Core Web Vitals are a collection of useful metrics that we can use to get a picture of how the performance of our websites are affecting users. And the other day my mentor Dora Chan wrote about why gathering all this information with the help of Sentry is a great idea:

Google Web Vitals can be viewed using the Google Chrome Lighthouse extension. You may be asking yourself, “Why would I need Sentry to see what these are if I already have Google?” Good question. Google provides synthetic lab data, where you can directly control your environment, device, and network speed. This is good and all, but it only paints part of the picture. Paint. Get it?

Sentry gathers aggregate field data on what your users actually experience when they engage with your application. This includes context on variable network speed, browser, device, region, and so forth. With Web Vitals, we can help you understand what’s happening in the wild, how frequently it’s happening, why, and what else is connected to the behavior.

So once you’ve connected Sentry with your app you’ll be able to see which transactions got significantly better over time and which regressed. This gives you a good idea as to what code caused what perf problem. And that’s pretty gosh darn neat.

Now, I work at Sentry so I’m somewhat biased here but I’m really not trying to sell an ad here. I just think what’s so fascinating is how these tools are developing and improving across the industry and how the words we have to describe these problems are changing.

Also earlier this week I read this really great post by Katie Sylor-Miller about the Core Web Vitals hype train and how we need to think critically about which metrics make sense for our product and our customers:

When talking about Core Web Vitals, we need to make sure that we keep in mind both the benefits and the tradeoffs inherent in narrowing our scope to three metrics out of many. Performance cannot be measured by a single number, or even three numbers, no matter how much easier our lives would be if it was. Core Web Vitals are an engine that can help pull us forward, not a fully decked-out passenger train with sleeping cars and a cafe that will whisk us wherever we need to go.

I think it’s important to look closely at which metrics are important to our business, because Core Web Vitals might not be what you need to make your website fast. But I still think they’re a pretty good indicator of trends that you should pay attention to and which parts of your website need more focus when it comes to perf improvements.


World-class courses taught by WordPress experts.

WordPress.com is producing official training courses! Their first course, Blogging for Beginners, is available now. Blogging is more than putting words on a screen. It’s about finding your tribe, connecting with new friends, and finding an audience who can share your struggles, triumph, ideas, and dreams. They designed Blogging for Beginners to help you do it all. $49 for the course, which updates annually, and includes office hours and expert-led sessions. Use coupon CHRIS50 for 50% off!

Psst… Automattic is hiring! If you’ve been hunting for a new job, there are tons of openings and one of them might just have your name written all over it. Check them out!


[Chris]: I’ve got some solid recent links on accessibility I’ve been saving up for you:

  • Steve Faulkner with big details on using the aria-label attribute. My brain thinks of it as the one you use to totally wipe out the text content of an element and read what is in aria-label="new content" instead. But, first, only do that if you absolutely have to (visible, nearby, regular HTML labels are better) but if you do have to, still, it only works on a subset of HTML elements. Notably not <div>, <label>, <pre>, and many more.
  • Speaking of aria-label, Léonie Watson wrote about The difference between aria-label and aria-labelledby. Again, don’t use it unless you have to, but if you have to, if the text exists elsewhere in the document, point to it with aria-labelledby rather than re-create the value.
  • Nataly Birch with a big guide on HTML email accessibility. A lot of it is the same as accessibility anywhere else (semantic HTML, good color contrast, alt text for images…), but some is somewhat unique to email. For example, if you don’t make the email responsive for small screens, it can be nearly unreadable in many clients. A client may not support zoom. Some people’s clients are set to text-only, so it’s an accessibility issue if you don’t send a text version.
  • Andrew Easton gets into the gnarly “clickable div” territory. This is JavaScript from step-one, which… ok, well it’s React so I guess nothing is rendering at all unless this runs so, fine. Part of it looked clever, the bit about looking for clicks and then forwarding them to internal clickable elements. I thought that would handle the text-selectability problem. But I happen to have a Wealthfront account (this was written on the Wealthfront blog) and I found the exact element in question, and I see the whole thing is wrapped in an <a> tag now (the worst thing you can do), so this must have not really worked out. This is a hard problem, but I think a dang-near perfect solution is right here. It allows for clickable divs, nested interactive elements, text selectability, and good accessibility with semantic HTML (the one downside being a smidge of JavaScript).