css bugs

css is probably the most bug-ridden part of front-end development. In your quest to squash every minor bug standing between you and the perfectly rendered website, you'll be battling hordes of outdated browsers, unclear css specifications, half-finished implementations and just plain wrong browser code. To ease the pain just a little, here is a collection of minor fixes to get you on your way.

ios7 safari lazy repaint bug / android stock browser had a baby

date
September 25, 2013
permalink

Last week iOS7 finally saw the light of day. For Apple it was an important step away from their original mobile design paradigms, I on the other hand was looking forward to the new Safari (which always comes bundled with major iOS updates), at least until I actually took it for a spin. Apart from some dreadful UI problems that are sure to haunt us in the coming months, I saw some rendering bugs I really wish I hadn't.

It's not entirely unnatural for stuff to break with a new browser update, yet one problem in particular stood out as quite perplexing. For some reason the main navigation flyout on my smallest responsive view had stopped working. Rather than fail completely, the entire flyout just wouldn't appear unless you started to scroll a little, after which it reappeared where it was supposed to be. The thing that got me worried is that the code I used to make this flyout work is incredibly basic.

body #site {right:-17em; width:17em; position:fixed;} body.showSite #site {right:0;}

Of course I have some extra css on there to make everything transition more smoothly between states, but even with that bit of code gone it just wouldn't work. It didn't take me very long to remember a similar bug I once encountered though. A nifty little bug on the Android Stock Browser I often use as an anecdote to illustrate what a crap browser that really is.

What happens is that browsers are getting a little too lazy for their own good. When a class is set (or removed) using javascript (and especially when it is set as high up the dom tree as the body element), they pretty much have to run through the entire page to check whether one or more elements are impacted on css level (the extra class might trigger some extra selectors). In order to save time, some browsers are attempting an educated guess. Some attempts fail, painfully, which happens to be the case on Safari for iOS7.

There are basically two ways to fix this. Either make sure the class is set on the element that is affected (you might even gain a minor performance boost), as the browser knows it should at least re-evaluate the element that received the extra class. Not too difficult, but not always possible when multiple elements on a page are affected by a single state change.

body #site.showSite {...}

The other fix is to force a repaint on the element with javascript. On Android Stock Browser you could fix things by applying zoom:1; (which felt rather appropriate), on the latest Safari for iOS z-index seems to do the trick.

$("#site").css("z-index", "5");

It's a bit worrisome to see such bugs introduced in the latest update of what is one of the oldest browsers on mobile. I understand the pressure they face to improve performance with each new iteration of their browser, but this clearly shouldn't go at the expense of faulty rendering/lazy repaints. This really is basic css that shouldn't be allowed to break, sadly I don't expect to see a fix for it any time soon.