I've had "All You Fascists (Bound to Lose)" in my song rotation for a little while – for, you know, reasons.

Bette Midler's getting some coverage for her cover, so I thought I'd round up some other versions I like very much.

To begin with, here's that Bette Midler cover:

This Resistance Revival Chorus version with Rhiannon Giddens is probably my favorite: upbeat and alive.

The Billy Bragg version with Wilco is really strong too:

Nina Hagen's father Hans was a Holocaust survivor held at Moabit, and her paternal grandparents were murdered at Sachsenhausen. This is therefore a very personal cover:

Here's Ani DiFranco with Zoe Boekbinder, Gracie and Rachel, and Diane Patterson - all artists I love:

And finally, here's the great Woody Guthrie, one of my heroes, singing the original:

Actually reading RSS feeds

I’ve been trying to follow weblogs and news via RSS for ages. And I’ve tried various ways of coping with the endless stream of updates. Different apps, different ways of stucturing my feeds, but with all of them I quit using feeds after a while. There was just too much to read, and I basically gave up.

The Hans de Zwart method

My colleague Hans de Zwart explained me his simple but effective RSS-feed method: Some feeds are in the morning directory, others in the daily, and the rest is in the weekly folder. I’ve been using this method for a while now and it works, kinda.

Be picky

Every morning I open the morning directory and click on a feed that has new items. Then I choose what to read. And that, for me, is the whole trick. I always tried to be complete, read every article in order of arrival. And now I just pick the stuff that sounds interesting, from one feed at a time, and read it.

In the evening I open the daily folder and read the items that seem interesting and ignore the rest. The only thing I haven’t figured out yet is on what day should I read the weekly feeds? My weeks aren’t structured enough to follow a strict weekly regime. Maybe I should call this directory (ir)regularly.

A friend and I were talking about AI and the question of where I lie on the spectrum came up: “I’m now on the handmade, artisanal, craftsperson end of the spectrum.”

A client project recently moved into the LLM layer. Some of the team had already been working with an LLM to wireframe and prototype some aspects based on my initial Figma designs. I’m far more judicious and faster (it is my design to be fair), but it’s interesting to see how Figma Make and Claude extrapolate my basic design system file and screens into primitives and code. Things got... lost in translation. Extraneous primitives, too many primitives, borders got ignored. The results look like the blurry part before something comes into sharp focus.

When I was a little kid, all I wanted to do was draw and make things. I drew characters from movies and cartoons. I later kept at it through the art I’d experience in skate culture, and eventually music. That through line is knowing how to draw the line, knowing when to stop, dig in, turn the pencil to make it thicker, release pressure to make it lighter. All in the hand, through years of practice, and experienced intuition.

Decades later, I still love the drawing. When something goes off the rails, the hand can guide it back to a path, or work with the line to form something completely new.

→ This looks better on the web
→ Reply via email

Thanks for reading and using RSS!

CSS anchor positioning isn’t baseline yet, and there’s good reason for that. You can use it, but it comes with some caveats. James, Stacy, and Miriam cover new resources to make anchor positioning easier, and work through some demos to help you understand how anchor positioning works. We also look at what new capabilities are in the pipeline.

Subscribe to Channel »

• Don’t ignore the containing block.
• Do get excited about future things.
• Do try it. Many paths work.
• Don’t be surprised if something doesn’t work, but ask whether it’s baseline.

• Absolute value CodePen
• Clamping CodePen
• Select flip CodePen
• Element.matchContainer()
• Allow anchor() within shape()
• Anchor Positioning in Space
• Shadow DOM CSS - Anchor Positioning

Turns out, no.  I could use, and often have used, Firefox’s “Screenshot node” menu entry in the web inspector, or the :screenshot command in Firefox’s console, but not do it with an in-page button.  Because HTML nodes don’t go in <canvas>, you see, let alone styled and scripted ones.

Or they didn’t, until just recently, when Chrome shipped a flag-gated preview of the HTML-in-canvas API.  How it works is, you add a layoutsubtree attribute to a <canvas> element, and then you can put whatever HTML you want in there, with whatever CSS and JS you would normally apply to it, add a couple of magic JScantations, and what the browser would normally have painted to the page is painted to the canvas, at whatever speed the browser can manage (usually 60 frames per second or more, because web browsers are high-end first-person scrollers).

If you want to try all this out for yourself, I commend you to Amit Sheen’s “The Web Is Fun Again” over at the Frontend Masters blog, where he details how to get yourself set up for the wackiness this makes possible, and then shows some experiments.  Water ripples over your pages, lens distortions that follow the mouse pointer, chromatic aberrations!

Which, I admit, all sound really off-putting to the “I just want to use the web” folks among us.  What possible utility is there in having an input form that, say, makes ripples spread out from every character you type?  Or having dropdown menus fall to the bottom of the page, but still actually work?  Probably not a lot, unless you’re an expensive design studio working on a brag page.

But remember, this is how any new graphic advancement goes: we, by which I mean the collective web industry, start by doing really outré and eye-catching stuff that we later have cause to regret.  Remember parallax scrolling effects?  The early days of CSS animation?  Drop shadows?  There will be an initial period of excess, and then it will all settle down.

I’ve already skipped straight to the settle down part, though.

See, when I asked myself if I could render HTML+CSS on a <canvas> and then save the image to my computer, it wasn’t just me doing that “push at the limits of web features” thing I do sometimes.  I had an actual, practical use case in mind: I wanted to save social media banners and thumbnails from a browser-based tool I built for my work at Igalia, just by clicking or otherwise triggering a button.

If you’re subscribed to our YouTube channel, you’ve seen these thumbnails; ditto if you’re following us on Mastodon or Bluesky.  To produce those, I have an in-browser thing I built out of custom elements.  It’s where the super-slider pattern developed (though they have a different name in the tool).  I’m not going to link to the tool because it’s on our intranet and very few of you have a login, so here’s a screenshot of it in all its dweeb-designed semi-glory.

The text bits in the banner are all contenteditable HTML elements, and the various themes are managed with various blocks of CSS.  (And yeah, those range inputs are all “super sliders”.)  The point of all this being, I built it so that anyone at work could use it to make banners whenever they needed, without having to wait on me to do so.

What I’ve always wanted, in order to make things easy for anyone who isn’t me, is a “click this button to save the banner as an image” feature.  Anyone at Igalia could easily learn (if they didn’t already know) the web-inspector-or-console stuff I was using, of course, but it just felt so janky.  A touch embarrassing, if I’m being honest.

Well, now I have what I wanted.  In any browser that supports HTML-in-canvas, there is a button labeled “Download banner image”.  Right now, that’s recent Chrome with the proper developer flag enabled.  For all other browsers, there’s no button, and you just use the same web inspector screenshot tricks we’ve always relied on.

Making this happen wasn’t as easy as maybe that sounded, though.  I hit a couple of snags along the way, one of which was quite frustrating.  Those are what I actually brought you here to talk about.

The first snag was that I had to get the thumbnail preview into a <canvas> element without blowing the call stack.  To explain that, let me show you a rough skeleton of the tool’s markup.

<section id="youtube_talks">
	<thumb-panel class="text"> … </thumb-panel>
	<thumb-panel class="colors"> … </thumb-panel>
	<thumb-panel class="highlightImage"> … </thumb-panel>
	<thumb-panel class="backgroundImage"> … </thumb-panel>
	<thumb-panel class="icons"> … </thumb-panel>
	<thumb-panel class="scaler"> … </thumb-panel>
	<thumb-panel class="loader"> … </thumb-panel>
	<thumb-preview> … </thumb-preview>
</section>

As you can read, it’s basically all custom elements, each with their own connectedCallback() function to do whatever scripting magic needs to be done when the browser first encounters them.  To wrap that last element, the <thumb-preview>, inside a <canvas>, I needed to create a new canvas element, shift the preview element into the new canvas, and then insert the preview-bearing canvas, ending up with this structure.

<section id="youtube_talks">
	<thumb-panel class="text"> … </thumb-panel>
	<thumb-panel class="colors"> … </thumb-panel>
	<thumb-panel class="highlightImage"> … </thumb-panel>
	<thumb-panel class="backgroundImage"> … </thumb-panel>
	<thumb-panel class="icons"> … </thumb-panel>
	<thumb-panel class="scaler"> … </thumb-panel>
	<thumb-panel class="loader"> … </thumb-panel>
	<canvas layoutsubtree>
		<thumb-preview> … </thumb-preview>
	</canvas>
</section>

Thus, when the <thumb-preview> was loaded in, I had its connectedCallback() run a check to see if HTML-in-canvas is supported.  In situations where it is supported, I did what was needed to get to the above result.

At which point, since the <thumb-preview> is a custom element that was being placed into the DOM, it fired its connectedCallback(), thus starting the process again, creating a canvas and inserting the <thumb-preview> into the new canvas, which started the process again, recursing toward infinity.  Within milliseconds, the call stack was exceeded.

So… that wasn’t going to work.

I thought for a moment that I could avoid this by setting a flag variable to true and then checking for its existence in order to skip the whole canvas-creation-preview-insertion part, but I couldn’t figure out how to make that actually work.  Then I thought maybe I could sidestep the whole imbroglio using connectedMoveCallback(), but this wasn’t a move, it was a (re-)creation.

That callback was the route to fixing this problem, though.  You see, there is a way to move elements from one part of the DOM to another: Element.moveBefore().  There’s no moveAfter() or moveInto(), sadly, just “move this node to the spot right before some other node”.

Here’s how I made use of that feature:

let canvas = document.createElement('canvas');
canvas.setAttribute('layoutsubtree','');
canvas.setAttribute('width','1280');
canvas.setAttribute('height','720');

this.closest('section').appendChild(canvas);

let beacon = document.createElement('span');
canvas.appendChild(beacon);
canvas.moveBefore(this,beacon);
beacon.remove();

Yep.  I created a canvas, stuck the canvas into the closest ancestor section, created a span, stuck the span into the canvas, moved the preview element to right before the span, and then deleted the span.  (There may well be a better way to do this, one that my DuckDucking failed to turn up.  If so, please comment below!)

Oh, and here’s what gets executed when the preview is moved, instead of append-created:

connectedMoveCallback() {
	return;
}

Heckuva way to run a railroad.

At that point, I had the canvas where I wanted it and the preview where I wanted it, and the call stack remained un-blown.  Huzzah!  I then recited the magic JScantations to make the canvas actually render its subtree (see the “Web is Fun Again” article I linked earlier for details on this), and hey presto, DOM was being rendered into a canvas!  Then, when I clicked the button, the canvas was rendered as a PNG and my browser downloaded that PNG!  I had what I wanted!

Almost.

Because the second snag, you see, is that canvases have an explicit size.  Are in effect required to do so, because otherwise they default to zero pixels tall and wide.  So if you want to see anything, you need to give them some dimensions.  I did that, as the code before showed, making the canvas 1280×720 (YouTube’s recommended thumbnail size) through setAttribute() methods.

The problem is, the default scale factor on the thumbnail preview is 0.75, which translates to 960×540.  Thus, when I clicked the image capture button, my browser downloaded a 1280×720 image with the thumbnail in the top left, and transparency below and to its right.

“Just resize the canvas, ya dork!” you might say.  I certainly did (say that, I mean).  But if I set it to 960 wide and 540 tall, then when the scale was increased to 1, I got a 1280×720 DOM node cropped to its top left 960×540.  I needed to dynamically resize the canvas element to have its size match the size of the thumb-preview.

And this is where I ran headfirst into several brick walls, because orcing a canvas element to resize in all the situations you want it to, including when it’s spawned, is not nearly as easy as you’d think.  It wasn’t for me, anyway.  I bulled my way through to a solution, eventually, painfully, but I got there.

(As I write this, I’m wondering if I should have also created a <div>, appended the canvas to that, and then used CSS to change the div’s size while the canvas was set to have 100% height and width.  Or maybe have the DOM subtree pinned to 1280×720 and use CSS scale to change the canvas size visually.  Or perhaps some kind of resizeObserver shenanigans.  Or probably just pass some parameters to the HTML-in-canvas drawElementImage method.  Hmmm.)

Regardless of whether I overlooked a less frustrating way do what I wanted, this does still point to a fundamental tension in the HTML-in-canvas approach: sizing.

Canvases do not, as a rule, grow or shrink to fit their contents.  DOM elements, as a rule, very much do, unless you force them not to.  HTML-in-canvas is taking a very fluid, flexible, mostly unbounded layout paradigm and rasterizing it, or at least some of it, into a very bounded window of a given size.  Sixty times (or more) every second, the browser is taking a screenshot the size of the canvas’s content box and pasting said screenshot into that content box.  You can do fun stuff to it along the way, with filters or shaders or canvas draw calls or whatever you can code up, so that each one of those screenshots gets jazzed up in some fashion, but at base, it’s still fundamentally screenshot, paste, screenshot, paste, over and over.

For use cases like mine, this isn’t really a big problem.  I am, in the end, trying to get a screenshot of a static part of the page.  HTML-in-canvas is very good for that.  It could completely revolutionize the browser-based slideshow genre.  The Reveal.js plugin landscape alone could be a sight to behold.

But in the general cases — the kinds of things we mostly do most every day — I don’t think this is likely to catch on.  We might develop some patterns to make it easier, some interesting hacks to overcome the mismatch, but I don’t think that will significantly move the needle.  On the other hand, if canvases can be made as flexible and content-wrapping as a bog-standard <div>, then I would expect to see a lot more usage.

Although if that can be done, then we wouldn’t really need to stay chained to HTML-in-canvas.  Instead, we could define a syntax to mark standard HTML elements as more visually manipulable, via an HTML attribute or CSS property or DOM method or all three.

We’ve gotten close to that before: CSS Houdini and Microsoft’s original filter property, to pick two examples.  We could try again.  Maybe the HTML-in-canvas period is how we figure out what that simpler syntax should look like, by figuring out what it should make possible, and what it should make easy.

I’d be okay with that.  How about you?

Many thanks to my colleagues Brian Kardell and Stephen Chenney for their early review and feedback on this post.

Have something to say to all that? You can add a comment to the post, or email Eric directly.

Faster individuals don’t make a fast company

My mind immediately went to the 4✕100 relay at the Olympics.

(Not sure which race that is? Watch the London 2012 one.)

Imagine you were put in charge of winning the 4✕100 relay.

All you gotta do is find the four faster sprinters in your country — right?

I’m no track and field expert, but I doubt it’s that simple.

In a relay race, the baton is arguably the most critical element. Passing it cleanly is vital because if you fumble it you’re easily behind a few meters or maybe even disqualified.

