19
Button component broke our checkout flow for 3 days straight
Honestly I was sitting in my home office on a Tuesday when I got a Slack from our QA lead saying the checkout button wasn't showing up on mobile Safari. Turns out someone on our team added a z-index of 9999 to a new toast notification and it was covering the button entirely. We spent 3 days digging through 40 component files before we found it. Has anyone else had a single CSS property wreck an entire page like that?
2 comments
Log in to join the discussion
Log In2 Comments
evand653d ago
Start by adding a z-index stack management system. Your mileages may vary, but in my experience a simple spreadsheet or even a big comment at the top of your main CSS file listing every z-index value you're using works wonders. I've been burned by the "just put 9999 on it" approach so many times that I now keep a hard limit of like 5 or 6 layers max. Also run a quick visual regression test every time you add a new overlay or toast - saved me twice already this year. Take this with a grain of salt but a single z-index collision can absolutely eat your whole week.
5
barbara4293d ago
Funny thing is I used to be one of those devs who just threw 9999 on everything and called it a day. But after a similar nightmare where our modal ended up behind the footer for two days I completely flipped my stance. Now I keep a simple note in our team wiki that lists every z-index value we use and what layer it belongs to. It sounds basic but it saves so much pain. Visual regression tests are the real MVP here too, catching those gaps before they hit production. Have you had to explain to a PM why a three pixel bug is costing a week of work?
3