tl;dr: i painted three paintings, and here are all three paintings together:

i call this series "nearest neighbor" because i digitally render the references by scanning my sketches and scaling them down using the nearest neighbor scaling algorithm which gives it a sharp pixel art output. i've been using photopea for this a couple of years now.

okay, so i'll start each study showing my original sketch and then process shots. remember, these were taken with a 20-year-old point and shoot digital camera, so do try to appreciate the dreaminess of the shots instead of lamenting the...lack of focus lol.

for the first study, i took the scan of the sketch, scaled it down and then fussed with color levels so that the pixels were mostly black but there were accents of purples, greens and a couple of reds. it reminded me of when you'd put your eyes right up to a crt television screen and can see the colorful dots that are still needed to make a mostly black and white image.

i worked on this in december on our dining room table. i used some colors from this winsor and newton student gouache set that i got dirt cheap during a sale.

i recorded the entire process. maybe i will post a timelapse one day. i record a lot of my art practice and talk to myself so that i can go back and take notes of things i call out to myself. if i die and someone posthumously posts these videos, i will haunt them.

i was painting on a livestream the other day and showed this final painting off and said i will probably go back and make the background more opaque. i like the color accents, but i wonder if it would look even cooler if the background was fully black. i will probably do this figure again in black and white with a cyan background based on my experience of the following studies.

oh, i also made a little beaded tapestry to see if i would enjoy doing beadwork. the answer to that is...no. lol. at least not right now in my life. the beads against the board sound very cool when pumagreg jumps onto the cat tree that it currently adorns. beads sure are heavy and expensive.

the inspiration that sparked this series actually came from this figure sketch. this was from an online model, and it is such an elegant, simple and interesting pose. this was my favorite painting of the series so far as well.

this time i wanted to skip the color accents and just go full grayscale on the body and a bright background. i am also now realizing as i edit this photo that i recorded this painting's process too. i forget if i captured the whole thing though.

i'm also working at the same table with a similar setup except i only had to work with black, white and yellow gouaches. i used holbein gouaches, one of tubes i bought in berlin a very long time ago and the others were part of this 12-piece set i impulse bought - a purchase that i think i would regret if i believed in the act of having regrets. 😈

