Check it out now. The file size is even smaller, no gutters, and the lastUnit takes all remaining space, even in IE5.5 and 6! I’m so pleased. Position relative on the lastUnit was the key.

The only caveat now is that content being wider than the grid itself can cause a wrap. For example an extra long word at really narrow widths. In my tests it works perfectly for all normal scenarios.

The IE5.5 support is really key, because quirksmode in later versions of IE is much more like 5.5.

http://github.com/stubbornella/oocss/blob/3f0b8664446ee1f911d91370945cf948581ba484/css/grids.css

Let me know if you manage to break anything, good use cases are always welcome!

Cheers,
Nicole

I wrestled with this issue for a couple of sleepless nights back then. Here were the results of my own research:

1) There’s no way around the issue without feeding IE lesser values.
2) The more columns you have, the lower the value needs to be, making it pretty obscene if you have enough columns (I was shooting for a 12-column grid because of how divisible it is).

I, for one, like the gutters on the grid level, so if you had a solution with gutters I’d personally be interested in it. So far of all the CSS grids I’ve seen I’ve liked your fledgling one best, and am interested in building off it and extending it if I don’t end up rolling my own.

I saw your tweet re: IE rounding errors. I hadn’t capitalized the “lastUnit” class name in the AG test grids. Oops.

Thanks for the link to this article. I resolved the problem for better browsers (IE7+, FF, Safari, Chrome) by having no set width on the last unit in any row. This means that the last unit absorbs the subtle rounding differences between those browsers. overflow:hidden is the trick, if you read the spec it is a subtle effect of this property when no height is specified.

On the other hand, IE6. My grids used to have gutters. I recently removed them, because I felt it was important that gutters live on content objects rather than grids. I used the gutter to help IE6 by floating the last unit right. That meant that between the last two units an ~10px gap absorbed the rounding errors in IE6. Ultimately, I need a way to tell IE6 that the last unit should be all the rest of the space on the line, whatever that might be. Removing the width causes the calculation to be content dependent and, like you’ve talked about above, having a width causes (at some resolution or another) the unit to wrap.

I really don’t want to put gutters back in the grids (though they worked very well and were well tested with gutters)… so I’m searching for a solution. I’ve documented the bug here:
http://stubbornella.lighthouseapp.com/projects/26663-object-oriented-css/tickets/1-arnaud-gueras-test-wrapping-on-ie#ticket-1-4

Thanks again for your feedback,
Nicole

Cool enough; whatever gets the job done for you! I’m a JS junkie myself. I was indeed quite surprised to see that resizing video with the rounded-up widths; I knew I didn’t like using CSS width percentages as a production-ready layout solution, but I didn’t know I had that much reason to stay away. Ouch!

Kick ass post, by the way, thanks.

I forgot to mention that taking the absolute positioning approach and calculating pixel coordinates and widths dynamically will actually produce a layout that is actually more precise than making divs that are sized according to a percentage of the width.

If the first column ends up wanting to be at 110.2 px from the left edge, stick it at 110; if the second one wants to be at 462.8px, stick it at 463… if the third column then wants to be at 815.4, and you naturally put it at 815px from the left, then the distance from the left edge of the first column horizontally to the second column (353px) is different than the distance from second to third (352px).

This means that the layout is actually more accurate than ever could have achieved using percentages, woot! Some nicer, newer browsers may do this rounding for you (maybe Firefox 3?), but I really don’t know, because I never need to care, since I can make sure it happens all the time anyway. And yeah, if you want, you can make it degrade to best-effort CSS when JS is unavailable…

And don’t worry about it being slow, either; if you write decent JS code, you can get something like a column layout done in negligible time, say, well under 1ms worth of execution. Take the MobileMe Gallery grid layout as an example; it’ll manually lay out 100+ photos (each with width, height, left, and top) in under 10ms in Safari, and under 50ms in Firefox. Though IE is horrendously slow in other ways, the actual photo layout loop even works pretty well in IE when resizing the window with the album list on the left collapsed. I ramble too much… my point all along in is that laying out a few columns with absolutely calculated pixel coordinates would never be a hit in any browser or on any machine.

So… may as well go for the manually implemented “anti-aliasing” !!

Absolute positioning is epic!

If you’re wanting to make it REALLY perfect, then you can do only what a crazy person does, and put one-pixel COLUMNS on the left- and right-hand sides of each column box. Make sure you do all your JavaScript-based width divisions without doing a Math.floor or .ceil or .round anywhere to round to an integer (i.e. keep the decimal.) Make the DIVs the exact same color as the background of the column div, and set their opacity to the decimal fraction that is left over after rounding the position down or up to the nearest integer. That way, the outsides of the boxes themselves are actually rendered down to subpixel precision, and the world is a happier place for it! (Granted, the contents of the DIV columns will still nonetheless be jumping pixel by pixel, but while the page is in motion during a window resize, everything will be beautiful!)

JavaScript forever.!