Howdy, everyone! Stay well out there.
/* be kind */
To kick things off, this week Sarah Drasner gave this absolutely-fantastic-whoa-holy-heck talk at JSConf about the art of code comments. Sarah argues that comments can be a form of kindness—helping more inexperienced engineers understand complex parts of a codebase, but she also argues that they can help yourself in the future, too. Things can easily be forgotten, and in six months’ time it’s rather unlikely you’ll remember why this one weird CSS doodad was written in this particular way.
There have been many times when I’ve used
git blame and found that the last person that touched this super weird bit of the codebase was, in fact, me. I’ve spent countless hours cursing myself for not writing better comments—and so Sarah’s talk is a rather good reminder to try more care of them in the future.
Comments as footnotes?
Speaking of comments, Justin Duke wonders whether we could reinvent them. He made this mockup, showing how they could be hidden away just like the footnotes in a blog post:
I like this idea a whole lot! Although, I reckon sometimes it would be best to show all the comments just in case that was necessary. But most of the time, I agree with Justin—we don’t need to see all the comments in a file and they can sometimes make the code harder to read.
In that screenshot above, the look more like “collapsed” code comments (something a code editor could like do for us), but note that the UI looks a lot like a classic pattern for exposing footnotes within the article, like bigfoot.js. Which begs the question, what kind of comments would be more appropriate as footnotes rather than inline? Have you ever done that?
“bias towards conservative choices”
A little over a year ago, Max Stoiber wrote about the tech choices he regrets whilst working on Spectrum. And although the specifics of the post might not be all that useful if you’re working with a different stack, I think the lessons that Max highlights are super useful here:
Lesson 1: Building a good product is all about experimentation and momentum. Optimize for iteration speed and flexibility.
Lesson 2: Use existing solutions for technological problems where possible, particularly ones you do not understand deeply.
Lesson 3: Carefully choose core technologies that are hard to change later.
Riffing off this, I remember when my pal Kelly Sutton once told me that it’s okay to write bad code. There are deadlines! Sometimes we can’t refactor! There are things beyond our control! But we should try our dang hardest to write code that is easy to delete.
If we have to rush things for whatever reason, that’s okay. What’s not okay is making this rushed thing difficult to remove in the future.
Anyway, I think that’s really good advice for design systems and “one-off” components that a team has to make. So long as we can delete this weird code and this bad component in the future and replace it with something much better easily then that’s a-okay.
Out with the FCI and in with the TBT and CLS
Lighthouse, the performance measuring tool by Google, changed how its performance score is measured and Paul Irish built this nifty tool that shows how the new version measures things.
I love this blog post about how to create a pencil effect so very much. Scott Turner shows us how to recreate this effect with
feTurbulence is an SVG filter element, and Scott uses it to create rather lovely map designs like this one that look shockingly accurate and hand-drawn:
Google Sheet as a content database > Prebuiling with 11ty
Here’s how to create an editable site with Google Sheets and Eleventy. David Atanda shows us how to use the Zapier app to tie the two together—in this demo we hop into a spreadsheet, make a few columns, and then the content into those columns magically appear with Eleventy.
I love this stuff. This is the real value of JamStack projects for me: the ability to avoid all the complexities of databases, doing it all ourselves, and keeping things relatively simple in the process.
Next up, Ahmad Shadeed dives into CSS viewport units and there’s a pretty top-notch explanation of two values that I haven’t used at all:
vmax. These two properties allow you to set a value depending on whether the height is greater than the width of the browser window, or vice versa.
Food for thought from Chris:
if you’re doing a calculation where the goal is to generally factor in viewport size (like fluid margins/gaps or fluid type) that using
vminmight be more appropriate than
vh. For example, if a user has a browser window that is currently quite wide, but very short, they probably don’t need massive header text like a
vw-only calculation might come up with.
Emojis as Favicons
Lea Verou had a super nifty idea the other day to make an emoji favicon using inline SVG. Surprisingly little code:
<head> <link rel="icon" href="data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 100 100%22> <text y=%22.9em%22 font-size=%2290%22>🏆</text> </svg>"> </head>
Chris then went ahead and made a cute website that lets you update the favicon based on which emoji you select:
The other day I wondered aloud as to why I’d never made an animated gradient before. Well, that’s sort of because we can’t! CSS won’t let you animate a
linear-gradient and the only way we can do that is with an oversized gradient that we then move the
The trick to animating gradients is moving them
But! There’s a great tool out there called CSS Gradient Animator that lets you pick multiple colors, the speed of the animation, and then you can sit back and tweak it to your heart’s content:
Tyler Gaw wrote this piece about
mask-image and how he used it to make a squiggly line repeat indefinitely, just like this:
As Tyler shows in that post, we can style this thing in all sorts of ways which can be handy as a background pattern or texture, too.
Turns out we didn’t have an Almanac entry for masks yet, so we got started building one for
mask-image to kick things off.