i love how this one came out. the yellow was such a good choice, and i love how it contrasts with the grayscale figure. maybe i should another bead project but with this one using the lessons i learned from the first beaded peace i did [btw if you'd like to contribute to my heavy and expensive bead budget as a thank you for blogging, you can tip me and/or shop my store, bugs rock xoxo]

for the third study i wanted to do a larger painting and try a model that has some kind of props or accessories. this model was from an online gallery.

i livestreamed most of the process of this painting but i didn't record the majority of it. this means that if you happened to watch any of my streamplace streams, you are special and got to watch something no one else ever would. i'm still trying to figure out the best desk setup to paint live. at least it finally occurred to me that my easel is extremely adjustable in height as it's on a standing desk lol. this was way better for my back than the table!

another thing i wanted to try was keeping the pencil grid, in the other two paintings i erased any visible pencil grid lines. i think this is cool for inside the figure, but not so much in the background.

i loved this "cosmos pink", it reminds me of a hotel i had stayed in berlin in 2019 that had a freight-like elevator this exact color. i did not like painting the accessories, the scarf in particular. it was a lot of work to keep its dimension without a lot of pay-off. it will be awhile before i try to paint this big again unless the figure is smaller.

🦋🍌🎀

when i got into painting pixel art, that was only after an entire era of me using colored pencils and gel pens to make "analog pixel art". i find painting to be way more ergonomic and affordable, with the only tradeoff being that paint is harder to control or do very precise work than with pencil or pen. even though i've been doing it awhile, i still love capturing and iterating on my process to make the practice and my work more fun. anyway here is what i learned from this series:

1. i am not a big fan of acrylic gouache. it's hard to clean up after, and can't be reactivated.
2. monochrome figures with a high contrast background are cool to paint and look at
3. beads are heavy and expensive
4. my camera works great still even though it is 20 years old, all it needed was a new battery.
5. i shouldn't wait 7 months to share a painting

at the end of the day, if any of you can take one thing out of this entire series - which is only just beginning - it's that my hoarding of peripheral cables for over 20 years has been validated, which means so has yours.

xoxo jenn

Every day it seems there is a new tool, new MCP, new model, new skill, new workflow, new feature, new social post that is some form of “Hey look! I have completely figured out AI with this one weird prompt.”

I…don’t believe you.

I work with AI every single day, and what I’m finding is that less is way more. It’s not about what I install or configure or trick the agent into doing that makes any real difference. That stuff is interesting, but at the end of the day it feels like gimmicks.

I see the biggest gains in my productivity from how I use the harness and how well I understand it.

So in this post, I’m sharing you a simple workflow that you can use to drastically improve your effectiveness with AI just by using existing features of GitHub Copilot. No weird prompts. No skill everyone else seems to know about. Just the harness. The harness is all you need—mostly.

1. Pick a tool, any tool

This is an obvious one, right? Pick a tool! It’s so easy!

But even within the GitHub Copilot family, there are a lot of options. These include the CLI, the new GitHub Copilot app, VS Code, Visual Studio, and JetBrains, just to name a few.

The good news is that these experiences are increasingly being centralized on the same harness. The details can differ by tool, but the core workflow is consistent. Learn the harness once, use it everywhere.

That said, I do believe that learning the harness is key, and the best way to learn it is to be as close to it as possible. So if you are just starting out, I’d recommend beginning with the GitHub Copilot CLI. It’s a terminal interface, which means it’s just text. There isn’t much UI to learn. You enter a prompt. The agent does things. But the interaction is more direct, immediate, and, frankly, very satisfying.

For this demonstration, I’ll be using the new GitHub Copilot app. But the harness that app uses is the exact same thing you’ll be using if you are using the GitHub Copilot CLI, Visual Studio Code and many other places you can find GitHub Copilot.

2. Turn on YOLO mode

YOLO mode is also known as “Allow All.” This lets the agent execute any command without asking permission. This can vary depending on the tool you are using, but for most it is simply an /allow-all command in the chat. Otherwise, the agent is going to stop and wait for your approval every single time it needs to do some work.

Agents need autonomy for you to see an increase in productivity. If you have to approve everything the agent does, you might as well just do it yourself. Besides, that’s a miserable user experience. Nobody wants to be relegated to sitting at a desk pressing the “Approve” button all day. And pressing “Approve” over and over just trains you not to read what you are being asked to approve, which defeats the purpose.

You want to be safe with agents, though. Bad things happen to good people. When using YOLO mode, you don’t want to run the agent on your local machine. This is especially true when you are using them at work—data is private on your organization’s systems, and mistakes can be costly.

Fortunately there are a bunch of options for running agents in sandboxes. An easy one to get started with is GitHub Codespaces or development containers.

3. Start with a prototype

One of the most magical things about AI is that you can easily prototype anything and everything up front. Historically, this was not the case. Prototyping was a full phase of a project, and were often a luxury. Now, you can make one with a prompt.

Let’s look at a few examples.

Let’s say we want to build a date picker web component. That seems straightforward, but it’s actually quite complex. Think of all the different things you might want to do with it.

• How do you navigate within the component?
• What does the selected date look like?
• What does a selected range look like?
• How does the user navigate between days, months, and years?

Start with a simple prototype and get several variations. I usually start with something like this:

Give me 20 mocks for a date picker web component. Put them all in an HTML file so I can compare.

In this case, the AI generated a bunch of different layouts, but one of them is a mock where it starts with the year view. That’s interesting. I would like my date picker to enable the user to zoom out to the year, then into the month, and finally to the day. These are the kinds of things you don’t consider until you see them.

As humans, we process sensory-rich models like images, shapes, and tangible layouts much faster than dense text. Creating low-effort prototypes early on helps make complex concepts immediately intuitive.

And this applies to non-visual tasks as well.

For instance, if I want to add a new API endpoint, I’ll still create a visual prototype to understand the requirements and constraints before diving into the implementation.

Create a visual mockup of the API for this project. Add five options for how we could handle a new API endpoint that allows the user to download their analytics data.

Since the GitHub Copilot app supports Mermaid diagrams, the agent renders this as Markdown, mapping out five different ways we could implement this API endpoint.

When working with agents, it’s easy to forget that everything is nuanced. Prototyping helps uncover the nuances up front, so you avoid spending valuable time and tokens on rework.

I recommend using a medium-sized model, such as GPT 5.6 Terra or Claude Sonnet, on medium reasoning for most work. I also recommend you stick with whatever model you choose here for the duration of this particular feature, bug, or enhancement. Prompt caching will save you tokens. As long as you don’t switch to a different model or reasoning level, your previous chats remain cached with the model, giving you a discount on future requests.

4. Plan methodically

Now that you know what you actually want versus what you initially thought you wanted, it’s time to plan out the implementation.

Switch to plan mode in GitHub Copilot without starting a new session.

/plan Build a date picker web component. I want the user to be able to zoom in and out of years, months, and days.

That’s a pretty vague prompt, and you’ll likely have more context for the model than I do here, but this is just a demonstration. If you don’t have more context, it’s OK. That’s exactly what this step is for.

In theory, you can get a model to one-shot anything if you compose the perfect prompt with the perfect context in the perfect order. In theory.

But none of us can do that. Planning helps you get closer to that ideal, though, by asking all of the questions that you would need to answer yourself along the way if you were to build this out by hand:

• Can the start and end date be the same?
• Are partial selections valid?
• Should users be able to clear the date?
• Should “today” always be a visible option?
• Is manual entry allowed?
• What format is the date stored in?
• Should pasting in dates be allowed?

The list goes on and on. You cannot possibly think of all of these edge cases, but the model can help you identify many of them.

You can make plan mode even more aggressive in the sheer number of questions and edge cases it asks about by installing the “grill-me” skill from Matt Pocock.

/plan /grill-me Build a date picker web component. I want the user to be able to zoom in and out of years, months, and days.

This planning step is critical. The point is not for you to just accept every suggestion from the AI. If you do that, you are negating the value of this planning process. The point is for you to deeply engage with the problem and guide the model. This is where your expertise comes into play.

You can also ask the model questions back. In the screenshot below, it asks me about “non-contiguous dates.” I’m pretty sure I know what the model means here, but I’m going to ask for clarification so we’re on the same page.

The planning process will keep going even if you interrupt to ask clarifying questions, etc.

5. Implement with Autopilot

Once the plan is finished, GitHub Copilot will likely prompt you to switch to Autopilot and start implementing the plan.

Autopilot is a built-in loop. It forces the model to continue working by ensuring that it has actually done what it said it would do—which in this case is completing every item in the plan.

GitHub Copilot will automatically act as an orchestrator during this phase. If it needs to read files in the codebase, it will use the “Explore” subagent with a small model. If it deems an action relatively complex, it will likely choose the “General Purpose” subagent with a larger model. While you can get fine-grained control over orchestration in GitHub Copilot with custom agents and instructions, you don’t need to do anything special to get the advantages of subagents and multimodel workflows. This works out of the box, even if you did not know that any of these things existed.

6. Human review and iteration

This is where you get your dopamine hit. You get to see what the AI has created.

But it’s likely that you won’t get exactly what you wanted. That’s normal and expected. The model cannot read your mind, and it is error-prone. Iterate with the model until you get what you actually want. Whether that’s just code or an improved UI, this is the part where your taste will decide the quality of the final product.

For instance, here’s the date picker that GitHub Copilot gave me.

Already I can see it has some issues:

• Animations are inconsistent
• Text is unreadable when hovering over a selected date because of color contrast
• It doesn’t need to say “12 YEARS” at the top.
• When I click “Today”, it doesn’t take me to the day if I’m in the month or year view.

Also, I don’t love the design. It looks a little too much like it was created by AI—because it was!

So here we’re just in follow-up mode. I’m going to use a CSS framework I created called Postrboard. I add it as a skill that just points to the CSS and tells the agent how to use it. You can feel free to install it yourself if you’d like to use it, or you can pick any other CSS framework out there that you like. Giving the model some design guidance is quite helpful, and often a CSS framework is all you need.

ok - we don't need a landing page here - just the component, output and settings panel in a minimal setting. Use the /postboard skill for the design and colors.

For the date picker, when I click on the day, it tries to zoom in, but can't because there is nothing to zoom to. There should be no zoom there.

It doesn't need to say "Zoom Out" at the top

When I mouse over a month or year that contains the selected day, I cannot read the hover text.

When I click "Today" it should take me to that day view, even if I'm on the month or the year.

The months don't need numbers under them and they don't need to be in boxes

Same goes for years. And it doesn't need to say "12 years" at the top."

Notice how conversational this is. Don’t overthink it. When you’re fixing a bunch of small things like this, just give it to the model. If you’ve got the context, you’ve got the prompt.

The most important thing is not to settle for AI output that is “good enough.” Insist on quality. Be ruthless about it. That part is still your responsibility, and knowing what a quality result is from something that isn’t is the value that you bring. No AI will ever replace your human touch and creativity.

Here’s what my final date picker looks like. Scroll to the end of this post to see it in action.

7. Rubber duck the result

After you’ve iterated and are happy with what you’ve created, it’s time to do a final review.

Request a Rubber Duck review from GitHub Copilot. You can do this just by asking for it:

Perform a rubber duck review on this date picker component implementation

In a Rubber Duck review, GitHub Copilot will request a review from a model of a different AI family. For instance, since I was using GPT 5.6 Terra, it requested a review from Sonnet. Different models were trained on different data, so they have different blind spots. A Rubber Duck review helps identify potential issues that might be missed by a single model.

Note that you can use this at any point in this workflow. You can rubber duck prototypes. You can rubber duck plans. It all just depends on if you want a second AI review on something.

And if you want to take this a step further, you can combine rubber duck with Autopilot to get the models to work together in a loop to improve the final result.

/autopilot rubber duck this date picker implementation. When you have the result, review it carefully and make any necessary adjustments. Repeat the rubber duck review until both you and the reviewing model agree that the only items that remain have diminishing returns.

After this step, you will have an even more refined result than before and will have likely identified many extra edge cases. This step does cost more tokens, but you are really battle-hardening the code. Think of it as an investment in your future self who won’t have to deal with these issues because you caught them now.

8. Profit

At this point, you’re ready to stage and commit, or move on to the next feature you want to add along with this pull request.

I’d recommend starting a new chat session for anything you do next that doesn’t have to do with this date picker. You can think of chat sessions as being topical; if you start to diverge too much from the main topic, it’s probably time for a new session.

Here’s the final result from my workflow building the date picker for this post.

I realize that this is a bit of a contrived example, but can we all just pause for a moment and marvel at what we’re able to pull off with AI now? Building a date picker used to be one of the hardest things you could try to do. Just ask any of the heroes out there who have built them.

Things don’t have to be complicated

This simple workflow will be enough for most people. The simplicity also helps you multitask. It’s easier to reason about what agent is in what state and what you were doing last when you keep things simple. Your context window is limited too.

There is so much happening in the AI space right now. There is no upper limit on the things that you can build and experiment with. You can add MCP servers, skills, instructions, and custom agents. You can set up workflows and loops, create agents that prompt agents, and stand up entire virtual dev teams.

But keep in mind that nobody really knows what they are doing right now. We’re all figuring this out as we go. A lot of what is today’s magical incantation for AI will be tomorrow’s anti-pattern.

Just focus on getting a repeatable, high-quality result in the simplest way that you can. Learn the harness and you’ll be just fine.

The post The harness is all you need (mostly) appeared first on The GitHub Blog.

At the crux of the new experience is the new and improved editor. When you first launch into the v2.0 editor, your first response will probably be “Who moved my cheese!?” New is always uncomfortable, but there’s a fix for getting back to the old familiar UI…

• Hit ⌘ + U or CTRL + U to hide the new pen sidebar
• Install the Classic Block Template to remove ~14 lines of HTML (Optional)

Okay, now hit ⌘ + U or CTRL + U again, because what’s in the sidebar are all the new features and favorite parts I want to talk about.

An entire file system

The first thing you’ll notice when entering the new CodePen editor is a file explorer. That’s right! CodePen is breaking out of its three-file constraint and allowing you to build entire multi-file and multi-page websites.

A not-so-secret feature of CodePen was that you could mimic a file system in CodePen by using other pens as external resources, but referencing your custom reset.css by importing <user>/pen/<slug>.css wasn’t the JS module-like experience you come to expect from the modern web.

But gone are the days of 2,000 line JavaScript files, I can now import foo from './foo.js' like TC39 intended. I must admit that my more complex ideas were hitting the limit of what was comfortable to type into a tiny textbox. But now creating a folder of web components or JSON data files to loop through is easier than ever. I can build multi-file and multi-page prototypes (e.g. view-transitions! service-workers!) all without spinning up a local dev server. Digging up an old CodePen is much easier than finding an old folder on an old hard drive and it’s arguably the easiest way to put a custom webpage up on the internet right now.

Without drawing too many comparisons to competitors, CodePen at times felt a bit underpowered when compared to other online code editing environments. But those other services that spin up an entire Node.js Docker so that I can build my <fart-button> always felt like overkill to me. CodePen now occupies not just the entry-level and middle ground, but almost the entire spectrum of needs that I have for prototyping and small site building.

Versioning and deployments

Who amongst us hasn’t totally beefer’d up a good pen before?

Ruining an otherwise quality pen to idea creep or losing work to a browser refresh is always a possibility with online editors. It’s typically not world-ending for me and my …ahem… spartanly styled pens, but for sure results in a couple choice swear words. I imagine trending tab experts and newbie beginners find this even more frustrating. But now pens have a version history so you can roll back if necessary.

The deployments are better now too. Sometimes when building an idea, I like to send the “chromeless” version of the pen to non-developer friends or partners/clients to avoid overwhelming them with CodePen UI. This is also useful when debugging on your phone. The debug/URL worked, but if you’ve ever URL-hacked a private pen URL on your phone you know how un-fun that is. But now I can deploy the pen, get a nice codepen.dev URL or point my custom subdomain at CodePen’s DNS, and Airdop that URL to myself. A small but meaningful quality of life improvement for me.

Blocks

My favorite feature of the new CodePen is Blocks. One of my biggest gripes with modern web development is the amount of tooling it takes to get started. We’ve made it so damn complex to make a webpage, no wonder AI is so popular.

Blocks adds a visual layer to the opaque world of preprocessors, linters, and build processes. CodePen takes those processes and stack them on top of each other to form a predictable pipeline that you can easily visualize and understand how the sausage gets made. Imagine how this must feel for beginners compared to a dozen config files littering the root of your repo! Web development demystified.

I’ve wanted a UI like this for build processes for a long time: Gulp, Webpack, Vite, GitHub Actions, Azure DevOps Pipelines… I feel every service would be better if it had a Blocks UI. Like Scratch, but for servers. Experienced developers might even be less afraid to operate on their build tools if they had something like this.

I think CodePen has created something special here that most people won’t fully understand. A perfect fit for their beginner audience as well as their professional audience who don’t want to copy, paste, and manage config files to build a simple website or goofy pen.

A simplified but more powerful UI

A whole new product with a new file-system, versioned deployments, and customizable build chain smooshed in… yet the UI still feels familiar. It’s rare for products to evolve so intuitively. There’s more features, but everything feels more predictable. In the “classic” CodePen editor you’d have to surf through a handful of dropdowns and modals to tweak your settings and now a lot of that work is automatic. You want Sass? Add the .scss file extension. You want TypeScript? Add the .ts extension. CodePen will add all the Blocks for you with a default config that works.

It feels like all the configuration options are all co-located in the right place now. And the new omnibar search box is the ultimate get-out-of-jail-free card, exposing most of the features you’d need without all the hunting and pecking. Expanding the capabilities of the product while maintaining simplicity deserves some applause and I feel the team at CodePen walked this delicate line and succeeded.

A couple final thoughts

I’ve said it before (and I’ll say it again) I admire the team at CodePen and –despite my obvious biases– I think they’re one of the best product teams out there. In their podcast they give you a rare, honest, behind-the-scenes look at how they are thinking about and building their product. No one even comes close to their level of transparency.

Probably my favorite part of Team CodePen is that they’re not afraid to tackle the hard work and pay down technical debt when needed. They stay small, sweat the details, and take their time. There’s no back-pressure from venture capital to move fast and break your things. In my view it’s software done right.

Because I was part of the beta, I’m already using the hell out of CodePen 2.0. I’ve built dozens of big ideas (a browser-based camera, a service-worker based declarative shadow DOM solution, a half-dozen in-browser AI chatbots, a minimum viable design system, and more) that would have been either cumbersome or next-to-impossible in the previous editor. CodePen 2.0 is already enabling me to build bigger, better, and more complex ideas without leaving the comfort of one of my favorite applications on the whole entire internet.

So thanks, CodePen, for the huge upgrade and congrats to the team on the launch. 🎉

To call this derivative is an understatement. But that's what this genre demands; rehash all your favourite media properties into something new. It's the literary equivalent of having your Transformers™ fight your He-Man© toys.

The plot, such as it is, features the Vogon Constructor Fleet destroying Earth due to a late beurecratic appeal, forcing people to play The Hunger Games, while a Twitch streamer narrates the action.

The protagonists in Andy Weir's books are boys who know enough science to save the day. The ones in Scalzi's books have enough pop-culture knowledge to save the day. Dinniman's has played enough loot-box gatcha RPGs to save the day.

It is mostly pretty good fun. The tropes are goofy, the gore is splattertastic and only rarely ventures into torture porn, the villains are suitably campy, and the wisecracking sidekick doesn't become too annoying.

But the prose…

Here's a classic scene from Red Dwarf which exemplifies the major problem I had with this book.

There's only so many times you can read "Then I severed a +3 damage with poison debuff while he raised a +1 shield and used his armour of holding to neutralise the attack". I find opening endless lootboxen a chore when I'm playing a game - reading 150 instances of "I got a bronze box with a cauldron of Mafeking, then a gold box with an enchanted ring, then…" just becomes tiresome.

I tried listening to the audiobook of the sequel and I just couldn't get past the endless recitation of lists about +5 to elbows and -6 to arseholes. Just unbearably tedious.

Look, I've never written a novel and doubt I could do any better. This has obviously found its fanbase but, regrettably, I'm not one. It was a fun enough read, but I'm not sure I can be bothered with a dozen more sequels of recycled plots and repetitive squishing of cackling enemies.

CSS infinity (and -infinity!) solve some pretty specific problems elegantly, but can also just be plain fun to use.

Showing support for infinity, -infinity, NaN, pi, and e

Lets spur creative CSS juices with infinity and follow a couple use cases.

Basics and gotchas #

infinity and -infinity need to always be wrapped in calc().

If you want it to represent a dimension, it also needs to be multiplied by a unit like:

div {
  border-radius: calc(infinity * 1px);
  z-index: calc(infinity);
}

Not quite limited to calc() too, you can use it with other calc()-like scenarios like clamp(), min(), max(), etc, which we'll dig into a bit 🤘🏻

1. Circles and Pills #

Before infinity, I would have used scientific notation like 1e9px (which is 1000000000px) to create a "big enough" radius for circles and pills at any size.

But with infinity..!?

.radius-full {
  border-radius: calc(infinity * 1px);
}

2. Perma-state #

Setting duration calc(infinity * 1s) makes an animation/transition so long that it appears to be frozen ⛄️

Hover over those boxes and the duration will be pinned to happen over infinity seconds, sticking the state for the duration of the page's life.

I like how the duration of your hover is permanently made visible too. Visible millisecond duration via background color.

3. z-index #

Need to beat z-index: 999999999 or something?

.tippy-top-of-stacking-context {
  z-index: calc(infinity)
}

This will max out at the largest int a browser allows: 2147483647. Speaking of that number, you can see it by using counters like this:

.css-max-int {
  counter-reset: cssInt calc(infinity);

  &::after {
    content: counter(cssInt);
  }
}

See!

4. To infinity and beyond #

Use calc(infinity * 1px) to remove the floor or ceiling of a clamp.

div {
  inline-size: clamp(
    calc(-infinity * 1px), /* no floor */
    100%, 
    calc(infinity * 1px)   /* no ceiling */
  );
}

5. Freeze view transitions #

Make view transitions never complete.

::view-transition-group(*),
::view-transition-old(*),
::view-transition-new(*) {
  animation-duration: calc(infinity * 1s);
}

The ::view-transition tree stays in the devtools DOM, giving you an opportunity to inspect or tweak.

You can also freeze and inspect animations using the Animations panel in devtools.

6. Responsive radius #

Another scenario where I would have reached for making a large number with scientific notation, is a responsive border radius.

.viewport-responsive-radius {
  border-radius: clamp(0px, (100vi - 100%) * infinity, 20px);
}

.container-responsive-radius {
  border-radius: clamp(0px, (100cqi - 100%) * infinity, 20px);
}

If the elements inline-size is less than 100vi, the radius will be 0. If it's greater than 100vi, the radius will be 20px.

There are a set of these available in Open Props.

7. Bools #

Clamp an arbitrary number down to exactly 0 or 1, then use it:

.flippy {
  --solo: clamp(0, (2 - sibling-count()) * infinity, 1);
  --crowded: clamp(0, (sibling-count() - 5) * infinity, 1);

  flex-grow: calc(1 - var(--solo));
  font-size: calc(1rem - var(--crowded) * 0.125rem);
}

One variable now can drive color, offset, opacity, gaps, whatever.

8. Backdrop #

You can use the spread feature of box-shadow to create a non-interactive backdrop:

.backdrop {
  box-shadow: 0 0 0 calc(infinity * 1px) #0005;
}

Paint past the "entire viewport".

9. Scroll Trigger #

Trigger a scroll driven transition in, and never transition out.

.nav-title {
  timeline-trigger-activation-range-end: calc(infinity * 1px);
}

.product-title {
  animation: slide-and-fade 150ms ease both;
  animation-trigger: play-forwards play-backwards;
}

Though you'll see in the demo I use scroll 100% which is a specced way that feels closer to the intent I was going for, in that I wanted the range end to be the end of the scroll area.

Try it:

Also, just for funsies to share, here's the scroll driven version of the same navbar effect. Doesn't use infinity, but fun to try and compare scroll-triggered vs scroll-driven animation.

Thats all #

Hope you found that interesting!

Comment with your own creative uses of infinity?

But first, there’s something you should know about me. I have this aphorism I live by: everyone is weird and everything is complicated. The former is mostly meant as a compliment. But today, I’m going to do what I can to mitigate the latter. And you know what’s complicated? Web apps. There are so many tech stacks you can choose for websites and web apps these days. They all have these dumb acronyms—LAMP, LEMP, MEAN, MERN, JAM.^[1]

Let’s take the LAMP stack, for example. It stands for Linux, Apache, MySQL, and PHP. This has to be the most popular server stack on the internet thanks to the popularity of WordPress, the venerable blog and website content management system that powers a whopping 40-something percent of all the websites on the internet.^[2]

WordPress uses PHP to reach into the MySQL database and construct whatever page is being requested. There’s quite a lot that goes on when WordPress does that, and it can be slow. It’s also pretty old (if actively maintained) software and isn’t always the funnest thing to develop sites with. I’m not saying it’s bad, just pointing out a few reasons why people might choose a different piece of software—or a different server stack altogether.

The rise of JavaScript on the server (i.e., Node), and frontend frameworks like React led to other stacks like MERN (MongoDB, Express, React, and Node). A lot of people are using static site generators which allows them to remove server-side complexities (although it potentially comes at a cost of introducing more complicated client-side JavaScript).

I do a lot of low to medium-size websites and apps. For these types of apps I’ve really come around to enjoying the SLAP stack—SQLite, Linux, Apache, and PHP. It can do it all, and doesn’t require you to run a database server. And I don’t mean to imply it’s only good for small projects. I think this stack can scale quite well considering its simplicity. Let’s talk about it.

The SLAP stack: SQLite, Linux, Apache, and PHP

Alright, first of all, if you thought I was going to go into a nerdy, analytical deep dive on the performance of SQLite and/or this stack let me go ahead and disappoint you right now. I am way too lazy to look into all that and get specific numbers. I’m kind of going by what I’ve read and what I’ve learned so far in the very cool course, High Performance SQLite.

Let me take each technology in turn and discuss.

SQLite

Here is a summary of my current understanding and intuition about SQLite.

• The database is one file^[3] and doesn’t need a database server
• Easy to backup because it’s one file and has a backup command
• Really good at reading data quickly
• Not super great if you have a ton of concurrent writers (1,000+ writes per second maybe?)
• Not super great if you have over a terabyte of data
• Can (and does) easily power a website
• For a website that will be doing a decent amount of writing, you should use the write-ahead logging (or WAL) option

I’ve only started scratching the surface of this technology so there is a ton I don’t know about it.

Linux

Really nothing to talk about here as many, many web servers are running Linux. But if you’re curious, I am running Ubuntu 26 LTS for my app in question (which I will discuss shortly).

Apache

I’m using Apache because it’s simple and boring and because the apps I build typically use .htaccess files to disallow access to certain files and directories.

PHP

I only really know two programming languages well enough to build web apps with them—PHP and JavaScript. I’m not proud of this, but it is what it is and I’m busy. My side projects need to be built with what I know. Sometimes I go vanilla PHP, other times I use my beloved Fat Free Framework.

SLAP the app together

All of these technologies have been around for a long time. They’re mature, well understood, and there’s plenty of information on the web about them. For me, as someone who only has nights and weekends available to mess around building apps, this is perfect. I do enjoy learning new languages. And I enjoy the act of programming, even if it’s an exercise or puzzle. But I live for the holistic thing itself—the website, the application, whatever it is. I love combining all the disciplines—backend code, frontend code, UI/UX, writing, art, soul—and delivering a useful app that people like. This is my passion.

Next up, I want to show you how you can set up the SLAP stack on a VPS (virtual private server). This is a step-up from shared hosting because it means you’re managing most aspects of the server yourself. This fact scared me for a very long time. But recently my hand was forced (my shared host’s filesystem wasn’t a good fit^[4]), and I decided it was time to buckle up and learn this ancient skill. I’m sharing what I’ve learned here but with the disclaimer that I am a beginner at server management. You should definitely check up on anything I tell you to do here.

The stuff I’m going to show you should work for most SLAP stack projects, but I want to tell you briefly about my specific project, Minimal Character Sheet. I’ve written about my freeform digital character sheet previously but, to summarize, this is a web app that facilitates Dungeons & Dragons character sheets in a format that is very similar to form-fillable PDFs. But unlike PDFs, there is plenty of room to write. I also throw in some extra goodies like dice rolling and doing some light number-crunching (for ability and skill modifiers).

It runs on the SLAP stack and uses Fat Free Framework. F3 is another blog post altogether, but it’s the one PHP framework I’ve found that is as simple and noninvasive as I need.

The app has moderately low traffic at the moment with around 250 monthly active users. Its needs of the server are light—it’s mostly shipping JSON between the frontend and backend. It does need to send emails related to authentication, but does that with the email sending service, Postmark.

One regret I have about this project is that, much like WordPress, all of its files are in the public HTML root. This means I have to take care to block access to certain parts of the app (like the database). I’d like to refactor the structure of the app at some point, but I have other, more pressing, things on the to-do list.

How to set up the SLAP stack on a VPS

I made a ton of notes while I was figuring out this process and I was doing a lot manually at first. But I narrowed things down to a few reproducible steps using scripts. That’s what I’ll share here.

First up, you’ll need a VPS provider. The field is huge and pricing is all over the place. It seems everyone loves Hetzner, but they had a recent price increase and seem to be rationing the cheaper VPS options at the time of this writing. DigitalOcean is another big name here. They call their VPS products, Droplets. This would probably be my choice, except for the fact that this self-hosting project is experimental for me and I want the cheapest reliable-ish VPS I can find. So I grabbed a $5/month no-commitment VPS from IONOS. I’m not recommending the service per se, but I was able to get a VPS up and running with decent specs at a low cost. So far so good.

What we’re installing

After a bit of research^[5] I determined that these are the packages I need to install on my VPS for the simple app that I’m running.

• apache2: the Apache web server
• sqlite3: the SQLite3 CLI
• php: the latest version of php
• libapache2-mod-php: this is what lets Apache execute PHP files
• php-sqlite3: the SQLite3 extension for PHP
• php-opcache: automatically caches compiled PHP (not needed for PHP 8.5 turns out, but install it if you need it)
• php-mbstring: I don’t entirely understand this one but I think it is essentially support for UTF-8
• php-curl: enable a PHP app to make network requests
• php-xml: DOM-parsing capabilities
• php-zip: I have a backup script that will need to zip up files
• micro: this is a text editor I prefer to use because it has some mouse support, which is helpful for me

Cloud config

After messing around with different options, I found that the quickest way to get a VPS provisioned with the stuff you want on it is to use a cloud config. This is a yaml file which lets you specify a configuration for your VPS much like you would do with a Dockerfile. I think most, if not all, VPS providers have some way for you to supply this configuration file during the VPS setup process.

Using this cloud config will let us set up a user with our ssh key(s) and disable the root user as well as password authentication. All of this is part of the basic user setup you would do for a new VPS. In addition, we can specify the packages to install, set some permissions, and get our firewall up and running with a basic configuration.

#cloud-config

package_update: true

users:
  - name: YOUR_USER
    groups:
      - sudo
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
    lock_passwd: true
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... keys go here

disable_root: true
ssh_pwauth: false

packages:
  - ufw
  - micro
  - apache2
  - php
  - libapache2-mod-php
  - sqlite3
  - php-sqlite3
  - php-mbstring
  - php-curl
  - php-xml
  - php-zip
  - php-opcache # if < php v8.5

write_files:
  - path: /etc/ssh/sshd_config.d/00-hardening.conf
    owner: root:root
    permissions: "0644"
    content: |
      PasswordAuthentication no
      KbdInteractiveAuthentication no
      PubkeyAuthentication yes
      PermitRootLogin no

runcmd:
  - ufw allow OpenSSH
  - ufw allow "Apache Full"
  - ufw --force enable
  - sshd -t
  - systemctl reload ssh
  - systemctl enable --now apache2

Configuring Apache and getting an SSL cert

Once my VPS is running and I can SSH into it, I run the following script. It’s doing several things for me. The most important being configuring Apache and getting an SSL certificate. The script assumes that you have a domain pointing at the IP address of your VPS.

I tried to keep everything simple and understandable, but I was getting an error related to the JIT compiler and I added a magic line of configuration that I don’t really understand (if you are reading this and you know what that is, and a better way for me to fix it, please let me know).

The script expects a few variables, so you should run it like this:

DOMAIN="example.com" SSH_USER="USERNAME" sh vps-setup.sh

#!/bin/bash

# Stop the script if a command fails.
set -e

# This is where the website will live on the server.
WEB_ROOT="/var/www/$DOMAIN/public"

# This server does not allow PCRE to allocate the executable memory used by
# its optional JIT compiler. Regular expressions still work without it.
echo "pcre.jit=0" | sudo tee /etc/php/8.5/apache2/conf.d/99-pcre-jit.ini

# Create the website directory.
sudo mkdir -p "$WEB_ROOT"

# Create the Apache configuration file.
sudo tee "/etc/apache2/sites-available/$DOMAIN.conf" > /dev/null <<EOF
<VirtualHost *:80>
    ServerName $DOMAIN

    DocumentRoot $WEB_ROOT

    <Directory $WEB_ROOT>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog \${APACHE_LOG_DIR}/$DOMAIN-error.log
    CustomLog \${APACHE_LOG_DIR}/$DOMAIN-access.log combined
</VirtualHost>
EOF

# Enable URL rewriting and the new website.
sudo a2enmod rewrite
sudo a2ensite "$DOMAIN.conf"

# Check the Apache configuration and reload Apache.
sudo apache2ctl configtest
sudo systemctl reload apache2

# Install Certbot and request an SSL certificate.
sudo apt install -y certbot python3-certbot-apache
sudo certbot --apache \
    --non-interactive \
    --agree-tos \
    --no-eff-email \
    --email "$CERTBOT_EMAIL" \
    -d "$DOMAIN"

# Make the data directory.
sudo mkdir -p "$WEB_ROOT/data"

# Create the temporary directory.
sudo mkdir -p "$WEB_ROOT/tmp"

# Set the normal permissions for the deployed files.
sudo chown -R "$SSH_USER:www-data" "$WEB_ROOT"
sudo find "$WEB_ROOT" -type d -exec chmod 750 {} \;
sudo find "$WEB_ROOT" -type f -exec chmod 640 {} \;

# Make data writeable by php
sudo chmod 770 "$WEB_ROOT/data"

# Make tmp directory writeable
sudo find "$WEB_ROOT/tmp" -type d -exec chmod 770 {} \;
sudo find "$WEB_ROOT/tmp" -type f -exec chmod 660 {} \;

# Deployment is handled outside this script.
echo
echo "Deploy the website to $WEB_ROOT now. Be sure to upload the environment file and the database (if it exists)."

The script is a bit specific to my setup. It assumes that everything is going into a public directory as the web root. As my app has a data directory inside of the web root (again, this is not a good idea, but my application does block access to that directory with a .htaccess file), the script creates the folder and sets the permissions for it. My PHP framework also makes use of a tmp folder, which I create and make writable here.

The Apache configuration is a very basic one that allows .htaccess files to work and disables automatic file listings.

The script also installs certbot which will grab an SSL certificate from Let’s Encrypt and create a task to renew it automatically.

A little message at the end is just a reminder of what to do next.

Deploying a website to your VPS

At this point, we need to get our website files into our web root directory. The how doesn’t matter so much here—use whatever’s convenient for you. The absolute quickest way to get started would probably be to use rysnc, a command line program for transferring files. Don’t underestimate the power of rsync! Your project may be suitable for a one-line deployment script.

rsync -avz --delete mysite/ user@example.com:/var/www/example.com/public/

If you’re like me and you like to use a nice GUI instead of the command line, you could use an SFTP client and manually move your website over.

I like to use a service called DeployHQ for this purpose. It lets you set up a server connection and choose a git repo. You can set up a build pipeline if needed to run any build scripts. When you’re ready to deploy, you can choose which commit you would like to deploy, and DeployHQ will build everything and transfer the necessary files. It has some niceties like only transferring the files that have changed since the last deployment as well as a quick rollback feature if you make a mistake. If you are like me and you have a bunch of small projects, it can get a little pricey.^[6]

GitHub, GitLab, Bitbucket—they all have fancy ways to deploy stuff. I’m gonna be honest I haven’t really tried them and don’t know much about them. Point is you have a lot of options. An automatic deployment process can be really nice but isn’t necessary.

Write-ahead logging mode

I mentioned earlier that if your website is doing a lot of writing then you want to use write-ahead logging (or WAL) for your SQLite database. According to the SQLite website, this mode is usually faster. It does not work with a networked file system, however, which is the reason I began this whole journey in the first place.

All processes using a database must be on the same host computer; WAL does not work over a network filesystem. This is because WAL requires all processes to share a small amount of memory and processes on separate host machines obviously cannot share memory with each other.

— Write-Ahead Logging, SQLite.org

You might do this as some sort of migration script or other or you can do it manually. If you want to use this option, you can run a command like this:

sudo sqlite3 "/path/to/db.sqlite3" "PRAGMA journal_mode=WAL;"

Setting permissions on your website files

Once the website files are in place, we need to make sure they have the correct permissions. I have a set-permissions.sh script that ensures that all files start with base permissions, then elevates permissions for whatever files needs to be writeable. The script takes the same variables as the setup script.

DOMAIN="example.com" SSH_USER="USERNAME" sh vps-setup.sh

Again, the script is a bit specific to my particular app. Feel free to change the paths to fit your own application.

#!/bin/bash

# Stop the script if a command fails.
set -e

# This is where the website will live on the server.
WEB_ROOT="/var/www/$DOMAIN/public"

# Create the temporary directory.
sudo mkdir -p "$WEB_ROOT/tmp"

# Set the normal permissions for the deployed files.
sudo chown -R "$SSH_USER:www-data" "$WEB_ROOT"
sudo find "$WEB_ROOT" -type d -exec chmod 750 {} \;
sudo find "$WEB_ROOT" -type f -exec chmod 640 {} \;

# Make the data directory writable by PHP.
sudo chmod 770 "$WEB_ROOT/data"

# If the database file exists, make it writable by PHP as well.
if [ -f "$WEB_ROOT/data/db.sqlite3" ]; then
    sudo chmod 660 "$WEB_ROOT/data/db.sqlite3"
fi

# If the database file exists, make it writable by PHP as well.
if [ -f "$WEB_ROOT/data/db.sqlite3-shm" ]; then
    sudo chmod 660 "$WEB_ROOT/data/db.sqlite3-shm"
fi

# If the database file exists, make it writable by PHP as well.
if [ -f "$WEB_ROOT/data/db.sqlite3-wal" ]; then
    sudo chmod 660 "$WEB_ROOT/data/db.sqlite3-wal"
fi

# make it writable by PHP
sudo find "$WEB_ROOT/tmp" -type d -exec chmod 770 {} \;
sudo find "$WEB_ROOT/tmp" -type f -exec chmod 660 {} \;

It SLAPs

That’s it! That’s the setup for a basic SLAP stack server. I think this is a cozy little setup that will hold up over the long term and keep my maintenance burden light.

I’m still in the experimental phase so I will write a follow-up (or edit this post) if I learn anything new, which I most assuredly will.

Message me on Mastodon or email me if you have any opinions about this setup, or if you want to tell me about your favorite server stack.

Due to my compulsive need to self-host whatever I possibly can¹, I decided to set up a self-hosted PDS. All that's on it so far is my Bluesky profile data, but it was a surprisingly painless process.

Why bother? Well, I get to own my identity (DID) and my data. The relay and AppView remain Bluesky's, but the authoritative copy of my account is mine. I already syndicate from my site to Bluesky and controlling the PDS is the last part of this infrastructure I can reasonably control.

I've been bolting features on to my own CLI to manage my infrastructure for a bit². I use Hetzner for hosting and it wraps their hcloud CLI for my own convenience. I spun up a CX23 box with backups turned on and then ran another CLI command to bootstrap the server.

The server is running only two things: the canonical ghcr.io/bluesky-social/pds container maintained by Bluesky and Caddy. I use forwardemail.net for transactional emails.

With the server provisioned, I updated the _atproto record for my domain and added a pds A record. I use DNSControl to manage DNS records, so this only took a few minutes.

The migration

Migrating my data from Bluesky's PDS to my own was the only part of this process that made me a little nervous. I needed to preserve my DID, followers and just over 1,000 account records. I used Bluesky's goat tool to manage this process.

1. I generated a recovery key using goat key generate --type k256
2. Logged in to my old (Bluesky) account: goat account login -u <username> -p <app-password> --auth-factor-token <email-code>
3. Created a PDS invite for myself using my CLI (or SSH into the box and run pdsadmin create-invite-code).
4. Ran the migration — it pauses and emails a PLC confirmation code that you paste into the prompt:

goat account migrate \
    --pds-host <host> \
    --new-handle <username> \
    --new-password "<password>" \
    --invite-code "<pds-invite-code>"

5. Added my recovery key to the identity so it's my highest-priority rotation key (this also emails a confirmation token): goat account plc add-rotation-key <recovery-pubkey> --first

It ran faster than I expected and worked without any issues (shocking, I know). I syndicated a post, opened my profile in an incognito window and it loaded without issue. I also verified that DID doc #atproto_pds pointed at my new host and threw my private recovery key in my password manager.

Cleanup

The last step was to add support for a custom PDS URL to my site and the PWA I built myself to browse Mastodon and Bluesky simultaneously. This consisted of a migration to update the database schema to save the URL and the corresponding field in the UI. The app passwords I use for both also needed to be recreated on the new PDS which I did from the aforementioned CLI.

I have yet another server running which, at this point, I'm starting to collect like trading cards. My ATProto data sits on its own server, free to be used with any apps that support it (for my purposes that's only Bluesky — for now). It was a surprisingly straightforward process and I'm thankful for that.

