Amazon’s sales dropped 1% with 100ms longer load times. Site performance is money, and this is a useful video on the basics of making a fast website.
I have been working on a grid design framework for able2know, and have been wrestling with the inconsistencies between browsers when it comes to percentage rounding. There are good static grid CSS frameworks out there (e.g. Blueprint, 960gs) but the attempts to convert them into liquid grids (e.g. Liquid Blueprint, fluid960gs) share the same bugs I was running into, where width is not correctly calculated and in IE6 and IE7 the effect was often dramatic, with columns jumping around when the browser is resized. At some widths everything would be perfect, but at others columns would wrap into the next row, breaking the layout. A couple of pixels off might not sound like much, but have a look at this video to see the effect on the layout those few pixels can have.
I set out to fix this problem, and began writing my own grid CSS framework, trying all sorts of different mathematical approaches to the problem (I was working with three columns so my initial suspicion was that the browsers were having a hard time dealing with fractions like 1/3). I also tried every IE CSS hack to try to coax the floats the grid uses into compliance, but no dice. So after more investigation, I learned that this is a rendering problem with no perfect solution for the browser manufacturs. The limitation is your monitor.
To make a very long story short, your monitor needs your browser to display objects sized in pixels. Browsers have no easy way around this problem, and there is no perfect solution. This, of course, doesn’t mean that the various browsers will find a consistent way to handle it, and as per usual IE managed to settle on the least optimal approach of the bunch.
First of all, let’s explain the problem. Let’s say you want to divide your layout into 4 columns. The pixels this area will represent may not be divisible by four. Let’s say you are dividing 50 pixels (no matter what you choose, the browser may end up with an indivisible problem, so I’m just using an easy example that John Resig used in his comparison of how each browser handles the rounding), each column should be 12.5 pixels wide according to your CSS telling the browser to divide the 50 pixels into 25% columns. The problem is that your browser can’t do this, and needs to round to an integer. No matter what your browser does at this point, there will be imperfections. If your browser rounds down there may be gaps and if you round up, then there can be an overflow.
Here is a test you can use to see this error in effect in your browser. It should display a black box, but drag your browser around resizing it, and at some sizes you should see gaps (in Firefox 3 you may not be able to do so due to an innovative way they are handling the rounding rounding the layout to 1/60th of a CSS pixel).
Now I understand the limitations each browser faces, and how they can’t possibly get it all perfect, but what IE does that breaks layouts as you resize the browser, causing your divs to jump around is round up. By rounding up they may cause your columns to exceed the width of their container, and wrap. There’s not a great way around this, and the only easy solution is to not let your columns add up to 100%, leaving room for rounding up without breaking your layout. It’s not a great solution, and it ruins the pixel perfect grid I was trying to implement on able2know with more space on the right than on the left but I thought I’d write up the problem in case others need it to fix their floats.
Today I was trying to achieve a 25%|50%|25% layout within the main block of my YUI Grid CSS layout. Everything I read in documentation seemed to indicate you could nest grids in any way you desire. So I tried doing the following:
<div class="yui-gf"> <div class="yui-u first"> <p>First Column (25%)</p> </div> <div class="yui-u"> <div class="yui-gc"> <div class="yui-u first"> <p>2nd Column (50%)</p> </div> <div class="yui-u"> <p>3rd Column (25%)</p> </div> </div> </div> </div>
However this didn’t work, it appears you can only nest grids in the ‘first’ column, unless you are using ‘yui-g’ (instead of one of the alternate layouts, such as yui-gc above). I couldn’t find this documented anywhere, but I don’t know why else the above code wouldn’t work.
I asked for help on twitter, and senior Yahoo engineer and CSS component author Nate Koechley (@natekoechley) was kind enough to point me to this solution. It appears that moving the nested grid under the ‘first’ unit fixes the problem. Of course, then you have to change which grids you are using, as follows:
<div class="yui-ge"> <div class="yui-u first"> <div class="yui-gd"> <div class="yui-u first"> <p>First Column (25%)</p> </div> <div class="yui-u"> <p>2nd Column (50%)</p> </div> </div> </div> <div class="yui-u"> <p>3rd Column (25%)</p> </div> </div>
This seems to reinforce my hypothesis that nesting of alternate grid layouts can only be done under the first grid unit. Is this by design, or is it a bug? If anyone has any insight, please let me know in the comments.
Working off the above code, I decided I might as well clean it up a little bit. Nate Koechley himself says that if you are going to use a nested grid, you do not need to enclose that grid in a grid unit div (in other words, a grid container can act as a grid unit). This was said during his YUI CSS Foundation speech (about 24 minutes in).
However, I quickly found that removing the first grid unit div broke the layout. As this goes against what Nate has said publicly, I am curious if this is a bug or if he misspoke in his presentation. Here is the non-working code:
<div class="yui-ge"> <div class="yui-gd first"> <div class="yui-u first"> <p>First Column (25%)</p> </div> <div class="yui-u"> <p>2nd Column (50%)</p> </div> </div> <div class="yui-u"> <p>3rd Column (25%)</p> </div> </div>
I would like to point out that I am loving the idea of the YUI Grid CSS, and am hoping to utilize it in all my future projects. All of the issues I have discovered thus far are not deal breakers. I am simply looking to master the framework in a basic testing environment, so I’m not wresting with it in a complex, large scale implementation. So again, if anyone has any insight, I would be happy to hear it!