Width Bug on iDevices?

Today, I was “unfixing” a footer on a client’s site. One that, last year when we coded the website, they wanted fixed to the bottom of the browser viewport. But with the arrival of iDevices who “don’t do fixed positioning,” this footer placement is now being rethought. (As an aside, this makes me sad because just as Internet Explorer 6 was starting to die enough to use position:fixed for some cool things, the iDevices come along and wipe it out again. Joy.)

Anyway, what should have been a five minute quick fix turned into about 45 minutes of WTF? To begin, I removed the position:fixed as well as the bottom and left values. And voila, browsers were happy as clams. The footer was in the flow of the page, it came after the entire page’s container ended, and still spanned the full width of the page. So quick and easy, I decided not to charge this client for such a silly little thing.

Nasty little space

Then I get the email. “Ummm, Stef.? Check this screen shot from the iPad. What’s up with the right corner?”

Excellent question. Furthermore, I noticed the border at the top, which was placed on the body element, was also not going all the way across the device screen (with the same amount of gap). And so the sleuthing began.

I found (bouncing thoughts and getting suggestions from Greg) that I could actually add a width property with 105% value to the body element to fill the original, large gap in iDevices. But, of course, that 105% width created a horizontal scroll bar in regular browsers. The body width had to be fed to iDevices (and hidden from browsers) using a media query, like this:

@media screen and (max-device-width: 1024px) {
      body { width: 105%; }
}

(The 1024px value should target an iPad and below.) The one problem with this is that Android devices don’t display this odd space (I don’t have another smart phone to test with). Thus, using a media query, which they can read, gives them a bit more width than they need and they “wiggle around” a little as you touch scroll. A small tradeoff I suppose.

But WHY?

Initially, in trying to discern the cause, I was working off the idea that perhaps iDevices were leaving room for chrome on the right side even though they don’t add an actual scrollbar. I quickly dispelled this myth by creating a minimum test case with only the top border on the body, a container and a full-width footer beneath that. Oddly enough, that demo/test had only a small space to the right of the top border and the full width footer—not the wider space I’d seen before.

As I picked apart my very simple code, trying to see what might add to the horizontal width (there was nothing on the body element), there were only two possibilities I saw. My div.container had a border and padding (though they certainly shouldn’t affect the width of the body itself). I decided to increase the border to 10px on each side. And sure enough, I had a wider space.

Hmmmm, interesting. I decided to decrease the padding to see if that was having an effect as well. In fact, decreasing the padding, which decreased the overall div.container width to 964px did get rid of the space. So now I’ve deduced that it’s the overall size of the div.container causing the issue which is awesome since, even using a media query to feed a different width to iDevices won’t work. It cuts off the right side of the page based on the value of the width given and I’m not resizing the entire layout (images and all) to make iDevices happy).

And here’s the bug!

Essentially, the issue is this—if you have a container for your page that is wider than 980px (this includes typical box model stuff: width/padding/border) and you place something on the body element or even a full width div that is not contained in that container, those elements will be cut off outside the 980px width. This is not expected behavior. This is definitely a bug. Android doesn’t exhibit this behavior. I’d love to know what people find on other smart phones.

I went back to the body width of 105% through adding in the media query. Once again, the iDevice issue was fixed (though not exactly elegantly), and any other devices reading the media query also get a tad extra width. [Shrug] This is where we are for now.