There has been a lot of discussion about CSS tables for page layout of late, with strong opinions for and against.
A strong advocate of using them is Kevin Yank. One of his arguments is that CSS tables offer an easy way for beginners to get up-and-running with CSS.
A strong detractor is Eric Meyer. One of his arguments against them is that they don’t allow for source order flexibility, and hence are a backward step in terms of advancing the web.
So perhaps it’s all a matter of perspective–depending on whether we are talking entry-level design or advanced. Of course, it’s probably better not to learn something if you will later have to drop it, so I’m starting to side with Eric Meyer.
Besides, I did not find it hard to learn CSS layout anyway. One good book is all one needs to get a pretty solid grasp of it.
Pro: Being a nested element it may mean that alike to HTML tables, inheriting percentage widths may be more consistent then trying to inherit widths using floats. Pro: If trying to achieve “stacked” elements (such as boxed items shown next to each other) this technique will be much more reliable than using floats to force everything into what could be 5 columns… an example of this could be an image gallery which shows 5 images per row without needing empty divs to clear for the next row. Con: By styling the element as a table, they force us to retract back to the older model pointing towards keeping our designs “within the grid” rather than trying to promote the benefits of more flexible unique layouts. Con: Reliance on this technique may lead to abuse and could result in divitis being invoked to overcome some of the systemic problems which tables of any kind usually end up causing (Especially with browser inconsistencies in rendering CSS).
It really is a toss-up… the application of CSS tables does have advantages, but it will be so easy to abuse, people who don’t understand semantics may end up making things worse.
The document isn’t being laid out using tables though, it’s being served semantically, just having nested tables served through CSS style, which does not affect the document flow - and ergo the accessibility for screen readers (that I am aware of).
Because the HTML itself retains semantic (as long as you code it correctly and don’t get hooked up with divitis), even if you alter the physical viewpoint of the code using positioning in CSS (absolute, float, table or otherwise), the mark-up is still semantically correct (in terms of using the correct tags for the right job) and they are logically positioned within the document flow. The CSS tables will nest them within parent elements (by declaring them through the style as cells – and serving them in the visual box model as such) and perhaps position them differently, but the fact still remains that the HTML as it stands (unlike an HTML table) is using the correct source order with tags.
Or perhaps I am putting what I am thinking across wrongly, lol
Yeah I still don’t get it. I write in (what I think is) a proper source order, and then set the desired visual order using whatever tricks I think of/steal/copy. The few times I’ve used display: table, the elements needed to be in that exact order (the order of the “row”). So, none of that sidebar-wrapping stuff, or whatever.
Esp with Firefox being such a pain with positioning and tables. I’d have to see a “css table” being used where it showed a different order than source to see what you meant.
Using CSS tables is okay if they can be applied to a logical source order. If you have to pervert the source order to make it work, then you shouldn’t use CSS tables. But if the display order matches the source order, then it can be a convenient way to handle the layout.
Semantic markup in a logical order must always be the foundation of a web document. Styling is applied on top of that. Limitations in what CSS can do and what browsers support may force us to add a few redundant elements (divs and spans, usually), but that’s okay. Changing the content order to make it suit a certain type of display, however, is not okay. That’s virtually as bad as using table markup in the first place.
This past week, i recently skimmed through Rachel Andrews book on CSS at Borders. I was surprised to read about the CSS-Table/Layout positioning information. I just skimmed through the book but i am familiar with XHTML in using divs to position, etc. This thread is informative. I was wondering if this approach is more ‘official’ or standardized within the W3C and/or everyone at Sitepoint? I will need to read this book.
The key points regarding display:table are that it has been a part of the W3C CSS 2.1 standard for many years and that a few weeks ago the last of the major browsers started supporting it in their latest release (IE8). All the other major browsers have supported it for many years. The main reason for people not using it in those situations where it would be useful is that IE7 doesn’t support it.
Thanks for the feedback Stephen. I’m gonna check out the book tomorrow.
I’m just surprised about that and ok with letting go of the positioning code in XHTML.
That’s reasonable at the moment with IE7 and earler not supporting them but once IE8 is the earliest version of IE in common use then CSS tables will be able to create true equal height columns the simplest possible way that it can be done in CSS.
^part of the goofy behaviour I usually want to avoid, or don’t expect. Using it in forms taught me some of the pitfalls, in browsers that support it.
It’s still a hack-- we’re using something designed to make an element look and act like a table (which sometimes we want), but only so height can act like width does in browsers. If I want something to look and act like a table while it’s semantically not, display: table is perfect. If I only want 100% high columns I’d rather CSS supported it as well as it supports 100% width (the browser’s doing goofy calculations for that as well, isn’t it?).
Actually, {display: table | table-cell;} are there to make <table>, <td>, and <th> act as expected. The advantage of moving the presentation to css is that we can now use other values for those elements (and I’ll admit to not knowing why anyone would want to), or apply the values to other elements.
Synchronizing height is only one reason to use a table group value.
They’re also a means of enclosing float elements.
In the ‘sticky footer’, using the table display method allows the footer height to be dynamic (set its height to 1px, and it will expand as needed for the content; all the while the main cell will adjust to accommodate).
Have you ever tried to show poetry or verse on a page? Proper typography requires that it be preformatted, and either be left aligned and indented (simple enough), or centered on its longest line (a real PITA without the table group).
Don’t think of {display: table;} as applying to tables; think of it as the name of a presentation ruleset that can apply to anything, with all the advantages and gotchas that accompany any non-trivial property.
When will IE8 become the common browser, currently IE6 still rules with the major and it is going to take a while before IE8 replace what ie6 is today.
I suspect it will take until the last win98 machines die. Neither IE7 nor Firefox3 will run on win98. Nor will XP or Vista run on those old machines. Don’t expect those old machines to be replaced until they crap out. My mother, for example, is perfectly happy with her ca. 1999 Dell with 98se. It is perfectly capable of handling her web surfing, email, letter writing, banking, and card games. It is not capable of running a newer Win OS.
Yeah, but. FF3 is quite a step up from FF2, and FF3.5 is another major upgrade. As long as those old machines with Win98 hang around, we will need to carefully evaluate whether to ignore IE6; or FF2, for that matter.
It is a Good Thing®, that MSFT is pushing IE8 through on Vista updates. (I have to be careful that I don’t let it replace IE7 on one of my VBox Vistas.) I haven’t a clue about XP’s update thingy.