So, one could argue, a sprinter’s ability to pass and receive the baton is more important than speed because all the speed in the world won’t help you overcome a dropped baton.

(There are other considerations too, like which leg each runner takes, which sequence works best given individual pairings and rapport, and whether a slower veteran might perform better in the heat of the moment.)

Faster runners won’t guarantee a faster team.

And faster coders won’t guarantee a faster company.

Like a relay race, it might be worth giving some thought to the relationships and interfaces between people.

Reply via: Email · Mastodon · Bluesky

Here's some rad CSS that just hit baseline between October 2025 - April 2026.

At this point with the following features, the "I can't use it" vibe can shed away.

Anchor Positioning #

Anchor positioning lets you natively tether components to target elements without adjusting DOM semantics or crowding the main thread.

This widget doesn't show green across the board as of writing this, there are sub features that aren't all supported, but the general featureset is ready.

Checkout Tab's talk about anchor called Anchor Positioning at CSS Day 2025.

Checkout my post on AIM if you missed it, neat anchor technique for FLIP-like transitions with anchor.

@scope #

CSS selector scoping, not style scoping; a common misconception.

However! With @scope we can simplify naming conventions or robobarf classnames just to avoid global cascade collisions.

The "donut" feature is very special, it can limit styles from cascading into nested components by setting an end to the selector (a donut hole 🍩).

Chris gave a talk about @scope called Scope In CSS at CSS Day 2025.

Name Only Container Queries #

@container no longer requires a size condition.

You can now conditionally style elements just by name:

.sidebar {
  container-name: sidebar;
}

.card {
  display: grid;

  @container sidebar {
    grid-auto-flow: column;
  }
}

• Chrome 149
• Safari 26.4
• Firefox 148

Chris wrote a good post about it over on FrontEnd Masters.

shape() #

Responsive, native CSS geometry.

Draw complex clipping paths using standard CSS syntax and dynamic units (like rem or calc()) instead of being locked into rigid SVG pixel coordinates.

Temani wrote a rad post about it over on FrontEnd Masters and a "complex" post CSS-Tricks.

shape-outside with xywh() and rect() #

Wrap inline text around precise geometric boundaries with xywh() and rect().

Typographical control over floating text flows without relying on images or clip-paths.

• Chrome 150 (soon)
• Safari 18
• Firefox 149

Still no pretext, but also still coo.

view-transition-class and Types #

SPA-like routing animations.

With view-transition-class you can target massive collections of DOM nodes with a single animation rule, while JS View Transition Types let you programmatically direct "forward" or "backward" contextual motion.

rcap, rch, rex, ric #

Even more typographic precision.

I wrote about these here.

I’m going to put my neck on the line on this story about Matt Mullenweg’s criticism of Wordpress’s open source release culture:

“WordPress co-founder Matt Mullenweg has delivered a wide-ranging critique of the WordPress project, saying it has spent years doing damage to itself and calling out a release culture he says produces ‘boring or mediocre crap.’”

It goes on to describe Mullenweg’s frustrations with an open source culture that prevents anything being released without a wide-ranging discussion that brings dozens of people into the thread.

“We are not being killed by competition, I believe we have done this to ourselves. We did it by blindly following rules and ideals to a point when they became iatrogenic. […] By definition the things that will give us the biggest wins will be the most non-consensus, so we have to accept the occasional failure or mistake otherwise we will never have any wins.”

So here’s my controversial statement in 2026: on these points, Matt Mullenweg is completely right.

This bureaucratic, consensus-driven culture has also been a blight on other large open source projects, for example at Mozilla. Contributions should be made quickly, and product design should be opinionated rather than consensus-driven. The more a project seeks consensus, the less able it is to innovate.

That doesn’t mean it should be a fiefdom or a dictatorship. Governance structures have been well-established by co-operatives and similar organizations that allow people to be elected into key roles; if they underperform, the voting base can support someone else. But it’s far better to put your trust in an architect — and achieve consensus about that trust — than it is to try and reach broad consensus about every change. Otherwise it’s not just that nobody wants to try bold new ideas; they literally can’t.

This is distinct from web standards, for example, which need a consensus basis to prevent a single vendor from dominating how interoperability works. For example, Mozilla’s objection to the web Prompt API that Google proposed is good; that’s how those systems should work. But for an individual software project, moving quickly and genuinely innovating are vital.

Dave Winer has another take: that WordPress should be more of a platform and allow different people to build opinionated interfaces on top of it. I think that makes a ton of sense too; in that world, WordPress can be an ecosystem monolith, and the opinionated innovation is left to smaller entrepreneurs. That, to be honest, might work a lot better.

In my case, I use Ant Design in a side project, and want to be able to use router navigation with Ant’s Button component. Passing a resolved href prop technically works, but it will be a browser navigation (including a full page reload), and not a router navigation.

import { Button } from 'antd'

// 😐 Kinda works, but triggers full-page navigation
function MyComponent() {
	return <Button href="/item/1234">Jump back</Button>
}

Approach 1: imperative routing

In its documentation, Next.js mentions “imperative routing”. It would look like this:

import { Button } from 'antd'
import { useRouter } from 'next/router'

function MyComponent() {
	const router = useRouter()

	return (
		<Button onClick={() => router.push('/item/1234')}>
			Jump back
		</Button>
	)
}

The problem with this approach is that it will render a <button> element, which is not semantically correct and an accessibility faux-pas. This is not actually a button, it’s a link to another page, and as such should render an <a> element.

Approach 2: headless link

The second approach, which I opted for, is to use Next’s <Link> as a headless component — that is a component that doesn’t actually render DOM. This is how to do it (and still works in Next.js 16):

import { Button } from 'antd'
import Link from 'next/link'

function MyComponent() {
	return (
		<Link href='/item/1234' passHref legacyBehavior>
			<Button>
				Jump back
			</Button>
		<Link>
	)
}

There is a lot going on in Next’s code, so here is the summary:

• The legacyBehavior prop resorts to cloning the child element. On its own, it basically does nothing.
• The passHref prop assigns the href prop onto the child.

So if you use only legacyBehavior, nothing happens because all it does is clone the child element. And if you use only passHref, it renders a <button> element (from Ant) within a <a> element (from Next), which is not what we want. It’s by combining both that we get it to render an Ant <Button> component rendering a <a> element, using Next’s routing logic.

Making a reusable component

It’s something I’ve used often enough in the project that I resorted to create a small wrapping component for that:

import { Button, type ButtonProps } from 'antd'
import Link, { type LinkProps } from 'next/link'

export type RouterButtonProps = Omit<ButtonProps, 'href' | 'htmlType'> & {
  href: LinkProps['href']
  linkProps?: Omit<LinkProps, 'href'>
}

export function RouterButton({ href, linkProps, ...props }: RouterButtonProps) {
  return (
    <Link href={href} {...linkProps} passHref legacyBehavior>
      <Button {...props} />
    </Link>
  )
}

And it can be used like this:

<RouterButton
	// The `href` prop is handled by the Next link
	href="/item/1234"
	// Occasional and optional link props can be passed
	// See: https://nextjs.org/docs/app/api-reference/components/link#reference
	linkProps={{ onNavigate: () => track('jump_back_click') }}
	// Everything else goes to the Ant button
	// See: https://ant.design/components/button#api
	type='primary'
	ghost
	block
	className="MyButton"
>
	Jump back
</RouterButton>

And of course, it renders what we expect: a single <a> element, benefiting from Next routing navigation, styled as a button. No invalid DOM, no full page reload. Neat!

Six of those eight security reports turned out to be valid vulnerabilities. The resulting Kirby 5.4.0 release ships with a list of advisories that reads less like a changelog and more like a triage report. Nothing critical, nothing exploited in the wild, luckily – but for a small team that has been quietly maintaining a beautifully designed CMS for more than a decade, this is unlike anything they’ve had to deal with before.

And Kirby is far from alone.

A few weeks ago, Anthropic’s red team described how their large language model Claude Opus, pointed at a handful of open source projects, autonomously found and validated more than 500 high-severity vulnerabilities – some of them in code that had been aggressively fuzzed and reviewed by humans for years. Earlier this month, the same kind of work went public in a much bigger way. Project Glasswing, Anthropic’s partnership with AWS, Apple, Google, Microsoft, the Linux Foundation, and roughly forty other organisations, uses an unreleased model called Claude Mythos Preview to find vulnerabilities in the software that runs pretty much everything. Thousands of zero-days. Including a 27-year-old bug in OpenBSD, an operating system famous for its security hardening. A model, Anthropic says, capable enough that they have decided not to release it.

There is, obviously, a marketing layer to all of this. Glasswing is a beautifully staged announcement, complete with partner logos and a butterfly metaphor. Independent researchers have pointed out that the list of CVEs directly attributable to the project is, at the moment, much shorter than the headline numbers would suggest. And there are legitimate antitrust concerns about a private consortium of the world’s largest tech companies having exclusive access to a tool like this. And yet, if you look around, even the more sceptical voices in security seem to be treating this as a genuine inflection point. Rich Mogull at the Cloud Security Alliance has been calling it the “Vulnpocalypse” – the moment when language models can find zero-days and write working exploits faster than we can patch them.

What this means on the ground, for the people actually maintaining the software, is a flood.

In January, Daniel Stenberg, who has maintained curl for nearly three decades, shut down the project’s bug bounty program because he and his security team were drowning in AI-generated slop. A few months later, the slop receded. But it was replaced by something harder to dismiss: genuinely good security reports, almost all done with the help of AI, arriving at a frequency his team has never seen before. The quality went up. The workload did not go down.

And that’s the problem: generating a finding is cheap. Validating and patching it is not. And that cost then falls entirely on the maintainers – on people like Bastian and his Kirby team, on the Linux kernel reviewers, on the handful of volunteers who keep the dependencies of the dependencies of the dependencies alive. If the only realistic answer to machine-speed discovery is machine-speed triage and patching, then the maintainers who are drowning in reports don’t just need more time and more hands – it feels like at some point, they will need the same kind of tooling that is drowning them. The tool is both the flood and the pump.

But the pump has a price tag. Right now, that pricing is softened by subsidy – the big AI companies are losing money on every query while they compete for market share. When prices adjust – and they will, in fact, they already are – the bill lands somewhere. Big companies will pay it without flinching. The corporate security industry is already busy selling them tools to handle attacks “at machine speed” – agentic AI, autonomous SOCs (security operations centres), hyperautomation platforms. But who pays the bill for a small team like Kirby’s, or the maintainer of a Craft CMS plugin, or the PHP library three layers down that half the web quietly depends on? All of this is also going to become a governance question for open source, and I don’t know whether we have an answer yet.

And ultimately, we, as an industry, are the downstream.

I run Kirby in several client projects and I trust the team and their work. Every time a security release lands, I update quickly and quietly, usually covered by a reasonable maintenance retainer. But the cadence is changing. The usual “let’s skip a few minor updates to save the budget for the bigger ones” will probably not hold up anymore – at least not if you care about security, which you should. And for each update, someone has to read the release notes, test the update, and push it to production, ideally the same day. That is going to become a much more explicit part of the conversations I have with clients.

And of course, it’s good that these bugs are being found. And they need to be fixed. The 27-year-old hole in OpenBSD was there all those years – we just couldn’t see it. Making bugs visible is a gift, even when the gift arrives wrapped in a pile of work. But visibility is only the first step. What matters is whether we can really close the gap between finding and fixing – and whether we, as clients, as agencies, as developers, as a community, are willing to fund, staff, and support the people doing the work.

But also: what can we do, together, to make the software we depend on more secure? In budgets, in update routines, in client conversations, in the way we contribute to and pay for the projects we use every day. I will see Bastian at beyond tellerrand Düsseldorf next week and we’ll certainly talk about all of this a bit. But I know I’ll also be having that conversation with every one of my clients in the coming weeks. And I’d love to hear your thoughts on this as well: how does it all play out for the projects and websites you maintain?

The search engine no longer says “here, go read what this person wrote.” It now says “here, I’ve already read it for you.” The contract is broken.

He’s absolutely right.

But…

Have you ever clicked on a result from a search engine? Unless you’re lucky enough to land on a nice personal website, you’re more than likely to be confronted with pop-ups to allow tracking, or a desparate plea to subscribe to a newsletter, or just rubbish ads all accompanied by a slow page loading somewhere in the mix.

Don’t get me wrong. I’m not saying that what Google is doing is okay. But let’s not pretend that everything indexed by Google is just fine and dandy for people to visit.

And of course the main reason why websites are so terrible is because they’ve tied their business model to heaps of behavioral advertising driven by invasive tracking courtesy of …Google.

This reminds me of AMP. Remember Google AMP? It was a terrible solution to a real problem. Web pages were (and still are) bloated and slow. The correct solution would be to encourage people to fix that, but instead Google mandated a proprietary format for your content that had to be hosted on their servers.

AMP was a disaster, both in practical terms and in the reputational damage it did to Google’s developer relations.

Now they’re doing it again, powerwashing away any goodwill they ever had with site owners. Now Google doesn’t even send search engine traffic to the websites that host the ads that Google encouraged people to put on every page.

It’s almost as if Google is a company so large and with so many competing interests that it now suffers from an incurable split personality disorder.

Personally I think they’re missing a trick. They should be using “AI” summaries as a stick.

If your site is slow, or filled with user-hostile annoyances then it should be cockblocked by a hallucinated summary. But a nice fast respectful website? Send the traffic their way! Everyone wins—users, site owners, Google, the World Wide Web.

Could you imagine how quickly this would revolutionise the world of search engine optimisation? They’ve always told us that we should make websites for humans in order to get good Google juice. This would be a way of making it come true, without any of the over-engineered woefulness of AMP.

It’ll never happen of course. But I can dream.

Subscription Cost Visualizer is a lightweight, interactive tool that turns your subscriptions into a visual grid. Instead of a list of numbers, you get a clear, proportional view of where your money is going—larger blocks represent higher costs, making your spending instantly legible.

Hello, Simple Friends. Today, we're announcing the official release of our latest typeface, Beeswacks!

Beeswacks is a vintage-esque, display sans-serif based on a handful of letters found on an old box of candles made by Columbia Wax Works in Ozone Park, New York. Like a lot of other old lettering, this one spoke to me, particularly the wide M, R, and S.

We took those capital letters as guidance in filling out a whole alphabet that retains the worn, hand-painted vibes from the candle box. Beeswacks will be fantastic for logos, posters, signage, branding, etc.

