It’s been something that designers have wanted better control of ever since CSS started to be considered the best way to layout HTML pages: table style grids.
David Shea sat down with the IE 7 team and later reported back that:
Naturally, I had to bring up (probably more than once) the question about CSS tables; namely, when will we get them? Cause that’s what us designer types are really waiting for. Grid-based layouts in IE? Hell yeah. Long story short: not IE7. Maybe IE7.5. It’s on their list.
The question is then raised as to how different using (minimal) tables is from divs and CSS? Having fought so long against table layouts (and going to considerable trouble to make it work), do layout tables have a place?
Comparison
The issue in focus at the moment is that: it looks better to have columns that match each other’s height, expanding to the height of the longest content column, for example (and please ignore the inline styles – I’m just using them for one off examples) this is a table version:
| column 1, more content than the other column and pushing the bottom down. | column 2 |
Without a lot of effort, the CSS equivalent comes out like this:
How are tables for layout different from CSS layout?
It depends on what they are being used for, and I would like to separate out the two main uses:
-
Page layouts
Layouts for the whole page are repeated from page to page, and the order of the content in the source is important, for example: Whether you have the navigation at the top or bottom of the code.
When using tables you have no choice over the source order, when using CSS you have more choice.
-
Within content ‘boxes’
Making square boxes in columns in the content area of the page is quite common, (example), and it doesn’t tends to matter what order the source code is in.
I might tackle page layouts in a future post, but for now I’d like to focus on within-content-area layouts.
For within page boxes, the David Shea came up with the a good solution, a simplified version of which I used for example 1, screen shot here:
For many instances this is fine, but it isn’t as robust to different font and layout options as tables. I highlighted that with the extra few words in the second box. In a content-managed situation this is especially difficult as non-technical editors are likely to assume it’s fine because for them, it is. At different resolutions or font-sizes, it might not be.
Can table properties in CSS help?
The second example uses the same HTML, but uses table display properties to create the layout. As the screen shot shows, it works as advertised, and even trying to disrupt the layout doesn’t work:
However, an unexpected issue came up. The links that should be located at the bottom of each box (with positioning) suddenly aren’t. The position:relative each box has is suddenly nullified. Checking through the spec under relative positioning, this is why:
The effect of ‘position:relative’ on table-row-group, table-header-group, table-footer-group, table-row, table-column-group, table-column, table-cell, and table-caption elements is undefined.
This phrase wasn’t in CSS 2.0, but was added to the CSS 2.1 spec, presumably highlighting that it hasn’t been sorted out yet. In Firefox at least, the position property seems to act as expected on these ‘table cells’ except for relative, which does nothing.
You could get around this by making the links another row, however that would separate them in the code from the content they are associated with, not ideal. It also means that the nice little corners used on Nomensa.com that use relative positioning wouldn’t work, and this was the aspect I was trying to improve!
So what to do?
Using table CSS properties in this way is pretty much equivalent to using tables. Apart from not putting a ‘table summary’ on the wrapper, the advantages and disadvantages are the same as they behave the same.
Even Yahoo!’s grid based layouts don’t try match the heights of columns. You could use them for ‘progressive enhancement’ where positioning isn’t important, but you will have to include the nearest floated equivalent until IE catches up.
Personally, I don’t think there will be a good way of achieving matched height layouts or content boxes until CSS 3’s layout module is supported. It is pretty powerful stuff, and allows that type of layouts that I assumed would be possible before I tried CSS 2 positioning:
- Template based positioning, by mapping areas into slots in a
table-like template
. - Re-defining the layout for different medias.
- Tabbed interfaces (show-hide style).
It’s still in working draft, which means it will be years (if ever) before it is supported, but personally, I think it would save millions of hours in web development every year that are currently used hacking floats around to create layouts.
Tags:
One contribution to “CSS tables verses layout tables”
Comments are closed.