Ran into a tiny little design bug yesterday. Maybe it’d be of interest to you.

Last week, I thought I’d clean up my blog entries a bit. (Yep. I’m that fun.) Before, there were a couple short but dense paragraphs, each containing a truckload of links: one linking to my archives, a couple links to read either the previous and next posts, and then a few trillion links to “share” the “entry” on “social media” “web-sites.” Now, that’s all been reduced to two links, one for the preceding entry, and one for the next one.

(This is just riveting stuff, I do realize. Sorry. Bear with me.)

Anyway! After a bit of whittling, I ended up here:

If the video’s not available to you, you’re not missing too much: it shows two links side-by-side, with a little arrow animation that appears on hover or focus. The one slightly fancy bit is that I’m applying position: sticky to the list if the browser’s above a certain height. (Currently, @media (min-height: 40em).) That means that in the browsers that support that property, the links will appear anchored to the bottom of the browser’s viewport until the links scroll past their default, “natural” position in the page. Once they reach that point, they’ll stop scrolling with the browser.

If you’re a sighted user, and you’re visiting this page with Safari, Firefox, or a relatively recent build of Chrome, you should see the behavior described above. But in terms of browser implementation, position: sticky is not…widely supported, as these things go. But that’s okay: if a browser doesn’t understand that particular bit of CSS, the links’ll sit at the bottom of the article. And as enhancements go, that’s just fine with me.

But. There’s a weird little thing happening in Chrome, or at least in versions below 57: specifically, it’s happening whenever someone hovers on, or focuses into, the left-hand link. Here’s another video:

It’s a minor issue, but a noticeable one. When the arrow animation occurs — on :hover or on :focus — the entire list — the position: sticky element — shifts to the right. When the arrow returns to its default position, so does its parent.

This is…weird, since the animation itself’s a transform: translateX( -1em ) transition, which doesn’t affect the layout of the parent. Or, well, it shouldn’t — but here we are.

I’ve mocked up a simpler example — a “reduced test case,” as the kids say — which seems like it might be related to this Chromium bug.

And the oddest thing of all? I started writing this blog entry yesterday, on some decimal-ridden version of Chrome 56; today, Chrome updated to version 57, and the bug appears to have fixed itself. Which is weird timing, but great news! For me, the takeaway here is that MY BLOG HAS MAGICAL HEALING PROPERTIES it was okay to ship this little design tweak, even with the bug. Designing for the web means, for better or for worse, that not every browser looks the same. And trusting in that fact can, sometimes, work out okay.

(I’d still like container queries, though.)