Beeswacks comes in a single weight and includes upper & lowercase letters, numerals, punctuation, diacritics with expanded language support, as well as some alternate character icons and script-y, discretionary ligatures for the words the, of, in, at, and, for.

Beeswacks is available now, individually in our shop or join our Secret Club™ and get ALL of our 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 our next Studio Notes™.

Cheers!

As I watched the teaser trailer for season three of Silo, I discovered that I am very much looking forward to this new season. July 3, 2026.

Tags: silo · trailers · TV · video

Web tools

Web tools are web-based tools, obviously. Used in a web browser without a download. Some may be installed as progressive web apps but I prefer a progressive browser tabs. Most tools do one thing and do it well. Some of my links are actually just text information, but “web tools and documentation and specifications” is a mouthful.

All the tools I’m collating are related to web development. I’d guess I use Squoosh the most, followed by Can I use or this specificity calculator (there are many, I like that one.) Stu Robson’s ReliCSS is a new addition that looks very useful.

I realise now I’m not hosting any web tools myself. Many moons ago I maintained a few NPM packages that did stuff (grunted, mostly). Web tools are so much better. Less malware, for one. I once hosted a to-do app, but who hasn’t? That reminds me, sub-domains are the secret to hosting side projects. I must stop buying short-lived project domains.

Anyway, I should build a web tool. Any ideas?

Do you have any favourite web tools I should be aware of? I’m not looking to list everything, just stuff I might personally use.

P.S. This is definitely not another bookmarks project I’ll forget about.

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

I love traveling to new places and getting to enjoy new experiences. And as much as I love travel, it can be chaotic.

A friend once said that if you’ve ever tried to meditate and failed to quiet your jumbled mind, you should take a trip instead. 

Because when you travel, your entire world distills down to finishing a single task to keep yourself safe and alive, letting everything else fall away (just like meditation!).

First, you have to find your plane. Then you have to find your luggage. Next, you have to find your hotel. Then—surprise!—you need to find dinner at 9pm in a city you’ve never set foot in. Good luck!

So here's a bunch of tips I use to keep the chaos at bay, to feel more at home when I'm traveling, and bring some semblance of control back into my time in new places.

Have a dedicated electronics travel bag

I put this off for years and it wasn't until last summer when I finally bought a dedicated bag to hold all my electronics that is ONLY used for travel. I've stuck to my promise to never touch anything inside my bag when I'm at home, so it's always fully stocked and ready for a trip. This has been such a game changer.

Here's what's always in the bag:

• A wall charger with 4 high-speed usb-c charge ports
• Two usb-c to usb-c cables
• A couple usb-a to usb-c cables because you never know what a rental car or hotel room might have for extra charge ports
• A usb-c to lightning cable for my headphones
• A usb-c to Apple Watch charger in a 3D printed case to keep things tidy

For each trip I add these things from home:

• A Bivo water bottle that fits in the bottle slot in the bag
• My iPad Pro with Magic keyboard (I only bring a laptop when I must for work, otherwise this is enough)
• AirPod Max headphones for noise canceling on the plane, AirPods 4 headphones for walking around

I also recently added two new things to the permanently-in-the-bag pile.

Take an old AppleTV and HDMI cord with you

The AppleTV is my absolute favorite set-top box and I have two of them at home. I tend to upgrade them whenever a new version comes out, so I have a few older AppleTVs laying around and I recently started bringing one with a power cord and a short HDMI cable with me on trips.

Every hotel I stay in has a modern flat screen TV but it's rare for them to support any screencasting technology (maybe 1 in 10 hotels have this feature in my experience?). But every hotel TV has a HDMI port and I've yet to have any issues plugging in my own AppleTV while using my phone as the remote for controlling it.

If you use profiles on your AppleTV, you can even make your travel AppleTV mirror exactly the same apps you have at home. This means after a long day, you'll get a little slice of home wherever you are, and you can keep up with shows before you drift off to sleep.

But how do you connect it to the hotel's wifi?

Use a travel router

I've heard about the benefits of a travel router for years but it wasn't until last month that I finally picked up a Beryl 7 travel router and after a couple trips, I wish I bought it sooner.

First, they're great for sharing a connection with all your devices, which means gadgets like an AppleTV or Apple Watch that can't connect to a hotel's WiFi now get can get online. It also means you can buy WiFi on a plane for $8 and share it with everyone in your party if you want.

A travel router has a couple ethernet ports but also a couple wifi points inside it. It's got flexibility so it can take any outside internet connection and funnel it into its own WiFi point that all your devices connect to normally with a simple password.

Here's how it works:

• Plug it into usb-c power and give it a few seconds to boot up
• Connect to the router's WiFi and pull up its own internal website (the default is at http://192.168.8.1)
• Use the website's wizard to log into whatever system you're trying to connect to, including hotels, planes, trains, or cruise ship wifi
• Once you're logged in, anything connecting to your travel router shares a single outside connection

You can do more things with a travel router like share files and tunnel all your connections through a VPN but at its core, getting to share one connection with all your devices is really handy.

Install Tailscale at home and setup an exit node

I've said it many times before but Tailscale is the glue that holds my tech stack together, and you can level up your travel experience by installing it at home onto an always-on device like a desktop Mac, Raspberry Pi, or an AppleTV (in my case it's on a Synology NAS server).

Next, set up an Exit Node so you can pipe all your traffic through your house connection, no matter where you are.

I bring this up because whenever I travel, I like to unwind before bed by watching an hour or so of TV and movies. 

But I remember one trip to Vancouver where I popped open my laptop to finish a show I was watching at home, and instead I got an error that I couldn't view it because it’s wasn't available on Canadian Netflix.

The worst experience was when I was flying into SFO and I spent most of the flight watching a Golden State Warriors game using my $17/mo NBA League Pass, but we landed with ten minutes left in the game. I pulled it up on my phone once I got into the terminal but all I saw was a blackout screen blocking playback and I missed the end of the game I'd watched for the past 90 minutes.

I get that companies have complex broadcast rules governed by your geo-location but I pay streaming services hundreds of dollars a year to use them and last week when I got a cutesy error on the Peacock app while trying to watch a baseball game, I felt like I, as a customer, was being treated like a child. It's patronizing and annoying as hell.

The good news is that if you use an app like Tailscale, you can avoid this when you travel, because you’ll be able to do everything you can at home, as you'll actually be sharing your home's IP address when you connect your phone or AppleTV to your Exit Node. Everything you use will be exactly as if you were at home, no matter where you are on earth.

Bonus tip: If you run a network-level adblocker at home like Pi-hole or Adguard, you can set Tailscale to use that as your DNS server. So that means the setup I have to keep ads off for anyone using my home network works outside of my house too, since my phone is always connected to Tailscale.

Now, when I read the New York Times (that I also pay for!) on my phone while I'm out and about, all the movie ads and junk in the middle of articles is gone, just like when I'm on home WiFi.

The old internet classic: use the pants hanger hack to sleep in

I don't remember where I first heard about this but it was probably around 2008 or so. You've probably have seen this tip, but if it's new to you, you're in luck because it'll change your life while traveling.

Most hotel chains have blackout curtains but they always seem to not quite meet in the middle correctly. So you get a searing beam of light piercing your eyes at 7am when you really wanted to sleep in and feel well-rested after a long flight.

The next time you travel, look for a hanger in the hotel closet with spring-loaded clasps for hanging pants, and use those to clamp the blackout curtains tightly together the night you get into your room. Then put the do not disturb sign on your door.

The next morning, you'll sleep like a baby.

Two classic apps I never travel without

Speaking of internet classics, there are two apps I've been using every time I travel, one for over 10 years and the other for 20.

The oldest one is TripIt, which I joined when it launched in the 2000s and all it does is check your email for travel-related confirmation emails, then adds them to your calendar along with all the confirmation numbers and addresses and proper flight times. It's worked flawlessly for years doing that one function very well.

The other app is FlightAware. I run the iOS app and any time you fly, you put in your airline and flight number and it'll show you the flight history over the past few days, how often the plane was late, etc, but there's a button marked "Where is my plane?" that you can hit on the day of your flight and see in realtime exactly where your plane is located, and quickly determine if your flight will leave on time, or if it's backed up from three late arrivals earlier today. Honestly, this little app gives me more information than the airline ever would, and I love it to death.

Last one: every hotel has room service thanks to food delivery apps

I've never been a big user of DoorDash, Uber Eats, Toast, or any of the local restaurant delivery apps because most of the time adding delivery doubles the order cost and I can drive myself to pickup my food just as quickly.

But when I'm in a strange town and I'm exhausted and it's late and I don't know anything good to eat at nearby, I pull up a food delivery app, search for something that would hit the spot, and treat myself by getting something delivered. It's been great on trips, as I often fly to cities and skip renting a car, using public transit or walking as much as possible.

After a long day on a plane, nothing hits the spot like getting to eat my favorite Indian dish that was brought to my lobby at the same time I was settling in and unpacking my clothes.

I’ve been rehearsing the talk this week, and was struck by…well, how weird it felt to rehearse a talk. That’s when I realized that next week’s meetup will be the first in-person talk I’ve given since 2019. Twenty-nineteen! Seven entire years! An eternity ago. Public speaking used to be, like, a whole entire thing I used to do. And now it’s just…not. I’ve given plenty of remote talks since then, mind you. (And they’re still plenty of work!) But as much fun as a virtual event is, I’ve missed getting a chance to meet attendees, hear what they’re working on, and what they’re excited about.

A lot of this is due to a changing world. The amount of travel I did fell off sharply back in 2020, and my house acquired some new health concerns back in 2021 that’ve made it harder to attend public events amid an ongoing pandemic. And the industry hasn’t escaped unscathed, either: many of the conferences I used to speak at simply don’t exist anymore.

This is all to say that amid all that change — and my nerves — I’m so glad to see that local, community-focused events are still going strong. And I’m honored to be in the room at the next Boston WordPress meetup. I’ll be masked up, sure, and probably a little more rusty than I used to be. But if you’re able to come, I hope you’ll say hi. It’d be great to meet you.

This has been “Retour.” a post from Ethan’s journal.

Reply via email

Google released a native Mac app for its Gemini chatbot today.

The app, which can be launched from your Applications folder, Dock, the menu bar, or a global hotkey, will be familiar to anyone who has used Gemini in a browser. The chatbot supports Gemini 3 in Fast and Thinking modes, as well as Pro mode, which uses Gemini 3.1 Pro. Gemini can also interact with files, the contents of a window, Google Drive, Photos, and NotebookLM. It’s multimodal, too, with support for the generation of text, images, video, and music. Dig a little deeper into Gemini’s menus and you’ll find support for Canvas, Deep Research, Guided Learning, and Personalized Intelligence.

A Gemini mini window is available from the menu bar and a global hotkey.

Even though I just downloaded the app a short time ago, my Gemini chat history was immediately available in the app. The history appears in the app’s sidebar along with a search field, My Stuff, which includes things like images and video generated in the past, and access to your account. The app is written in Swift which was a pleasant surprise.

All my past prompts were immediately available in the new Gemini Mac app.

I’ve only just begun testing Gemini for Mac, but I can already tell that it’s a cut above my hand-crafted single-purpose Safari web app solution. All the same tools found on the web are here, but in a native wrapper, which I appreciate. If you use a Mac and Gemini, the new app is well worth giving a try.

Gemini for Mac is available as a free download from Google.

I love these oversized prints of vintage Pan-Am luggage tags from artist Ella Freire. The typography and colors are just perfect. (via daringfireball)

Tags: art · design · Ella Freire · travel

I ran across this article on the LA Times site about the friction developing around shared trails in the Los Angeles area between e-bikes, bikes, horses, hikers, and dog walkers. It does a good job summing up everyone's issues but it barely scratches the surface of just how complicated trying to regulate e-bikes can be.

E-bikes are all over mountain trails. Some want them banned

The intrusion of e-bikes is sparking a fierce backlash from traditional trail users and forcing land managers into a confusing new debate over safety and fairness.

Los Angeles TimesJack Dolan

I want to walk through all the competing viewpoints, hopefully giving everyone some background context on how hard it is to develop future laws around these devices.

My bona fides

I first learned to ride a bike at age 7 and never stopped. It gave me the freedom to go anywhere and see the world, and that's what I use bikes for. I've regularly competed in bike events since I was twelve, all the way up to last weekend when I raced in a 40mi gravel event. If you ask me how many bikes I currently own I know I sound like an asshole when I say "I dunno, somewhere between 8 and 10ish maybe?" I've collected loads of bikes and parts over the decades and so that tends to happen.

I disliked the concept of e-bikes when I first heard about them like every other bike racer. They seem like "cheating" and the idea seemed silly because why would you let a motor do all the fun of actual bike riding? Eventually I learned the origin story and understood it better (more on that in a bit), but I still couldn't imagine myself owning or even wanting one.

Then one day back in 2019, I was at my local bike shop getting some parts and saw a big rack of city-focused e-bikes all charged and ready for test rides, so I took one out for a 20 minute spin around town. Long story short, I had a smile on my face bigger than any I could remember since I was seven years old doing it without training wheels for the first time. It was liberating and felt safer now that I could keep up with car traffic, it was endlessly fun to have a motor to back up your movements, and I saw how it could open the possibilities of what you could do on a bike. I was instantly converted and bought my first one for running errands around town.

My current stance on e-bikes

Over the years I've tried all sorts of e-bikes. The kind of e-bikes I own and enjoy are pedal-assisting Class 1 types (top motor speed: 20mph), which is the most mild of the e-bike varieties. They ride like normal bikes and the motor doesn't kick until you're actively pedaling, offering an added push to let you go further and faster. They tend to have about 10 to 20 pounds of additional weight compared to a normal bike.

Class 1 e-bikes make up about 50% of bike sales in the US and I'm all for more people getting to enjoy them in more places. I'm less of a fan of Class 2 e-bikes, which are those that use a throttle and don't require pedaling, although they do have a 20mph motor limit. People tend to use Class 2 bikes like mopeds around town. The ones I most dislike the higher powered "e-motos" that come with a throttle and either no pedals or a joke set of sprockets and chains to still be classified loosely as a bike by some regulatory body. They're backed by much larger motors and batteries and are essentially electric motorcycles but are often sold as e-bikes in the marketplace. These are significantly heavier and much faster, sometimes weighing as much as motorcycles, so the chance for injury or damage from impacts is much higher.

The physical abilities angle

