The despair that became a library
bleedblend started as a bug.
We were building reef, and a `backdrop-filter` sticky banner kept getting its blur clipped at the notch. WebKit forces the filter's sample point below the safe area, so the frosted strip under the status bar exposed the raw background underneath — a hard seam right where the design was supposed to feel seamless. The usual move is to fight it: nudge the element, fake a layer, give up and ship the seam. Instead we painted that exposed strip *on purpose*, so the status bar took the brand color cleanly. Bug turned into feature. Feature turned into a habit.
Then Safari 26 landed, and the habit turned into a rabbit hole.
The despair
Safari 26 decides the color of its chrome — the status bar and the URL bar — from whatever sits at the very edge of the viewport. Same model on iPhone, iPad, and Mac. Elegant idea. The problem is the rules are quirky, undocumented, and they shift between versions, and on iPhone and iPad they bite hardest:
- The viewport bottom tints mint while your belt section is dark teal — a visible
**seam** at the chrome boundary.
- A compact tab bar appears and the tint "shifts" by 30px, because `100lvh` and
`100svh` no longer agree on where the chrome is.
- A user pulls past the footer and rubber-band overscroll exposes the `<html>`
background — the *wrong* color, flashing at the bottom of every page.
- `theme-color` — the one knob you'd reach for — is simply ignored on iOS 26.
- `position: fixed` elements tint the chrome correctly… except when they don't,
depending on opacity, display, edge proximity, and, as far as we could tell, mood.
Every one of those was discovered the hard way, on cver.net's own full-bleed gradient homepage — the gradient, the sections, the footer, the overscroll, all arguing with each other across three devices. None of it is in any changelog. You find it by shipping, watching a real phone get it wrong, and going back in.
The turn
At some point the goal stopped being "stop the bug" and became "understand the model well enough to drive it." Safari isn't drawing the chrome wrong — it's sampling exactly what you put at the edge. So the fix isn't to override Safari; it's to put the *right thing* at the edge, every time, on every device. Read the gradient from the page. Extend it into the overscroll zone. Step back where Safari's natural sampling already looks right. Give a sticky header a way to say "this is mine, tint the chrome to match me."
That's the whole library. One import, and the chrome lands on the right color — not because we repaint it, but because we stopped feeding it the wrong color.
It shipped in production before it became a package. The README is the calm version — what it does, how to use it, the escape hatches. This is the other version: the despair it came out of, kept here on purpose, so the README can just be a tool that works.
Keep reading
-
Fifteen years of Trello, then a plugin of a plugin
The origin of tugtile: Trello slowly grew heavy, obsidian-kanban went quiet, and after one too many plugins written for a plugin, rebuilding the whole card table was the only move left.
-
The cube solver that refuses to be confidently wrong
cubeconjure reads a Rubik's cube through your Mac's camera and tells you how to solve it. The hard part was never the solving — it was reading six colors honestly under real light. This is the story of how 'just read the stickers' turned into a lesson about not being confidently wrong, on either side of the camera.
-
Why your Mac cleaner found 47 GB (and where it really went)
A friendly teardown of how black-box Mac cleaners work — the big scary number, the invisible delete, the one thing almost none of them tell you about APFS snapshots — so you can judge any cleaner, including ours.