Ask HN: CSS vs table based layouts
28 comments
Cheat. Use Blueprint, from Blue Flavor, which gives you semi-semantic layout in table style using DIVs and spans. Blueprint actually gives you more layout control than tables do --- your stuff will look better --- but gets rid of almost all the CSS headaches.
Standards zealots get all up in Blueprint's face because it's fundamentally non-semantic (you end up putting presentation details in your markup). But now you're splitting hairs. If you're using Blueprint, you get to call yourself a CSS designer.
Standards zealots get all up in Blueprint's face because it's fundamentally non-semantic (you end up putting presentation details in your markup). But now you're splitting hairs. If you're using Blueprint, you get to call yourself a CSS designer.
+1 for cheating, and for BluePrint - it makes CSS bearable for those of us who aren't pros. 960gs (http://960.gs) is also a very nice framework.
One correction though, Blueprint isn't from Blue Flavor, though they did do an article on it. It's by Olav Bjorkoy, and currently maintained by Christian Montoya.
One correction though, Blueprint isn't from Blue Flavor, though they did do an article on it. It's by Olav Bjorkoy, and currently maintained by Christian Montoya.
Thanks for the 960gs, looks great. As I'm starting a small side project without a frontend developer and I hate writing CSS, I'll consider using it. The previous candidate was Malo (http://code.google.com/p/malo/).
Also take a look at Bluetrip (http://bluetrip.org/) it combines features of Blueprint, Tripoli, 960 and Hartija. So you can get a nice CSS website running pretty quickly and then customize from there.
Ah yes, web standards zealots. These are the guys who run blogs debating the use of <b> vs <strong> on a monthly basis. The funny thing is that I jumped on the CSS bandwagon early (Netscape 4 era) because of the obvious benefits. Now I find myself disgusted at what the community has become.
They live in their inbred web standards blog world where they have a very polished view of what is "semantic" and what it means to separate content and presentation. All the while completely oblivious to the ecosystem in which web standards live and the constant tradeoffs that must be made in any software system.
Ignoring what should be obvious: there's precious little semantic information in an HTML document. The standardized tags are all but completely presentational. Naming CSS classes strictly according to some pedantic definition of "semantic" meaning "not presentational" is deluded. First, because we add classes to things because need a hook for presentational purposes. Second, because 99% of the time, the actual goals of writing HTML/CSS are presentation, concision, maintainability, and maybe SEO. It turns out you should name your classes descriptively, which may align with a semanticist's notion of best practice 80% of the time. But then the remaining 20% of the time they'll rip you new one for use class="red" instead of using a half-dozen "semantically pure" names like class="slightly_more_important_block", class="second_heading_in_a_row", class="something_i_just_want_to_be_different", class="sometimes_i_just_want_to_be_different", class="why_web_design_sucks_in_96" and class="i_love_you_man"
They live in their inbred web standards blog world where they have a very polished view of what is "semantic" and what it means to separate content and presentation. All the while completely oblivious to the ecosystem in which web standards live and the constant tradeoffs that must be made in any software system.
Ignoring what should be obvious: there's precious little semantic information in an HTML document. The standardized tags are all but completely presentational. Naming CSS classes strictly according to some pedantic definition of "semantic" meaning "not presentational" is deluded. First, because we add classes to things because need a hook for presentational purposes. Second, because 99% of the time, the actual goals of writing HTML/CSS are presentation, concision, maintainability, and maybe SEO. It turns out you should name your classes descriptively, which may align with a semanticist's notion of best practice 80% of the time. But then the remaining 20% of the time they'll rip you new one for use class="red" instead of using a half-dozen "semantically pure" names like class="slightly_more_important_block", class="second_heading_in_a_row", class="something_i_just_want_to_be_different", class="sometimes_i_just_want_to_be_different", class="why_web_design_sucks_in_96" and class="i_love_you_man"
Or you can use compass with sass and get to use blueprint together with semantic names for classes...
This debate is endless. Simply put, there is no clear answer.
Clearly, from what you've stated, CSS is not your forte. There's nothing wrong with that. In fact, there was a time that I felt exactly like you. Now however, I find CSS/tableless html easier, faster and cleaner overall. I use it exclusively for general presentation. It really shines when I need to fix websites after the fact, or two clients want different presentations of the same code/datasets. It's a lot of fun to limit presentation to 2-3 files, rather than your entire codebase.
That said, what's your motivation here? Do you believe/recognize the benefits of CSS, or are you just feeling guilty because "all the cool kids are doing it"?
If the former is your thinking, you have to realize that you are in learning mode. Of course it's going to be harder. You're comparing a learning state to a mastered state. Riding a bicycle is a lot harder if all you've done is ride tricycles. It says nothing though about whether learning to ride a bike is beneficial to you or worth the time and effort.
If you can see that moving to CSS layouts would have noticeable impact on your production, tough it out, it gets easier I swear. If you can't see any benefit to switching, then don't.
Clearly, from what you've stated, CSS is not your forte. There's nothing wrong with that. In fact, there was a time that I felt exactly like you. Now however, I find CSS/tableless html easier, faster and cleaner overall. I use it exclusively for general presentation. It really shines when I need to fix websites after the fact, or two clients want different presentations of the same code/datasets. It's a lot of fun to limit presentation to 2-3 files, rather than your entire codebase.
That said, what's your motivation here? Do you believe/recognize the benefits of CSS, or are you just feeling guilty because "all the cool kids are doing it"?
If the former is your thinking, you have to realize that you are in learning mode. Of course it's going to be harder. You're comparing a learning state to a mastered state. Riding a bicycle is a lot harder if all you've done is ride tricycles. It says nothing though about whether learning to ride a bike is beneficial to you or worth the time and effort.
If you can see that moving to CSS layouts would have noticeable impact on your production, tough it out, it gets easier I swear. If you can't see any benefit to switching, then don't.
Doesn't your question include its answer? Guilt is not a very productive motivation.
I've noticed that once people settle on something as "the" right way, they measure everything against that yardstick. This is so common, I wonder if having a yardstick -- an easy way to answer questions -- is the purpose of settling on "the" right way in the first place.
Software people do this a lot because software projects are so uncertain: if you can do anything (computable), why do X rather than Y? That's overwhelming, so we look for paradigms and processes and yardsticks. These reduce hard questions like "is this good" to easy ones like "is it standards-compliant". It's like the drunk looking for his keys under a streetlight, rather than down the block where he dropped them, because the light is better.
I noticed this when everyone around me was equating "good" programming with "object-oriented" programming. It was too hard to answer "is this good", so people instead would answer "is this OO". I caught myself doing it one day and was shocked. I decided never to use the phrase "the right way" again, but always to replace it with "a right way".
The trouble with the yardstick instinct, of course, is when it produces fake reductions. It gives you false positives ("it must be good because it's OO, CSS, or whatever") and false negatives ("it must be bad because it isn't"). I think the false negatives are more harmful than the false positives; they shut down options and inhibit creativity. There's a joke in which a Frenchman says to an Englishman, "I can see it works in practice, but does it work in theory?" (Told by an Englishman of course.)
Coming back to CSS vs. tables: if it looks good, is fun for you to make (apart from guilt), and does what users want (or will get you there), what's bad about that? Conversely, if it's hard to make, not fun (apart from guilt relief), and doesn't make things look better or work better, what's good about that?
This is way more than I intended to write, damn you, but one more thing: if you haven't, go read Adam Bosworth's classic 2004 talk on the web as the triumph of the "simple, sloppy, and flexible". I can't recommend it enough. It addresses all of this profoundly.
Edit: Surprisingly, it hadn't been posted to HN, so I just did. http://news.ycombinator.com/item?id=447086
Edit 2: Whenever I recommend that piece to someone I go back and re-read it. How's this for apropos:
What is more, in one of the unintended ironies of software history, HTML was intended to be used as a way to provide a truly malleable plastic layout language which never would be bound by 2 dimensional limitations, ironic because hordes of CSS fanatics have been trying to bind it with straight jackets ever since, bad mouthing tables and generations of tools have been layering pixel precise 2 dimensional layout on top of it. And yet, ask any gifted web author, like Jon Udell, and they will tell you that they often use it in the lazy sloppy intuitive human way that it was designed to work. They just pour in content. In 1996 I was at some of the initial XML meetings. The participants' anger at HTML for "corrupting" content with layout was intense. Some of the initial backers of XML were frustrated SGML folks who wanted a better cleaner world in which data was pristinely separated from presentation. In short, they disliked one of the great success stories of software history, one that succeeded because of its limitations, not despite them. I very much doubt that an HTML that had initially shipped as a clean layered set of content (XML, Layout rules - XSLT, and Formatting- CSS) would have had anything like the explosive uptake.
I've noticed that once people settle on something as "the" right way, they measure everything against that yardstick. This is so common, I wonder if having a yardstick -- an easy way to answer questions -- is the purpose of settling on "the" right way in the first place.
Software people do this a lot because software projects are so uncertain: if you can do anything (computable), why do X rather than Y? That's overwhelming, so we look for paradigms and processes and yardsticks. These reduce hard questions like "is this good" to easy ones like "is it standards-compliant". It's like the drunk looking for his keys under a streetlight, rather than down the block where he dropped them, because the light is better.
I noticed this when everyone around me was equating "good" programming with "object-oriented" programming. It was too hard to answer "is this good", so people instead would answer "is this OO". I caught myself doing it one day and was shocked. I decided never to use the phrase "the right way" again, but always to replace it with "a right way".
The trouble with the yardstick instinct, of course, is when it produces fake reductions. It gives you false positives ("it must be good because it's OO, CSS, or whatever") and false negatives ("it must be bad because it isn't"). I think the false negatives are more harmful than the false positives; they shut down options and inhibit creativity. There's a joke in which a Frenchman says to an Englishman, "I can see it works in practice, but does it work in theory?" (Told by an Englishman of course.)
Coming back to CSS vs. tables: if it looks good, is fun for you to make (apart from guilt), and does what users want (or will get you there), what's bad about that? Conversely, if it's hard to make, not fun (apart from guilt relief), and doesn't make things look better or work better, what's good about that?
This is way more than I intended to write, damn you, but one more thing: if you haven't, go read Adam Bosworth's classic 2004 talk on the web as the triumph of the "simple, sloppy, and flexible". I can't recommend it enough. It addresses all of this profoundly.
Edit: Surprisingly, it hadn't been posted to HN, so I just did. http://news.ycombinator.com/item?id=447086
Edit 2: Whenever I recommend that piece to someone I go back and re-read it. How's this for apropos:
What is more, in one of the unintended ironies of software history, HTML was intended to be used as a way to provide a truly malleable plastic layout language which never would be bound by 2 dimensional limitations, ironic because hordes of CSS fanatics have been trying to bind it with straight jackets ever since, bad mouthing tables and generations of tools have been layering pixel precise 2 dimensional layout on top of it. And yet, ask any gifted web author, like Jon Udell, and they will tell you that they often use it in the lazy sloppy intuitive human way that it was designed to work. They just pour in content. In 1996 I was at some of the initial XML meetings. The participants' anger at HTML for "corrupting" content with layout was intense. Some of the initial backers of XML were frustrated SGML folks who wanted a better cleaner world in which data was pristinely separated from presentation. In short, they disliked one of the great success stories of software history, one that succeeded because of its limitations, not despite them. I very much doubt that an HTML that had initially shipped as a clean layered set of content (XML, Layout rules - XSLT, and Formatting- CSS) would have had anything like the explosive uptake.
A agree. In the end it is about what is going to save you the most time.
For example, if you decide at some point you want all page titles to be bright green and placed below the main text of the page, how much work will it be?
The whole argument about separating content and presentation is about speed. If they are separate, and changes need to be made to one, then you don't have to get knee deep in the other to change what needs to change.
CSS based layouts mean the changes might only require editing the one .css file. Table based layouts might mean that you have to edit each page, or if you are using a decent templating system, it might be a single page
The same goes for accessibility. Will it take more time to make your site usable by screen readers and small screens while using one layout or another? What types of accessibility are even important to you?
For example, if you decide at some point you want all page titles to be bright green and placed below the main text of the page, how much work will it be?
The whole argument about separating content and presentation is about speed. If they are separate, and changes need to be made to one, then you don't have to get knee deep in the other to change what needs to change.
CSS based layouts mean the changes might only require editing the one .css file. Table based layouts might mean that you have to edit each page, or if you are using a decent templating system, it might be a single page
The same goes for accessibility. Will it take more time to make your site usable by screen readers and small screens while using one layout or another? What types of accessibility are even important to you?
Speaking of "sloppy", Bosworth's site is XHTML served as text/html and says it's UTF-8 when really it's ISO 8859-1. I only know this because it didn't render correctly.
>> if it looks good, is fun for you to make (apart from guilt), and does what users want (or will get you there), what's bad about that? Conversely, if it's hard to make, not fun (apart from guilt relief), and doesn't make things look better or work better, what's good about that?
You're tapping into a quite a bit of psychology there :) I've been thinking about the idea of popularity as a measurement of "goodness" (think PHP vs Python), and I think in the end, the answer depends on the programmer.
Some might like to get things done quickly so that their not-necessarily-geeky idea is off the ground early (which is arguably a strong factor for a technology's popularity), and some might prefer to "invest time" and learn about complicated problems (scalability, for example) as they go along. I'd say things are (as usual) a mix of both extremes, so we need to prioritize what's important to us.
As far as tables vs css goes, I find that tables make layouts easy for the average person to visualize while building it, but css is far easier to maintain (especially when you are responsible for maintaining/revamping 50+ stylesheets per year in sites and apps of varying degrees of complexity - think heavily widgeted layouts)
You're tapping into a quite a bit of psychology there :) I've been thinking about the idea of popularity as a measurement of "goodness" (think PHP vs Python), and I think in the end, the answer depends on the programmer.
Some might like to get things done quickly so that their not-necessarily-geeky idea is off the ground early (which is arguably a strong factor for a technology's popularity), and some might prefer to "invest time" and learn about complicated problems (scalability, for example) as they go along. I'd say things are (as usual) a mix of both extremes, so we need to prioritize what's important to us.
As far as tables vs css goes, I find that tables make layouts easy for the average person to visualize while building it, but css is far easier to maintain (especially when you are responsible for maintaining/revamping 50+ stylesheets per year in sites and apps of varying degrees of complexity - think heavily widgeted layouts)
It's like the drunk looking for his keys under a streetlight, rather than down the block where he dropped them, because the light is better.
Beautiful.
Beautiful.
I'm so glad I'm not the only one that feels this way.
As far as I'm concerned, CSS is a miserable piece of work. Witness how hard it is do a simple three column layout. It fails half of the simple edict:
Make easy things easy and hard things possible.
As far as I'm concerned, CSS is a miserable piece of work. Witness how hard it is do a simple three column layout. It fails half of the simple edict:
Make easy things easy and hard things possible.
Agreed, it was a huge failure to clearly think about designer's problems.
We have decades of experience with real layout models in both traditional graphic design software and in developmental software that has layout manager.
And nobody thought that being able to flow several columns on a webpage would be useful?
We have decades of experience with real layout models in both traditional graphic design software and in developmental software that has layout manager.
And nobody thought that being able to flow several columns on a webpage would be useful?
Since when is it hard to do a three column layout with CSS? It is in fact quite easy, and always has been. What has been hard is three columns with a liquid center column that works in Internet Explorer without hacks. That's a Microsoft problem, not a CSS problem.
Sorry but that is an understatement.
Creating a three column layout is surprisingly hard and completely counter-intuitive and it gets only harder when you want liquid columns. IE is part of the problem but many of the other browsers also had their own quierks until recently.
Creating a n-column layout in CSS, in a sane way, has literally turned into a pseudo-science over the years. That wouldn't be the case if it had ever been as simple as spelling it out the obvious way and adding some IE hacks.
Even todays state of the art solution ("the holy grail") is a fairly strange beast. It admittedly gets away without the nasty hacks and negative margins that previous solutions required - but it took us literally years to arrive there and it's still far from pretty.
Creating a n-column layout in CSS, in a sane way, has literally turned into a pseudo-science over the years. That wouldn't be the case if it had ever been as simple as spelling it out the obvious way and adding some IE hacks.
Even todays state of the art solution ("the holy grail") is a fairly strange beast. It admittedly gets away without the nasty hacks and negative margins that previous solutions required - but it took us literally years to arrive there and it's still far from pretty.
It really isn't complicated. Float three columns left with a combined width less than that of the container and you have a three column layout.
If you really think that then you have obviously never tried it.
Look here for the real solution, which is slightly more involved:
http://matthewjamestaylor.com/blog/perfect-3-column.htm
http://matthewjamestaylor.com/blog/perfect-3-column.htm
It's easy if your mind thinks in CSS but if you still think in tables (a habit that I find surprisingly difficult to undo) then yes, it's a bit of a mess. I'm happy CSS frameworks & their browser resets exist so I can think about more important things.
Here's the deal: CSS was designed to have all the styling and layout power of presentational HTML, and more. Even universally hated features like "blink" were supported, so nobody would have to use presenational HTML ever again.
So what whent wrong with tables? The culprit is that the CSS equivalent of tables, the display:table CSS property (defined in CSS 2) has not been implemented in Internet Explorer yet, even though the standard is 12 years old (IE8 will reportedly support it, though).
So there is no direct CSS equivalent to the layout properties of tables which works in IE. You can emulate some of the properties using floats, absolute positioning and so on, but be aware that this approach is not the "correct" CSS way. Rather it is a workaround around limitations in IE's implementation of CSS. Using tables for layout is a alternative workaround for the same problem. The approaches have different tradeoffs.
The main tradeoff is that HTML-tables are bad for accessibility, while CSS alternatives are often convoluted and hard to maintain. So the choice is basically if you want to cause pain for yourself or for disabled people. Its not hard to understand how this debate turns into more of a moral than a technical discussion.
Note that it is not all uses of tables which require workarounds to implement in table-less CSS. Before CSS, tables were used for a wide array of layout tasks like spacing, margins, positioning and so on, which is generally better handled by CSS today. The limitations are specifically when tables are used as dynamically adjusting grids. I wrote a small article to point out the concrete issues: http://olav.dk/articles/tables.html
BTW - it's a myth that tables render the same across browsers. Table rendering has about the same amount of inconsistencies and browser differences as CSS. The difference is that there is no "right way" to render tables, since table rendering is not specified anywhere. It's all just a chain of reverse-engeneering leading back to the first haphazard table implemtation in Netscape 1.1. With CSS there is at least a spec, and the hope that browsers implentations move incrementally closer to the spec.
So what whent wrong with tables? The culprit is that the CSS equivalent of tables, the display:table CSS property (defined in CSS 2) has not been implemented in Internet Explorer yet, even though the standard is 12 years old (IE8 will reportedly support it, though).
So there is no direct CSS equivalent to the layout properties of tables which works in IE. You can emulate some of the properties using floats, absolute positioning and so on, but be aware that this approach is not the "correct" CSS way. Rather it is a workaround around limitations in IE's implementation of CSS. Using tables for layout is a alternative workaround for the same problem. The approaches have different tradeoffs.
The main tradeoff is that HTML-tables are bad for accessibility, while CSS alternatives are often convoluted and hard to maintain. So the choice is basically if you want to cause pain for yourself or for disabled people. Its not hard to understand how this debate turns into more of a moral than a technical discussion.
Note that it is not all uses of tables which require workarounds to implement in table-less CSS. Before CSS, tables were used for a wide array of layout tasks like spacing, margins, positioning and so on, which is generally better handled by CSS today. The limitations are specifically when tables are used as dynamically adjusting grids. I wrote a small article to point out the concrete issues: http://olav.dk/articles/tables.html
BTW - it's a myth that tables render the same across browsers. Table rendering has about the same amount of inconsistencies and browser differences as CSS. The difference is that there is no "right way" to render tables, since table rendering is not specified anywhere. It's all just a chain of reverse-engeneering leading back to the first haphazard table implemtation in Netscape 1.1. With CSS there is at least a spec, and the hope that browsers implentations move incrementally closer to the spec.
I seriously find it difficult to believe that this is still a debate on YC. Once you attempt to build a site of a reasonably level of complexity and/or learn how to build a site using clean, valid, semantic markup, you'll never go back - unless horribly messy code and hack piled upon hack are your thing.
This isn't about being a web standards zealot. It's about learning to do your job. Look to any of the industry leaders in frontend development - it is simply no longer an issue. Table-based implementations of layouts (and all non-tabular data) are the GOTOs of modern markup.
This isn't about being a web standards zealot. It's about learning to do your job. Look to any of the industry leaders in frontend development - it is simply no longer an issue. Table-based implementations of layouts (and all non-tabular data) are the GOTOs of modern markup.
CSS layouts offer a whole host of advantages over their ancient table-based brethren. Historically, there has been a lot of discussion on this, but the conversation has basically been concluded with CSS layouts overwhelmingly recognized as the best option.
A CSS layout lets your site be flexible, scalable and semantically pure. When you do a table-based layout, you're basically locked into that presentation unless you choose to overhaul all your files, and chances are good that you've also partially destroyed the semantics of your document, which ruins accessibility and can be bad for SEO. Tables were basically a layout hack that let designers solve a presentation problem for which adequate tools didn't exist; their true purpose is to display tabular data. When browser support for CSS became relatively ubiquitous, people gradually switched over because there was no longer any reason to suffer the inherent inadequacy of table-based layouts.
Once you learn the syntax and the basics of how the box model works, CSS makes everything faster, easier, and more precise. By all accounts, it's the standard for web design nowadays.
I think the proof is in the pudding though; csszengarden.com is a shining example of the benefits of CSS. Surf there, and you can select different stylesheets to be applied to the page. Same HTML, different CSS, hundreds of designs.
alistapart.com is a great resource for discussion on the benefits of web standards and how to apply them. quirksmode.org has technical tips, and w3cshools.com has quick descriptions and examples of most almost everything web-design related.
A CSS layout lets your site be flexible, scalable and semantically pure. When you do a table-based layout, you're basically locked into that presentation unless you choose to overhaul all your files, and chances are good that you've also partially destroyed the semantics of your document, which ruins accessibility and can be bad for SEO. Tables were basically a layout hack that let designers solve a presentation problem for which adequate tools didn't exist; their true purpose is to display tabular data. When browser support for CSS became relatively ubiquitous, people gradually switched over because there was no longer any reason to suffer the inherent inadequacy of table-based layouts.
Once you learn the syntax and the basics of how the box model works, CSS makes everything faster, easier, and more precise. By all accounts, it's the standard for web design nowadays.
I think the proof is in the pudding though; csszengarden.com is a shining example of the benefits of CSS. Surf there, and you can select different stylesheets to be applied to the page. Same HTML, different CSS, hundreds of designs.
alistapart.com is a great resource for discussion on the benefits of web standards and how to apply them. quirksmode.org has technical tips, and w3cshools.com has quick descriptions and examples of most almost everything web-design related.
That sounds kind of snobby, in that it's largely theoretical but just doesn't work in the real world. It's like trying to explain to someone why a good Napa Cabernet is so much better than the $5 Merlot they like.
"Well, it was grown from the Carneros region, fermented in French Oak barrels, then cellared for 10 years."
"Yeah, but this Carlo Rossi Paisano tastes better."
(and I say this as a devoted wine snob.)
CSS is one of those things that sounds great "it lets you separate presentation" but just kinda sucks for some purposes. The problem is, all of the theory is just generally not how it functions in the real world. In the real world, if you're running one site and redesigning it, you're doing just as much changes anyway. You're not just changing some colors and some background images and voila. You're moving things around drastically. (If you could do absolute positioning, it would function a lot better in that regard, but then your page will look crappy because it will be left-aligned in browsers rather than centered.)
CSS doesn't really seem to be meant to do layouts anymore than tables were, as evidenced by all of the hacky kludges you have to use to get it to work that way. Every time I find myself typing style="clear:both" I wonder why the hell I'm doing it. Still I did, grudgingly because guys like you tell me I should, and I wanted to learn .
Don't get me wrong, CSS is great for some things. Defining fonts, sizes, colors, hovers, etc. But for layouts, tables are often easier to implement, easier to maintain, and equally hard to change later. Even though I'm highly competent with CSS, I don't think I'd do it that way in the future.
"Well, it was grown from the Carneros region, fermented in French Oak barrels, then cellared for 10 years."
"Yeah, but this Carlo Rossi Paisano tastes better."
(and I say this as a devoted wine snob.)
CSS is one of those things that sounds great "it lets you separate presentation" but just kinda sucks for some purposes. The problem is, all of the theory is just generally not how it functions in the real world. In the real world, if you're running one site and redesigning it, you're doing just as much changes anyway. You're not just changing some colors and some background images and voila. You're moving things around drastically. (If you could do absolute positioning, it would function a lot better in that regard, but then your page will look crappy because it will be left-aligned in browsers rather than centered.)
CSS doesn't really seem to be meant to do layouts anymore than tables were, as evidenced by all of the hacky kludges you have to use to get it to work that way. Every time I find myself typing style="clear:both" I wonder why the hell I'm doing it. Still I did, grudgingly because guys like you tell me I should, and I wanted to learn .
Don't get me wrong, CSS is great for some things. Defining fonts, sizes, colors, hovers, etc. But for layouts, tables are often easier to implement, easier to maintain, and equally hard to change later. Even though I'm highly competent with CSS, I don't think I'd do it that way in the future.
>>> "You're moving things around drastically."
Funnily enough I just altered two sites this week by moving columns around. One was a simple CSS change, the other was one altered margin declaration and one moved div - I also get to see the alterations as they will appear live in a browser (FF).
>>> " Every time I find myself typing style="clear:both" I wonder why the hell I'm doing it."
Because of IE?
>>> "equally hard to change later"
It depends what you're trying to achieve, if you require a pixel based layout that renders identically in all browsers and completely misunderstands the original web paradigm (accessibility of information, not accessibility of design) then yeah, tables .. though you'd probably be more comfortable with Flash or just going the whole hog and printing it out on paper and pasting it to your screen.
When columns finally arrive in CSS3 (http://www.w3.org/TR/css3-multicol/) across the major UA will you still use tables for non-tabular data?
Funnily enough I just altered two sites this week by moving columns around. One was a simple CSS change, the other was one altered margin declaration and one moved div - I also get to see the alterations as they will appear live in a browser (FF).
>>> " Every time I find myself typing style="clear:both" I wonder why the hell I'm doing it."
Because of IE?
>>> "equally hard to change later"
It depends what you're trying to achieve, if you require a pixel based layout that renders identically in all browsers and completely misunderstands the original web paradigm (accessibility of information, not accessibility of design) then yeah, tables .. though you'd probably be more comfortable with Flash or just going the whole hog and printing it out on paper and pasting it to your screen.
When columns finally arrive in CSS3 (http://www.w3.org/TR/css3-multicol/) across the major UA will you still use tables for non-tabular data?
No, columns are awesome, and CSS3 in general looks like it does a lot more to make CSS useful for layouts. HTML 5 + CSS3 is going to be a designer's dream.
There are lots of ways to define quality. The problem is how much measure people put in them. Guilt or coolness can be a good driver and so they are often used instead of reasons based on quality. One of the other commenters pointed out that guilt seems to be your motive.
There are a number of reasons not to use tables. The main 2 are maintenance cost and accessibility.
Maintenance cost the main point here is by separating the visual styling from the data you have much greater control over redesigning, changing the way the data is displayed, etc.
Accessibility since many people who use the web can't see they listen to their web pages. This means the source order of the site matters. If you create tables that don't linearise then the information becomes out of context and difficult for these users to understand. Using CSS it's possible to create a source order which makes sense but display a different visual order.
My recommendation for a way to do this is to use a grid system like YUI Grids. Like many other parts of development rolling all your CSS from scratch doesn't make sense any more. There are plenty of libraries which take care of the hard problems for you. My favorite CSS library for this is the YUI Grids library. (http://developer.yahoo.com/yui/grids) It has tons of documentation and examples to get started with. I use it for all my work and personal projects.
You might also consider the YUI Reset, Fonts and Base CSS libraries which reset default CSS styles across browsers, standardises the fonts and sets back a common default styling across all browsers respectively.
Disclaimer: I work for Yahoo!
There are a number of reasons not to use tables. The main 2 are maintenance cost and accessibility.
Maintenance cost the main point here is by separating the visual styling from the data you have much greater control over redesigning, changing the way the data is displayed, etc.
Accessibility since many people who use the web can't see they listen to their web pages. This means the source order of the site matters. If you create tables that don't linearise then the information becomes out of context and difficult for these users to understand. Using CSS it's possible to create a source order which makes sense but display a different visual order.
My recommendation for a way to do this is to use a grid system like YUI Grids. Like many other parts of development rolling all your CSS from scratch doesn't make sense any more. There are plenty of libraries which take care of the hard problems for you. My favorite CSS library for this is the YUI Grids library. (http://developer.yahoo.com/yui/grids) It has tons of documentation and examples to get started with. I use it for all my work and personal projects.
You might also consider the YUI Reset, Fonts and Base CSS libraries which reset default CSS styles across browsers, standardises the fonts and sets back a common default styling across all browsers respectively.
Disclaimer: I work for Yahoo!
Just for funsies, here's a pastebin that shows the CSS for a 3-column liquid layout in its simplest incarnation, and then a second set of rules for the same HTML that produce a 2-column fixed layout, with space for a horizontal navbar.
http://pastebin.com/f51ee9672
http://pastebin.com/f51ee9672
I spent much time researching why the tables are bad camp exists, and this is the result of my research:
The beginning
Initially tables were the only way to layout a web page, and so much abuse occured - this was before CSS and the only way to make a layout was to use 'spacer' gifs. spacer gifs were one pixel gifs that you had to put in td elements so they would retain there shape. As you can imagine this was a mess.
Then came CSS and the DIV tag, many books were written about 'spacer gifs were evil' use Divs and CSS, and this was correct spacer gifs were a nightmare.
However what seems to have happened is the baby was thrown out with the bathwater. Tables are the easiest way to do what's now called 'liquid layout'. You can do these using Div's but it takes a bit of fiddling, and the result can sometimes be wrong if the screen width becomes too small.
From a software development point of view I regard using div's for liquid layout as an optimisation - semantically what you want is a spaced layout that resizes dynamically. However, using tables does cause a couple of problems that div's avoid (which I mention below), div's avoid these problems but at a cost (which I also mention below).
The real crunch was early on - Netscape 4.7 (the one that was widely used) crashed with multiple nested tables (try this on browsershots if you're curious). So Div's were used and techniques for using div's in browsers became prevalent.
The combination of the Netscape problems and spacer gifs created the 'tables are bad' thing and new developers coming in were told 'tables are bad' and it continues.
So people used div's and IE6 became the dominant browser, but the engineers who built IE6 never expected anyone to use divs for layout - that's what tables were for - and so the mess occured with div's and css and IE6. This, I think, made the situation worse, as to use div's meant you could MS bash, it also required a deeper understanding of HTML and CSS and so arose the specialist web designers who used multiple incantations in DIV tags and CSS to create what any joe could do in 5 minutes using table tags. This strengthened the DIV/CSS camp until anyone who used table tags was openly scorned as a newb.
In any argument you have with the DIV people the last one they always bring up when they're on the ropes is that braille readers can't handle tables - because the ordering isn't defined. However most of these people don't actually write for disabled readers and this too seems to be without base, I have asked many times for concrete examples, and never have received any.
There are some negatives with tables:
1) The whole page needs to be loaded before it can be rendered (in some cases), as the layout can't be done until the contents of each cell are known.
2) This seems to be a big one - it's very hard to edit nested tables in notepad and figure out where you are, you need more expensive tools to navigate the document, something web developers seem to be averse to for some reason. Me, I buy whatever tools make my life easier.
The negatives with Div's as layout are there too:
1) If you have a few fixed width div's with the rightmost floating (the usual way) and make the page smaller than the width of the div's the rightmost falls below the other div's, it's not possible to stop this from happening. If you use tables a scroll bar appears.
2) You have to have a deep understanding of CSS and a lot of time to experiment on multiple browsers to see what works
Div's can start to display quicker as they have a fixed width usually and so no layout algorithm is required to be calculated. (The actual time to calculate the layout is no longer an issue, but it used to be for tables).
So that's the issues as I see them, and how we ended up with these two camps. If anyone has some more data I'd like to see it. Personally I use a couple of layers of nested tables to establish the rows and columns and fill it up with div's as necessary, and don't worry too much any more. Oh and use styles to actually describe the TABLE/TR and TD elements, which is CSS as far as I can see.
The beginning
Initially tables were the only way to layout a web page, and so much abuse occured - this was before CSS and the only way to make a layout was to use 'spacer' gifs. spacer gifs were one pixel gifs that you had to put in td elements so they would retain there shape. As you can imagine this was a mess.
Then came CSS and the DIV tag, many books were written about 'spacer gifs were evil' use Divs and CSS, and this was correct spacer gifs were a nightmare.
However what seems to have happened is the baby was thrown out with the bathwater. Tables are the easiest way to do what's now called 'liquid layout'. You can do these using Div's but it takes a bit of fiddling, and the result can sometimes be wrong if the screen width becomes too small.
From a software development point of view I regard using div's for liquid layout as an optimisation - semantically what you want is a spaced layout that resizes dynamically. However, using tables does cause a couple of problems that div's avoid (which I mention below), div's avoid these problems but at a cost (which I also mention below).
The real crunch was early on - Netscape 4.7 (the one that was widely used) crashed with multiple nested tables (try this on browsershots if you're curious). So Div's were used and techniques for using div's in browsers became prevalent.
The combination of the Netscape problems and spacer gifs created the 'tables are bad' thing and new developers coming in were told 'tables are bad' and it continues.
So people used div's and IE6 became the dominant browser, but the engineers who built IE6 never expected anyone to use divs for layout - that's what tables were for - and so the mess occured with div's and css and IE6. This, I think, made the situation worse, as to use div's meant you could MS bash, it also required a deeper understanding of HTML and CSS and so arose the specialist web designers who used multiple incantations in DIV tags and CSS to create what any joe could do in 5 minutes using table tags. This strengthened the DIV/CSS camp until anyone who used table tags was openly scorned as a newb.
In any argument you have with the DIV people the last one they always bring up when they're on the ropes is that braille readers can't handle tables - because the ordering isn't defined. However most of these people don't actually write for disabled readers and this too seems to be without base, I have asked many times for concrete examples, and never have received any.
There are some negatives with tables:
1) The whole page needs to be loaded before it can be rendered (in some cases), as the layout can't be done until the contents of each cell are known.
2) This seems to be a big one - it's very hard to edit nested tables in notepad and figure out where you are, you need more expensive tools to navigate the document, something web developers seem to be averse to for some reason. Me, I buy whatever tools make my life easier.
The negatives with Div's as layout are there too:
1) If you have a few fixed width div's with the rightmost floating (the usual way) and make the page smaller than the width of the div's the rightmost falls below the other div's, it's not possible to stop this from happening. If you use tables a scroll bar appears.
2) You have to have a deep understanding of CSS and a lot of time to experiment on multiple browsers to see what works
Div's can start to display quicker as they have a fixed width usually and so no layout algorithm is required to be calculated. (The actual time to calculate the layout is no longer an issue, but it used to be for tables).
So that's the issues as I see them, and how we ended up with these two camps. If anyone has some more data I'd like to see it. Personally I use a couple of layers of nested tables to establish the rows and columns and fill it up with div's as necessary, and don't worry too much any more. Oh and use styles to actually describe the TABLE/TR and TD elements, which is CSS as far as I can see.
HTML is the metadata around your content, and CSS is the style that you apply to your content.
I used to design using tables, then I learned how to do it in CSS and now I use CSS exclusively. There are only a few instances when I don't, namely:
* When I want vertical centering and the column height is not fixed.
* When I want the width of a column to expand to the width of its widest element, but no further.
* If I wanted a background color to run the full length of a column, not just where the content was. (Actually there are CSS hacks for this, but I don't love them. I myself never use this design pattern any more, so it doesn't matter.)
In other words, you can still deploy tables non semantically to address certain, specific challenges that are not easy in just CSS, while still predominantly using CSS for layout and tables for data.
* When I want vertical centering and the column height is not fixed.
* When I want the width of a column to expand to the width of its widest element, but no further.
* If I wanted a background color to run the full length of a column, not just where the content was. (Actually there are CSS hacks for this, but I don't love them. I myself never use this design pattern any more, so it doesn't matter.)
In other words, you can still deploy tables non semantically to address certain, specific challenges that are not easy in just CSS, while still predominantly using CSS for layout and tables for data.
I only use tables when its not possible to go without them (but it happens very rarely). Actually, it requires some time to get used to CSS technique. And I've never used CSS frameworks.
If you are displaying a table of data, use <table>. <div> grids don't paste well into Excel. Tables really aren't evil, they are a better fit for many tasks where you effectively need a table and can generate the data in row order. Nested tables can be pretty evil. Go with a div grid if you feel the even the hint of wanting to nest.
See the triumph of KML (which mixes content and presentation) over straight GML (separate content and presentation) in the GIS world for comparison.
See the triumph of KML (which mixes content and presentation) over straight GML (separate content and presentation) in the GIS world for comparison.
Honestly, I've used CSS for as long as I've been slicing web pages (which is now a couple of years) It'd probably cost me more time designing with tables than with CSS. Once you understand the principles behind it, it's not that hard... (for me it feels like a lego-construction snapping together when a design falls into place)
On the other hand, a professional designer often needs to know how to design with tables as well as it is practically the only way to design an email newsletter decently.
On the other hand, a professional designer often needs to know how to design with tables as well as it is practically the only way to design an email newsletter decently.
[deleted]
I feel like if it's a simple table with divs inside - it probably wont be a big deal because it will be maintainable.
But if you're going to nest tables inside of tables nested inside of tables - then I'd suggest not doing it.
You want to keep it maintainable for not only yourself but anyone else who might be working on it in the future.
But if you're going to nest tables inside of tables nested inside of tables - then I'd suggest not doing it.
You want to keep it maintainable for not only yourself but anyone else who might be working on it in the future.
Although tables is easier than CSS, most browsers will render CSS almost the same way. But not always true for tables. Especially wider sites that need to shrink to fit a screen. I just weigh amount of work I have to do against how much I'm getting paid and do which ever way I feel comfortable with.
"Most browsers will render CSS almost the same way".
Either you have an odd definition of most browsers or you are just completely wrong. CSS is implemented differently by most of the major browsers.
Use a good CSS grid framework like Blueprint, Bluetrip, or YUI. They make most supposedly "tricky" CSS layouts (like 3 column liquid) quite easy.
And of course, remember that it's not necessarily an either/or decision. Sometime part of your page really is a grid, and really should be a table.
And of course, remember that it's not necessarily an either/or decision. Sometime part of your page really is a grid, and really should be a table.
i used to "slice" my layouts with Adobe ImageReady then customize the generated tag-soup with Dreamweaver. Then i transitionally changed my techniques to adopt full-css templating. It takes me more time but i like the way i can control several page's presentation by changing only one (ore more) file. I also find it more php (or templating system) friendly because there are less tags involved.
I find it interesting to see other hacker's point of view on that. It seems like the css way is not THE only way of doing things. Maybe you can get the better of both worlds and use tables for things that looks like tables and use css for what it's made for (i.e :floating stuff, styling fonts).
Not that tables are made to structure the content. It's just easier.
Not that tables are made to structure the content. It's just easier.
Tables won't show up until the entire table has loaded but if that's not an issue then use whatever you find easier (and don't feel guilty--if it works, it works).
If it's tabular data ALWAYS use tables.
If it's tabular data ALWAYS use tables.
a 30 second review:
tables: easier to design with and more intuitive for people who aren't well-versed in css.
css: much greater flexibility, smaller code, separation of design and information
tables: easier to design with and more intuitive for people who aren't well-versed in css.
css: much greater flexibility, smaller code, separation of design and information
CSS-based sites are also supposed to be better in terms of accessibility as screen readers etc. can separate out the semantically distinct parts better.
CSS layouts take some practice, and they made some design choices I'd describe as bizarre, which make your task more difficult, but now that I've got a good grasp on it, my markup is much more compact and I wouldn't want to go back.
CSS layouts take some practice, and they made some design choices I'd describe as bizarre, which make your task more difficult, but now that I've got a good grasp on it, my markup is much more compact and I wouldn't want to go back.
You don't have to pick just one. On one of my sites I have tables for the navigation elements and CSS for the content elements. Use what works for you.
If you have the time, use CSS. For prototyping you could use tables perhaps, but for the real thing, tables are considered bad form and inflexible.
HTML is flawed at every level:
It's design is flawed- rather than having a minimal set of tags they have a tag for everything and most people use only a fraction of total tags.
It's implementation is flawed- no two browsers render HTML the same way.
The way people learn HTML is flawed- some people learn to use inline styles, some people use br's to delineate paragraphs, some people build pages without head tags.
In conclusion, fuck it, use tables.
It's design is flawed- rather than having a minimal set of tags they have a tag for everything and most people use only a fraction of total tags.
It's implementation is flawed- no two browsers render HTML the same way.
The way people learn HTML is flawed- some people learn to use inline styles, some people use br's to delineate paragraphs, some people build pages without head tags.
In conclusion, fuck it, use tables.
I thought this question was not only answered, but went away, three or four years ago. The first quick response is that tables for layout is stupid. You lock yourself into a predefined grid which you have little control over, it provides immovable elements that are more difficult to style and is slower to download and render.
That's just the tip of the iceberg. Google for more. But you can get any piece of crap markup to make a presentable page on the internet right now. So would you continue to write crap code just because it works? Ridiculous!
Over 4 years of doing this. Never used tables for layout and I do mostly ecommerce sites for national chains.
That's just the tip of the iceberg. Google for more. But you can get any piece of crap markup to make a presentable page on the internet right now. So would you continue to write crap code just because it works? Ridiculous!
Over 4 years of doing this. Never used tables for layout and I do mostly ecommerce sites for national chains.
You're halfway correct. This question went away 3 or 4 years ago, but in the other direction.
Everybody independently figured out that 35 DIV tags half-nested into each other is actually MORE markup than a table, and it's less readable. So we all went back to using Tables for stuff that looks like Tables.
I thought we copied you on the memo. Sorry about that!
Everybody independently figured out that 35 DIV tags half-nested into each other is actually MORE markup than a table, and it's less readable. So we all went back to using Tables for stuff that looks like Tables.
I thought we copied you on the memo. Sorry about that!
This argument is over. Tables lost...like 3 or 4 years ago.
I know that from time to time, PG gets crap for using tables for HN, but it seems to work rather well, and it renders the same across all the browsers I've used, including my Android phone.
I'd love to hear an educated discussion on table based vs CSS based layouts. Please discuss.