The origin story of e-bikes is worth knowing. I remember when they were first developed in The Netherlands, primarily for a specific population. Amsterdam is famous as a place where you can run many short errands on a bike so much so that it's often easier than a car to get around. Middle-aged people there often ride 5-20 miles a day while they go to work, run errands, and ride home, but as people age into their 70s, 80s, and beyond, it's harder to cover that much distance in a day, and that's where the e-bike concept was born. It makes perfect sense for that specific audience as it lets you ride further while also saving effort.

I also have a friend that suffered a serious illness a few years ago, requiring an organ transplant, and they were formerly a competitive cyclist. Thanks to e-bikes, today that friend can hang onto group rides with their old bike racing buddies, because of their e-bike's additional propulsion.

The bottom line: An e-bike is revolutionary for anyone that wants to continue riding a bike and covering distances when some other factor is keeping them from doing that. It's important to know that any kind of a blanket e-bike ban means a small subset of e-bike riders using them as assistive devices will lose their access to the outdoors and exercise.

The safety angle

Another obvious issue around e-bikes is that the faster you go on a bike, the more you can get hurt (and hurt others in the process). Bikes handle differently at different speeds and seasoned riders know you put your weight back and slow down any turning when you're flying downhill at high speed, but e-bikes often end up in the hands of newer riders and casual cyclists who ride less often. They might only be used to riding bikes at 10mph but when their bike can now hit 25mph+, bad things can happen. Helmets are way more important for e-bikes and collisions with walkers and hikers are going to happen when people are moving faster.

Lately there's been a rash of stories about tweens and teens getting seriously injured on powerful e-bikes with at least one lawsuit against an e-bike manufacturer brought on by the parents of a child who died in a crash riding one of those e-bikes. To date, most e-bike companies say you should be at least 18 to ride so kids getting hurt isn't their fault, legally speaking.

The bottom line: The safety of riders and people around them is vital to crafting any legislation around e-bikes, but it's really difficult to set the specifics into law that make sense. I do think high powered "e-moto" types of e-bikes should be kept out of the hands of kids and remain off-road use only. But it's tough to justify a blanket e-bike ban on safety concerns when a Class 1 e-bike generally gets to the same speeds as a bike without a motor. Lawmakers often end up trying to craft nuanced rules around which e-bikes are ok versus which are not, but the public often views any bike with a motor an e-bike they'd like to see stopped.

The legal angle

There is lots of confusion around all the varieties of e-bikes and not just in how the general public views e-bikes but even among owners of the bikes themselves. The Class 1, 2, 3, and beyond system I describe isn't totally clear when you walk up to any random e-bike and look at it, or even if you're riding one. Different manufacturers build different features into their e-bikes based on what sells and there isn't a strict process or vetting of which bikes are classified into each class. There isn't even accurate labeling around it! When I look at any random instagram ad I get for an e-bike, speaking as someone that spent years working at bike shops I can't tell you which class of e-bike something is unless I look at a detailed spec sheet of what the bike has on it.

The bottom line: It's incredibly difficult to put up rules or signs banning certain types of bikes when even the riders might not even know what they're riding. It's also tough to train people to enforce e-bike laws because it's usually not clear what power levels, top speeds, or features a specific e-bike has, just based on looking at them.

The trail access angle

Access to trails is vital, and finding good places to ride anywhere in the US isn't easy. My current favorite MTB trails are located two hours away from me and though they've been around for about a decade, any changes to state or federal funding could close them up instantly. A couple of years ago they allowed Class 1 e-bikes on those same trails, but any sorts of bans could take those away.

A typical MTB trail system involves driving to a trailhead parking lot, then riding your bike up a long slow climb to the top, where you'll find a variety of downhill trails to get back to where you started. Most places I end up climbing for 45 minutes or so, then enjoying a 10-15 minute quick jaunt back down to the bottom. Usually I do another lap or two, until I feel exhausted.

A Class 1 e-bike makes the long climb up much easier, as you can get to the top of that same trail system in about 15 minutes, then ride down as normal. Instead of being exhausted after a couple laps on a normal mountain bike, an eMTB might let you do 3-4 laps in the same time it'd take you to complete 1 or 2.

A couple years ago, I rode trails in the Gemini Bridges area of Moab, Utah. At each trailhead there were signs that said all not only were all e-bikes were banned on MTB trails in Moab, but you could be fined thousands of dollars, have your bike confiscated, and risk up to 6 months in jail for your first infraction. I thought that was pretty extreme, so I only brought my regular mountain bike on the trip.

The trails were great fun, but at 6,000' above sea level, after an hour I was close to exhaustion. While I was resting on a ride, I saw an older couple likely in their 70s riding downhill towards me and they looked happy. I noticed their mountain bikes had large downtubes (where batteries are stored on e-bikes) and though they were toying with some pretty steep penalties, those trails were the perfect place and reason to use a mild e-bike on MTB trails.

A lot of organizations that maintain trails want to keep them safe for hikers, walkers, and horse riders so they don't get hit, and they want trails to last year after year. A Class 1 eMTB usually only weighs about 10-15lbs more than a regular MTB, and though people on them might do more laps, I would argue the additional impact on trails from eMTBs is minimal.

But without a blanket ban, you might see more of the e-moto type "bikes" show up and those can be 100-200lb bikes with up to 80 horsepower and larger 3-5" wide tires that can really tear a trail system up because they are basically motorcycles and will have a much larger impact from usage.

The bottom line: Trail access is vital to riders but that access has always been tenuous and can go away at any time, so riders tend to defend their trails. Blanket bans on e-bikes can certainly curtail impacts and dangers of all the various kinds of e-bikes, but my hope is any trail access includes Class 1 e-bikes as they're closer to regular bikes than anything else in the mix of what is generally considered "an e-bike". It's a little nuanced, but I really do hope all MTB trails eventually allow Class 1 e-bikes for all the previously mentioned reasons, while trying to keep the faster/larger bikes/e-motos out.

What's the ultimate solution?

Unfortunately there's no easy way out of this, as here are the competing problems:

• The bike industry is largely unregulated and there's not much oversight or standardization across e-bikes. Even if we wanted consistent labeling on e-bikes, it would be a difficult thing to implement. Any mix of features can end up on any kind of e-bike as there are almost no requirements around most e-bikes.
• People in charge of trails are getting complaints about riders (likely on e-motos) and they can do much more damage to trails that require increased maintenance costs to the trail owners. They're also potentially reaching dangerous speeds and endangering others and that is worth talking about, but a blanket ban, while easier to enforce, goes too far.
• There's a rash of teens and kids getting seriously hurt on high powered, high speed "e-bikes." I see people riding them on streets like real motorcycles but an e-bike has no special licensing process, whereas getting a motorcycle license in Oregon is an expensive, month-long process with hours of classroom training and parking lot testing. There's a lot of lawmaking that would be required to get e-moto "bikes" treated more like motorcycles,
• Implementing a blanket e-bike ban for anything with two wheels and a motor makes enforcement easier, since you don't have to figure out which class an e-bike is part of. Laws that carve out access for Class 1 bikes will need to be nuanced and training will be required for those enforcing any rules.
• Any ban on e-bikes in outdoor spaces is going to restrict people using them for assistive purposes, which likely isn't the goal of any e-bike laws and will be an unfortunate side effect.

Honestly this is a complicated issue on several fronts, but I do believe Class 1 e-bikes to be the safest and most mild variety of motor assist, and should be able to go wherever most bikes can go. But I also see why bikes with a throttle stop being quite like a regular bike and more like something else while larger e-motos shouldn't be considered e-bikes and instead classified as motorcycles.

Hopefully this clears up why it's so hard to make rules around e-bikes, and why some cities are implementing new laws, trying things out to curtail the bad effects of e-bikes while still allowing for some e-bikes.

At the same time, view transitions can be tricky to “get” at first. They can be simple, sure, but most anything beyond a cross-fade involves several moving parts.

I tend to find that the best way to learn something new is to see the code, use them myself, and then build upon them. So, I’ve collected seven view transition recipes for exactly that. We’ll go over the basic setup, demo the recipes, and turn you loose to experiment!

It’s perfectly fine to go below and just copy the one you like the most, but if you want to understand what view transitions are all about, then I recommend going through a quick introduction first before getting to the recipes.

Oh, and before we jump in, it’s worth noting that view transitions are indeed Baseline and supported by all major browsers as I’m writing this. But some types of animations may or may not be supported by a specific browser, so keep an eye on that and test, as always.

The setup

For each view transition, we’ll need to do a little setup beforehand. First off, we need to opt in to them using the @view-transition at-rule on both pages — the page we’re on and the page we’re transitioning to. If you’re using templates on your site, then this might go in the header template so it globally applies everywhere.

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
    types: <transition-type>;
  }
}

That <transition-type> is the only part you can’t directly copy-paste. It’s a placeholder for the types descriptor, something we’ve covered in detail before. It’s more nuanced than this, but types are basically the animation name we give to a specific transition. That way, if we’re working with multiple transitions, we can be explicit about which ones are active to prevent them from conflicting with one another. But read that linked article to get deeper into it.

Notice how we have the @view-transition walled behind the prefers-reduced-motion: no-preference media query. Not everyone wants movement on their pages and that’s a preference that can be set at the OS level, so we’ll respect that where needed this way.

Lastly, we’ll apply our animation as follows:

html:active-view-transition-type(<transition-type>)::view-transition-old(root) {
  animation: a-cool-outgoing-animation 1.4s ease forwards;
}

html:active-view-transition-type(<transition-type>)::view-transition-new(root) {
  animation: a-cool-incoming-animation 1.4s ease forwards;
}

…where the :active-view-transtion-type() pseudo matches the transition type we define in the @view-transition rule. For example, if we’re calling an animation that we’ve named bounce, then we’d use that in the at-rule like this:

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
    types: <transition-type>;
  }
}

…as well as the pseudo like this:

/* The "current" page */
html:active-view-transition-type(bounce)::view-transition-old(root) {
  animation: bounce-in 1.4s ease forwards;
}

/* The page we're transitioning to */
html:active-view-transition-type(bounce)::view-transition-new(root) {
  animation: bounce-in 1.4s ease forwards;
}

OK, that’s enough context to get started with the recipes. Again, feel free to use any of these in your own experiments or projects.

Pixelate dissolve

This one’s sort of like a simple cross-fade, but blurs things out as the old page content fades out and the new page content fades in.

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
    types: pixelate-dissolve;
  }
}

html:active-view-transition-type(pixelate-dissolve)::view-transition-old(root) {
  animation: pixelate-out 1.4s ease forwards;
}

html:active-view-transition-type(pixelate-dissolve)::view-transition-new(root) {
  animation: pixelate-in 1.4s ease forwards;
}

@keyframes pixelate-out {
  0% {
    filter: blur(0px);
    opacity: 1;
  }
  100% {
    filter: blur(40px);
    opacity: 0;
  }
}

@keyframes pixelate-in {
  0% {
    filter: blur(40px);
    opacity: 0;
  }
  100% {
    filter: blur(0px);
    opacity: 1;
  }
}

Wipe up

Here, we’re using the clip-path property to achieve the “wipe-up” effect we’re the content for a new page slides up from the bottom, replacing the “old” content.

The process is straightforward: for the outgoing page, we move from its default inset() value of 0 0 0 0 (which creates a rectangle at the top, right, bottom, and left borders) of the page and change the bottom value to 100%. Meaning, the page goes from top to bottom.

The incoming page starts clipping from the top at 100% and goes down to 0.

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
    types: wipe-up;
  }
}

html:active-view-transition-type(wipe-up)::view-transition-old(root) {
  animation: wipe-out 1.4s ease forwards;
}

html:active-view-transition-type(wipe-up)::view-transition-new(root) {
  animation: wipe-in 1.4s ease forwards;
}

@keyframes wipe-out {
  from {
    clip-path: inset(0 0 0 0);
  }
  to {
    clip-path: inset(0 0 100% 0);
  }
}

@keyframes wipe-in {
  from {
    clip-path: inset(100% 0 0 0);
  }
  to {
    clip-path: inset(0 0 0 0);
  }
}

We could just as easily make things wipe right, wipe bottom, and wipe left simply by changing the inset values. For example, here’s things wiping right:

@keyframes wipe-out {
  from {
    clip-path: inset(0 0 0 0);
  }
  to {
    clip-path: inset(0 0 0 100%);
  }
}

@keyframes wipe-in {
  from {
    clip-path: inset(0 100% 0 0);
  }
  to {
    clip-path: inset(0 0 0 0);
  }
}

The wipe right works similarly to wipe up, except that the outgoing page goes from the center and cuts towards the right. That’s why the second value goes from 0 to 100%. Similarly, the incoming page goes from 100% from the left to 0.

Same sort of deal with wiping downward:

@keyframes wipe-out {
  from {
    clip-path: inset(0 0 0 0);
  }
  to {
    clip-path: inset(100% 0 0 0);
  }
}

@keyframes wipe-in {
  from {
    clip-path: inset(0 0 100% 0);
  }
  to {
    clip-path: inset(0 0 0 0);
  }
}

You get the idea!

Rotate in-out

This one’s a little, um, weird. Definitely not the most practical thing in the world, but it does demonstrate how far you can go with view transitions.

We use the the scale() and rotate() functions to zoom and rotate the page content, where the “old” page scales down to 0 and rotates clockwise by 180deg. Following that, the “new” page content scales up to 1 and rotates counter-clockwise by -180deg. A little opacity is thrown in to help give the illusion that stuff is going out and coming in.

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
    types: zoom-rotate;
  }
}

html:active-view-transition-type(zoom-rotate)::view-transition-old(root) {
  animation: zoom-rotate-out 1.4s ease forwards;
  transform-origin: center;
}

html:active-view-transition-type(zoom-rotate)::view-transition-new(root) {
  animation: zoom-rotate-in 1.4s ease forwards;
  transform-origin: center;
}

@keyframes zoom-rotate-out {
  to {
    transform: scale(0) rotate(180deg);
    opacity: 0;
  }
}

@keyframes zoom-rotate-in {
  from {
    transform: scale(0) rotate(-180deg);
    opacity: 0;
  }
}

Circle wipe-out

This one’s a lot more subtle than the last one. It could be a lot more noticeable if the content we’re transitioning to is more distinct. But as you’ll see in the following video, the “background between “old” and “new” pages share the same background, making for a more seamless transition.

The circle comes courtesy of the clip-path property, draws the shape from the center using the circle() function, going from from 0% (no size) to 150% (sized beyond the content), making it encapsulate the entire page.

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
    types: circular-wipe;
  }
}

html:active-view-transition-type(circular-wipe)::view-transition-old(root) {
  animation: circle-wipe-out 1.4s ease forwards;
}