I'm still getting my head around ATProto, but I appreciate that you can own your own data, if not all of the application infrastructure. I was used to the Mastodon mental model where, while you can migrate between instances, not all data comes with you. You own the identity but, perhaps, not all of the content. You can't own everything in either case, for now, but it feels like we're heading in the right direction.

When I redesigned my website earlier this year I removed dark mode. I never liked the colours, and the light switch toggle was so 2010’s.

Personally I prefer reading with a dark theme for long-form content. Dark is not my brand though and I don’t believe every website needs to support colour scheme preference automatically. A good browser has reader mode, I use that all the time.

An experiment

But what if I let my readers decide on a dark colour scheme?

Below is a colour picker doohickey that should let you experience dark mode (on this page only). I’m testing in production (for reasons) so if it’s broken come back in an hour, or update your browser. It uses the native colour input which sucks in every browser.

This is just an experiment so your colour choice will not persist. If you want to keep it, like and subscribe and @ me on the socials. Use your preferred hex code as a hashtag.

Here’s how my homepage looks with a dark blue scheme.

I reckon the duotone effect works much better than trying to invert my brand colours.

Thanks for reading! Follow me on Mastodon and Bluesky. Subscribe to my Blog and Notes or Combined feeds.

If you sense a joyous exhale, that’s Team CodePen in crossing this launch milestone for the most ambitious professional project any of us has ever achieved. Today, we declare CodePen 2.0 officially launched. We do it, naturally, for you, as we set out to rebuild our online editor to better support what today’s developers want and expect. We did it in a way that makes this single editor forever extendable in its capabilities, so we can evolve with new technology.

What Can It Do?

A short answer is that it can do anything that the Classic Pen and Project editors could do, and more¹, combined into one editor. Even the Vue-specific editor is wholly supported by the 2.0 editor, upgrading to a modern Vite build. This means you write code and immediately see the results; the core CodePen experience. Save the Pen, share it, reference it, embed it… anything you’d do before.

The complete list of new things that the 2.0 editor can do is as long as my arm. Here’s a taste of some big ones:

• Every Pen is deployable. With one click, you get a *.codepen.app subdomain website of your Pen. Update it anytime with another click, or set it to deploy on save. Easily point your DNS to it, and CodePen is now your web host for your own domains.
• Every Pen has a file system. Like Projects did, only this is a much-improved true file system with a completely custom new UI designed for a smooth experience. You don’t have to use it, but it’s always there if you need it. Anything from just an extra HTML, CSS, or JavaScript file or three, to a fully blown mega multi-page website.
• Every Pen has a version system. Make a mistake? You can roll back in time to any place you know the Pen was in a state you want it to be in.
• Invite anyone, anytime. You can invite anybody (CodePen users by username, or anyone by any email) as either an editor or viewer of a Pen. An editor will have write access to the Pen at any time, so you can work together. If you happen to be there at the same time, it all happens in real time.
• Combine technologies as you please. This is the big idea with Blocks. Stack them up! Don’t worry about how to wire things up together. The CodePen Compiler handles that for you.
• The screen reader accessibility of the editor has been vastly improved.

The complete list of new features is much longer, but those are some biggies!

Podcasts

At one point, we literally stopped CodePen Radio, because 2.0 wasn’t out yet, and we didn’t wanna talk too much about it publicly. All we did internally was work on 2.0, so we didn’t have that much to talk about. That Hiatus started in February 2023, and we didn’t bring it back until about a year ago, when 2.0 stuff was gelling, we were close to an alpha, and things were easier to talk about.

Now, we’ve got a bunch of podcasts that dig into 2.0 and its specific features.

The Past

As I said, the CodePen 2.0 project has been worked on for years and years and years. I thought I’d dig up some early artifacts of our thinking, planning, and playing just for fun.

Much of the editor’s new functionality occurs in those Panels along the left. You can see on our new homepage that we showcase five of them as vertical slices of video that can move independently. Those vertical videos showcase the features fairly nicely:

The Future

Hey, where’s the AI?

Fair question, fictitious and kind reader of my mind. We know some of you don’t care about AI, and others care very much. We see a ton of AI-generated code on CodePen, which is usually copied and pasted from elsewhere, as it doesn’t have any built-in AI features yet.

We are experimenting. We’ve got ideas. We need to do things carefully.

What’s going to happen with the Classic Editor?

Not much, for now! You can still access and use it normally at https://codepen.io/pen. You may not see an obvious link in the sidebar (and other places) anymore, because we’ve launched and that’s what we want to point people toward. But it’s there if you need it.

Perhaps, some future day, with warning, we’ll convert all Pens to 2.0. After all, part of our goal here is to consolidate on a single editor so we can focus our entire attention on constantly improving it.

If 2.0 is all about extensibility, where are all the new processors?

There are some there already. The Tailwind, Lightning CSS, and MJML Blocks are new. Vue as processed by Vite, and without using a special single-component editor, is new. Nunjucks for Pens is new. But of course, we’ll be adding many more now that we’ve gotten through launch. Got some you’d like to see? Let us know.

A Little How-To on Replicating the Classic Experience

If you’re really familiar with the Classic Editor and you’re having that “can it just stay the way it was?” feeling, know that you can have that while using 2.0. Here’s how:

1. Use the Classic Block. This means you can write “just the part that goes into the <body>” like the Classic Editor, and the scripts/styles get connected automatically. See the config at /.codepen/classic.config.json to see those and other classic settings. Here’s a template, which you could set to be your default template.
2. Use Minimal UI. This closes the far-left sidebar and panels area, most of which represent 2.0 functionality. There is a toggle under the Controls menu, it’s findable in the Omnibar, or use ⌘-U on Mac or Control-U on PC.

By doing this, you get an editor that is actually a bit faster, is more accessible, and has capabilities to grow in case you need it.

1. The small footnote to “anything” is that there are some deprecated processors, which were a choice made entirely because of extremely low usage. ↩︎

Last fall, I started taking Zepbound and wrote about the first couple weeks and touched on it after a few months. While it was a pretty life-changing at first, as I did lose 20lbs quickly, I plateaued for the next six months. During that time, I tried a higher dosage level, but unfortunately, the side effects slowly made me feel worse.

A few weeks ago, my last vial ran out and I decided to stop taking it. I might try another GLP-1 in the future—hopefully one with milder side effects—but for now I'm letting my digestive system to recover for a while.

The positives

Zepbound was remarkable about quieting the influence of hunger on my body. For the first few weeks I almost had to schedule meals in a calendar app otherwise I would forget to eat. Eventually, a more normal appetite returned but I did always have to remember to eat light, otherwise my stomach and digestive system would be in for a world of hurt later on. The one thing it really helped out with was I no longer snacked between meals and I would rarely eat after dinner no matter how late I was up.

I am impressed that a drug could control my appetite so completely, which is an impossible thing for any magic pill to do, since so many have promised this over the years but never really delivered until now.

The not-so-great parts

My digestive system slowed waaaaay down and that was a new feeling, and not a particularly good one. My old reliable schedules got out of whack as food took longer to process. When I got food poisoning twice while on Zepbound, it wrecked me for several days each time instead of being a 24hr minor inconvenience, pre-GLP-1.

After 7-8 months using Zepbound, I started getting severe intestinal gas even though I took GasX daily. I'd never had acid reflux before, but I constantly chomped on Tums to keep the heartburn at bay. Some nights, I would randomly wake up in extreme pain in the middle of the night, then belch out a 30-second burp and suddenly feel better.

I began to hate the “shot day” that you had to do once a week. Whenever I injected my shot, I would feel terrible for a day or two after. It got so bad that I started adding a few days after each week, in an attempt to avoid how bad my body would feel after each shot.

Right up until I stopped taking Zepbound, my stomach felt like the gut biome I had that kept things on an even keel had been obliterated over the past few months. I was getting an upset stomach several times a week. I was now severely lactose intolerant whenever I touched ice cream, and after spending half my life as a vegetarian, if I ate any sort of pinto or refried beans, I would feel bloated to the point I almost considered going to an ER once because I was in so much pain.

What's next

Like I said, I might someday try a different GLP-1 or a hybrid mix of them. I disliked the needles and vials of fluid I had to interact with for the first few months of Zepbound. Later, I got injection pens through my health provider and those were a million times easier to use. I would be interested in the pill forms someday, since stabbing yourself gets old after a few months.

I've learned from this experiment that my eating habits were pretty bad in the past, and far too often I ate too much after dinner and late at night. On Zepbound, I was surprised at how little I should be eating at my age and with a slower metabolism. Even while on it, I stopped losing weight for months, even though it was still causing me to eat much less than I used to. I can tell that exercising is definitely more important than I thought. I never really felt I needed to force myself to eat protein though.

After a month away from it, I've gained a couple pounds back but I feel like I know what it would take to lose a few more. I'm glad I tried Zepbound and GLP-1s out, as they're pretty remarkable drugs, but I experience strong side effects with almost any prescriptions and eventually this particular drug was just too much for my system to handle.

You almost can’t miss it as a web developer; it’s in almost every performance guide, and to be fair, it is good advice. We all know the browser’s main thread is single-threaded, meaning it can only do one thing at a time.

Plus, as we know, the main thread isn’t ours alone; we share it with the browser’s rendering engine, input handlers, and other critical tasks. As a result, the less time we hold onto the main thread, the more responsive an app feels. That leads us to share tasks with background workers as we’ve convinced ourselves there should be a hard line between the UI and any computation, and that line shouldn’t be crossed.

And that is what a “recommended” architecture looks like.

But I dare say that sometimes**, moving the data to a worker is slower than just letting the main thread do the work.

I found this out a few months ago while building a Chrome extension with screenshotting features called Fastary. I kept finding a latency of about 2 to 3 seconds in all my testing, even after using an Offscreen Document (a background process in Chrome extensions) to handle the canvas operations. A screenshot task should feel instant without lag, after all.

It is quite ironic that by reflex, we move work away from the main thread to avoid freezing the UI, but sometimes the act of moving that work (e.g., serializing, copying, and deserializing) can also freeze the UI. And sometimes the recommended approach of letting the background do the work can be slower than just doing the work on the main thread.

Let’s talk about that.

To put things in perspective, let’s understand why we isolate browser contexts and how they communicate with each other, with emphasis on the communication part.

A browser is more than a single environment. Different environments are running at the same time, each having its own memory space, what it can access, and rules:

• The main thread is what we are most familiar with; this is where JavaScript logic runs, where the DOM lives, where styles get rendered, and where users interact.
• The Web Workers are separate threads that can also execute JavaScript without DOM access. We mostly use this for heavy data tasks.
• The Service Workers are network-related proxies in charge of intercepting network requests and can even run when the page is closed.
• And then there are Chrome extension contexts, where we have background service workers, content scripts, and Offscreen Documents (the relevant ones for this article).

Each one of these is isolated from the others. A web worker or background script lives in a different memory space from the main thread. They cannot just reach and read each other’s variables or logic, and this is known as the “shared-nothing” architecture.

How do these isolated environments communicate? They explicitly message each other back and forth using APIs, like postMessage().

The Structured Clone Algorithm

postMessage() tells the browser to take a piece of data and deliver it to the context that requested it. But to do this, the browser relies on the Structured Clone Algorithm (SCA).

You’re probably familiar with JSON.stringify(). SCA is similar, but much stronger and smarter. In its simplest form, SCA is a deep, recursive copy operation, i.e., cloning. It walks through the entire data structure it is given, clones every single value, serializes it into a transportable format, ships those bytes to the target contexts, and then reconstructs the original object on the receiving side.

SCA is fast, or maybe fast-ish... For a small regular config object like {theme: "dark"}, it is imperceptible; you don’t even notice it. The story changes, however, when dealing with heavy data because the SCA is a synchronous blocking O(n) operation, i.e., the cost increases linearly with the size of your data.

Let’s put that into perspective. A user clicks a button, and internally, an 8MB image payload is sent to a background worker for processing. When you call postMessage(), the main thread must immediately stop what it is doing to run this serialization and copying process.

