Honesty time: somewhere this quarter, you absolutely shoved a swipe handler into a desktop layout because someone in the meeting said the experience should feel consistent. (We've all shipped it. It's fine. It's not fine.) The version of you who did that is the one Bramus is writing to in his new post, and the verdict is overdue.

The piece's frame is a callback. Per the source, the community-built single-purpose site dowebsitesneedtolookexactlythesameineverybrowser.com is what dragged the field, kicking, into accepting that pixel-perfect cross-browser parity was a fantasy. Progressive enhancement won. Cool. Bramus's argument is that we have rebuilt the same trap one floor up: the demand now is that sites must function exactly the same on every platform, regardless of input. Same disease, new costume.

The old fight, fought again

Per the source, the inputs we keep trying to flatten are wildly different beasts. Mouse wheel scrolling on desktop. Swipe and pinch-zoom on touch. Hand or eye scrolling on the Vision Pro. Trying to make all of those resolve to a single behaviour is how you ship the worst version of each: a desktop site with a fake swipe carousel and no keyboard support, a touch site with a hover state that needs a long-press to fire, and a Vision Pro tab where nothing wants to focus.

Here's the rad part of how the source flips the framing. Input-specific features are not a regression. They are progressive enhancement, just on the input axis instead of the rendering one. The desktop user gets the thing the desktop is great at. The touch user gets the thing touch is great at. The baseline still works for everyone, so nobody is locked out. You just stopped pretending the keyboard user wanted to mime a swipe.

The examples are the receipts. Per the source, YouTube, GitHub, Gmail and Feedly all expose keyboard shortcuts to power users; typically ? brings up the shortcuts dialog, and YouTube uses f to fullscreen the current video. None of those four products are worse on touch because the keyboard layer exists. The keyboard user got affordances that map to their input. Touch gets its own. Think about what that actually means for one beat. A mouse user on Gmail is not deprived of anything when j and k move between conversations. The shortcut is invisible to them. That is what an additive design looks like.

Drag-scrolling, and the part nobody is shipping yet

The forward-look the source picks up on is desktop drag-scrolling. Per the source, Bramus filed CSSWG Issue #9811 on Draggable Scrollers in 2024, proposing that the touch convention of pressing and dragging the content to scroll should be expressible on desktop too, where the platform currently insists on scrollbars and wheels. That's the bit that should make every layout author lean in. Read the issue carefully. The proposal is about letting the author opt the desktop user into a touch-style affordance where it actually fits the content, without breaking wheel, scrollbar or keyboard scrolling underneath. Additive again. Same pattern.

And here's a fast tangent: this also kills the entire 2018-era "fake horizontal carousel with a wheel listener" category of hack, but only if the platform actually ships the primitive. Until then we're stuck rolling our own, which is the whole motivation for filing the issue in the first place.

The score

The parity reflex is the cross-browser-pixel-perfect reflex with a new haircut. Both come from the same place: a discomfort with the web's actual nature, which is that it adapts. Different machine, different input, different ergonomics. Bramus names the new misconception out loud. That's the framing you need the next time someone writes a brief demanding platform-consistent behaviour.

Stop sanding off the affordances each platform is actually good at. Build the baseline. Layer the input-specific stuff on top. Let the keyboard user keyboard, the touch user touch, and the hand-and-eye-on-Vision-Pro user do whatever wild thing they are doing. Score for the framing: a flat 8/10 — the only point off is that we are somehow having this conversation a second time.