html:active-view-transition-type(circular-wipe)::view-transition-new(root) {
  animation: circle-wipe-in 1.4s ease forwards;
}

@keyframes circle-wipe-out {
  to {
    clip-path: circle(0% at 50% 50%);
  }
}

@keyframes circle-wipe-in {
  from {
    clip-path: circle(0% at 50% 50%);
  }
  to {
    clip-path: circle(150% at 50% 50%);
  }
}

Diagonal push

This one pushes out the “old” page with the “new” page from the bottom-right corner of the screen to the top-right corner — or, really, any corner we want by adjusting values.

For the bottom-right, I set the animation to translate to -100% on the X and Y axes, which pushes it away from the screen. Then it comes in from the opposite corner to its default position at 0%. A little opacity helps smooth things out.

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
    types: diagonal-push;
  }
}

html:active-view-transition-type(diagonal-push)::view-transition-old(root) {
  animation: diagonal-out 1.4s ease forwards;
}

html:active-view-transition-type(diagonal-push)::view-transition-new(root) {
  animation: diagonal-in 1.4s ease forwards;
}

@keyframes diagonal-out {
  to {
    transform: translate(-100%, -100%);
    opacity: 0;
  }
}

@keyframes diagonal-in {
  from {
    transform: translate(100%, 100%);
    opacity: 0;
  }
}

Curtain reveal

This one’s like the a curtain is closing on the “old” page and opens up with the “new” page. It’s another one where the inset() function comes into play. We define rectangles placed 50% at the right and left. This increases to 50% when the page is going out and reduces to 0 when the page is coming in, making the image appear from the middle going to left and right like a curtain!

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
    types: curtain;
  }
}

html:active-view-transition-type(curtain)::view-transition-old(root) {
  animation: curtain-out 1.4s ease forwards;
}

html:active-view-transition-type(curtain)::view-transition-new(root) {
  animation: curtain-in 1.4s ease forwards;
}

@keyframes curtain-out {
  from {
    clip-path: inset(0 0 0 0);
  }
}

@keyframes curtain-in {
  from {
    clip-path: inset(0 50% 0 50%);
  }
  to {
    clip-path: inset(0 0 0 0);
  }
}

3D flip

We’re sort of faking one page “flipping” out like a two-sided card while the next page flips in, both along the Z axis.

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
    types: flip-3d;
  }
}

html:active-view-transition-type(flip-3d)::view-transition-old(root) {
  animation: flip-out 1.4s ease forwards;
}

html:active-view-transition-type(flip-3d)::view-transition-new(root) {
  animation: flip-in 1.4s ease forwards;
}

@keyframes flip-out {
  0% {
    transform: rotateY(0deg) translateX(0vw);
  }
  100% {
    transform: rotateY(-90deg) translateX(-100vw);
    opacity: 1;
  }
}

@keyframes flip-in {
  0% {
    transform: rotateY(90deg) translateX(100vw);
  }
  100% {
    transform: rotateY(0deg) translateX(0vw);
  }
}

Any cool recipes you want to share?

I would love to see more examples and ideas if you have them! Bramus (or Brandi, as I call him) took the time to create a bunch of view transition examples in an interactive demo that are definitely worth looking at.

7 View Transitions Recipes to Try originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

For a laugh I ran some of my pre-2020 blog posts (safely written in the pre-ChatGPT era) through an AI detector and it came back telling me they were between 59% and 93% AI-generated. I am now in a full spiral that I just naturally write like a language model that has been asked to sound like a person. I’ve been a robot this whole time. The robots didn’t take my job. I was always the robot.

One of my absolute favourite pieces of trivia, which I keep locked and loaded in my back pocket, is that we only have good blueberries because of USAID (rip). The full thing is a Planet Money episode which you should listen to but the tl; dr is: blueberries used to be bad and seasonal and therefore pointless, Peru was growing coca leaves, America was doing its whole thing about that, and USAID showed up (with what I can only describe as the most optimistic foreign policy proposal in recorded history) and said what if instead of cocaine you grew asparagus. The farmers loved asparagus so much they immediately destroyed the asparagus market by growing too much asparagus, so this one Peruvian dude had a look at what else could grow in sandy Peruvian soil and the answer was blueberries and that’s it, that’s the whole thing. Bingo bango, you can now eat blueberries in January like a queen. The war on drugs gave us bloobs.

Saved from last week’s update in what I am choosing to call “planning”: face jugs at the Atlanta High museum. Face jugs are jugs (or jars, the taxonomy is loose) from the 1800s American South, and they have faces on them, and the reason they have faces on them is to scare children away from the moonshine inside. Or spices. Or genuinely anything else you care about; children get their grubby little hands in everything. I found this especially delightful because I took a portrait sculpture class last year and since then have been putting faces on pottery, and it turns out once again that nothing is new. Nothing has ever been new.

What stack?

My understanding is that a “stack” is a choice of software used to build a website. That includes language and tooling, libraries and frameworks, and heaven forbid: subscription services. Text editors aren’t always considered part of the stack but integration is a major factor.

Web dev stacks often manifest as package.json used to install hundreds of megs of JavaScript, Blazing Fast™ Rust binaries, and never ending supply chain attacks.

A stack is also technical debt, non-transferable knowledge, accelerated obsolescence, and vendor lock-in. That means fragility and overall unnecessary complication. Popular stacks inevitably turn into cargo cults that build in spite of the web, not for it.

Let’s break that down.

Technical debt

If you have a go-to stack, you’ve prescribed a solution before you’ve diagnosed a problem. You’ve automatically opted in to technical baggage that you must carry the entire project. Project doesn’t fit the stack? Tough; shoehorn it to fit.

Non-transferable knowledge

Stacks are opinionated by design. To facilitate their opinions, they abstract away from web fundamentals. It takes all of five minutes for a tech-savvy person to learn JSON. It takes far, far longer to learn Webpack JSON. The latter becomes useless knowledge once you’ve moved on to better things. Brain space is expensive. Other standards like CSS are never truly mastered but learning an abstraction like Tailwind will severely limit your understanding.

Accelerated obsolescence

Stacks are a collection of move-fast-and-break churnware; fleeting software that updates with incompatible changes, or deprecates entirely in favour of yet another Rust refactor. A basic HTML document written 20 years ago remains compatible today. A codebase built upon a stack 20 months ago might refuse to play.

Vendor lock-in

The cost of re-stacking is usually unbearable. Stack-as-a-service is the endgame where websites become hopelessly trapped. Now you’re paying for a service that can’t fix errors. You’ve sacrificed long-term stability and freedom for “developer experience”.

When stack?

I’m not saying you should code artisanal organic free-range websites. I’m saying be aware of the true costs associated with a stack. Don’t prescribe a solution before you’ve diagnosed a problem. Choose the right tool for each job only once the impact is known. Satisfy specific goals of the website, not temporary development goals.

Don’t ask a developer what their stack is without asking what problem they’re solving. Be wary of those who promote or mandate a default stack. Be doubtful of those selling a stack. When you develop for a stack, you risk trading the stability of the open web platform, that is to say: decades of broad backwards compatibility, for GitHub’s flavour of the month.

The web platform does not require build toolchains. Always default to, and regress to, the fundamentals of CSS, HTML, and JavaScript. Those core standards are the web stack. Yes, you’ll probably benefits from more tools. Choose them wisely. Good tools are intuitive by being based on standards, they can be introduced and replaced with minimal pain.

My only absolute advice: do not continue legacy frameworks like React. If that triggers an emotional reaction: you need a stack intervention! It may be difficult to accept but Facebook never was your stack; it’s time to move on.

Use the tool, don’t become the tool.

Edit: forgot to say: for personal projects, the gloves are off. Go nuts! Be the churn. Learn new tools and even code your own stack. If you’re the sole maintainer the freedom to make your own mistakes can be a learning exercise in itself.

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

button:focus-visible {
  outline: none;
  box-shadow: 0 0 0px 4px blue, 0 0 0px 8px red, 0 0 0 12px blue;
}

That's okay in browsers' default color mode, but in forced colors mode, it's problematic because the box-shadow property computes to none, which means that there are no shadows and consequently no focus styles in this mode. You can confirm that by opening this page in a Chromium-based browser, switching to the Rendering tab in DevTools, and setting forced-colors to active.

There are two solutions to that problem. Either don't try to be fancy and simply use an outline, or, if you think the user experience will be better with a box shadow, don't set outline: none; instead, set outline: 2px solid transparent.

button:focus-visible {
  outline: 2px solid transparent;
  outline-offset: 2px;
  box-shadow: 0 0 0px 1px blue, 0 0 0px 2px white, 0 0 0 4px blue;
}

The outline will be transparent in the regular mode but visible in forced colors mode. That works because in forced colors mode, colors on the page are constrained to a restricted, user-chosen palette. For transparent, which is a CSS color, this means it becomes visible.

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

Safari is only good for one thing, which is battery life.

And:

Commonly accepted facts.

Accepted by who? Lunatics?

I would say ask any browser enthusiast.

And:

I'm on an Apple Silicon laptop. Battery life is going to be legit no matter what or where I'm going.

No, no, it's not. That's not true.

Bro, I'm a super turbo power user. I can at least get like four hours of battery life minimum.

The difference between Chrome and Safari in regular browsing for several hours is shockingly high. It's huge.

Really?

It's dramatic. This laptop is terrifyingly long-lasting battery on Safari, is average at best with Chrome.

I happened to test exactly this in 2024, and I took great care to document my process and findings. Here's what I found:

In my 3-hour tests, Safari consumed 18.67% of my battery each time on average, and Chrome averaged 17.33% battery drain. That works out to about 9% less battery drain from Chrome than Safari. Yes, you read that right, I found Chrome was easier on my battery than Safari.

Yeah, I found that in controlled tests where I did the exact same things in both browsers for hours at a time (across multiple test runs), and found that they were very close to each other, with Chrome using slightly less battery. As Marques put it, it sounds like Chrome halves his Mac's battery life. As someone who uses Chrome for work and spends all day in it doing work in Atlassian apps and video calls, I can confidently say it easily makes it through an 8-9 hour work day on battery. This is true of my M5 Pro and it was also true of my M1.

I asked for any sort of data from the past decade people had to back up the idea that Chrome was horrible on battery and Safari was a saint, and I got nothing sent my way in 2024. If you have it now, I'd love to see it! Hit me up on Mastodon if you've got it!

Until I get any sort of compelling data, I'm going to continue thinking that people who think this are just like people who think that religiously force closing your iPhone apps improves your phone's speed and battery. It's a shared hallucination that feels like it's true, even though it's not. Considering many Safari users can't seem to believe that Chrome is a faster browser than Safari these days either, despite effectively every benchmark showing this, I suspect the feelings will continue.

adactio.com/links/22527

Go to Settings > Accessibility > Zoom, and then turn on “Use scroll gesture with modifier keys to zoom.”

Then, at any moment, you can hold Control and swipe with two fingers (or use a scroll wheel) up or down to zoom the entire screen.

I’d also recommend turning off “Smooth images” under “Advanced…” so you see individual pixels better.

This is one of the very best MacOS tips. No third-party software. Built into MacOS for several (many?) years now. Incredibly useful.

But I had no idea it existed until last June at WWDC. It was Monday, after the morning keynote and just before the afternoon State of the Union. Beautiful sunny day at Apple Park. I ran into my old friend Cabel Sasser, and, maniac that he is, he’d already installed the first Tahoe developer beta on his MacBook Pro. So I sat next to him and we started examining the UI changes in detail. And Cabel was zooming in and out instantaneously. I was like, “Whoa, how are you doing that?” And Cabel was like, “You don’t know about the Accessibility Zoom gesture? Here, let me show you!” And my mind was blown. Cabel emphasized the importance of going into the “Advanced…” dialog to turn off “Smooth images”, and I agree. This is a fantastic feature, but Apple has the default setting wrong for smoothing (a.k.a. blurring) the zoomed image. I honestly can’t imagine why anyone would want the zoomed image blurred.

Anyway, then we both laughed ourselves silly and made ourselves a little queasy examining, in detail, just how bad the Tahoe UI was. And I thought to myself, I need to post this as a tip on Daring Fireball.

Well, it took 10 months, but Wichary posting it on Unsung reminded me that I never posted about it here. [Update: Actually...] Turn this on, start using it, and you’ll find yourself using it every day if you care about design details.

Bonus tip: Subscribe to Wichary’s Unsung in your RSS reader. He’s only been posting there since early December, and it quickly became one of my favorite blogs in the world. One of those blogs where I’m excited every time I see there’s a new post. I would read a post from Wichary describing what it’s like to watch paint dry, because I know he’d only write about it if he noticed something interesting and nuanced. Because he’s only been writing Unsung for a few months, you can catch up on the whole thing.

AI is a sycophantic dev wannabe that skimmed a shitload of tutorials. You get the results of a probabilistic guess based on patterns it saw during training. What did it train on? Ancient solutions, unoriginal UI patterns, and watered down junk.

I'm about to rant about how this is both useful and lame.

The Good #

AI loves the boring stuff. It thrives on mediocrity.

If you want some gloriously unoriginal UI, it has your back 😜

• Scaffolding: Generic regurgitation of patterns it's seen, done.
• Tokens: Migrating tokens or mapping them out? It eats this tedious garbage for breakfast.
• Outlining features: Generic lists ✅
• Lying to your face: Confident hot garbage on a silver platter. It'll hand you a snippet, dust off its digital hands, and tell you it finished the work. It did not finish the work.

Aka: If it's a well-worn pattern, AI is there to help you copy-paste faster. Which, for a lot of programming, is totally the case. I'm genuinely finding a lot of helpful stuff in this department.

The Bad #

Pixel perfection & bespoke solutions… what are those?

The exact second you step off the paved road of unoriginality, it faceplants.

• Bespoke solutions & custom interactions: Try asking it for some scroll-driven animations or custom micro-interactions. It will invent a CSS syntax that hasn't existed since IE6.
• Layout & Spacing: Predicting intrinsic/extrinsic page properties? It's already bad at math, how could it get this rediculously dynamic calculation correct. Spacing? Ha, seems reasonably to expect symmetry, but it's terrible at the math.
• Combined states: Pinpointing where to edit a complex component state makes it cry.
• Accessibility: It throws aria-hidden="true" at a wall and hopes it sticks.
• Performance: It will give you the heaviest, jankiest solution unless you explicitly ask it to be for a specific (apparently "indie") performance solution.
• Tests: Writing good tests? Good, no. A lot, yes.

