#290: Designing context menus, CSS presentations, and complaining about web browsers

[Robin]: Stephanie Eckles wrote this nifty piece about how to use CSS scroll snap to make a website that feels more like a slide deck. With just a few interesting bits of HTML and CSS, you can make a pretty dang good Powerpoint-esque website that could be better for you. Another great idea here is to use the contenteditable attribute so that you can make live coding examples during your talk:

Smart! But make sure to play around with the demo because I think that this is a really neat idea and scroll snap is one of the most overlooked newish CSS features. I am absolutely biased here—but!—I think that being able to change the pace of reading a website now with scroll-snap is what’s so exciting.

Also, somewhat related: I just finished reading Russell Davies’s excellent book about making presentations called Everything I Know About Life I Learned from Powerpoint. It has absolutely nothing to do with front-end development but if you’re interested in learning about how to do a really great talk or you want to improve your writing skills then I’d highly recommend it.

Aspect Ratio is A-Okay

Speaking of mighty fine CSS properties, “Aspect Ratio is great” writes Michelle Barker:

Maybe it’s just me, but I feel like a lot of the time learning new CSS features doesn’t involve just learning a what a single property does, more like getting to grips with a collection of properties and how they work together — even learning a whole specification. That’s certainly not a complaint from me: it makes sense to consider properties as part of an ecosystem. But I have to confess, I love it when a new CSS property lands in browsers that doesn’t have a steep learning curve and just works, with no fuss. The aspect-ratio property hits all the right spots there, neatly solving with a single line of CSS something that was, quite frankly, a bit of faff before.

I couldn’t agree more: the real power of CSS comes into play when you learn all these individual properties and then begin to see how all these properties overlap and what new power that unlocks. Take Michelle’s example later in the post, where she combines aspect-ratio and object-fit: cover together in order to make a series of cards that have exactly the same width and height but might contain images of different sizes inside:

I remember writing a quick overview about object-fit back in 2016 (!) and thinking “okay, this is incredible” because it made my life so much easier when working with images. Now I wouldn’t have to faff about with an image to make it take up the full size of its parent element. Just one CSS property. In. Out. Done.

Complaining about web browsers is okay, but please do not be a jerk about it

Dave Rupert wrote a great piece the other day about some of the lessons he’s learned when it comes to complaining about web browsers. Take it away, Dave:

The best thing I’ve ever done in my career is blog about my specific problems with browsers (or any software you’re passionate about). This goes for software beyond browsers too. I’ve done this for IE, Safari, Edge, Firefox, Chrome, Windows 10, WSL and I’ve seen first hand how a “friction log” can become a powerful tool in an organization.

Behind the scenes, your posts will get picked up by external-facing developer advocates and shared internally. A single blog post is worth 10,000 tweets. It’s valuable because it shows you thought through your problem and narrowed it down to a set of specific issues. All the more if it’s non-combative (see above). I’ve seen this play out dozens of times.

A simplified example of a problem solved by Container Queries is a million times more helpful than an abusive “Support Container Queries, ya fuckers” jab. A list of features causing expensive workarounds is great. If you’re blocked on a feature due to a lack of implementation… blog it.

It’s real easy to dunk on a browser about a specific problem. I have a few 👀 opinions 👀 about how some browsers treat the scroll-snap property for instance, but blasting the developers on twitter is 1. not productive whatsoever but 2. (and most importantly) it isn’t kind. Browsers are super complicated! At this point, they’re nigh on operating systems unto themselves and so dragging a bunch of developers into a snarky conversation about the one thing that frustrates you isn’t the best use of anyone’s time. Even if it’s for my beloved scroll-snap.

Context menus are neat but also tricky to get right

Michael Villar wrote about how to build context menus—those are the sorts of menus that pop up when you right-click something in an operating system or perhaps in a ••• button on the web—and shows just how many intricate details are required to study in order to make the best user experience possible.

Here’s one detail I often miss:

Your context menu should be navigable through keyboard shortcuts. This is another one that seems unpredictable on the web these days, yet it’s so obvious in retrospect. And of course, a nice little touch is to cycle through the menu when reaching the end of the options.

Keyboard navigation for all the things!

A good reminder about text-size-adjust

Kilian Valkhof reminded me the other day to add text-size-adjust to my CSS reset:

[…] Mobile Safari increases the default font-size when you switch a website from portrait to landscape. On phones that is, it doesn’t do it on iPad. Safari has been doing this for a long time, as a way to improve readability on non-mobile optimized websites. While undoubtedly useful in a time when literally no website was optimized for mobile, it’s significantly less helpful nowadays. […] Text size increasing randomly in a single situation is exactly the type of thing you want to guard for with a CSS reset.