So, if the time it takes to pack, ship, unpack the data, and go back to the start is longer than the time to just process the data on the main thread, why not do that instead?

I’m sure some of you are already thinking, “Why not just use Transferable objects?” And that is a valid point. Let’s talk about that.

Developers who really pursue ultra-high-performance web apps usually use Transferable objects (e.g., ArrayBuffer, ImageBitmap, or MessagePort) to bypass the Structured Clone Algorithm. This is because when you transfer an object, you’re not making a copy (like SCM). Instead, the browser switches ownership of the data from one context to another.

The browser performs a hand-off whereby the sending context loses access to the data instantly, and the receiving context takes full control. It is actually insanely fast. According to Chrome Developers’ benchmark, transferring a massive 32MB ArrayBuffer can take under 7ms, compared to about 300ms when cloning with SCM. That’s a 43x speed boost.

But like all good things, there are downsides. To name a few:

• You lose it once you send it.
  If the UI still needs that data (like to show an image preview), you can’t access it anymore.
• Not all data is transferable.
  A plain JS object is not. A Blob is not. Even a Base64 string is not.
• API limitations.
  In the context of browser extensions, Chrome’s internal messaging (chrome.runtime.sendMessage) traditionally forces everything through JSON serialization.

So, as far as my screenshot extension went, Transferable objects were not an option.

Why do we even bother isolating contexts at all? Why not just leave it all to the main thread?

Offloading long-running CPU tasks to a background thread is absolutely the right thing to do. The browser needs to paint a new frame every 16.6ms to keep things fluid; that means any task that takes >50ms is generally considered “long”. Offloading to the background is absolutely the right thing to do.

The issue, however, is that we’ve turned this “never block the main thread” into an absolute rule, without asking is this task expensive to process or expensive to move?

I have come to realize now that the rule is less “never block the main thread” than “never block the main thread for too long.”

My goal with the Fastary extension was to make it feel like a native app, running as smoothly and instantly as you would expect a native app to.

As you already know, I took the recommended approach to use the Offscreen Document to handle DOM work in the background. But to my surprise, that took a different turn.

The Offscreen Document API is a clear winner. You create a hidden, undisplayed document that runs entirely in the background. It has a DOM and supports Canvas. For example, if I want to crop a screenshot, stitch multiple screenshots together, perform heavy image manipulation, or add a watermark, Offscreen Document was made for that.

Turns out that was not the best approach. This was my architecture:

1. The background Service Worker captures a screenshot with chrome.tabs.captureVisibleTab(), which returns a Base64-encoded data URL string.
2. The background Service Worker uses chrome.runtime.sendMessage() to ship this image payload to the Offscreen Document.
3. The Offscreen Document receives the image, loads it into an <img> element, then draws it onto a canvas before it applies the user’s crop coordinates, encodes the result, and sends the processed image back to the background worker.

But when I tested it, the screenshot didn’t feel instant. As I said earlier, there was a consistent 2–3 second lag.

I figured out that when captureVisibleTab() takes a screenshot, it returns a Base64 URL string, and on a standard 1080p screen, that string could be approximately 1MB or more, depending on how detailed the image is. It gets even more interesting on modern Retina displays (e.g., MacBooks) as they tend to automatically double the image’s size by default.

Keep in mind that since the image payload could be doubled and extension messaging relies on JSON serialization (as of this writing), we potentially deal with massive synchronous communication that costs an entire round trip.

The image string data is JSON-serialized at least twice: once when going into the Offscreen Document and once coming back out with the processed results to the background worker. The actual image processing (cropping) done inside the Offscreen Document was fast, no doubt, but I can’t say the same about the transfer overhead.

The Retina High-DPI Problem

As if the latency itself wasn’t enough, I noticed a rather subtle bug — which, now that I think of it, was more of my ignorance. After a screenshot was taken, the crop result was completely off in a way that either weirdly scaled the image or resulted in incorrect coordinates.

It turns out that when a user selects a region to crop, the content script gets the box coordinates using getBoundingClientRect(), which is measured in CSS pixels; this is what the DOM uses. But when the screenshot is captured natively in Chrome, the browser doesn’t crop it automatically; it instead uses the physical hardware pixels to get the full screen capture. And the browser uses devicePixelRatio (DPR) to know how many physical pixels should represent one CSS pixel. Basically, if a user on a Retinal display (DPR = 2) highlights an area of 400x300 CSS pixels, the actual captured image area is 800x600 physical pixels.

Note: One CSS pixel is equal to 1 physical pixel (DPR of 1) on a standard monitor. On a Mac Retina display or a modern 4K monitor, however, the DPR is usually 2 or 3.

For an accurate crop, I needed to apply these two different measurement systems with the right DPR, i.e., scale the crop coordinates by the DPR. But remember, Offscreen Documents have no physical display. Processing any image would have a default DPR equal to 1. To fix this, I would have to capture the exact devicePixelRatio from the active tab, serialize it, pass it alongside the image payload, and manually do the scaling math inside the Offscreen Document. The complexity starts to compound.

What if I broke the golden rule and did the work on the main thread instead?

Some developers will argue that UI tasks are the only things that should run on the main thread, but I don’t fully agree with that. Personally, I believe that user explicitly-invoked actions that need immediate results can sometimes get a solid pass to run on the main thread, provided the work is incredibly fast (e.g., 1s).

That’s what I did: scrap out the Offscreen Document and reengineer the logic. Instead of:

Background → [serialize] → Offscreen Document → [serialize] → Background → Content Script

…I decided to run the whole image processing in the active tab:

1. The background Service Worker captures the screen and gets the Base64 string (same as before).
2. The background sends the payload directly to the content script in the active tab using chrome.scripting.executeScript().
3. The content script (running on the main thread) receives the payload, draws it to a canvas, performs the crop using the correct DPR value, and copies the result to the clipboard.

// Background Script
const screenshotUrl = await chrome.tabs.captureVisibleTab(undefined, { format: "png" });

// Inject the processing function into the active tab as a content script
await chrome.scripting.executeScript({
  target: { tabId: activeTab.id },
  func: processAndCopyImage,
  args: [{ base64Image: screenshotUrl, cropData: userSelection }]
});

This approach completely clears out multiple context hops and round trips that JSON serialization requires. The only cross-context transfer involves sending the data URL from the background to the content script.

The Retina DPI issue essentially solved itself, as the content script runs directly inside the real, active browser tab because it knows the monitor’s real devicePixelRatio.

But there’s an elephant in the room that you may have noticed.

Sure, the image is now processed on the main thread, and the background manipulates the canvas in the active tab. I could technically be blocking the main thread. That’s where I amended the “no blocking the main thread” rule to “no blocking the main thread for too long.” In this specific case, at least, blocking the main thread for a task the user requests for approximately one second is justifiable. It works conversely as well: maybe don’t isolate processes if the data transfer cost is greater than the processing cost.

I’ve boiled it down to a mental model that depends on whether the task is:

1. Compute-Heavy Tasks (CPU-Bound)

These are tasks where the primary cost is computation and not the size of the data itself. These are tasks where most of the time is spent on doing calculations or heavy transformations, e.g., image compression, audio profiling, physics simulation, etc.

The transfer cost for these tasks is minuscule compared to the actual work.

2. Data-Heavy Tasks (Data-Bound)

These tasks are the exact opposite. These tasks are only expensive because of the size. The processing time is almost insignificant, but the data is expensive to transport, e.g., image cropping, filtering an array, shallow copy, etc.

In my specific case, offloading the task to the background falls mostly into negative-sum efficiency. If we are talking about moving megabytes of data to perform a 50ms operation, there is no benefit to offloading it to the background.

Perhaps we can think of it like this:

Total Time = Serialization Cost
  + Transit
  + Background Processing Time
  + Deserialization Cost

Looking at this, if the “background processing time” is the most dominant task in your operation, then isolation is the clear winner. But if serialization, plus deserialization, plus transit exceeds that cost, then there’s no need to isolate things.

And if you can’t figure out if the task is CPU-heavy or data-heavy, it certainly doesn’t hurt to measure it, for example, using performance.mark() and performance.measure() around postMessage calls to profile the transfer cost.

Do you know what shipped in the new JavaScript version? Do you know about all the fancy anchor positioning features yet? And do you use CSS zoom?

Turn on the Web Weekly tune and find some answers below. Enjoy!

::: song by="Olivier" title="Connor Price & Nic D - Too Easy" youtube="zOVkU-P3SyA" It's been on repeat in my playlist for the past two weeks since I watched an Android Gemini Intelligence ad... :D :::

Do you want to share your favorite song with the Web Weekly community? Hit reply; there are five more songs left in the queue.

If you enjoy Web Weekly, share it with your friends and family.

• 🦋 Bluesky
• 🐘 Mastodon
• 💼 LinkedIn

A quick "repost" really helps this indie newsletter out. Thank you! ❤️

Sponsored

Full-Featured React Event Calendar

SVAR React Calendar brings Google Calendar-style scheduling to your React app — multiple views, drag-and-drop event editing, and a built-in edit form for creating and updating events. Events are easily organized into color-coded calendar groups.

It's built natively in React, with no wrappers or adapters, and includes TypeScript support, easy backend integration, light/dark themes, free core + PRO with timeline, agenda, and resources views.

Start building scheduling UIs in minutes.

Try SVAR React Calendar

Web Weekly is open for sponsorships. When you want to reach 6k developers, you know what to do!

This week's bag of karma points goes to Chris, Spike, Dan, James, and Gerrit, who all started to support Web Weekly financially. This brings the supporter count to mind-boggling 53. After subtracting the cost of sending and hosting, Web Weekly makes now a bit under $150 per month.

Thank you all for supporting indie publishing. ❤️

Aerospace engineer Cauê added a town square to his site (scroll to the bottom) and this brings back strong vibes of when the internet used to be fun. The project is open source if you want to have a place on your site for people to hang out.

Talk to strangers

• How to ask for help from people who don't know you → "One of the strongest ways to show that you’re worth helping is to demonstrate that you are a serious person."
• Goodbye, forever, probably. → "People aren’t seeking information in the ways we once knew; The Internet and its communities have fragmented."
• Memories Can’t Wait—or, How I Learned to Keep Worrying About the Web → "We need to stop pretending that “the cloud” is a place. It’s not a place. It’s a promise"

I'm still wondering about anchor positioning (baseline newly available) use cases beyond the tooltip example. Emil explains how multiple anchors help out with creating clickable card overlays. Fancy stuff!

And if that's not enough anchoring, Josh explains how to get started with anchor positioning. But don't be fooled, the post gets into advanced topics like the anchored container query and position-try-fallbacks quickly.

Safari shipped display: grid-lanes. Chromium's working on it. But what does it mean for accessibility when grid items are free-flowing and reordering themselves? Can an adjusted flow-tolerance help? Manuel asks the same questions and cautiously proposes a very interesting solution.

Be aware

Ollie described a fact that tripped me up big time:

There’s an unfortunate disconnect between color-scheme and the prefers-color-scheme media query. prefers-color-scheme reflects the OS settings — regardless of the color-scheme value. If you’re providing an in-page toggle that implements dark mode, you can’t adopt the prefers-color-scheme media query.

So what do you do about it? The post has some web platform answers.

Use the new and fancy

So! If you're dealing with SVG icons you probably know the pain of overwriting colors. Patrick listed missing SVG features and as it turns out there's a new spec in the making that allows controlling CSS variables from "the outside". And I didn't test it, but he says that it's shipping in Firefox already!

Control your SVGs

The music nerds will love this one!

Produce

Honestly, I'm up for opinions here. The new Deno release now supports building desktop apps. When I saw this I was confused. Didn't Deno lay off people and isn't the money in providing hosting and infrastructure? Odd.

But then I also saw Vercel pushing for building Zig and web-based desktop apps with Native SDK?

Honestly, what is going on? Is this about market share? I don't get it.

What you see above aren't canvas or SVG elements. These three range sliders are classical range inputs with some CSS magic. I've got no idea how Temani comes up with that stuff.

Wiggle

It's already a tradition and I'm happy to see that Paweł is still summarizing the new JavaScript features. Check out what's coming to JavaScript.

Use the language

Jake went on a journey to "improve" the sizing behavior of customizable selects (Chromium-only so far) and oh boy... he goes into anchor positioning, stretch and fit-content, and calc-size. I'm sure you'll find more than one rabbit hole to dive into here.

Select

• TypeScript 7 is out. And yes, that's the Golang rewrite.
• The new QUERY HTTP method moved from draft to proposed standard.
• Chrome ships a new usermedia element.

From the unlimited MDN knowledge archive...

Quick reminder, cross-document view transitions can be enabled with a few lines of CSS. Safari and Chromium ship them, so you can add some polish to your static sites. No harm done for Firefox users.

Transition

A while ago I learned about valid use cases for the CSS zoom property. zoom? Yes, exactly. 😅

Scale up

I've got my own tooling for checking baseline updates, but if the Web Weekly updates aren't enough, webstatus.dev now lets you set up baseline notifications.

Stay up to date

My buddy Orçun is building AutoShelf and you should check it out if you want automated file organization.

• ashleydavis/photosphere – A cross-platform application for managing your database of digital media files
• duongductrong/Snapzy – An open-source native macOS screenshot and screen recording app.
• charmbracelet/glow – Render markdown on the CLI.

If you've ever wondered what specific analyzer tools, user agents, or browsers execute when they crawl sites, ua-tracer helps out!

Check what's happening

Side note: the last time I mentioned that I'm not really sure about Tiny Helper's future because frankly I'm drowning in vibe code submissions. Some of you replied telling me that you really like this section. So, what should I do with it?

For now, I closed contributions to the project and this section will become optional. I'm annoyed by this because I'm a big fan of consistency, but let's see how this plays out.

This is a take I can get very much behind.

❤️ If so, join 53 other Web Weekly supporters and give back with a small monthly donation on Patreon or GitHub Sponsors.

Loved this email? Hated this email? I want to hear about it!

If you think something needs improvement or something sparked some joy, reply to this email because I want to know more!

And with that, take care of yourself - mentally, physically, and emotionally.

I'll see you next week! 👋

TIL: MDN exposes up-to-date page view data through https://popularities.mdn.mozilla.net/current.csv.

To visualize the data, I had Google AI Studio generate me a visualizer, which I deployed to CodePen

Check out “MDN Traffic Browser” →

Two weeks ago, I’d be in the same boat.

Polyfills and I go way back. I dug up a JSConf EU talk of mine from 2011 on exactly this topic.

One of the few opinions I have held strongly over the years is that polyfills are a net positive for the Web, and the good outweighs the rare failure cases where polyfills became too popular, too soon, and restricted the design space for the native API.

As with most things in life, it’s all about the cost-benefit. We don’t stop flying planes because crashes happen. We do a post-mortem and figure out how we can prevent the same accident from happening again. And crucially, the point of a post-mortem is to find the root cause — not to ground the entire fleet.

Don’t get me wrong, concerns about polyfills are well-intentioned. They come from implementors and standards folks who want to preserve the design flexibility to build the best API surface possible — a goal I share deeply. Being both a spec editor and a library author, striking that balance is something I navigate all the time.

Still, I was under the impression that seeing polyfills as a net positive was the consensus view of the web standards community as a whole. That while we may not have consensus on the specific tradeoffs or solutions, we see polyfilling as a good thing and we generally do want web platform features to be polyfillable.

So, you can imagine my surprise when in a recent WHATWG meeting where I presented a proposal for extending mutation observers to observe shadow root attachment, Anne van Kesteren expressed the view that polyfilling is harmful.

It’s important to note that Anne is not some rando. He is the main active editor of most WHATWG specs (HTML, DOM, Fetch, import maps, etc.), a WebKit engineer at Apple, and has tremendous overall influence on the direction of the Web platform.

I had to find out if Anne’s comment reflected broader committee consensus, so I brought the topic up in the WHATWG Matrix and asked some folks privately.

Thankfully, it became clear that no, Anne’s comment did not reflect broader consensus (😮‍💨), but some of the views expressed about polyfills were more ambivalent than I’d have expected.

As I said, these concerns are well-intentioned — but I believe they are generally misplaced. Most fail to consider the system holistically, and especially the human factors that drive developer behavior.

Let me explain.

It’s not the polyfills

Authors want to use native behavior when it exists, without breakage when it doesn’t. That’s the crux of it. That’s what restricts design flexibility.

Whenever this happens too early, by too many people, you can have a problem. It doesn’t matter whether the code using it is a polyfill, a fallback, “progressive enhancement” or “graceful degradation”.

Fundamentally, every pattern that uses the native feature when it exists and a userland implementation (or even nothing) when it doesn’t risks breakage if the feature changes in a way that is incompatible with that usage.

This includes:

• Using CSS properties for progressive enhancement, accepting that they won’t work everywhere
• CSS fallbacks via the cascade or @supports
• Conditional imports after feature detection
• Using a modern HTML element, with a script that converts it to (or wraps it with) a web component if not supported
• Build tools that include fallbacks alongside the native feature
• JS let foo = nativeThing?.() ?? fallbackThing()
• etc etc

In all of these cases, if the native API were to change in a way incompatible with the fallback usage, stuff could break.

Eliminating polyfills does not eliminate the need for them.

The benefit of polyfills over the techniques above is author-facing: polyfills are portable, maintainable, and typically more correct than ad-hoc fallbacks.

When a bug is identified in a polyfill, it can be fixed centrally. When a bug is identified in an ad-hoc fallback strategy, good luck finding all the callsites and fixing them.

Bottom line: eliminating polyfills does not eliminate the need for them and all other avenues of satisfying that need are measurably worse.

Polyfills decouple API design from implementation

Standardized APIs have intrinsic value, independently of browser implementations.

We think of polyfills as a toggle: use a polyfill, leave it in there, and later when all browsers implement the feature natively, it gets removed.

This misses out on one of the biggest benefits of polyfills: decoupling API design from implementation.

If a userland library isn’t working well, you must weigh the tradeoffs of refactoring your codebase to use a different library, and educating your team about the new library.

With a polyfill, the API itself is not within the purview of the polyfill. The polyfill supplies only implementation, while the API is externally decided by the standards. Thus, swapping a misbehaving polyfill for another has near-zero cost.

The benefits of API standardization are far greater when we consider the broader ecosystem. A dependency isn’t aware what your userland implementation may be for certain functionality. Either it needs to provide a way to pass it via configuration (expanding its API surface), or it needs to implement its own version of the functionality, which may be incompatible with that of the host.

Standardized APIs are the town square of the Web, uniting all consumers (developers, agents, tooling, etc) around a shared vocabulary.

For example, suppose we’re using:

• a data binding framework that synchronizes JS data with form controls
• a library that reads form control values and stores them in localStorage until the form is submitted
• a custom command invoker for copying the value of an arbitrary form control to the clipboard