And the absolute best part? The more complex the component gets, the slower and dumber the front-end help becomes. Incredible how it can one shot a totally decent front-end design or component, than choke on a follow up request. Speaks to what it's good at.

Why? #

1. It trained on ancient garbage #

It lacks modern training data.

It has an excessive reliance on standard templates because that's what the internet is full of. Modern CSS? It's barely aware of it.

2. It literally cannot see #

It's an LLM, not a rendering engine!

It's notoriously bad at math, and throwing screenshots at it means very little. It's stabbing in the dark.

This leads to the classic UI interaction:

AI: "I'm done! Here is your perfectly crafted UI."
Me: "There's a gaping hole where the icon should be, fix the missing icon."
AI: "You're absolutely right. Let me fix that for you."

3. It does not know WHY we do things #

It doesn't understand the "why" behind our architectural decisions.

SDD, BDD, or state machines might help guide it, but the models weren't exactly trained on those paired with stellar solutions.

We're asking a giant text-predictor to make new connections on the fly. We can get it there, but there's so much to consider we have to spell it out before it starts making the connections we want.

4. Zero environmental control #

It doesn't control where the code lives.

It can write annoyingly amazing Rust, TypeScript or Python, but those have the distinct advantage of a predictable (pinnable!!! like v14.4) environment the code executes in.

That's not how HTML or CSS work, there is no pinning the browser type, browser window size, browser version, the users input type (keyboard, mouse, touch, voice), their user preferences, etc. That's complex end environment shit.

The list goes on too, for scenarios, contexts and variables the rendering engine juggles before resolving the final output. The LLM doesn't control these, so it ignores them until you make them relevant.

Even prompting in logical properties, you have to ask for this kind of CSS. These should be CSS tablestakes output from LLMs, but it's not. And even when you ask for it, or provide documentation that spells it out, it's not guaranteed to work.

The place where HTML and CSS have to render is chaotic. It's a browser, with a million different versions, a million different ways to render, a million different ways to interact with it, and a million different ways to break it.

It's a moving target, and LLMs are terrible at moving targets.

Damnit humans #

We're a LLM combinatorial explosion.

We're wildly unpredictable targets. We change our minds, we switch viewports, we change theme preferences, we changes devices, we change browsers, we change browser versions, we switch inputs, we change our everything.

We're not a static target. We're not a pattern that can be learned.

There is a "human mainstream" of behaviors, preferences, and expectations where LLMs can be genuinely helpful; but our "full potential" matrix will be exploding LLM output patterns for a long time to come. IMO at least.

unless we Borg.

I used to see that retro multi-stroke text effect quite often and tried to replicate it using the CSS text-stroke property, but the results never quite matched. Because text-stroke accepts a single value, stacking elements was the only workaround I could think of, though it didn't seem to work.

One evening late last year, I was eager to give it another shot after seeing the text effect again in the book Graphic Japan : from woodblock and zen to manga and kawaii.

I kept stacking several elements and accidentally varied the text-stroke-width for each layer. To my suprise, the result was getting closer this time.

--c: #cc0d55;
--n: @i(-1);

@grid: 36x1 / 240px;
@content: '✱';

position: absolute;
inset: 0;
font: 100px/0 sans-serif;
color: var(--c);
z-index: @I(-@i);

-webkit-text-stroke-color: @pn(--c, #f4e1e8);
-webkit-text-stroke-width: $em(.08n+.02(1-(-1)^n));

How it works

For different values of the text-stroke-width, browsers will automatically draw outlines of the charater, The larger you set the stroke width, the thicker the outline will get, while still maintain its original shape.

@grid: 7x1/ 360px auto noclip; @content: '✱'; font: 50px/0 sans-serif; color: transparent; -webkit-text-stroke-color: #cc0d55; -webkit-text-stroke-width: @i(*1.8px);

The next step is to use different colors and put them in order.

@grid: 12x1/ 100px ß #f4e1e8; @content: '✱'; position: absolute; inset: 0; z-index: @I(-@i); font: 50px/0 sans-serif; color: transparent; -webkit-text-stroke-color: @pn(#f4e1e8, #cc0d55); -webkit-text-stroke-width: @i(*3px);

The interesting part is how the browsers outlining the character shapes differently. FireFox offers more smoother rendering than in Chrome and Safari.

Another interesting part is when there are more text put inline, the character shapes will be merged.

/* ... */
@content: '秋收冬藏';

Trying different fonts

The final result really depends on the font you choose. To help experimenting with different fonts more quickly, I added the @google-font function for faster font loading.

font-family: @google-font(Matemasie);
@content: 'b';

font-family: @google-font(Tangerine);
@content: 'Love';

font-family: @google-font('Cherry Bomb One');
@content: '+';

Unfortunately, the performance is as bad as CSS filters, especially when the font-size is getting bigger, you may have noticed some flicking above. It's fine for experiments like this, or for generating images with css-doodle, but it's not well-suited for production usage.

More examples

Here are two more examples to play around with different colors and characters, generated with css-doodle, just for fun.

CodePen link for the first one: https://codepen.io/yuanchuan/pen/ogzarGo

Following is an initial explanatory paragraph. It serves to help back up the previous paragraphs, and start to ground it in more applicable information. Expectations are set, and potential skepticism is addressed. A link to prior art is supplied, to provide additional context.

There is then a paragraph that serves as a segue. It connects the high-level concepts and begins to draw them down the realm of the practical.

A subheading to help segment the content

This paragraph begins to answer the questions in the reader’s mind that the segue paragraph introduced. It begins with level-setting. Certain key concepts are bolded to accommodate people who skim. Following that is supplying more context, albeit still at a relatively high level.

A short sentence isolated as its own paragraph to drive attention and impact.

The following paragraph begins to dive into particulars. It introduces a new concept related to the subsection’s topic at-hand, careful to stay focused to help the reader understand the larger goal you’re driving towards.

• Bulleted lists help the reader digest these particulars,
• Break up the flow of content, and
• Step through a process.

A follow-up paragraph at the end of a subsection may allude to the author‘s opinions or larger thoughts about the topic. It also sets up the next subsection.

Another subheading

The next concept is addressed, getting more technical as the reader becomes more acclimated. A link to a peer resource is threaded in as an appeal to authority, to help reinforce confidence in the author.

An ordered list is used to:

1. Communicate a series of instructions the reader should take,
2. In which order they should be followed, and
3. Do so in a way that both makes it easy to follow and also breaks up reading flow to be more noticeable.

There might then be another follow-up paragraph. This one might contain a sentence with an em dash—indicative of a trailing thought that is still topically related.

A deeper subheading

This section works deeper into the technical topic. It dispenses with reasoning and analogies and discusses practical specifics.

A piece of code that translates the practical specifics into language a computer can be instructed with. Comments are supplied to help facilitate understanding.

• A bulleted list is used,
• It breaks down and explains code concepts that may not be self-evident, and
• These points may be more holistic, meaning they aren’t a good fit for inline code comments.

A new concept is introduced

We break out of the depth of the deeper subheading’s content and return to a level higher. This is a new concept, yet still living under the umbrella of the overall topic at-hand.

The format of this new concept mirrors the structure of the previous section. This predictability helps with reading flow and answering the reader’s unspoken expectations.

A subheading that begins to tie all the previous sections’ content together

This subsection takes each of the previous points raised and reinforces their need to be sequentially discussed. It then explicitly confirms the case the rest of the content has been implicitly building, that this topic was worth breaking down to better appreciate as a holistic whole.

Some established trust is cashed in. The author is allowed some space to wax philosophical about larger implications, or discuss their feelings on the matter.

A conclusion

The bold first sentence is revisited now that the reader has completed learning about the concept being discussed. A subsequent sentence explicitly ties the nuance the rest of the content discusses to the overall point.

The reader is thanked, and the content ends.

Join Stacy, James, and Miriam as we explore some hidden gems of UI development – from @starting-style for smoother entry transitions to performance boosts with AVIF images and using the browser’s built-in lazy-loading. We cover a variety of quick wins that you can use to make your life easier and improve the experience for your website visitors.

Subscribe to Channel »

• AVIF
  • What makes AVIF a good choice
  • How to convert images
  • Where you can use them
  • Example image sizes after converting
• Lazy Loading
• @starting-style
• Backdrop-filter
• Relative colors
• Text-box
• nth-child of .class CodePen

• caniuse AVIF
• AVIF has landed
• Squoosh
• caniuse Lazy Loading
• caniuse @starting-style
• caniuse CSS backdrop-filter
• caniuse CSS relative colors
• caniuse CSS text-box-trim
• CSS text-box-trim by Adam Argyle
• CodePen Quick Wins
• caniuse transition-behavior

I’m a huge fan of Sir Tim Berners-Lee, his values and his modest and humble aura. I ordered a physical copy of “This is for Everyone” the moment it came out, but I mostly listened to it on Audible, read by a great voice of Stephen Fry. The audiobook contains a great prologue read by the author, and also a (not so great) conversation between the web inventor and the narrator.

Book starts in a very biographical way by telling a little story of Tim’s and his family, education and early career that eventually drove him to CERN. Inspired by the lack of interoperability between documents systems in the particle laboratory, he started constructing a mesh of interconnections. In fact “Mesh” was what Tim called his invention, but inspired by catchy names of products Steve Jobs liked to give to his products, he decided to call it World Wide Web.

The early days were rather tough and the book goes in depth about other competing protocols, first browser wars and attempts to monopolise the Internet. Throughout the book the author expresses his never-ending desire to keep the web open, valuable and accessible for everyone. On multiple occasions the author mentions the fear of fragmentation present on the web, domination of the social media silos and also the importance of the governance bodies behind them. The last chapters of the book go in depth (too much if you ask me) into the SOLID protocol that Tim has worked on for the recent years.

I would recommend it wholeheartedly to everyone, not only tech-savvy folk. Geeks will also find this read incredibly interesting as it reveals a lot of great stories about other tech makers of our generation, some drama behind the web clients, an interesting relationship between the author and the UNIX philosophy and tonnes more. I loved the read!

Having light-dark() makes it trivial to support dual color modes in a single stylesheet and doesn’t add too much weight (0.5kb gzip for ~500 variables). It also gives you the ability to switch themes mid-page.

:root {
	color-scheme: light dark;
	--bg-color: light-dark(white, black);
	--text-color: light-dark(black: white);
	/* ...etc */
}

/* Add hard-coded theme overrides */
[data-theme="light"] { color-scheme: light; }
[data-theme="dark"] { color-scheme: dark; }

Adding [data-theme="dark"] to the body, or any element with color tokens defined, will force that section to be dark mode. The difference here between hanging variable definitions off a class is that you can respect the user preference without using JS to toggle, light-dark() does all the work.

Adding dark tier on a light theme is dramatic. Adding light tier on a dark theme sure would stand out. But when yielding light and dark modes over to the browser… something changes. In that situation hardcoding a theme mode into HTML loses a bit of meaning because I’m not controlling the theme anymore, the user is. What I actually want is the theme to be “opposite” the current theme. After a handful of attempts I think I came across a solution that’s easy to understand, maintain, and I even wrote a polyfill for you.

Automatic inversion with [data-theme=“inverted]

See the Pen [data-theme="inverted"] by Dave Rupert (@davatron5000) on CodePen.

The goal was to make it so that when the browser switched from light/dark modes, themed elements would switch to their inverse theme. The trick I uncovered was setting the current theme as a CSS variable:

:root {
	color-scheme: light dark;
	
	/* Initialize the theme variables */
	--theme: light; 
	@media (prefers-color-scheme: dark) {
		--theme: dark;
	}
}

/* Have data-theme use the variable */
[data-theme] { color-scheme: var(--theme); }

/* Update hard-coded themes to use the variable */
[data-theme="light"] { --theme: light; }
[data-theme="dark"] { --theme: dark; }

The reason we use manage --theme variable instead of purely color-scheme is because we can pass that into a style() query. An that’s the magic that enables inverted themes:

/* Add style query magic ✨ */
@container style(--theme: light) {
	[data-theme="inverted"] {
		--theme: dark;
	}
}

@container style(--theme: dark) {
	[data-theme="inverted"] {
		--theme: light;
	}
}

Again, the nice thing here is that we’re not creating two different trees of variables or re-redefining variables inside [data-theme="inverted"], we’re relying on light-dark() and color-scheme to do the heavy lifting. We’re contextually updating the color-scheme and letting the browser negotiate the cascade.

I added a .funky card theme to the demo to give an idea of how far you might be able to push this tech. Roman Kamorov noted in his post on Querying the Color Scheme something Vadim Makeev said on a Russian podcast that while this inversion trick is neat, people who prefer dark-mode (e.g. for medical reasons) probably want dark mode and not to be flash-banged mid-page. That’s something to think about and I think I have some ideas about that but I’d love to see/hear yours.

Polyfilling browser support

At the time of writing this trick only works in Safari 18+ and Edge/Chrome 111+. Firefox is the outlier but the good news is container style queries is on the roadmap for Interop 2026 and behind a flag in nightly. That gives you two options:

• Roll out a bespoke polyfill for [data-theme="inverted]
• Do nothing. Wait it out.

Given that I know the experience will auto-upgrade for Firefox users at some point this year, I’m prone to wait it out per the rules of progressive enhancement. If it falls back to the current theme, I don’t think the world falls over.

However, you probably support browsers outside the latest version and what’s acceptable for a fallback depends on your company’s understanding of the eventual consistency of browsers. iOS devices version-locked at Safari 17.4 are of particular concern for me, so I wrote an inverted theme polyfill.

The CSS style-query-support detection is pretty simple, but quirky.

/* Style query support check */
body {
  --syle-query-support: 0;
}

@container style(--theme) {
  body { --syle-query-support: 1 }
}

There’s a new @supports at-rule() function that would be more idiomatic, but you can’t detect at-rule function support with at-rule() so we have to do this variable hack. Ideally we could do this purely in JS with CSS.supports(), but alas. Booleans in CSS, what could go wrong?

That brings us to the JavaScript part which is pretty simple as well but comes with one big potential tradeoff…

/**
 * Polyfill for inverted themes using a `--theme` variable in a style query
 * ⚠️ The use of `getComputedStyle` can trigger layout and style recalcs
 */
(()=>{
  const isContainerStyleQueriesSupported = () => {
    const bodyElStyle = getComputedStyle(document.body);
    const hasStyleQueries = bodyElStyle.getPropertyValue("--syle-query-support");
    
    if(hasStyleQueries === "1") {
      return true;
    }
    return false;
  }
  
  if(!isContainerStyleQueriesSupported()) {
    const invertedThemes = document.querySelectorAll('[data-theme="inverted"]');
  
    invertedThemes.forEach((el) => {
      const elTheme = getComputedStyle(el).getPropertyValue("--theme");
      const invertedTheme = elTheme == "light" ? "dark" : "light";
      el.dataset.theme = invertedTheme;
    })
  }
})();

Because we need to get the computed value of --style-query-support, getComputedStyle is known to trigger style recalcs and layout reflows, effectively penalizing all users not just browsers that don’t support container style queries. I tested this out by putting the polyfill inside a setTimeout, turning on paint flashing, and checking the Performance Monitor panel and I didn’t see any recalcs or layout reflows, but your mileage may vary depending on your setup.

Anyways, happy inverting! Let me know if you do something cool with it or if you already figured this out 10 months ago and I didn’t see your blog post.

I also took a stab at vibe coding my dream app: an RSS reader.

To clarify: Reeder is my dream RSS app and it already exists, so I guess you could say my dreams have already come true?

But I’ve kind of always wanted to try an app where my RSS feed is just a list of unread articles and clicking any one opens it in the format in which it was published (e.g. the original website).

So I took a stab at it.

(Note: the backend portion of this was already solved, as I simply connected to my Feedbin account via the API.)

First I tried a macOS app because I never would’ve tried a macOS app before. Xcode, Swift, a Developer Account? All completely outside my wheelhouse. But AI helped be get past that hurdle of going from nothing to something.

It was fun to browse articles and see them in situ. A lot of folks have really great personal websites so it’s fun to see their published articles in that format.

This was pretty much pure vibes. I didn’t really look at the code at all because I knew I wouldn’t understand any of it.

I got it working the first night I sat down and tried it. It was pretty crappy but it worked.

From there I iterated. I’d use it for a day, fix things that were off, keep using it, etc.

Eventually I got to the point where I thought:

• Ok, I could use this on my personal computer.
• I don’t know that I’ll be able to iterate on this much more because its getting more complicated and failing more and more with each ask (I was just trying to move some stupid buttons around in the UI and the AI was like, “Nah bro, I can’t.”)
• I have no idea how I’d share this with someone.
• I don’t think I’d be comfortable sharing this with someone (even though I think I did things like security right by putting credentials in the built-in keychain, etc.)
• I guess this is where the road stops.

I’m picky about software, so the bar for my dreams is high. But I’m also lazy, so my patience is quite low.

The intersection of: the LLM failing over and over + my inability to troubleshoot any of it + not wanting to learn = a bad combination for persevering through debugging.

Which made me say: “Screw it, I’ll build it as a website!”

But websites don’t really work for this kind of app because of CORS. I can’t just stick an article’s URL in an <iframe> and preview it because certain sites have cross site headers that don’t allow it to display under another domain.

But that didn’t stop me. I tried building the idea anyway as just a list view. I could install this as a web app on my Mac and I'd get a simple list view:

Anytime I clicked on a link, it would open in my default browser. Actually not a bad experience.

It worked pretty decent on my phone too. Once I visited my preview deploy, I could "isntall" it to my home screen and then when I opened it, I'd have my latest unread articles. Clicking on any of them would open a webview that I could easily dismiss and get back to my list.

Not too bad.

But not what I wanted, especially on desktop.

It seemed like the only option to 1) get exactly what I wanted, and 2) distribute it — all in a way that I could understand in case something went wrong or I had to overcome an obstacle — was to make a native app.