html {
  -moz-text-size-adjust: none;
  -webkit-text-size-adjust: none;
  text-size-adjust: none;

It’s one of those things that’s easy enough to forget but when you notice it, you NOTICE it. It can definitely bork your website in that one case.

What’s happening with CSS and color these days?

For a long time, CSS has been limited in terms of what we can do with color. We’ve been stuck with one color model, RGB, and it meant that our modern screens could display more colors than what we could make browsers do. But there are a lot of exciting changes these days when it comes to color and CSS, as Chris writes:

It turns out that modern monitors can display way more colors, particularly extra vibrant ones, but we just have no way of defining those colors with classic CSS color syntaxes, like HEX, RGB, and HSL. Super weird, right?! But if you use Display-P3, you get a wider range of access to these vibrant colors.

Display-P3 isn’t available in all browsers yet, but it is in Safari, and it looks like this in CSS:

body {
  background: color(display-p3 1 0.08 0); /* super red! */

Color spaces, like RGB or display-p3, are most certainly not my area of expertise but this is very exciting. However! It’s important to remember that display-p3 won’t be entirely replacing how we do color in the future. This isn’t a flexbox over float for layout situation:

In a conversation with Adam Argyle, he used a memorable phrase: All the color spaces have an Achilles’ heel. That is, something they kinda suck at. For sRGB, it’s the grey dead zone thing, as well as the limited color gamut. LAB is great and all, but it certainly has its own weaknesses. For example, a blue-to-white gradient in LAB travels pretty awkwardly through purpletown.

Ah! I feel like I’m going to return to display-p3 once it has better browser support. There’s nothing stopping me from learning about it now but I feel like it’s going to be a neat, additional thing we can do in the future, rather than rewriting the whole playbook.

Resolve incidents faster through ops, alerting, and documentation

The longer the MTTR, the greater the impact on the organization, whether in cost, risk, or diminished trust from customers or partners. Learn how modern development teams are using monitoring and alerting to improve their incident response workflows.

Netlify Identity, a Key Aspect to Jamstack Development

Say you want to build a TODO app with users. Those users will need to sign up and log in. Can’t do that with a static site, right? You can, actually. Netlify helps with Netlify Identity, a robust offering they’ve had for years. Enabling it is just a few clicks in the admin UI, and they even provide auth widgets so you have to build precious little to get this working.

[Chris]: Eleventy is kicking butt lately. Just last month they had a big 1.0.0 release. I guess moving on from the ol’ zero.point area means breaking changes, but it also means huge new features and implied stability that I’m sure is very attractive to people considering site-building frameworks.

What I like using about Eleventy (I’ve done a couple little sites in it, like our conferences site), is that it’s just an easy foundation to build a static site around. It had smart default behavior that processes templates, moves files around, and produces a shippable website. What I don’t like about Eleventy is that out-of-the-box, the processing languages are slightly old-school, like Liquid and Nunjucks. To me, none of them really embrace “components” in the way I like. I think all digital products should be built from components. Not any particular technology, but that essentially follow this pattern:

import "Component";

<Component pass={data} />

That gives you the power to compose anything in the way that maps best to your brain and to your organization. So I perked up a bit when I saw Eleventy + Lit. Lit is a framework for Web Components, which fits the organization bill for me, but the server-side rendering story for Web Components, Declarative Shadow DOM, doesn’t feel very nice to me if you have to do it manually. So… don’t do it manually! Let Eleventy do it! You should check the blog post, but I’ll post an image here that sells the story for me:

Brad seems convinced too:

Declarative Shadow DOM always looked gross to me and I felt it almost defeats the purpose of web components. BUT! With tools like this (especially this @lit-labs/ssr project), we can have our cake and eat it too: use web components in a dev-friendly way, and then have the machines do the heavy lifting to convert that into a grosser-yet-progressive-enhancement-enabled syntax that ships to the user.

I’ll also admit that the reason I like component composition is from working with JavaScript frameworks for so long now. They just straight up did a good job with it, from an API perspective. The tables have completed turning though, using JavaScipt frameworks in an entirely-client-side rendered way isn’t nearly as good for anything (users, SEO, performance, accessibility, etc) as server-side rendering (the effects of hydration are still debatable, but I view as largely worth it).

So what about Eleventy + JavaScript frameworks? That’s the deal with Slinkity:

🚀 Unlocks component frameworks like React for writing page templates and layout templates. Turn an existing .html or .liquid file into a .jsx file, and you’re off to the componentized races.

So in the same way you might reach for Next.js because you know React and want easy SSR, now you might reach for Eleventy.

And I just heard today that Zach is now fully sponsored by Netlify for the open-source development of Eleventy. Sweet.