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
100lvhand100svhno 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: fixedelements 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.