As long as these are implemented in an element-agnostic way, reading element.value ^[1] and listening to input and change events, they will work with any form control that implements the same API, whether it’s a native HTML element or a custom element, allowing for loose coupling.

But without this standardized API, we need to specify how every custom element expresses its data and what event(s) it uses to notify for changes to each and every one of these libraries. This is user effort on the magnitude of O(M × N) on the number of consumers and producers that must know about each other. Standardized APIs collapse it to O(1).

Are separate namespaces the solution?

From the same WHATWG discussion:

Anne: I would much rather people write a library that demonstrates the need for something as opposed to something that attempts to mimic the exact API shape of a proposal while simultaneously trampling all over our design flexibility.

Anne: You want to enable people using the amount element? Fine, but call it [something]-amount.

Stephen: I see “library that implements some feature” and “polyfill” as synonymous, but I can also see that fails to capture everything.

Anne: When I hear polyfill I think specifically of things that attempt to occupy the exact same API space and tend to cause issues, such as we had recently with Scoped Custom Element Registries. We ended up with a much worse standardized API because of that.

The topic of polyfilling often comes up in discussions about CSS and HTML polyfilling, which are currently much harder to polyfill than JS features.

Many people are of the opinion that the solution is to have a separate namespace for polyfills, so they cannot conflict with native implementations. For example, instead of polyfilling <amount>, you’d create a web component that polyfills <polyfill-amount>. Instead of polyfilling the CSS property border-shape, you’d write a polyfill that makes --border-shape work the same way.

At first glance, this seems ideal: the benefits of polyfilling without the risk of syntax lock-in! But we’ve tried it before.

Who remembers vendor prefixes?

Their core premise was exactly the same: if we experiment in a separate namespace, the native implementation can change without breaking any existing deployed experiments!

But remember, humans want to use the native feature when it’s there. And they don’t want to go back and edit their code when that happens. So what do they do? They use both! Even if the native feature has no implementations yet, pre-emptively.

We know exactly how this plays out, because it already has: stylesheets everywhere declared -webkit-border-radius with an unprefixed border-radius right below it — before any browser shipped the unprefixed property, and before its syntax was final.

So authors get worse DX, and web standards get no more design flexibility. Everybody loses.

Is dropping feature detection the solution?

As another attempt to mitigate the issues, some have started recommending polyfills that skip feature detection entirely and always use the fallback implementation, even when the native feature exists.

This is extremely wasteful. Polyfills add weight, are typically slower than native implementations, less accessible, less i18nclusive, and rarely handle edge cases. As their name implies, they are meant to temporarily cover a gap. They were never meant to be a long-term solution. The whole point is planned obsolescence: they eventually become dormant, even in a codebase that is no longer actively maintained. Feature detection and conditional loading are essential for that to work.

Authors accept these costs because they are temporary: every browser update quietly moves more of their users onto the native implementation, until the polyfill fades into a no-op. Remove feature detection, and the costs become permanent. Every user pays the download forever, and no user ever gets the native implementation’s performance, accessibility, or i18n — even when it’s sitting right there in their browser.

This approach does preserve the advantages of a standardized API, but at what cost? It trades away real, tangible benefits, felt by every user of the Web, to prevent a rare, largely theoretical risk. Every economist would be pulling their hair out at this cost-benefit!

Are ponyfills the solution?

Ponyfills, as originally envisioned by Sindre Sorhus, are basically userland libraries that closely track the native API, but do not modify the global environment and may intentionally diverge from the spec.

They are often suggested as a better alternative to polyfills.

For example, a polyfill for RegExp.escape() might look like this:

if (!RegExp.escape) {
	RegExp.escape = function (s) {
		return s.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
	};
}

Whereas a ponyfill might be:

export function regexpEscape(value) {
	return value.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
}

Note that this does not use the native implementation at all. It is not meant to be removed later. Its link to the native API is purely psychological.

I can see ponyfills being helpful for iterating on and getting feedback on an API while the standard is still being developed, or even to motivate a new proposal. But then again, so are userland libraries.

But for a mature feature, that has shipped in at least one browser, their appeal is much weaker.

They lack all strengths of polyfills:

• They don’t use the native implementation, even when it exists.
• They cannot be removed without refactoring
• Without a standardized API, a ponyfill cannot be swapped for another without further refactoring.
• They introduce a new userland dependency that needs to be evaluated, learned, documented, and maintained, just the same as if no standard existed at all.

IMO ponyfills are just userland libraries with better marketing.

Even their only advantage, not modifying the global environment and thus not trampling on the spec, is typically negated by actual usage: as a sort of …deconstructed polyfill.

See this post where the author is using a ponyfill for Number.MAX_SAFE_INTEGER as part of a makeshift polyfill:

const MAX_SAFE_INTEGER = Number.MAX_SAFE_INTEGER || require('number-max-safe-integer');

This is the norm, not some lone author failing to grok the concept of ponyfills. In fact, many people would call something like this a ponyfill as well:

export function regexpEscape(value) {
	if (RegExp.escape) {
		return RegExp.escape(value);
	}

	return value.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
}

This combines the disadvantages of both approaches, while getting you the benefits of neither!

In the end, the usage hasn’t changed, because the human need hasn’t changed.

Do polyfills discourage native implementations?

Stephen: […] polyfills can reduce the need for all browsers to implement something in a timely fashion.

Do they?

Yes, the existence of high-quality, lightweight polyfills can reduce the urgency for browsers to be the last to implement. But even then, the pressure never drops to zero: polyfills are slower and heavier than native implementations, and it’s the lagging browser’s own users who feel the difference. Without polyfills, authors wouldn’t use the feature at all — every browser would be equally fast at not supporting it, and the laggard could drag its feet indefinitely, consequence-free.

More importantly though, being last is not what’s critical for the Web’s evolution.

Check out my specs page. What is the average time from spec to first implementation, from that to the next, and from that to the last?

The first implementation is the hardest.

A Web platform without polyfills would be a stagnant platform.

What is the motivation for a browser to be the first to implement if authors cannot use the feature until all others implement it as well? Would you sink millions of dollars of engineering time into something your competitors can render moot, by means of simply …doing nothing?

We cannot A/B test reality, so this is purely a thought experiment, but I think if polyfills, fallbacks, and progressive enhancement suddenly disappeared, it would slightly increase motivation for those shipping last, but would significantly reduce motivation for shipping first. And since nobody can be last without someone else being first, a Web platform without polyfills would be a stagnant platform.

Additionally, often the biggest blocker in getting browsers to implement new features is demonstrating developer demand. A popular polyfill does that beautifully.

In fact, there is already plenty of precedent that if a feature cannot be used conditionally, browsers are reluctant to implement it. For example, decorators consistently top the list of missing JS features, but because JS syntax cannot be reasonably polyfilled, they are nontrivial to implement, and they are so widely used via transpilers, no browser has shipped them. “Let them use build tools” seems to be the general unspoken consensus.

Polyfills only get in the way when the standards process fails

I did some digging; Anne’s view traces back to a 2025 whatwg/html discussion where an API around scoped custom element registries had to be renamed due to conflicts with two existing polyfills that implemented a different behavior (emphasis mine):

We have prototyped a solution that seems to work and preserves the API pretty much as-is (still unfortunate though; please stop polyfilling and deploying polyfills)

To be fair, the underlying concern is real, so let me steelman it. Once a library squatting a proposed API name becomes popular enough, its exact behavior — bugs and all — becomes a web compat constraint. Standards groups then face a choice between adopting the library’s semantics or breaking deployed sites, and sometimes the only way out is renaming or redesigning the native feature, which is what happened here. That is a real cost, borne by the very people designing the platform.

But let’s be clear: none of the libraries that caused this problem was actually a polyfill, since there was no standardized API to polyfill.

At worst, they were naughty userland libraries, much like MooTools’ Array.prototype.flatten() that caused the smooshgate fiasco. At best, they were speculative polyfills (aka prollyfills) — an imagined API occupying the same namespace as a future builtin so authors can experiment with an emerging standard. Prollyfills are (rightly) more controversial, and not what this post is about.

Assigning blame to polyfills is like blaming car accidents on the ambulances that show up on the scene.

But when you examine the failure cases more closely, they all have something in common: In every single one, standards groups and/or browsers failed to react to a strong user need in a timely fashion.

Assigning blame to polyfills is like blaming car accidents on the ambulances that show up on the scene. A popular polyfill is a consequence. Polyfills should never become too popular in the first place: the feature should be widely implemented by then!

If a polyfill (or prollyfill) becomes so popular that it can create a compat problem, that is a symptom that a pervasive user need went unmet for too long. Whether it’s a polyfill or a prollyfill only changes which entity failed to react in time.

And even in the failure cases, consider the counterfactual. When a prollyfill constrains the design space, the damage is a worse name or a compromised API shape — bounded, and known before shipping. When an API ships without real-world validation, the damage is unbounded, and only discovered once the design is frozen into the platform by web compat. Remember AppCache? It shipped natively with no userland trial run, turned out to be fundamentally wrong, and took a decade to deprecate and replace with Service Workers. A prollyfill that surfaces design problems while the spec can still change is far cheaper than deploying the wrong API.

Developers don’t use polyfills in vain. Every dependency has a cost. If we see a polyfill becoming wildly popular, that should be a signal for urgent prioritization, not a reason to complain that authors are naughty.

Instead of blaming the user (“please stop polyfilling and deploying polyfills”), we should be doing a post-mortem on how to avoid such process failures in the future.

“If one user gets it wrong, it might be them. If two users get it wrong, it’s definitely you” — Ancient UX proverb^[2]

When web platform design follows the priority of constituencies, and prioritizes end-user and author needs above implementors and standards authors, the failure cases are practically nonexistent, even when polyfills jump the gun and ship too early.

The WHATWG process invites these failures

Why did scoped registries take so long to ship? The web components community had been asking for years!

Part of this is that the WHATWG process is designed to be reactive rather than proactive. Even if there is a strong, demonstrated author need, WHATWG will refuse to flesh out a feature until at least two implementors express interest in implementing it. “needs implementer interest” is where so many good ideas go to die.

This made sense when WHATWG was founded as a reaction to the increasingly academic W3C HTML Working Group, which had been designing XHTML 2 in a vacuum, speccing features that no browser was willing to implement.

But having spent 15 years in the CSS WG and having proposed and/or helped drive several features to Baseline, I cannot imagine gating spec development on implementor interest. That’s putting the cart before the horse!

Demonstrating developer need is exactly what drives implementor interest in the first place! And that’s much easier to do with a feature that is actively being worked on.

For one, researching use cases and prior art to flesh out the feature often demonstrates author need in itself. But also, users have a lot of trouble expressing abstract pain points. It is much easier to point to an existing feature and say “I want browsers to support this” than to express a need for which no feature exists.

In a way, polyfills are to the web platform what user testing is to product design — and the prototype part isn’t even an analogy: a polyfill literally is a prototype of the feature. Real user feedback, without baking technical debt into the platform. One could even argue that browsers should be funding — or outright developing — these polyfills, precisely so they can gather this feedback before an API is frozen into the platform by web compat. Yes, there is some risk they may constrain the ergonomics of the eventual API — but if high-demand features actually ship at a reasonable pace, that risk shrinks dramatically.

Polyfills restore power balance in the ecosystem

Who remembers IE7.js? Or html5shiv?

For nearly a decade, IE was the boat anchor of the Web: dominant market share, no meaningful competition, and no incentive to implement anything new. Without polyfills, the rational strategy for many authors was to target IE and call it a day — and the rational strategy for every other browser would have been to stop investing in features nobody could use.

Instead, polyfills allowed authors to adopt modern standards years before IE supported them. That kept demand for standards alive, sustained pressure on IE, and gave end-users reasons to switch browsers. The fact that we were finally able to move away from IE6 and IE7 is in large part thanks to polyfills.

A browser lagging behind is not always a matter of will, either — release cadence matters. IE, and EdgeHTML after it, was bound to the Windows release schedule, just as Safari is tied to the macOS and iOS release trains today — a constraint the engineers working on these engines have no say in. A slow release train stretches exactly the gap that polyfills exist to cover: even once a feature ships, it reaches users in OS-update time, not browser-update time. If every engine could ship at the cadence of Chromium and Firefox, the need for polyfills would shrink significantly. Until then, polyfills are how authors deliver the benefits of native APIs — performance, accessibility, i18n — without being held hostage to the slowest release train.

Without polyfills, a single browser has undue power to hold back the Web.

Without polyfills, fallbacks, and progressive enhancement, a single browser has undue power to hold back the Web — whether by choice or by circumstance. I’m far more concerned about that than about the occasional smooshgate.

Polyfills make the Web faster, inclusive, and more robust

Native features are typically more performant, more accessible, more i18nclusive, and handle more edge cases than any userland implementation.

A userland library can cut corners, exclude locales, declare that a11y is out of scope, and fail to consider edge cases. A web standard cannot.

A polyfill inherits some of these limitations while it’s active, but unlike a userland library, it is graded against a spec: its target behavior has already been through accessibility and i18n review, so its gaps are well-defined, visible, and centrally fixable. A userland library gets to define its own bar.

Developers being able to use web features before wide availability is a win for the Web as a whole.

Can we stop trying to solve the wrong problem?

Cost-benefit analysis is a fundamental part of human decision-making.
We get in cars, even though there is a risk of accidents.
We go outside, even though we may catch a cold — or worse.
We swim, even though there is a small risk of drowning.

We weigh the extent of the risk, the probability of it happening, and the cost of mitigating it, against the extent and frequency of the benefits, and decide accordingly. We do this all the time, whether consciously or not.

When it comes to the Web, the benefits of polyfills are tangible and felt by everyone who develops for it. Historically, failure cases have been few, and generally have been mitigated well. Even smooshgate resulted in array.flat(), which to me is not obviously worse than array.flatten().

We are spending so much collective energy trying to mitigate a largely theoretical problem, that has only been a significant issue a handful of times in the 30+ years of the Web’s history. And yet, many are willing to sacrifice significant, tangible, far-reaching benefits to do so. This is an emotional reaction to a few high-profile incidents, not a rational cost-benefit tradeoff.

Instead of trying to eliminate polyfills, we should be more proactive in discovering and reacting to developer needs, so polyfills never become so popular that they threaten the design space of a native API.

Starting from polyfilling itself. ^[3]

Huge thanks to Greg Whitworth and Cassondra Roberts for reviewing an earlier draft of this post.

People also asked if AI in Search would mean that people never click through to websites anymore.

Actually, as we’ve shared before, we continue to send billions of clicks to the web every day through Search. And we’ve designed our AI features in Search to connect people to websites. In fact, we’re now sending billions of clicks to websites every week through AI features in Search alone – and we’re just getting started.

The specific effects of Google’s A.I. search features is made murkier by all the other features the company has to answer queries immediately instead of sending them to an external website. Nevertheless, the claim that Google still sends “billions of clicks” is just another way of saying Google still has a monopoly on the world’s web searches. It is a substantially similar statement to the one Google issued a year ago, and something the company is only repeating because the New York Times asked for comment.

If only Google had some kind of dashboard or console with information about a website’s search performance.

Barry Schwartz, Search Engine Roundtable:

Google even built out the AI performance reports in Search Console but excluded clicks. This is because Google is “continuing to work with website owners to understand what insights will be most helpful to inform their strategies” and Google doesn’t think those are clicks. Nope, because Google does not want us to see our click-through rates from AI Search features compared to traditional search features.

I am sure this is a mere oversight that Google will be eager to correct.

⌥ Permalink

A few months back, a friend bought me Apple’s Digital Audio Workstation. I’m teaching myself this entirely new (to me) way of producing music by creating music—like I taught myself HTML and CSS by making websites.

It feels like there is no end to the music that has built up inside me over the past decades when I silenced this part of myself. I am thrilled to be creating and sharing music again.

I have no commercial expectations for these tracks; I just want people who might like my music to be able to give it a listen. If you object to Bandcamp, you can also listen on Sonica, although the mixes there are slightly different.

(I published to Sonica one track at a time; once I had sufficient material to sequence into a proper LP-style side, I remastered the tracks—in some cases also adding parts, and in other cases, taking them away. BTW, if you create music and are looking for a place to share with other creators, Sonica is a great place for it.)

Sonica is also where the curious can hear some of the music I created in my studio during the late 1980s, as well as some initial rough drafts of the newer music that has now found its way into Side One of Side One.

Side Two of Side One will be out as soon as I finish creating it. Meantime, grab a pair of headphones and enjoy Side One of Side One.

The post The name of this LP is “Side One.” appeared first on Jeffrey Zeldman Presents.

First, I added a table of course:

<table id="table1">
	<thead>
		<tr>
			<th>Name</th>
			<th>DOB</th>
			<th>Gender</th>
			<th>Breed</th>
		</tr>
	</thead>
	<tbody>
	<tr><td>Whiskers</td><td>2019-03-14</td><td>Male</td><td>Maine Coon</td></tr>
	<tr><td>Luna</td><td>2020-07-22</td><td>Female</td><td>Siamese</td></tr>
	<!-- bunch more rows -->
	<tr><td>Nala</td><td>2022-04-18</td><td>Female</td><td>Persian</td></tr>
	<tr><td>Molly</td><td>2022-01-11</td><td>Female</td><td>LaPerm</td></tr>				
	</tbody>
</table>

Alright, so to enable this feature, I thought data attributes might be nice. This would let you use it on anything, a button, a link, image, etc. The data attribute would be responsible for pointing to the table (via an id) and specifying a format. Here's an example:

<!-- data-copy defaults to text -->
<a href="" data-table="table1">Copy as Text</a> ~ 
<a href="" data-table="table1" data-copy="md">Copy as Markdown</a> ~
<a href="" data-table="table1" data-copy="csv">Copy as CSV</a>

Now all I need to do is wire it up to code that looks for data-table and adds the appropriate handlers. The first part is trivial:

const links = document.querySelectorAll('*[data-table]');

Note that while I named the variable links, you can still use this with buttons or images.

I loop over each match and first get the table referenced, throwing an error in console if it doesn't exist:

links.forEach(l => {
	let table = document.querySelector(`#${l.dataset.table}`);
	if(!table) {
		console.error(`Unable to connect to table with id ${l.dataset.table}`);
		return;
	}

Next, I check the type, defaulting to text:

let type = l.dataset.copy || 'text';

The final bit is to assign the click handler:

l.addEventListener('click', async e => {
	e.preventDefault();
	console.log(`about to copy table ${table.id} to ${type}`);
	let data = getRawData(table);
	let formattedData = formatData(data, type);
	await navigator.clipboard.writeText(formattedData);
});

For each, I get the raw data from the HTML table, convert it to the right format, and then write to the clipboard. (Check out my article on working with the clipboard in JavaScript.)

getRawData just iterates through the table's DOM creating a 2D array:

const getRawData = t => {
	let data = [];
	t.querySelectorAll('tr').forEach(r => {
		let row = [];
		r.querySelectorAll('th, td').forEach(d => {
			row.push(d.innerText);
		});
		data.push(row);
	});
	return data;
}

formatData is a bit more complex and I used AI to help me with each of the main sections. I added support for plain text, Markdown, and CSV:

const formatData = (data,type) => {
	let numCols, colWidths, lines, buildRow, buildDivider;
	
	switch(type) {
		case "text": 

			numCols = Math.max(...data.map(r => r.length));
			// Compute max width for each column
			colWidths = Array(numCols).fill(0);
			for (const row of data) {
			for (let i = 0; i < numCols; i++) {
				const cell = row[i] !== undefined ? String(row[i]) : '';
				colWidths[i] = Math.max(colWidths[i], cell.length);
			}
			}
		
			buildDivider = () =>
			'+' + colWidths.map(w => '-'.repeat(w + 2)).join('+') + '+';
		
			buildRow = (row) =>
			'|' + colWidths.map((w, i) => {
				const cell = row[i] !== undefined ? String(row[i]) : '';
				return ' ' + cell.padEnd(w) + ' ';
			}).join('|') + '|';
		
			lines = [];
			lines.push(buildDivider());
			lines.push(buildRow(data[0])); // treat first row as header
			lines.push(buildDivider());
			for (let i = 1; i < data.length; i++) {
			lines.push(buildRow(data[i]));
			}
			lines.push(buildDivider());
		
			return lines.join('\n');

		case "md":
		case "markdown": 
			numCols = Math.max(...data.map(r => r.length));
			
			buildRow = (row) =>
				'| ' + Array.from({ length: numCols }, (_, i) =>
					row[i] !== undefined ? String(row[i]) : ''
				).join(' | ') + ' |';
		
			lines = [];
			lines.push(buildRow(data[0])); // header
			lines.push('| ' + Array(numCols).fill('---').join(' | ') + ' |');
			for (let i = 1; i < data.length; i++) {
				lines.push(buildRow(data[i]));
			}
		
			return lines.join('\n');

		case "csv": 
			const escapeCell = (value) => {
			const str = value !== undefined && value !== null ? String(value) : '';
			// Quote if it contains comma, quote, or newline
			if (/[",\n\r]/.test(str)) {
				return '"' + str.replace(/"/g, '""') + '"';
			}
			return str;
			};
		
			return data.map(row => row.map(escapeCell).join(',')).join('\n');
			
	}
}

With my test table (and I'm stripping out a bit here for brevity), here's the plain text version:

+----------+------------+--------+----------------------+
| Name     | DOB        | Gender | Breed                |
+----------+------------+--------+----------------------+
| Whiskers | 2019-03-14 | Male   | Maine Coon           |
| Luna     | 2020-07-22 | Female | Siamese              |
| Oliver   | 2018-11-05 | Male   | British Shorthair    |
| Max      | 2019-06-25 | Male   | Sphynx               |
| Stella   | 2021-05-04 | Female | American Curl        |
| Rocky    | 2018-09-20 | Male   | Burmese              |
| Molly    | 2022-01-11 | Female | LaPerm               |
+----------+------------+--------+----------------------+

Here's the Markdown:

| Name | DOB | Gender | Breed |
| --- | --- | --- | --- |
| Whiskers | 2019-03-14 | Male | Maine Coon |
| Luna | 2020-07-22 | Female | Siamese |
| Oliver | 2018-11-05 | Male | British Shorthair |
| Max | 2019-06-25 | Male | Sphynx |
| Stella | 2021-05-04 | Female | American Curl |
| Rocky | 2018-09-20 | Male | Burmese |
| Molly | 2022-01-11 | Female | LaPerm |

And here's CSV:

Name,DOB,Gender,Breed
Whiskers,2019-03-14,Male,Maine Coon
Luna,2020-07-22,Female,Siamese
Oliver,2018-11-05,Male,British Shorthair
Max,2019-06-25,Male,Sphynx
Stella,2021-05-04,Female,American Curl
Rocky,2018-09-20,Male,Burmese
Molly,2022-01-11,Female,LaPerm

I wrapped this all up in a function that you could add to your page. After adding it, don't forget to actually add the links/button/etc to enable it.

There's two issues with my code that come to mind, and I'd love people to comment in with their ideas. First, both the text and Markdown assume the first row is a header. In theory that might not always be accurate. I could update the code to see if the first cell in the first row is th versus td, but that kinda feels like overkill.

The second issue that comes to mind is user feedback. Usually these types of things will provide some kind of visual feedback ("Data copied!"). My code does not. I honestly don't quite know how I'd do that. Perhaps a data attribute that would replace the text (assuming it's a link or button) temporarily? I'm not sure.

If you've got ideas, leave me a comment below. Here's the demo:

See the Pen Copy Table As (2) by Raymond Camden (@cfjedimaster) on CodePen.

I'm not talking about the "star" rule, but what I imagine would be a wildcard on elements selector.

Existing methods

If I want to select and style all the .btn-* classes using attribute selector, I'd do this:

[class^="btn-" i] {
  …
}

This selector says: find all the elements with the class attribute that starts with "btn-" - case insensitive.

It's rather brittle, because it requires that the HTML class attribute starts exactly with btn-. Though it works, it does tie the HTML closely to the CSS - which I'd argue you'd want to be very sure you need to do.

But it is possible.

Equally, and a lot more robust, is the wildcard that says "anywhere in the attribute", so:

[class*="btn"] {
  …
}

It's fine, but it's a bit sledgehammery. However, if you want to do the same thing for a web component, for instance, you can't.

If I want to target all the rem-xxx custom components using rem-* { … }, I can't.

Obviously I'm not the first to think of this, and of course the venerable Lea Verou has thought about this and filed the issue over two years ago, though there doesn't seem to be much interest in supporting it.

The reason it crossed my mind is that I was thinking about how you would initialise web components on a page, and currently it requires searching every single element in the DOM, rather than targetting to the nodes you want ahead of time.

From this MDN article they included a code snippet that (I thought) was a clever way to initialise the components:

for (const element of document.querySelectorAll("*")) {
  const tag = element.tagName.toLowerCase();
  if (tag.startsWith("mdn-")) {
    const component = tag.replace("mdn-", "");
    import(`../components/${component}/element.js`);
  }
}

But really, it should be:

for (const element of document.querySelectorAll("mdn-*")) {
  const component = element.tagName.toLowerCase().replace("mdn-", "");
  import(`../components/${component}/element.js`);
}

This feels like a relatively cheap change to add support for wildcards, and gives the querySelectorAll a nice little boost, along with the benefits Lea already outlined in the github issue she raised.

Would it be valid?

I swear I found the documentation that read that the * asterisk was reserved for the universal selector (i.e. match all things), but I can't find it any more.

However, the from my memory, the parser only allows an asterisk after a space, to indicate it's a universal selector, so foo* or foo-* would not match in the parser.

Equally, it's allowed in the attribute selector, but only when followed by =, but attribute selector already has wildcard support. But maybe this would be extended to cover "glob" like support, so I could do .foo*bar to match .foo-dont-do-it-bar. Again, the current parser doesn't allow for this, so that means it's available for use.

Originally published on Remy Sharp's b:log

She makes the very good point that generative tools are a necessary accessibility recourse when humans have failed to do their job properly.

Images without alt text? Somebody messed up. But this is damage that can be routed around with large language models.

So if you—like me—don’t like the idea of people using extractive generative tools made by the worst kind of people, pay heed:

If you want to resist AI, make accessibility part of everything you do, every decision you make, every product you design and build. Remove the need for people to use AI to compensate, and remember, accessibility is resistance.

Also last month, I wrote about enhancing images from a carousel to masonry using CSS Grid Lanes. Here’s the context:

Over on The Session, I added a little enhancement to the events and sessions listings recently. I make a call to the Google Places API to see if I can find a match for the venue, and if I do, pull in some photos.

Sidenote: right now there’s a major issue with this. None of the photos come with text descriptions. This is something I need to fix, and I’ve got some ideas on how to do that.

I was one of those people with a website that doesn’t have alt text for images. I was one of those people not doing their job.

The first fix I put in place was very much in keeping with the ethos of The Session. I added a form so that any member of the site can edit the alt text of the images in the carousel/masonry layout.

The Session is quite WikiPedia-like. Anyone can edit the track listings in the discography. Anyone can edit the details of any tune. Anyone can edit the details of any session or event. So it made sense to add one more thing that anyone can edit.

With that functionality in place, I put out the call:

If everyone were to take just one or two sessions or events and add alt text to the photos, it would really, really help make the site more accessible.

The community went to work and did a pretty good job.

But there are a lot images. I’d like to have a least some kind of alt text for all of them, even if it’s just a placeholder until someone gets around to adding something better.

I was going to have to use generative “AI”, wasn’t I?

Holding my nose, I investigated some alt-text-as-a-service APIs out there. I signed up for some trials and kicked the tyres. They were rubbish. I suspect most of them were vibe-coded.

The more I thought about it, the more I realised that I probably didn’t need the latest and greatest energy-guzzling large langauge models. Some good old-fashioned machine learning could do the trick here. I’m aiming to do a relatively straightforward transformation—image to text.

Check out the COCO project: Common Objects in Context. It’s a few years old now, but it’s basically a dataset that’s been trained on images.

Ah, but where did the training data come from?

All images in COCO were sourced from Flickr, a photo-sharing platform where users upload images under various Creative Commons licenses.

Works for me!

I found a model on Hugging Face that was created by Microsoft from the COCO data. Confusingly the model is called GIT. It’s nothing to do with version control. It stands for GenerativeImage2Text.

I downloaded the model and set to work creating a script to trawl through all those images and generate alt text if the image doesn’t already have one.

I should mention: the way that I store the alt text is not in a database, but in the file system. Every image has its own folder. Inside that folder there can also be a file called alt.txt.

So the script needed to loop through lots and lots of folders, generate alt text where needed, and save it into a text file in the same folder.

Python is the go-to language for working with models like GIT. But Python is not my strong suit, to put it mildly. And this was going to be a throwaway script that I was only going to use once. So I held my nose again and turned on Copilot in VSCode (I usually keep it switched off).

With the right instructions I was able to get a script that—crucially—I could read and understand. Then I switched off Copilot and had a shower to try to wash the shame away.

Long story short, the script worked.

The results are mostly fine. The alt text is functional. Sometimes it’s wrong, but not disastrously so. A human-generated image description will always be preferable, so any member of The Session can over-ride the placeholder alt text.

It took a few hours to loop through all those folders and generate all those text files. My laptop got hot. But doing it locally sure beats paying for tokens from the baddies.

Like Scott says:

While the utility is there, the current landscape of these frontier corporate models comes with massive ethical and environmental baggage. This is not a long term solution!

That’s exactly why my hope is that ethically trained open-weight models will eventually catch up and that in the next couple of years, we’ll have something with this level of capability that can run locally. That feels like a much better place to be with this technology.

I especially like these two from the post:

Text overflow truncation from centre…

And:

More pseudo-classes. :sticky for if an element is currently sticky, :overflow for if overflowing, etc

Which falls consistently into the category of "JavaScript is used to do this, it shouldn't need to".

Original link: vale.rocks/[…]/web-platform-wishlist

Originally published on Remy Sharp's b:log

Greetings Simple Friends,

Today I'm excited to officially release my latest typeface, Kyroh. It's available for sale in the shop, and has also been distributed to all Secret Club members.

Kyroh is an all-caps, sans-serif display font inspired by a vintage luggage label from the National Hotel in Cairo, Egypt (found in the amazing book from Letterform Archive which is highly recommended).

I riffed off the hand-lettered word “EGYPT” from the label and filled out the rest of the alphabet informed by those five letterforms. I love how wide and chunky the word was lettered, and the simplified G and lowercase-ish Y had me thinking of how the rest of the alphabet might play off of those imperfect, inky, rounded-but-rough shapes.

Kyroh comes in three weights: Regular, Medium, and Bold and has our standard extended language support with diacritics and additional glyphs. Plus! A few Egyptian icons based on some of the common hieroglyphics.

Kyroh is available now, individually in our shop or join our Secret Club™ and get ALL the SimpleBits® fonts + other perks for just $60/year.

Thanks for your support! Enjoy the new font, tag us if you use it, and see you back here on Friday for my next Studio Notes™.

Cheers,

adactio.com/links/22644

Figured I’d blog about it.

Shuffle? On a Blog?

At the time of this writing, I have 974 “notes” that I’ve published.

For fun, I have a “shuffle” button that digs up a random note from the past. I like to press it from time to time and re-encounter some insight from the past.

It’s like going through an old album, pulling out a random photo, and thinking, “Oh yeah, I remember this! Good times.”

Like old photos, there’s also the occasional “that didn’t age so well”.

But I find it fun to randomly dig up old insights from others and continue to be inspired.

How Did It Work Before?

Since my site is built and hosted as static files without a runtime server, this feature required JavaScript to work.

Every page had a snippet like this:

<!-- In the site navigation -->
<button id="js-shuffle">Shuffle</button>

<!-- Way down at the end of the HTML -->
<script>
  // All 974 note IDs injected by my SSG
  const noteIds = ['id-1', 'id-2', id-3', 'id-4', '...'];
  document.querySelector("#js-shuffle")
    .addEventListener('click', () => {
      // randomly grab an item in `noteIds`
      const randomId = '...';
      window.location.href = `/n/${randomId}/`
    })
</script>

Essentially: inject every note ID into every HTML page and, when the shuffle button is clicked, randomly grab one and navigate the user to it.

Not the most elegant thing, but it worked.

The problem was that every time I published a new post, every single page had to be re-uploaded to Netlify because every file’s hash would change and its etag/cache was invalidated.

This made my builds slow. It also made it difficult, from a development perspective, to ensure refactors didn’t result in unexpected changes to output (using Dev.changes from my SSG web origami).

So I decided to make a change.

What About a No-JS Approach?

Because I love to see if I can make things work without JavaScript, I had the thought to randomly write the href at build time using my SSG, which would result in output like this:

<!-- /notes/1 -->
<a href="/notes/3">Shuffle</a>

<!-- /notes/2 -->
<a href="/notes/1">Shuffle</a>

<!-- /notes/3 -->
<a href="/notes/2">Shuffle</a>

And every time I re-build my site, just have this logic run on the static site generator so that it’s different href for every page, every time.

Pros:

• Doesn’t require JavaScript
• Doesn’t require a server (request-time logic)

Cons:

• File hashes change across builds (even if there’s no new content or template changes, every HTML page now has a different href for the shuffle link for every build). This makes deployments way slower because Netlify has to redeploy every file on every build. Plus Etags change so caching is basically ineffectual.

I decided I didn’t want to do this, so on to JavaScript!

How Does It Work Now?

My first thought was to create a single JSON file that contained all my note IDs. Then when the “Shuffle” button gets clicked, I fetch that, grab a random ID, and navigate the user, e.g.

<!-- In the site navigation -->
<button id="js-shuffle">Shuffle</button>

<!-- Way down at the end of the HTML -->
<script type="module">
  const noteIds = await fetch("/notes.json").then(...);
  // Handler code for when button is clicked
  // grab a note ID & navigate to that location
</script>

This would work. It localizes the caching issue to a single file, so only one file has to be invalidated/re-uploaded across builds.

But in playing with it a little more, I decided to try something a little more...unconventional.

I’ve written before about having lots of little HTML pages and I thought, “Can I put this functionality in a single HTML page rather than a JSON file?”

And what I ended up with was a link, e.g.

<a href="/shuffle/">Shuffle</a>

That when clicked navigates the user to a new page. That page has all the JS logic embedded in it, e.g.

<!-- In the site navigation -->
<span>Shuffling...</span>

<!-- In the body of the page -->
<noscript>JS is required to use the Shuffle functionality</nocript>
<script>
  // All 974 note IDs injected by my SSG
  const noteIds = ['id-1', 'id-2', id-3', 'id-4', '...'];\

  // A slight delay so user sees "Shuffling..." effect
  setTimeout(() => {
    // randomly grab an item in `noteIds`
    const randomId = '...';
    window.location.href = `/n/${randomId}/`
  }, 300);
</script>

There are a few things I like about the experience this implementation provides.

First: shuffle is a route, so I can navigate to it directly without using the GUI, e.g. notes.jim-nielsen.com/shuffle

Second: I handle the UI/X with a slight delay to make it appear like something is happening when you click the button. If you click the button and it immediately jumps to the next, randomized page, it almost seems to happen too fast. Like you’re left with this feeling of “What just happened?”

But in this scenario, it navigates you to the “Shuffle” page, the button you just clicked turns into a spinner + text indicating something is happening, and there’s a slight (intentional) delay before the JS executes and sends you to a randomized note.

I know it’s a bit weird. “Introduce artificial slowness? Are you crazy?” But I like it. It feels like the shuffle feature on an old music player.

I remember one of my CD players had a “Shuffle” feature. When I’d click the button, it would display “Shuffling…” on the little black and white screen and you’d encounter this brief state where (I presume) the lens inside the hardware would move along the physical track to the spot where it would start reading a new, random song from the CD.

The hardware constraints necessitated this kind of an experience, but I always liked it because it felt like the CD player was “thinking” about what track to pick next. This state clearly conveyed to me that my intent to shuffle was received and being followed. I liked that feedback, and it’s exactly what I wanted to do on my notes site (even though it was completely unnecessary).

I like having that brief moment of feedback where it’s very clear that your intention was received and being followed, vs. having it happen so fast you can’t even perceive precisely what happened.

Here’s a video to show it in action:

Why?

I know that’s a lot of information for something so small — and, arguably, unnecessary.

But I still enjoy writing about how I make decisions when I build things for myself.

Hence this post.

Reply via: Email · Mastodon · Bluesky

Calendar Mirroring allows you to connect two separate calendars (like work and personal) so that events from one automatically show up on the other.

The best part? No event information is sent to Flexibits servers or saved outside of your device.

You can choose to show full event details or just block the time out as a mysterious, professional “Busy”. Your coworkers don’t need to know you’re getting a root canal, they just need to know you’re unavailable.

In Flexibits’s example scenario, the idea is that you have a personal calendar with important events that you want to mirror to your work calendar, to block the times for those events off — and you might just want them marked as “Busy” on your work calendar, rather than revealing the actual details.

I’ve been using this feature in beta for a few months and love it, even though my use case is seemingly simple. For recording episodes of Dithering, Ben Thompson and I have a shared Microsoft 365 calendar. (You can guess which of the two of us set that up by that fact.) Fantastical has long had terrific built-in support for Microsoft 365 accounts. So for me, those events have always just shown up in Fantastical. For me.

The problem is, my wife and I share an iCloud calendar, where we put events we want each other to know about. My Dithering recordings have never shown up there. Ben and I record on a pretty regular schedule, but it’s always been a minor irritation that my wife can’t see when I’m booked for Dithering. Fantastical’s new mirroring feature solves this perfectly. I set up a mirror to copy all events from my Dithering calendar to my family calendar, keeping the original event titles rather than obscuring them as “Busy”. (The titles all just say “Dithering”.)

The icing on the cake is Fantastical’s longstanding “Combine identical events” preference setting. Because I have that setting on, I don’t see duplicate “Dithering” events — one from my Dithering calendar, and another from my family calendar. I just see one event for each scheduled recording, with a striped dual-color swatch that indicates that this one event exists on both calendars. It’s just perfect.

One more thing: Also somewhat recently, Fantastical added support for Anthropic’s MCP to integrate your calendaring with Claude Desktop and every other AI agent that supports the standard. David Sparks made a short demo video that shows it off. I don’t really use Claude so this didn’t hit for me personally, but it seems cool enough that it made me at least consider, for a moment, switching from ChatGPT to Claude. Then I remembered what the Claude app is like.

Any MCP-compatible client can connect to the Safari MCP server. By connecting your agent to a Safari browser window, your agent can emulate what your users experience, giving it the information it needs to debug more autonomously, like access to the DOM, network requests, screenshots, and console output.

It speeds up your debugging process and lets you stay in the comfort of your terminal, which means fewer rounds of hopping windows and typing prompts to debug your code.

The use cases

If you build for the web, then you know about the debugging dance. It usually goes something like this:

You see something wrong with your site in the browser. You open the console to hunt it down. You click into the styles tab. You see what’s broken. You go back to your code to fix it. Or maybe you take a screenshot, detail the problem to your agent, and let it do the fixing for you. Hopefully it gets it right, the bug is fixed, and you can move on.

But when it isn’t fixed, you go through the workflow again — Browser. Prompt. Agent.

And again and again, until you finally squash the bug.

Regardless of the browser or tools you use, the debugging workflow is a lot of clicks, tools, and window hopping to make a single fix, but it doesn’t have to be that way. If you’re already using agents in your development workflow, the Safari MCP server makes your debugging faster and more efficient.

The Safari MCP server enables your agent to do more debugging and troubleshooting on its own. Here are just a few examples of what it can help with:

Web development in Safari. The next time you develop in Safari, you’ll benefit from an upgraded workflow. Your agent already helps you with your code, now it can do even more by checking out how your code actually renders in Safari.

Improve compatibility with Safari. Testing in just one browser means missing potential bugs in another, giving those users a subpar experience. With the Safari MCP server, your agent can open your site in Safari, inspect computed styles, check layout, and compare it against what you expect without switching windows.

Analyze performance. See what parts of your site are slowing things down. The Safari MCP server lets your agent evaluate JavaScript on the page to surface performance metrics, like navigation timing and resource load times, so it can pinpoint what’s slowing your site down and work on the right fix.

Check for accessibility. The Safari MCP server lets your agent check for common accessibility issues like missing labels, improper ARIA attributes, and poor contrast, so you can catch problems that impact your users.

Verify any user state. Know that the page is working and looking as it should. Your agent can check the state of the form, query an element using a selector, confirm specific interactions, show different states of a checkout flow, and more. Spend less time on these manual checks and empower the agent to do it for you.

These are just a few of the use cases. However you decide to implement it, the Safari MCP server helps your agent do more for you and reduce all the back and forth that web development often requires. An easier workflow means more bugs squashed, happier users, and a better product.

The tools

Here are the available tools and what they do:

With the Safari MCP server, you no longer have to write the perfect prompt, carefully describing to your agent what you’re experiencing in the browser. You can give your agent the ability to find out for itself.

How to get started

Safari 27 beta

First, you’ll need to install Safari 27 beta. Once installed, make sure to enable web developer features and remote automation. To enable features for web developers choose Safari > Settings > Advanced > check the Show features for web developers checkbox. Then go to Safari > Settings > Developer > check “Allow remote automation and external agents.”

If you’re using Claude, you can use the following command in your terminal:

claude mcp add safari-mcp -- "/usr/bin/safaridriver" --mcp

If you’re using Codex, you can use the following command in your terminal:

codex mcp add safari-mcp -- "/usr/bin/safaridriver" --mcp

For other agents, you can put the following in your mcp.json or config.json file.

{
  "mcpServers": {
    "safari-mcp": {
      "command": "/usr/bin/safaridriver",
      "args": ["--mcp"]
    }
  }
}

Safari Technology Preview

First, you’ll need to install Safari Technology Preview. Once installed, make sure you enable Safari Settings > Advanced > Show features for web developers. Then go to Safari Settings > Developer > Enable remote automation and external agents.

If you’re using Claude, you can use the following command in your terminal:

claude mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp

If you’re using Codex, you can use the following command in your terminal:

codex mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp

For other agents, you can put the following in your mcp.json or config.json :

"safari-mcp-stp": {
  "command": "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver",
  "args": ["--mcp"] 
}

Note that while the above code names the server safari-mcp-stp, you can name it whatever you like, even just safari. Once you have the Safari MCP server installed, try one of the following prompts:

Find bugs on my site in Safari

How accessible is my site in Safari?

See how my website performs in Safari

While each agent works a little differently, it shouldn’t need to be told to use the Safari MCP server explicitly — it’ll figure it out on its own. Simple prompts like the ones above are enough to kickstart the MCP.

Here’s how a conversation with an agent using the Safari MCP server might go:

All you need is an initial request to get started, and with the help of the Safari MCP server, your agent can take it from there.

The Safari MCP server runs entirely on your local machine and makes no network calls of its own. It also does not have access to your personal information in Safari (e.g. AutoFill or other browser activity). When it captures page content, screenshots, or console logs, that data goes directly to the agent you’re running — not to Apple. What happens to that data from there depends on the agent and model you’re using. As with any agent you give access to your browser, only use ones you trust.

Why we built this

There are many ways to build for the web, both with and without AI. If AI is a part of your workflow, we think this tool will help make it even more productive. And if it isn’t, that’s OK too.

By creating this resource, we hope to make it easier than ever to test and debug in Safari by helping your agent understand how things look and work in the browser.

If you end up giving it a try or if this is your first time using an MCP server, let us know what you think.

Find us online: Saron Yitbarek on BlueSky, Jen Simmons on Bluesky / Mastodon, and Jon Davis on Bluesky / Mastodon. If you run into any issues, file a WebKit bug report. Filing issues really does make a difference.

It hasn't gotten much traction yet, and I think I know why: dictation has been bad for so long that most people stopped paying attention. I don't blame them. But I don't think most people realize how good local models have gotten. The thing that was flaky and frustrating five years ago is genuinely good now, and it runs entirely on your Mac.

Downloads are low. But the conversion rate is great. The people who actually try it tend to stick around, which tells me the problem isn't the app, it's getting someone to give dictation one more honest chance.

The real hurdle is the habit

The hard part isn't accuracy. It's that talking instead of typing is a new habit, and new habits are awkward before they're automatic. For the first week it feels strange. You catch yourself reaching for the keyboard out of muscle memory.

Then one day it clicks, and you realize how slow typing was making you for certain things.

I still write code by hand. That's thinking, not transcribing, and I want my fingers on it (plus saying HTML tags and attributes out loud seems counterintuitive 😂). But for almost everything else, I talk.

• I prompt LLMs
• I send emails
• I reply on Slack
• I write commit messages
• I do most other text with my voice

The common thread is that the thinking is already done and the only thing left is getting the words out. That turns out to be a surprising amount of my day.

My desk setup

On the go, the MacBook's built-in mic works just fine. You don't need fancy hardware to get good results. But when I'm at my desk, my laptop is docked, so I pair TongueType with a Tula mic. It's small, portable, sounds great, and looks the part! (Kuru Toga mechanical pencil positioned for size comparison.)

One tip: use a wired mic if you can. Bluetooth adds latency, and latency is the enemy of a tool you reach for dozens of times a day. A wired connection makes the whole thing feel instant.

Honest caveat: it's probably not a great look in a co-working space. 😂

"Why is this better than macOS dictation?"

More accurate. Less flaky. More customizable. More fun.

I could list the features, but the honest answer is the same one I'd give for most things: just try it and you'll feel the difference immediately. It's free to start.

What's your experience been with dictation? If you wrote it off years ago, I'd genuinely love for you to give TongueType a shot and tell me what you think.

In my last blog post, Your Grid Lanes will likely fail WCAG 2.4.3, I explained how Grid Lanes are inherently inaccessible by default unless you take extra measures. I also concluded that it's probably only safe to use Grid Lanes with Reading Flow. According to Rachel Andrew, Google Chrome also made sure to first ship Reading Flow and then Grid Lanes. Unfortunately, that's not what all browsers did. Safari shipped it, but doesn't support Reading Flow yet.

Is it a big deal?

Now you may think it's not a big deal because most people won't use Grid Lanes anyway until all browsers support it, and maybe, when that happens, Safari will also support Reading Flow. The thing is, Grid Lanes share many properties with Grids, and because CSS is beautifully designed, it's very easy to convert regular grids into Grid Lanes for browsers that support it.

HTML

<div class="grid-lanes">
  <button class="s">1</button>
  <button class="m">2</button>
  <button class="l">3</button>
  <button class="l">4</button>
  <button class="m">5</button>
  <button class="s">6</button>
</div>

In one line, you set the display property to grid, and in the next, you overwrite it with grid-lanes.

CSS

.grid-lanes {
  display: grid;
  display: grid-lanes;
  grid-template-columns: repeat(3, 1fr);
}

Browsers that support it will create Grid Lanes, and those that don't will just fall back to a regular Grid.

In theory, that's all you need to create future-proof Grid Lanes. People will use it, and some are actually already doing it. Jeremy Keith, for example, explains how he uses @supports to enhance a gallery built with Flexbox.

Generally, both strategies are fine, but neither addresses the focus order issue you may run into.

An accessible progressive enhancement strategy

Although progressive enhancement is possible by merely repeating the display property, I suggest using Grid Lanes only if the browser supports Grid Lanes and Reading Flow.

.grid-lanes {
  display: grid;
  grid-template-columns: repeat(3, 1fr);

  @supports (display: grid-lanes) and (reading-flow: grid-rows) {
    display: grid-lanes;
    reading-flow: grid-rows;
  }
}

If you test this demo in Chromium-based browsers with the feature flag enabled, you will see Grid Lanes, and in Firefox and in Safari, you'll see a regular grid. Yes, that means Safari users won't see Grid Lanes even though their browser supports it, but it also means that when browsers ship Reading Flow, they'll likely have a better, more accessible experience.

That's a great strategy, but…

The deal breaker

I really like this idea, but unfortunately, Reading Flow is currently scoped to Grid and Flex containers. I wasn't able to find out whether there are plans to extend the property soon. The only thing you can do in the meantime is test your Grid Lanes with the keyboard and adjust flow-tolerance accordingly.

If you need a more general solution, set flow-tolerance: infinite, but still test with the keyboard.

.grid-lanes {
  display: grid;
  display: grid-lanes;
  grid-template-columns: repeat(3, 1fr);
  flow-tolerance: infinite;
}

Conclusion

I suggest using the strategy that checks for support for both properties. It hinders you from shipping inaccessible layouts in Safari. Once reading-flow is extended, you can create well-balanced Grid Lanes while still maintaining a more or less expected focus order. Reading flow doesn't solve every problem, because focus can still follow a pretty wild path if the items used differ significantly in size, as described in my previous post.

The more I think about it, the less sympathy I have for Grid Lanes. You create a DOM order that you think makes sense, then you mess it up with CSS. Then, if you're aware of the problem, you fix it again with CSS. Finally, you have a patched-up layout that may have created other issues you can't address.

I'm looking forward to Chrome's, Firefox's, and Safari's next moves. Until then, to sum it up, my slightly adjusted recommendations are:

• Always test your Grid Lanes with the keyboard or a screen reader across different screen sizes.
• If you find a mismatch between the DOM and the visual order, increase the flow-tolerance value. You may have to use a high value or even infinite.
• As soon as it's available and supports Grid Lanes, try using reading-flow instead.
• If that doesn't work, consider using a regular grid.

My blog doesn't support comments yet, but you can reply via blog@matuzo.at.

We’re winding down the Notion Mail inbox across web, desktop, and iOS on September 22.

It's a bit of a bummer, but truth be told, this didn't quite hit the mark. It was kind of like "Superhuman, but for cheap" when it launched, but once they started charging for the AI features, it just became "as expensive as Superhuman, but not quite as good". Once the price advantage went away, I reverted to Mimestream, myself.

If they wind down Notion Calendar, someone better hold me back, though.

In systems thinking, this principle was best articulated by John Gall:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

I’ve long promoted Gall’s law to students and clients. It’s been hard going. We want to see products and services in their full glory ASAP. But you can only throw so much cash and person-hours at a problem. Ergo, we got the time-tested idea of a minimum viable product. (It’s no coincidence that orgs with more resources violate Gall’s law more often than scrappy startups.)

But the value of an MVP isn’t just that it allows you to get something that works quickly and cheaply. Instead, the value is that that first try isn’t overspecified to theoretical conditions. It’s only a draft meant to kick off an evolutionary process that leads to a system that meets real-world customer needs.

AI removes these constraints. An afternoon with Claude can yield a comprehensive spec for a very complex system. Further sessions can architect the system and build an initial release that includes bells, whistles, timpani, harps, violas, and all the other instruments in the orchestra. All this, at a fraction of the cost and time it would’ve taken in the past.

That’s amazing. It means we can now design and build much larger systems, faster. This opens new possibilities. Not just one new feature, a new product. Not just a new product, a suite. Not just a suite, a platform. The possibilities seem endless.

But in removing architecture and development constraints, we’re also removing the need to focus on what matters most and the discipline to run it by the market. All that upfront complexity doesn’t necessarily address real-world needs. Instead, it reflects a singular top-down vision that may or may not provide value to others.

Whereas MVPs in the “before times” called for minimal investment before validation, LLMs promise a much more realized vision from the first go. But there’s a significant difference between a sexy concept car and a vehicle customers will take grocery shopping. AI-augmented workflows will give you the former, but not the latter.

Here’s an example. Two years ago, I started building a product called SiteRanger, an AI-powered agent to help small teams manage large websites. This was before Claude Code or any of the current coding agents. Still, I got surprisingly far by using Claude to augment my basic PHP skills.

Together, we built a functional MVP that implemented what I considered to be the core functionality. The problem: my “core” was in fact an open-ended platform. Rather than solve a particular customer problem, it was designed to solve classes of problems.

By the time I got alpha users on board, the system was wildly over-architected. Worse, I learned new agentic systems could provide ~80% of its value. When I looked to pivot, I realized I’d have to move in a completely different direction, one with entrenched incumbents. It wasn’t worth it.

It wasn’t all a loss. This experiment taught me a lot about developing AI-powered software products using AI. But the most important lesson I learned is that AI makes it very easy for individuals and small teams to land in the same trap as resource-rich orgs: no constraints.

Which isn’t to say you shouldn’t use AI. To the contrary, I’m all for accelerating MVP design and development. But the word “viable” is fungible, especially when you have robot engineers. You want to expose the product to the discipline of the market. That means releasing something embarrassingly simple at first. And that requires discipline and constraint — the two things most scarce when working with LLMs.

My friend Karl Fast pointed me to a wonderful scene in the movie A RIVER RUNS THROUGH IT. The main character, a child, brings an essay to his dad, a strict preacher, for evaluation. The dad’s only reply: “Half as long.” The child does, and returns with the edit. After scribbling with a red pencil, the preacher looks at him and says: “Again, half as long.”

Step away from the console and ask yourself: What would I cut if there were no AI building it? Cut, cut, cut. Then imagine Tom Skerritt staring at you over his schoolmaster glasses and saying drily, “Again, half as long.”

This long-debated solution for masonry layout is now available and it’s time to figure out how to use it. Join us for a deep dive into the workings of Grid Lanes.

Subscribe to Channel »

• grid-lanes is a new CSS display property that allows you to create a masonry-like layout.
• flow-tolerance is a new property for grid-lanes that accepts a length value.
• Defining the grid-lanes with grid-template-columns creates a vertical “waterfall” layout. grid-template-rows creates a “brick” layout.
• Other grid features like gap, subgrid, and spanning a cell across multiple tracks work with grid-lanes.
• What alignment options do we have?
• Can we fill in gaps that are created after spanning cells?

• The Field Guide to Grid Lanes
• Poetic CSS Course
• CodePen demo
• Alignment is CSS Grid Lanes
• Browser Compatibility

This is an outrageous litmus test for the freedom to protest in America:

“A group of Texas protesters convicted of terrorism charges received unusually harsh sentences of at least 50 years in prison on Tuesday in a closely watched case that was widely seen as a test case of the Trump administration’s efforts to crack down on dissent.”

Let’s be clear: a few of the protesters were out of bounds. One fired an AR-15 at the police, which goes beyond legitimate protest into inciting violence (and maybe even deliberate provocation). I would never condone that kind of activity.

But these sentences far outstrip anything that’s been given to anyone on the right wing: the leader of the Proud Boys, as this article notes, was sentenced to 22 years in prison. One protester wasn’t even present, but was sentenced to 30 years for moving some zines:

“The ninth defendant, Daniel Sanchez-Estrada was not at the protest, but was convicted of corruptly concealing a document or record after prosecutors said he moved leftwing zines and other materials at the request of Rueda, his wife, after she was arrested. Sanchez-Estrada was sentenced to 30 years in prison on Tuesday.”

Many of the protesters had guns and were part of a gun club. They all possessed them legally. I personally wish there was not a right to bear arms and think that their ubiquitous presence in America makes everyone less safe, but the right to own them is enshrined in the Second Amendment. Instead, other “evidence” was used to infer that they planned violence, including this specific argument that should give everyone pause:

“[…] including their decision to communicate and auto-delete messages on Signal, an encrypted messaging platform widely used among activists, journalists and other citizens wary of government surveillance.”

Collectively, the justice department argued that these convictions are proof that anti-fascists are terrorists, which should also give us pause. The precedent here is obviously very dangerous for freedom of speech, freedom of assembly, and democracy in America.

Then I went up the street to the headquarters of Na Píobairí Uilleann, a beautiful Georgian building on Henrietta Street.

I was there to deliver my talk on the making of The Session. There weren’t that many people there in person but quite a few people watched it live online. You can watch the video of the talk if you want. I’m pretty pleased with it. The few times I played some tunes on my mandolin, the acoustics were lovely!

The next day we took the train down to Cork and onwards to my home town of Cobh. The town was looking its best. The weather was nice and the Queen Anne was docked at the deep water quay.

We spent a lovely weekend hanging out with my mother, including a trip to Cork to see Michael Keegan Dolan’s latest dance piece, Naoi Déag Seachtó Cúig. It was joyous! Normally I’d get irrated by someone in the seat behind me tapping their foot, but everyone was tapping along to the classic first album by The Bothy Band.

On Monday morning Jessica flew back to Brighton, leaving me to spend the week at the inaugural Irish Mandolin Gathering.

When I saw that this event was going to be happening, I thought “I’m going! Wherever it’s going to be, I’ll make my way there.” Then I saw it was happening in Little Island and I couldn’t believe my luck! Little Island is halfway between Cobh and Cork, easily reachable on the local trainline.

So I spent the week having a very pleasant commute. This was when the temperatures were getting dangerously high in England, but remained within reason in Ireland. Whenever anyone at the Mandolin gathering complained about the heat, I couldn’t help pointing out that we were actually in the coolest place in Europe for that week.

The mandolin nerdery was excellent. Lots of deep dives into technique, lots of trying out other people’s instruments, and of course, lots of playing tunes. Seán, Macdara, and Marla did a fantastic job, especially considering that this was the very first one!

The inaugural Irish Mandolin Gathering culminated with a concert at The White Horse in Ballincollig, which was excellent but every time it was mentioned, I had that John Spillane song in my head.

Now I’m back home and feeling recharged from a thoroughly enjoyable week in Ireland. Next time I’ll be there will be for a week of learning Irish at Oideas Gael in Donegal—táim ar bís!

When the The Type Founders worked with Cloud Four last year, it quickly became clear they were that sort of client.

I was already an enormous fan of their world-class stable of foundries. I’ve found their Typographer service indispensable since it was still invite-only. And it was a pleasure to collaborate with such an absurdly qualified team of true believers in the craft of type design, solving problems I’d seen crop up again and again throughout my career.

(It certainly didn’t hurt that type, and specifically usability of leveraging digital type, has been a natural area of interest for me since long before the days of sIFR and cufón!)

So when the time came to wrap up and hand off my UX recommendations, my heart felt unusually heavy. I was having a ball, and there was plenty to implement and iterate on. I wanted to keep going.

Thankfully, the enthusiasm was mutual, conversations continued… and eventually blossomed into a full-time opportunity!

I’ll be TTF’s Platform Experience Director, using my creative and technical skills in service of the typographic arts. I couldn’t be more excited!

I want to once again thank Cloud Four for 13+ years of making a better web together. And a huge thanks to family, friends and colleagues who lent an ear or offered words of support and encouragement throughout this process, it truly means the world to me.

1. This is information they can easily find elsewhere.
2. This is about you, not them.
3. This is boring.

Now, I will describe how to build an All Hands that will exceed their expectations. Let’s define the All Hands:

Everyone. Together.

There’s an important organizational inflection point when you need the All Hands. The basic definition is, “The whole team — together.” If you’re a leader of a team of seven, then you might think your team meeting is your All Hands and — strictly speaking — that’s correct, but that’s your team or staff meeting. Not an All Hands.

The whole team — together. This is a required meeting when the whole team is no longer able to be together organically. Is that 50? Maybe? Is that when they no longer fit in one room easily? Probably? The inflection point varies as a function of the company, but this is a required meeting because it mimics what you did instinctively when you were a smaller team, and that’s a good place to start.

When it’s you, Frank, Aki, Liz, Gigi, and Joshua sitting in the same room cranking on your start-up, what are the events that everyone needs to regularly understand?

1. What is the current state of the business?
2. When has something significant in the business changed?
3. What is important for us to do next?

In the same room, it is relatively easy to gather much of this information. You look around, see that Liz is on the phone closing her new head of engineering, and you think, “Go, Liz! I liked her candidate a lot.” Then you look over at Gigi, who has been quiet for two days and hasn’t smiled in four, and think, “She is the most focused designer in the world. I can’t wait to see what she’s done with our logo.” And so on.

The ebb and flow of information in a group of humans decreases as a function of population size. With growth, your ability to organically discern what is going on within the team decreases¹.

Pick a Format. Keep It.

It’s not just the ebb and flow of information, but the chance that Critical Piece of Information X reaches Correct Person Y. Each additional human creates another opportunity for important information to not reach its intended recipient.

As the senior leader, it’s trivial to forget this simple math because there’s a firehose pointed straight at your face. Your challenge is not the absence of information, it’s the abundance. Your challenge is picking out the signal from the noise while also not drowning.

The firehose is the primary reason for my first piece of structure guidance: pick a format for your All Hands and stick with it. Here’s the format I’ve been using for a couple of decades:

• Hello, let’s learn something.
• Here’s the current structure of the team and how it is different from the last time I showed this structure to you. If something huge changed or is about to change, there is room later to address this, or you can do it now.
• Here’s an opportunity to hear from my direct reports.
• Here’s a special guest.
• No Q&A. I’ll explain shortly.

I’ll explain the intent of each section in a moment, but the important thing to know right now is your structure will be different than mine, and that’s just fine. The point is not following my lead, but consistency. Anyone who receives an invite to this meeting understands broadly what to expect out of the meeting. Senior leaders who randomly do All Hands with fluid agendas at a time that suits them stress the team. When the unexpected and unexplainable meeting shows up, they instinctively think, “Uh oh. Someone’s in trouble.”

Tree Talk

We open with Hello. Nothing fancy. Over the years, a simple hello seemed empty. I wanted to do a little more than say hello while folks were still gathering and getting into the All Hands mindset. At the last gig, I followed Hello with a single slide called “Tree Talk,” where I spent a few minutes teaching the team something interesting about trees. One slide, a few facts. Totally irrelevant to the team, but absolutely essential to the culture.

Why? Because I believe curiosity is an intrinsic motivator. I don’t want the team sitting there as I drone on about things they already know; I want them to see what I care about. I care a lot about trees, but I care more about the team understanding the value of curiosity.

One Slide. What Changed.

This is often the most boring part of the presentation, except when it isn’t. This is a picture of your organization. “The org chart.” Your job is to describe what has changed since the last time you threw this up on the screen with a little color commentary.

• It will feel tactical and obvious, but as I said above, this is because it’s your organization, and it’s likely you were involved in whatever changes occurred. Zero changes? Really? OK, you still show the chart and briefly say, “Hey, nothing’s changed here. Next slide.”
• If massive changes have occurred since the last time you showed this, it’s worth cutting something from later in the agenda below in order for you and your team to explain what changed on the team and why.
• One slide. Never more. Yes, for a large organization, this means you’ll need to simplify or abstract out some organizations into simpler buckets. That’s fine — it just means you have subteams that need their own All Hands.

Not Your Show

The bulk of the presentation is not you, but some or all of your direct reports. What are they going to discuss? Up to them. The greatest hits:

• We built something!
• We learned something!
• Everything changed on the team, and we need to explain.

There are more.

We haven’t discussed the length of your All Hands, and now is a good time. The maximum amount of time is 90 minutes. Frequency? Minimum is once a quarter.

• 90 minutes is a lot of time. In my experience, the average human’s attention span in a meeting like this is 30 minutes, which is why I have the above-suggested agenda. Think of it as three acts. Act 1 sets the table. Act 2 is the heart of the matter — what the team is actually doing. Act 3 brings in the rest of the company — more on that in a moment. Each act gets about 30 minutes. Act 1 runs short unless the building’s on fire, Act 2 always runs long, and Act 3 you can cap.
• Once a quarter is the sweet spot for this meeting. Four times a year. Every month? Overkill and a waste of time. Once a year? Not an All Hands, it’s an Annual Report.

I’m talking timing right now because Act 2’s size is a function of the number of direct reports. Three? They should all have a slot — seven minutes per direct, but they’ll end up using 10. Anything more than three and you’ll need to devise a rotation between directs.

Back to their agenda. You should roughly know what they are going to talk about, but don’t micromanage it. It’s their schtick. If they screw it up, give them feedback.

You’re building the humans who will replace you. All the time. This is one of the many ways you do that.

The Mystery Guest

For Act 3, you want to bring in someone else for a fireside chat. Who? Depends on your team or your company. Start with known folks who are obvious co-conspirators. Folks you personally know with an existing rapport. Write 10 or so questions that you want to ask them, and send them the questions a week before. Warn them that you might go off-script — because you might — and see if they are OK with such vibes.

When you get to the External Speaker portion of the All Hands, sit down next to them and start asking the questions. The most important advice? Listen to their answers. By far, the most interesting bits of this interview are the new things you discover via the conversation.

After you’ve done a handful of familiar folks and have a well-refined set of questions, start asking humans you don’t know. Folks you’ve heard of that the team has worked with, but don’t know. My favorite one? I had the CEO show up once as a mystery guest. Fascinating 30 minutes.

Which reminds me. Tell no one who the speaker will be, except the humans who must know.²

No Q&A?

A controversial take, but an earned one. If I’m doing a talk at a conference, the Q&A portion of the presentation is my favorite. The questions quickly tell me how well I delivered the core messages of my talk. Even the random ones that have very little to do with my talk.

All Hands meetings are a different beast. Yes, it is a series of presentations and, yes, there are core messages delivered, but the large surface area covered in ninety minutes plus the size of the audience usually means questions:

• Feel random, and/or
• Purely serve the agenda of the human asking the question.

However, you must create one more venue for the team to ask questions. Think Slack, your favorite message app, or via staff meetings. Even if you don’t, don’t worry, the important questions will find you.

Entropy Crushing

Being social is work. Especially for engineers. We’d much prefer to be jamming at our desktop. Each time I’ve landed at a new gig where there was no culture of All Hands, I was disappointed by the attendance at first. 50% or worse.

Yes, you can order donuts, and more will show up, but the real draw should be the presentation.

They should leave with the lesson: This is where I will learn.

A regular All Hands meeting is inoculation. You are inoculating your team with quality information. This information will be used to disassemble gossip, rumors, and lies. This information will answer questions before they are asked. This information will remove noise so the human can focus on why they are there — to build.

1. The folks who need the All Hands the most are the ones who are the least able to request it. See, your old guard employees, even in a rapidly growing team, are the best equipped to gather and share signal. This is why when someone new says, “We should do an All Hands,” they react negatively, “Why? That’s a big company meeting, and we’re a small group of high-hustle movers and shakers.” Yes, this meeting is not for the old guard; it’s for everyone who came after them.
2. While I am preaching consistency, with regard to your External Speaker, I like keeping it a mystery because it will, eventually, give your team more motivation to attend. I wonder who it is this time!

People are sharing stories of their graceful encounters with him.

This one is mine.

Back at the beginning of 2021, I set a goal to write 72 blog posts.

I was puttering along, publishing whatever came to mind, mostly figuring that nobody was reading any of it.

But that was ok. The process was therapeutic and it helped clarify my professional thinking, so I kept going.

One day on Twitter I got a DM from someone with the handle @om.

“I don’t know who this is,” I thought, “but damn that is a great handle!”

Then I peaked at the follower count: over 1 million!

“WTF? Who is this???” I thought.

I’d never — then or since — been contacted by someone with such a high profile online.

How was I even on this person’s radar?

I continued on to his message:

Jim I wanted to thank you for your blog. I am neither a developer or a designer but appreciate the web, the open web and in general normal, common sense writing from experts.

I have quietly enjoyed your work — and hope you hit the target of 72 posts in 2021. My highly selfish ask, as I know it will feed my brain good important stuff.

Have a wonderful weekend and a great writing year

I was flabbergasted. Who was this person with such a high follower count saying such kind words and I’d never heard of him?

I quickly went to Google. He had his own Wikipedia.

“Om Malik…tech writer…founded Gigaom!” Ah-ha! I knew Gigaom the company/blog. It shaped a lot of my early exposure to the tech beat. I devoured it. I can still picture the logo in my head!

Now I knew the man behind it. Knowledge unlocked!

I thanked him graciously for taking the time to send a message whose importance seemed incredibly lopsided in my favor.

I quote his message here because I still think about it on occasion. His words then (as well as later ones) continue to lift me up on days when I feel like an imposter. They remind me of the power of a small act of kindness, even within such a vast world wide web.

I still think about his words.

I still think about him.

I’m sure many will for some time.

And that is a legacy.

Reply via: Email · Mastodon · Bluesky

About 3 weeks ago, Leo Laporte and I recorded the first episode of what will be a new monthly show on the TWiT network. Naming things is hard, and we almost voted on the name, like we did for Stack Overflow, but we quickly landed on Off By One with Jeff Atwood – which is funny for so many reasons, but mainly because of this programmer joke:

No, I did not come up with this variation on the classic quote, but I wish I had. Well, whatever, here's show number two – free to view for everyone.

The show is 1h 47m of pure joy end to end. No negativity, just low-level insanity and of course, mandatory fun. We record the next episode in 4 days – and there's a live stream for Club TWiT Members.

(Let's do this. If, and only if, you watched the whole episode and liked what you saw ... for the first 10 people that fill out this form, I'll cover your Club TWiT membership for one full year so you can see if you enjoy the rest of the programming.)

The permanent show homepage is at twit.tv/obo:

Jeff Atwood, co-founder of Stack Overflow and Discourse, creator of the Coding Horror blog, joins Leo Laporte monthly for a conversation that follows its own logic. Prop comedy, computing history, the open web, wealth inequality, yo-yos. Off by one topic at all times, in the best possible way.

This is another way for Leo and I to share our enthusiasm for positive stuff in tech, and sharing is crucial because...

I realized, that’s it. That’s it exactly. That is what is so intensely satisfying about writing here. My happiness only becomes real when I share it with all of you.

Now, thanks to Wesley Faulkner, who introduced me to Leo and recommended I appear on a show, every month we can make our happiness real in a completely different dimension than writing alone – via the expressions on our faces, the tone of our voices, our body language. In other words, you can see and hear how we feel.

Here are 3 key quotes from the second Off By One episode, with linked timestamps, so you can jump directly to that section.

Jeff: I am not an elite coder by any stretch of the imagination... I am very persistent.

Leo: Isn't that funny? Because people... I mean, I think of you as one of the voices, one of the chief voices, in coding

Jeff: Well, I advocate for code that doesn't kill you in so many different ways. You know, survivable code. Ideally, no code at all.

Leo: Right.

Jeff: That's the best code, is none.

Leo: Right.

Jeff: It's a bit of a zen statement but it's true. So, I'm an advocate for, you know, good engineering. Good process. A process that recognizes that we're human and we should do this together, and we should actually kinda like each other, even.

Jeff: Dad's funny. He had kind of a dark sense of humor that I enjoyed. Betsy doesn't like it so much, and not too much, and I get it, but I enjoy it. And I called it "the last season of the John Atwood show". It's gonna be a real banger! And it was, it f***** was, it really was! Because we won capitalism, and then we went back and made it better for everyone. I don't think it gets better than that for me.

Jeff: And the other thing is, you can just run the math on this, I've posted several times on Mastodon and other places like LinkedIn, I've done some research and if we simply collected a fair tax from Billionaires, we could literally elimate all poverty in this country at the 100% FPL level, which is $15,000 per year. All poverty. We would have zero poverty. We have the means to do it.

Leo: That's really important.

Jeff: We lack the will.

If you want to witness the chaotic good of my original guest appearance which led to this show, watch the first 45 minutes of Intelligent Machines #859, recorded on Feb 25th along with Paris Martineau, Jeff Jarvis, and Leo. I dialed down the chaos considerably for the Off By One show, but for this one, I personally think it's funnier to watch Paris' reaction to me for the entire show. You've been warned!

Here are 3 key quotes from this episode, with linked timestamps, so you can jump directly to that section.

Leo: Well in a way it's a shame because we have in the last year kind of stepped back from our global initiatives in the united states and I think we do have a responsibility. I think your partner is absolutely right. If you have everything you need, then help others have everything they need.

Jeff: What is money even FOR? I don't even have "that much", what do you.. how do you spend it all? I don't have.. I just want a simple life, man!

Jeff: I mean.. have you seen some of the stuff LLMs will do when you tell them to optimize? It's like, optimize this for 95% and it's like okay, "return true".

Leo: That's a good optimization!

Jeff: Well, because it doesn't know what it's doing. It has no actual understanding. It's playing a game of global brain statistics and copy paste. And it's good at like, merging... I call it JPEG for words, which it kind of is. And there's so much stuff. It's like reading summaries. And it is very accurate with summaries. We saw this on discourse. They implemented it. I was very skeptical. And I went to some very complex discussions. We had on our internal discourse and read the summary and was like that is a very good summary and it captured the key points in the discussion. It could have captured more, but it got nothing wrong. And it basically was JPEG for that conversation, wasn't it.. without much loss.

Jeff: Now does JPEG work on EVERY image? No. Garfield is a bad choice, for, yknow, JPEG.

Jeff Atwood – Ok, the first guilded age, we're deep in the second one now. I mean, just look up the numbers. More money in the hands of fewer people than in any other period of time. In the first guilded age, that was basically the railroad barons. Guess who it is in the second guilded age? I'm in this picture and I don't like it. So like, what are we gonna do about it?

So thank you, Leo and Wesley, for giving me another way to make happiness real by sharing it with all of you, now in video and audio form, all the feels, all the time. Well, once per month.

Let us know what you think – I don't mind comments here but I'm much more likely to answer on the TWiT community Discourse. Try on a paragraph for size, our old pal the pilcrow ¶. You might even like it! It's possible the practice of writing paragraphs and forming coherent narratives might even improve your overall writing and communication skills. Or your life, even.

I also heard a rumor that any Club TWiT users who make their way from the Discord and post regularly on the TWiT Discourse might get a super cool little token of appreciation in the postal mail from some user named "Junk". Who knows? Who can say what might happen? 🤔

I'll take a closer look at the field-sizing property in another blog post, but I wanted to show you a cool feature first.

By default, the width of a select element is determined by its largest option.

Pick a city Amsterdam Rotterdam Scheveningen Utrecht

<label for="place">Pick a city</label>
<select id="place">
  <option>Amsterdam</option>
  <option>Rotterdam</option>
  <option>Scheveningen</option>
  <option selected>Utrecht</option>
</select>

You can see how the select element here is much wider than the width of the characters in the word “Utrecht”. It’s large enough to fit “Scheveningen”, the largest option. That may or may not be desired. At least, I remember occasions in the past where I wanted it to be only as large as the selected option. With field-sizing that's now possible.

select {
  field-sizing: content;
}

Pick a city Amsterdam Rotterdam Scheveningen Utrecht

Now you can see how the width of the select changes with its selected option.

My blog doesn't support comments yet, but you can reply via blog@matuzo.at.