Eric Meyer said today in “Wanted: Layout System“:
Turning a bunch of divs or list items or whatever into table-role boxes is no better than just using table markup in the first place, and it’s arguably worse. Using element names other than table and td to create layout tables, and then claiming it’s not using tables for layout, borders on self-deception.
Not to mention doing things that way means you’re doing your layout in a highly source-order-dependent fashion, which was one of the things about table layout we were trying to get away from in the first place.
Amen, brother. I’ve heard enough about these CSS tables. This “Everything You Know About CSS is Wrong” stuff is absolutely insane to me. I was feeling a bit dense about it before, so it’s nice to hear it from Eric.
Yes, amen! I was really waiting that one of the “masters” gives a statement on that. thanx a lot for pointing that out, Chris. I just hope that css-“table” design will drop again! no good semantics and no progressive enhancement as IE 6 and earlier does not work at all.
Ahhhh. I feel relieved now. I just got done reading “everything you know about CSS is wrong” and felt sick to my stomach that I wasted my money on a clever marketing ploy.
CSS-tables are gimmicky. Like the book.
I was in the process of reading the book, and I was like for real, this is really how the web is going to be? I’m glad I heard this from you guys. It’s nice to hear it from the best in the business.
I agree wholeheartedly with Eric. I thought it was taking a huge step backward when I first read about it. But as the push for it kept working its way around, I thought I must be missing something obvious.
Now I see that I wasn’t. Using divs to essentially recreate a table-based layout is insane. We have fought so hard to move away from this mentality…I hate to see us get sucked back in.
I KNOW! I was reading that book and I was like.. wtf? Great post.
SitePoint books just plain suck.
For a complete newbie which the book was advertised towards I didn’t enjoy it. The beginning was great then it nosed dived into regular expressions. I didn’t like the flow of it. Where as Dom Scripting by Jeremy Keith was such a joy to read in comparison. I’ve just started to read his other book ‘Bulletproof Ajax’.
With regards to Sitepoint books they definitely do release great books but they also release some stuff that’s just utter tripe.
I also like their HTML and CSS references.
I definitely agree with you, to an extent.
CSS-tables… let’s hope that just gets skipped.
Totally untrue, Jason. Sitepoint publishes the best web development books on the market. They’re easy to read and they address real world problems and solutions. Most other publishers are too technical. Maybe this particular book under discussion is not as good as the others, but that doesn’t make the whole lot bad.
I agree totally. Especially as a intermediate CSS person, I just got floats and grids and everything down and now this madness.
I’m not ready to throw out CSS Tables yet, I can’t trust my initial reactions.
A friend and I learnt CSS at around the same time; we both thought the CSS box model was flawed. My instinct was to go back to html tables; fortunately I persevered and wouldn’t dream of going back now (and I think the MS box model – of old – is flawed).
My main concern is div bloat, if experimentation shows that bloat won’t occur, then I may use CSS Tables.
Shouldn’t multiple borders and border radius fix that?
they are CSS3 properties, if we’re talking CSS3 then we would probably be talking about http://www.w3.org/TR/css3-layout/ however that is very much at an alpha stage!
I use display:inline-block for my layout, if it weren’t for one annoying flaw it would completely replace float and clear.
If there is anyway to remove this gap between inline-block elements without floats that would be great.
I don’t want tables. My boss who is a designer still lay out websites with tables, and it’s horrible! I swear there is a table-demon which, after seeing all the little demon-followers leave his table-palace, now just went for a facelift and put a css-hood on…
i will stay away from this and never use it.
DIVs and SPANs for me.
Tables for ‘tabular data’.
Do you even know what CSS-Table is? Apparently, you don’t. I suggest you google it up.
Dude i think the guy know what it is.
Totally agree with you… let the beauty of div spread all over the web world (hoping IE6 will die someday!)
Some people crying for divs seem not to know what this is about… of course css table work on divs and it doesn’t mean to go back to semantic table markup.
:) that’s right. I don’t get it either. I’ve never done table-design with divs and css – and I’ll never will!
What a relief, I thought that it was just me who didn’t get it. Good to hear somebody else speak out.
Umm can someone explain what is so bad about using semantic mark-up still but having the mark-up act like a table? Surely its the best of both worlds? You can create table-like layouts with semantic markup?
It still retains the sepration of content and design?
I disagree. Many people do not understand what CSS tables are entirely different from HTML tables. CSS tables work on divs, li elements, etc. Floats still have a purpose, but in my opinion they should not be used for the underlying layout–just for “floating” something to the right or left. Maybe it’s just me, but I don’t see what the big problem is.
I think the table-like divs, spans or whatever could be great in some special cases (I think of vertical aligned text), but as a replacement for layout-tables it sucks as much as the layout-tables it wants to replace.
I totally agree with Eric!
I personally hate anything related to tables even CSS tables. Just use divs, they’re quite simple.
CSS tables are a display value, so they work on divs and list items—they have nothing to do with the table element in HTML.
I think using yahoo reset css and then making only divs is the best method to code your site. Floats and clear do my work for me.
I am all about divs and tableless web design 99% of the time. However, there are times when tables make more sense (these are rare, but I have ran into them). Why create a bunch of divs with a ton of CSS code to get the same desired effect you would get from a table?
I’m all about cleaner (and smaller) code. I say if a table fits better than a bunch of divs for part of your web design, then use it. Don’t make things more complicated than they need to be just to say your design is 100% tableless.
I wonder if there would be such a strong reaction to these properties is they were called ‘CSS Grids’ rather than ‘CSS Tables’ ?
Trust me, I hate html tables as much as anyone.. But I’ve still always felt like floating elements in order to create the appearance of columns seemed like an after-the-fact solution.
That said, I’m definitely not completely sold on the idea, but I’m willing to at least give it a chance, and not instantly dismiss a new approach just because it contains the dreaded t-word.
And it’s not like CSS 3 is going to be widely implemented any time soon, anyhow.
I disagree. I will bet most of you will start using it once IE 6 and 7 are no longer in the market.
I agree with colin here. I don’t think that css tables are the way to go all the time but I do belive they are another tool in our kit and should be used as such. Sometimes we will have a design that calls for them and sometimes we won’t.
Designing a layout with something like CSS-table or whatever they call it is not wrong – in fact it makes sense. It’s just using that are not appropriate because it was not intended for that layout purpose.
Yeah, this pretty much confirms my suspicions. Glad you posted this. As far as this whole table discussion goes, I think some people are missing the point.
First of all, the concept of CSS tables is NOT to build a layout with tables and then style those tables with CSS. You should look at nettuts or sitepoint and do a search for css tables to see what Chris and Eric are actually talking about.
Secondly, everyone is hating on the table tag. That makes just about as much sense as saying “I hate p tags” or “I hate unordered lists”. You’re not making any sense when you say that. Instead, you should say “I hate using tables for layout”. This would, of course, make sense because the table tag was not created for laying out websites. It was created for laying out tabular data.
So stop hating on the poor table tag and only use it when you’ve got data to display.
I agree. I say no no to css tables please please
I know it is considered heretical (or at least bad taste) to disagree with Eric Meyer, but I disagree with this post and the general sentiment of the commenters. The reason, I think, for
the love here for the present methods (float and clear, etc.) is that you’ve invested so much
time learning to cobble together layouts with the whole float and clear voodoo. It sucks to
think there might be an easier way.
And I agree with another commenter who says if we didn’t call them “tables” a lot of these complaints would go away.
My chief complaint is that until IE6 Iand E7 go away, we still have to do the float and clear dance anyway in IE specific style sheets.
There is still one situation when using divs for tabular data makes more sense then using and its relatives: When you are displaying column-based comparison data that can be refreshed via AJAX.
The TABLE element is fundamentally flawed in that it only supports row-based tables, and the coding/cost implications of trying to overcome this limitation are prohibitive. The obvious choice in this case is floated columns of divs.
“There is still one situation when using divs for tabular data makes more sense then using and its relatives:”
should have been
“There is still one situation when using divs for tabular data makes more sense then using table and its relatives:”
Eric is right when he says CSS needs something to allow some way of reordering HTML elements, but I think CSS tables still have their value. They’re just not enough for a really good, source-order independent layout, but they’re a step ahead.
I bought that stupid book, 111 pages. There is more free information on the subject on the web. What a waste of $29.95!
I borrowed it from my local library. Libraries are great :-)
I’m still surprised at the number of people who think CSS Tables (display: table) are the same as tables styled with CSS.
However Eric is wrong, display: table is in no way worse than using real tables for layout.
What it all highlights is that CSS is still in need of improvement for layouts.
I still think tables are wonderful things when used for tabular data, or coupled with CSS for certain things that need to “flex” together (three callout columns side-by-side with an unknown amount of content inside them, and all need to be the same height always). Display: table will only make doing this sort of thing smarter, but it still probably wont replace current layout methods entirely…
One pet peeve of mine are people who think they’re doing something “smarter” by not using tables at all, especially for tabular data. Thats not smart coding at all. The truth is tables are still very powerful in their age-old-form.
Seems to me that with modules such as Advanced Layout, Grid Positioning, Multi-column layout, etc, that CSS tables become further redundant; Given eventual support for (at least some of) the above, I’m not sure what value there might be in using CSS tables for page layout, which to me is again semantically incorrect given that we’re not displaying tabular data…
Also, what value is there in essentially replacing HTML tables with CSS tables for tabular data?
So, Is it worth getting ‘Everything you know about CSS is wrong’?
I was considoring buying it.
You could borrow it from your library, or browse through it in a bookshop…
I think “Everything You Know About CSS is Wrong” was an interesting book. I think the method described in the book could be appropriate for some sites in the future, but I still prefer divs. My main beef with tables is this – let’s say you have a 5 x 5 table of whatever, and then you decide you want to get rid of a cell in row 2, column 3. Shifting everything else appropriately in any kind of table is a hassle, but with floated divs, it’s a breeze.
It’s still an interesting concept though. Might be easier for newbies of the future to learn, especially if they’re just looking to make a simple site quickly.
Using HTML tables for tabular data is perfectly fine. And anywhere else it simplifies maintenance. My company maintains websites for several score clients and we often come across websites built by some supposed CSS guru who spent a year creating a supremely complex 100% table less css site for 20 times the cost it would have taken a faster goal oriented quick and not-very-dirty coder. The problem with the attention to detail/pure css approach is that cost and productivity never enters the discussion. I think coding should solve problems at a minimal cost. Use tables where you think it will simplify life for whoever is maintaining your website. Insanely good CSS does have some qualitative advantages, but how does it improve a company’s bottom line is the first question to ask. Therefore, I don’t really care for 100% tableless design.
I think to someone who has looked at table based layouts all of their life, tables will always seem easier to layout a site. I really cannot fathom that a true css “guru” or even someone who is not a guru would take a year to create any kind of tableless layout. If you’re at all familiar with CSS layouts, it’s just not that difficult. Do you have an example of a site that took a guru a year to create? I would love to see something that complex.
Maybe it’s just where I got into design in the tableless era and have never used tables for layout but I find that a tableless design is much easier than a table based one. It would likely take me twice as long (or longer) to layout a site with tables than I could throw a compliant tableless one together.
You should care about alternatives to HTML tables.
Using HTML tables for layout (rather than tabular data) can make your site less accessible for people with disabilities (e.g. users of screen readers), harder to maintain, slower to load, and use up more bandwidth.
If you’re only interested in the bottom line, then you need to justify pushing potential visitors away who can’t access your site, or who want to use an alternative site they found that loads quicker. CSS is bottom-line-friendly.
Completely agree. That is all.
Isn’t all the talk about CSS Tables basically a moot point until IE7 has since long gone? IE7 lacks support for CSS Tables, right? Correct me if I’m wrong but there are still a ton of people designing for IE6 and it’s been out for how many years now? If IE7 is anything like IE6, it will be around until about the year 2016 and as long as we’re designing for IE7, can we really get excited about CSS Tables?
I can see both sides of the argument on CSS Tables and hell, I’ll probably give them a try at some point, but I’m still not sure how much sense it makes to feed all compliant browsers one thing (css tables) and then feed IE7 a completely separate layout (float based) as that’s what I’ve heard is one popular approach to take?
I don’t agree with many of these responses, nor with Eric or Chris. CSS Table design is not meant to replace floats and positioning. What it does in fact do is give designers the ability to create a grid system and place elements within cells that the grid creates. This is a no-brainer in any graphics software. I create a grid using guides in Adobe Photoshop when I lay out a website. When I then “chop” this site into XHTML/CSS, I am faced sometimes with the inherent problems of float-based CSS designs, such as variable height columns. This is where CSS Table design can come in and be a serviceable solution. CSS tables are now another tool in the designer’s toolbox. I don’t have to fudge around, for example, when I create a flexible rounded-corner design. I just use CSS tables like I used HTML tables before. As for the progressive enhancement argument, I don’t design sites for IE5. IE6 and 7 will have to be considered outdated at some point, and it will make no sense then to continue designing for them.