At this point, I was thinking: “I’m too tired to learn Apple development right now, and I’ve worked for a long time on the web, so I may as well leverage the skills that I got.”

So I vibed an Electron app because Electron will let me get around the cross site request issues of a website.

This was my very first Electron app and, again, the LLM helped me go from nothing to something quite quickly (but this time I could understand my something way better).

The idea was the same: unread articles on the left, a preview of any selected articles on the right. Here’s a screenshot:

It’s fine. Not really what I want. But it’s a starting point.

Is it better than Reeder? Hell no.

Is it my wildest dreams realized? Also no.

But it’s a prototype of an idea I’ve wanted to explore.

I”m not sure I’ll go any further on it. It’s hacky enough that I can grasp a vision for what it could be. The question is: do I actually want this? Is this experience something I want in the long run?

I think it could be. But I have to figure out exactly how I want to build it as a complementary experience to my preferred way of going through my RSS feed.

Which won't be your preference.

Which is why I'm not sharing it.

So what’s my takeaway from all this? I don’t know. That’s why I’m typing this all out in a blog post.

Vibe coding is kinda cool. It lets you go from “blank slate” to “something” way faster and easier than before.

But you have to be mindful of what you make easy. You know what else is easy? Fast food. But I don’t want that all the time.

In fact, vibe coding kinda left me with that feeling I get after indulging in social media, like “What just happened? Two hours have passed and what did I even spend my time doing? Just mindlessly chasing novelty?” It’s fun and easy to mindlessly chasing your whims. But part of me thinks the next best step for this is to sit and think about what I actually want, rather than just yeeting the next prompt out.

I’ve quipped before that our new timelines are something like:

• Nothing -> Something? 1hr.
• Something -> Something Good? 1 year.

The making from nothing isn't as hard anymore. But everything after that still is. Understanding it. Making it good. Distributing it. Supporting it. Maintaining it. All that stuff. When you know absolutely nothing about those — like I did with macOS development — things are still hard.

After all this time vibing, instead of feeling closer to my dream, I actually kinda feel further from it. Like the LLM helped close the gap in understanding what it would actually take for me to realize my dreams. Which made me really appreciate the folks who have poured a lot of time and thought and effort into building RSS readers I use on a day-to-day basis.

Thank you makers of Feedbin & Reeder & others through the years. I’ll gladly pay you $$$ for your thought and care.

In the meantime, I may or may not be over here slowly iterating on my own supplemental RSS experience. In fact, I might’ve just found the name: RxSSuplement.

Reply via: Email · Mastodon · Bluesky

Related posts linking here: (2026) Prototyping with LLMs

The good news here is, you don’t have to take my word for it. Switching browsers is hard, and maybe you don’t want to do it just for vertical tabs. But update Chrome, right-click the tab bar, and just see what happens when you select Show Tabs Vertically. I bet you’ll never go back.

And there we go, the last of the major browsers has added side tabs, validating my opinion that Arc is right up there with ChatGPT for the most influential new apps released in the past 5 years.

Editor's note: Safari technically has side tabs, although they are a weird add-on, not a replacement for the normal tabs. I'm counting it, but it's not really what we're talking about when we talk about Arc-style side tabs.

The excitement—and, frankly, sheer giddiness—with which this developer introduces his new app is the most wholesome thing I’ve seen this week.

From the minute when I started watching it, I was thinking that the last thing I needed was an app launcher, having had a Powerpack license for Alfred for… checks notes… nearly 14 years!

But the more I watched, the more I was intrigued. Before I could even get done with the video, I had the app and the Pro license.

Yes, I am aware I have a problem.

(Yes, I know Raycast can do everything. If you like it, cool.)

The mindset I’ve noticed is that many developers are suspicious of browser features but trusting of third-party libraries.

Developers are more likely to trust, say, Bootstrap than they are to trust CSS grid or custom properties. Developers are more likely to trust React than they are to trust web components.

That post got some thoughtful responses but I never really understood the imbalance of trust and suspicion:

I’m kind of confused by this prevalent mindset of trusting third-party code more than built-in browser features.

But something happened recently that helped me understand that mindset better.

I wrote a while back about how the datalist element on iOS has been completely fucked up. It’s worse than if Safari simply didn’t support it.

Breaking the web like that should be a five-alarm fire, but nobody is in any rush to fix it. I recall a similar lackadaisical attitude when Safari completely broke their implentation of IndexedDB.

I had it in my head that browser features followed a forward path generally. They’d be iterated on and improved on to iron out any glitches, but it was reasonable to expect things to get better with each new version of a browser.

Now I see that’s not necessarily the case.

Had I used an over-engineered JavaScript library instead of the datalist element, I wouldn’t be facing the current situation of having to use browser-sniffing to avoid sending a standard HTML element to any browser on iOS.

Sure, that third-party JavaScript would mean that users are downloading more code, and it probably wouldn’t work well with assistive technology, but as long as I didn’t touch it, it would continue to work. That should be true of web standards—I should be able to use them secure in the knowledge that they won’t suddenly shit the bed.

Perhaps I should be grateful to Apple for dispelling my naïveté. I now have much more empathy and understanding for web developers who are suspicious of web standards and prefer to use third-party libraries instead.

Good job, Apple. Happy anniversary.

As I mentioned, the book series involves a man (and his cat, the cat is crucial) experiencing a real-world RPG and like a RPG, it's got achievements as the character progress through the dungeon. For those of you aren't gamers, most games now will give you an achievement for performing some task. These achievements give you nothing but bragging rights and a slight feeling of accomplishment, but some folks get really excited about them.

In the books, the main characters will also get achievements and typically the achievement is incredibly snarky and sarcastic. As an example:

And another:

These almost always make me LOL and I thought - what if I could make a simple web tool to generate these on the fly? I did so, using Chrome's built-in AI feature, which as of today is still behind a flag, so if you want to play with this, you'll need to follow the instructions on which flags to enable in your browser. If you've done that, and don't care about how this tool was built, you can head over to the demo now: https://dcc.raymondcamden.com/

The Code

The code behind this was a rather simple usage of the Chrome Prompt API. Here's the code that initializes the session:

session = await LanguageModel.create({
    initialPrompts:[
                { 
                    role: 'system', 
                    content: 
`Generate an achievement announcement in the style of 
the Dungeon Crawler Carl series. You will be given a 
prompt to base the achievement on, which will be an 
ordinary, mundane task. The achievement you generate
should have the snarky, over the top prose associated 
with the book.

do not comment about carl at all, or have any other output 
except the achievement title, text, and rewards` 
                }
            ],		
        monitor(m) {
                m.addEventListener("downloadprogress", e => {
                    console.log(`Downloaded ${e.loaded * 100}%`);
                    if(e.loaded === 0 || e.loaded === 1) {
                        $status.innerHTML = '';
                        return;
                    }
                    $status.innerHTML = `Downloading AI model, currently at ${Math.floor(e.loaded * 100)}%`;
                });
            }		
    });

Make note of the system instruction which is what guides the model when generating content. Your input is basically a "mundane" thing you've done, like wash dishes or take out the trash. When you've entered that and hit submit, I then simply get the achievement:

let achievement = JSON.parse(await session.prompt(input, {  
    responseConstraint: schema,
  }));

Notice the responseConstraint value? This is how I get precise results back, in my case an achievement title, the text, and a list of rewards. This is defined earlier in my code:

let schema = {
	"type": "object",
	"properties": {
		"title": {
			"type":"string"
		},
		"achievementText": {
			"type":"string"
		},
		"rewards": {
			"type":"array",
			"items":{
				"type":"string"
			}
		},
  },
  "additionalProperties": false
};

And that's pretty much it. The rest of the code is straight up DOM manipulation.

The Design

As for the look and feel of the app, I made use of Cursor and one simple prompt:

im going to be building a tool that uses Chrome AI to generate random achievements in the style of Dungeon Crawler Carl. i need your help with a design. i dont need you to do any of the javascript, just create my scaffold for me. its one web page and the title should be, "DCC Achievement Generator". There is a prompt, "What mundane thing did you get done?", a form field for the task, and then it will render out the achievment.

Achievements have a title, a body of text, and a list of rewards (bulleted list). Create a nice design for the achievement as well (just make something up for now)

I'm just now noticing the typo and thankfully Cursor didn't complain. I let it output my HTML and CSS and then simply copied that over to CodePen so I could start working on the actual implementation. I think the only work I needed to do was add some IDs to the HTML in order for my JavaScript to connect to what it needed to update. The design Cursor created was just fine:

In case you can't read that, my input was: i wrote a blog post and the achievement I received was:

Results May Vary

If you've got the flags enabled and try it out, please share your results, and let me know what you think. Feel free to fork the pen and modify to your heart's content. Also... Mongo is appalled!

See the Pen DCC Generator by Raymond Camden (@cfjedimaster) on CodePen.

Photo by Giorgio Trovato on Unsplash

i hope everyone remembers what this was all for.

Read the writings of Hamilton or Washington or Jefferson or MLK or the inscription on the Statue of Liberty. They wished to rid us of monarchies and professional armies and tyrants and hate.

Don't give that up. Fly your flag upside down, fly a Gadsden flag or Serapis flag. Just don't forget. #now

Consider the follower HTML:

<main>
  <p>I am main content.</p>
</main>

The <main> content could be simple headings and paragraphs.

It could also be complex HTML patterns from a Content Management System (CMS) like the WordPress block editor, or ACF flexible content (a personal favourite).

Typically when working with CMS output, the main content will be restricted to a maximum width for readable line lengths. We could use a CSS grid to achieve such a layout. Below is a visual example using the Chromium dev tools to highlight grid lines.

This example uses five columns with no gap resulting in six grid lines.

main {
  display: grid;
  grid-template-columns:
    auto
    30px
    min(45rem, calc(100% -  60px))
    30px
    auto;

  :where(&) > * {
    grid-column: 3 / 4;
  }
}

The two outer most columns are auto meaning they can expand to fill space or collapse to zero-width. The two inner columns are 30px which act as a margin. The centre column is the smallest or two values; either 45rem, or the full viewport width (minus the margins).

Counting grid line correctly requires embarrassing finger math and pointing at the screen. Thankfully we can name the lines.

main {
  display: grid;
  grid-template-columns:
    [inline-start]
    auto
    [margin-start]
    30px
    [main-start]
    min(45rem, calc(100% -  60px))
    [main-end]
    30px
    [margin-end]
    auto
    [inline-end];

  :where(&) > * {
    grid-column: main;
  }
}

I set a default column of main for all child elements.

Of course, we could have done this the old fashioned way. Something like:

main {
  margin-inline: auto;
  max-inline-size: 45rem;
  padding-inline: 30px;
}

But grid has so much more potential to unlock!

What if a fancy CMS wraps a paragraph in a block with the class full-width.

<main>
  <p>I am main content.</p>
  <div class="full-width">
    <p>I am subgrid.</p>
  </div>
</main>

This block is expected to magically extend a background to the full-width of the viewport like the example below.

This used to be a nightmare to code but with CSS subgrid it’s a piece of cake.

.full-width {
  display: grid;
  grid-column: inline;
  grid-template-columns: subgrid;

  :where(&) > * {
    grid-column: main;
  }
}

We break out of the main column by changing the grid-column to inline — that’s the name I chose for the outer most grid lines. We then inherit the parent grid using the subgrid template. Finally, the nested children are moved back to the main column.

The :where selector keeps specificity low. This allows a single class to override the default column. CSS subgrid isn’t restricted to one level. We could keep nesting full-width blocks inside each other and they would all break containment.

If we wanted to create a “boxed” style we can simply change the grid-column to margin instead of inline. This is why I put the margins inside.

In hindsight my grid line names are probably confusing, but I don’t have time to edit the examples so go paint your own bikeshed :)

On smaller viewports below 45rem the outer most columns collapse to zero-width and the “boxed” style looks exactly like the full-width style.

More columns

This approach is not restricted to one centred column. See my CodePen example and the screenshot below. I split the main content in half to achieve a two-column block where the text edge still aligns, but the image covers the available space.

CSS subgrid is perfect for WordPress and other CMS content that is spat out as a giant blob of HTML. We basically have to centre the content wrapper for top-level prose to look presentable. With the technique I’ve shown we can break out more complex block patterns and then use subgrid to align their contents back inside. It only takes a single class to start!

Here’s the CodePen link again if you missed it.

Look how clean that HTML is! Subgrid helps us avoid repetitive nested wrappers. Not to mention any negative margin shenanigans.

Powerful stuff, right?

Browser support? Yes. Good enough that I’ve not had any complaints. Your mileage may vary, I am not a lawyer. Don’t subgrid and drive.

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

April Fools’ Day on the web exemplifies what philosopher Jean Baudrillard called a deterrence machine — a single day on the calendar to celebrate funny fake news is like a theme park designed to make the fake constructs beyond its gates seem real by comparison. And oftentimes, the online pranks on April 1st are indistinguishable from the bizarreness that ensues all year round in the “real” virtual world.

Real things that looked like April Fools’ pranks

Tech has a history of April Fools’ Day announcements that remind me of what Philip K. Dick called “fake fakes,” emerging every year like real animals surreptitiously replacing the fake ones at Disneyland.

For instance, in 2004, people famously thought Gmail was an April Fools’ joke since it was announced on April 1st.

And on April Fools’ Day in 2013, long before the current generation of AI, Tom Murphy announced an AI that learns to play NES games. It was the real deal, even though he published the research paper and source code on “SIGBOVIK 2013, an April 1st conference that usually publishes fake research. Mine is real!” In Tom’s demo, the AI even devised the strategy of indefinitely pausing Tetris, because in that game on NES, “The only way to win is not to play.”

To give a more personal example of real tech that could be mistaken for an April Fools’ joke, my article on pure CSS collision detection was published on April 1st, 2025, my local time. I was amused when someone commented that using min to detect if a paddle was in range of a ball seemed like a clever hack that “brings up the question: Should game logic be done in CSS?” Of course it shouldn’t! I wasn’t seriously proposing this as the future of web game development.

I replied that if the commenter can take the idea seriously for a minute, it’s a testament to how far CSS has come as a language. It seems even funnier in hindsight, now that the range syntax has come to style queries, meaning we no longer need the min hack. So, maybe everyone should make games in CSS now, if the min hack was the only deal breaker (I kid because I love).

My CSS collision detection demo had a resurgence in popularity recently, when Chris Coyier chose it as a picked Pen. And in that CodePen, a comment again made me laugh: “Can it be multiplayer/online?” Yet, once I stopped laughing, I found myself trying to get a multiplayer mode working. Whether I can or not, I guess the joke’s on me for taking CSS hacking too seriously.

The thing is, much of what we have on the web this year seemed unthinkable last year.

Even the story of the origin of April Fool’s Day sounds like a geeky April Fools’ joke — the leading theory is that the 15th-century equivalent of the Y2K bug had some foolish people incorrectly celebrating the new year on April 1st when the Pope changed the calendars in France from the Julian Calendar to the Gregorian Calendar. And — April Fools’ again! — that’s a legend nobody has been able to prove happened.

But whichever way you feel about the constant disruptions at the heart of the evolution of tech, the disruptions work like pranks by flipping common narratives on their heads in the same way April Fools’ Day does. With that in mind, let’s go through history with an eye for exploring the core of truth inside the jokes of April Fools’ Days passed.

Note: These are the historical pranks I consider the top 10 most noteworthy, rather than the “best.” You’ll see that some of them crossed the line and/or backfired.

Google April Fools’ games

Google is famous for its April Fools’ pranks, but they’ve also historically blurred the line between pranks and features. For example, on April 1st 2019, Google introduced a temporary easter egg that transformed Google Calendar into a Space Invaders game. It was such a cool “joke” that nowadays, there’s a Chrome extension that offers a similar experience, turning your Google Calendar into a Breakout game. This extension also offers the option to actually delete items that your ball hit from your calendar at the end of a game.

On April Fools’ Day the same year as the original calendar game, Google also released a feature that allowed Google Maps users to play Snake on maps.

Personal Sidenote: The Google gag inspired an unreleased game I once made with an overworld that’s a gamified calendar, in which your character is trying to avoid an abusive partner by creating excuses not to be at home at the same time as their partner, but that’s a little dark for April Fools’.

Prank npm packages

In March 2016, a legit — if arguably trivial — eleven-line package was deleted from the npm registry after its creator decided to boycott npm. Turns out that deletion disrupted big companies whose code relied on the left-pad package and this prompted npm to change its policies on which packages can be deleted. I mention this because the humour of the npm packages released as jokes often revolves around poking fun at JavaScript developers’ overuse of dependencies that might not be needed.

Here is a 0kb npm package called vanilla-javascript and a page for the Vanilla JS “framework” that is always 0kb, no matter which features you add to the “bundle.” It lists all the JavaScript frameworks as “plugins.” Some of the dependent packages for vanilla-javascript are quite funny. I like false-js, which ensures true and false are defined properly. The library can be initialized with the settings disableAprilFoolsSideEffects, definitelyDisableAprilFoolsSideEffects, and strictDisableAprilFoolsSideEffectsCheck. If you read the source code, there is a comment saying, “Haha, this code is obfuscated, you’ll never figure out what happens on April Fools.”

There is also this useless library to get the current day. It seems plausible till you look carefully at the website and the description: “This package is ephemeral for April Fools’ Day and will be removed at some point.“ The testimonials from fictional time-traveling characters are also a bit of a giveaway, and you have to love that he updated it every day for months, “because… why not? 🤷‍♂️”

More “terrible npm packages” for April Fools’ are here.

aprilFools.css

There’s another category of dependencies that are functional but used for playing April Fools pranks. For instance, aprilFools.css by Wes Bos, which has a comment at the top saying:

/*
  I assume no responsibility for angry co-workers or lost productivity
  Put these CSS definitons into your co-workers Custom.css file.
  They will be applied to every website they visit as well as their developer tools.
*/

It does things like use CSS transforms to turn the page upside down.

It strikes me that following the advice in the comments could be a slippery slope to a dark place of workplace bullying, if you were to try it on the wrong coworker, just because they left their computer unlocked. As Chris Coyier pointed out in his post on practical jokes in the browser:

“Fair warning on this stuff… you gotta be tasteful. Putting someone’s stapler in the jello is pretty hilarious unless it’s somehow a family heirloom, or it’s someone who’s been the target of a little too much office prankery to the point it isn’t funny anymore.”

April Fool’s pranks using VS Code Extensions

While we’re on the topic of behavior that blurs the line between pranks and workplace bullying, let’s talk about this list of VS Code Extensions that could be used to prank a coworker by causing their code editor UI to behave unexpectedly. Most of the examples sound funny and harmless, like having the IDE intermittently pop up “Dad Jokes” or make funny sounds when typing. Changing the code editor to resemble Slack using a theme is also funny.

Then there’s the last example that made me do a double-take: “Imagine hitting CTRL + S to save your work and then it gets erased!” Yeah, if I were interviewing someone and they mentioned they consider this a funny joke, I would end the interview there. And if anyone ever does this to me, I’m going to HR.

Pranks by the W3C

I don’t think of the W3C as having a sense of humor, although I guess getting me excited about HTML imports back in the day, only to discontinue them, was funny in hindsight, if you have a dark sense of humor. Nevertheless, they have posted pranks on their official website, such as restyling to make their page look like a nineties GeoCities website in 2012, or claiming they were reviving the <blink> tag in 2021. There’s a theme of playing on the nostalgia of people my age who want these things to be real.

Sidenote: If you want more Nineties internet experiences, the game Hypnospace Outlaw, set on a retro internet in an alternative 1999, might be up your alley.

Other sites over the years have played a similar joke, which can never fail to charm an old-timer like me who remembers using a web like this at the public library, back when the internet was too expensive for my family to afford at home.

StackOverflow retro restyle

I can’t get enough of these nostalgia trips, so here’s what StackOverflow looked like on April Fools’ Day in 2019. They turned the site “full GeoCities” for fun. Yet everything comes full circle. Now StackOverflow itself seems destined to become as fossilized as GeoCities. Even so, the site is currently attempting a new, real redesign to survive rather than for fun. It’s sobering to consider that maybe the only StackOverflow experience for the next generation of coders will be if ChatGPT gets a StackOverflow restyle on a future April Fools’.

Stack Egg

While we’re on the topic of StackOverflow, their Stack Egg prank from 2015 was very cool, but it might win my award for the most over-engineered April Fools’ prank that caused the most serious problems for a website. The premise was another Nineties throwback, this time to the nineties Tamagotchi craze.

The idea, as the creator describes it, was that every site on the Stack Exchange network would have its own “Stack Egg,” representing that site. The goal was to collaboratively keep your metaphorical “site” alive using hypothetical actions named after real actions on the site, such as upvotes to feed the Tamagotchi, and review actions to clean up the poop so the Tamagotchi doesn’t get sick.

It was a nifty concept, although like Google’s April Fools’ games, it’s more neat than laugh-out-loud funny. The part that does make me laugh — I don’t feel too guilty saying it since it was more than a decade ago — was that this is a game about keeping the websites alive, and it inadvertently DDoS-ed its own websites and took down the whole StackExchange network.

And yet, the creators thought the fact that they had the foresight to implement a feature flag that allowed switching it off meant this was a case study in “Operational Excellence in AFPs (April Fools’ Pranks).” Yep, that is an actual article published in a peer-reviewed journal. According to the article, the engineers involved pushed a fix about two hours later to salvage the prank. Code Golf was the winner of the game, in case you’re wondering. According to the same post that announced the winner, “it’s by no means designed to withstand exploits,” and in the two days the feature was live, users discovered a vulnerability that was “close to voting fraud.”

I mentioned the over-engineering, so here’s the part that makes the unintentional punchline even funnier: rather than investing more time guarding against the basics, such as not bringing down the website and considering security, the creator spent time making his own Turing-complete language to handle the LCD-style animations, “because I wanted to! Creating a programming language is fun.”

That’s such a classically geeky way to prioritize!

Google Mic Drop

If Stack Egg created the most issues I’ve ever heard of for a website that created the prank, the most mean-spirited high-profile UI prank — which caused the most problems for users — has to be Google Mic Drop. It dropped (pun intended) on April Fools’ Day 2016, shortly after Google changed its motto from “don’t be evil” to “do the right thing.” Then, they promptly redefined the “right thing” as sabotaging people’s professional reputations with a minion GIF.

Google added a button, nice and close to the regular “Send” button in Gmail, that would send a farewell message to the recipient with an animated Minion dropping a mic then block all emails from that recipient permanently, without prompting the sender to confirm first. Better still, there was a bug that meant the recipient could receive that “GIF of death” and the block, even if the sender managed to press the correct “Send” button in the confusing new UI.

The “hilarity” that ensued included:

• A funeral home accidentally sent a mic drop and block to a grieving family.
• A man posted on the Gmail help forum, “Thanks to Mic Drop, I just lost my job.”

Google disabled the feature before the end of April Fools’ Day and issued an apology saying, “It looks like we pranked ourselves this year.” I am not sure how the joke was on Google, so much as the people whose livelihoods and relationships were destroyed.

Remember when I said in the intro that April Fools’ is a distraction from how the joke is on us for believing that the web is what it seems? This Google prank was a reminder that if you believe an advertising company masquerading as a search company has the judgment and ethics to prioritize your interests, when they hoard your personal data and don’t actually care if you can find anything, the real mic drop moment is when you realize that your career and relationships are a data point in Google’s next A/B test.

Prank UI/UX research articles

The funniest part of these April Fools’ UI/UX advice articles is that they’re published by a serious, high-profile consultancy and research group, so the authors work hard to make it obvious these are April Fools’ hoaxes. In each article, “APRIL FOOLS” is in the title in ALL CAPS. And in the first paragraph of the newer hoax articles: “This article was published as an April Fool’s hoax and does not contain real recommendations.” I like to imagine the marketing department thought this was a great idea, and then the authors of the articles tried their best not to make fools of themselves. I noticed the group stopped posting hoax content after 2022.

Sidenote: Educational resources people rely on as a source may not be the best place for prank posts. It reminds me of this peer-reviewed radiology website that on April Fools ‘ Day 2015 posted a hoax X-ray image under the title “Ectopia cordis interna – Tin(Man) syndrome.” Over the years, medical professionals circulated the image unaware it was a hoax, and then, in 2025, six medical journal case studies involving the made-up condition had to be retracted.

Actually, the hoax UI/UX articles are educational, in a UI antipatterns kind of way, such as “Users Love Change: Combatting a UX Myth,” which advocates redesigning the UI as often as possible for the heck of it — except I can’t help but feel JIRA took that advice literally. The “Canine UX” article teaches ideas of user personas and design in a fun way. And “The User Experience of Public Bathrooms” reads as if George Costanza from Seinfeld turned his toilet obsession into a lesson in usability.

DigitalOcean buys codepen.io

Regular readers of CSS-Tricks know that the founder, Chris Coyier, really did decide in 2022 to sell the website to our current stewards, DigitalOcean, so that he could focus on his other projects, such as CodePen. Therefore, the announcement on CodePen that DigitalOcean was also buying that website seemed maddeningly plausible. The level of detail in the hoax announcement increased verisimilitude. For instance, the claim that users could use custom domain names on CodePen for free, as long as the domain was DigitalOcean-hosted. In fact, the only sign it was a prank is that nobody anywhere announced anything like this, unless you count me posting it today on a DigitalOcean-owned website.

Happy April Fools’ Day, everyone!

Front-End Fools: Top 10 April Fools’ UI Pranks of All Time originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.