| This 101 message thread spans 4 pages: 101 (  2 3 4 ) > > || |
|Why is using tables for layout evil?|
I know... I know... beating a dead horse.
I know that the tables vs css for layout question is one that sparks hot debate among webmasters from all experience levels, but I'm genuinely curious as to why using tables, at least for some, is considered to be so taboo? This is a genuine question, mind you, not a poke or jab at anyone or anything.
I've never had any 'formal' training on how to develop websites. I've been doing it on and off for about 10 years, learning as I go, always teaching myself. I've taught myself html, php, sql, some unix stuff, and just basically whatever I've needed to run a website. At first trying to figure out how to make everything go where I wanted it was a tough job. In addition, I never even heard of css until I was years into making basic websites, and my habits had stuck. When I first started I got into the habit of using tables to structure the pages and make them look the way I want because it worked and was very simple.
I haven't changed.
Why? My question is why should I? I'm not trying to be negative or derogatory to the CSS layout crowd with that question either, I'm genuinely interested in hearing why I should switch.
Tables are easy to create, easy to understand, don't break in different browsers... they just work. I know that semantically they're for data and they aren't designed to be a layout element, but there are examples of stuff like that everywhere. Tires aren't made to be swings and AOL CDs aren't made to be coasters, but if they do the job quickly and effectively... why should I care? My visitors will never notice any difference unless they're technical, which most certainly aren't.
In fact, I have a couple very successful websites of which I'm very proud. Both generate income and both use tables for layout. Both look exactly like I want, both do what I want, and both are easy to work on if I need to make changes. I use CSS on each, but only for styling issues so the CSS is pretty basic and easy for me to understand. I would say that I know CSS enough that I can write a stylesheet that will change the way things look, but when it comes to positioning divs and floating things I'm pretty much in the dark.
It's not that I haven't looked into it, but as soon as I start digging into how to replicate a simple table layout in css I get discouraged.
Tables are just so... Simple. Quiet. Unassuming. Comforting.
CSS is Quirky... Unsupported at times, and even when it is, you have to really tie it into a knot to make it work like a table.
I guess it's just that I don't quite understand why many would perhaps consider me to be an amateur simply because I choose to use tables for layout. I'm by no means what I would consider to be a professional or a guru, but I design sites both on my own and at my job... and I think my peers at my job would consider my work to be of professional quality. Then again, they don't see the code. Then again, neither do my visitors.
When the final result is the same, do the methods really matter so much... at least in this case? I'm not interested in hearing why I'm supposed to do it another way, I want to know what I'll quantitatively gain if I switch.
How many times did I start div-layout for my next site... How many times after 3 hours, I decided not to do 100% rubber layout... How many times after 2 days, I cast hands, leaving smoking, and did layout with tables for hour...
I'm not really an html/css guy myself. I can play around w/ it and get something looking half way decent, but never great. I'm not 100% sure why CSS is prefered over tables.
However, I think that from an SEO perspective...
Tables typically require a LOT of markup to render even the smallest amount of text. What I mean by this is the ratio of markup in the HTML (all of the tags required for a typical table) is typically high in comparison to the images and text being marked up... A lot of tags for the table to position a few images and/or tidbits of text.
With CSS this can be done by placing the styling info in external CSS files. Very little markeup is required inside the actual HTML. The ratio of markup is low in comparison to the images and text being marked up.
Less markup in the HTML means faster loading of pages I guess... It also means a higher content to markup ratio.
Tables can sometimes be tough to debug when you have tables within tables withing tables and on and on.
Tables have their place... Especially for formatting data in tabular formats.
If you're comfortable w/ tables and not w/ CSS and you have sites that are doing fine w/ tables, I don't see why you should change.
Not everyone has to drive a Bentley. Some people are happy w/ a Honda Civic. They both get you from point a to point b.
[edited by: ZydoSEO at 5:20 am (utc) on Feb. 29, 2008]
It's much easier to do site wide design changes with CSS sites.
|It's much easier to do site wide design changes with CSS sites. |
There is no such thing as a CSS site. There are sites using mainly <table> tags for layout and sites mainly using <div>. CSS can be used to apply visual effects to both tags. The only difference is that individual <div> blocks can be easily repositioned independently on the screen with CSS, where that is not possible with the individual table cells, columns and rows within a table structure. But that is the only difference. CSS can be used (and is used) on almost all sites which use <table> for the primary layout.
That said, the pro's and con's of both approaches really depend on how your site is generated and what type of content you display. If you have a site written in static HTML which loads external CSS files, then yes, changing the external CSS files will have site wide effects and with a few edits you can change the layout site wide. But if your site uses templates that are dynamically applied to content in a database, the difference is not huge. A template change will also have site wide effects.
There are even some types of sites (like forums for example) where table structures give a much easier way to layout pags properly compared to div blocks. Tables are also easier in that they automatically stretch or compress content in neighbouring cells when the size of the content of one cells changes. Because <div> blocks--by design--have no relation with each other, this can be really difficult to manage.
Another pro for <table> is that it is implemented on all browsers in almost the same way, where positioning <div> blocks with CSS is still some sort of jungle where you have to test on every single browser and even different versions of browsers to see if what you want to do will give comparable effects for all users. The resulting CSS code is often so ugly to account for the differences and bugs in browsers that the HTML code itself may seem clean, but the total set of source code to generate the page is really ugly, both to read, and to maintain.
About 50% of my sites use <div> only, the rest a combination of <table> and <div>. I am happy with that and have seen no negative effects on search engines unable to parse or rank the content. Just as a heads-up, the site where you are posting on now is using tables almost exclusively, although things may change when a new version of the underlying source code is coming out in a month or so.
I *heart* tables. They are easy for me to do, I can visualize the page exactly in my head and translate it to tables, blah blah blah.
That's because it's all I've ever really done. I'm sure if I wanted to I could quit tables cold turkey and go CSS, but I just don't feel like it.
I think you should use whatever language/software/etc. you want. If tables are evil, then hand me my pitchfork!
not evil.. simply a choice
I choose CSS wherever possible,
- source ordered content: so it still makes for a legible document in screen readers or text browsers
- less horizontal scroll on small screen PDA's,
- can add/take away sidebars, have sidebars left or right, or both on either side (all at bottom of smaller screens)
- hide certain blocks depending on privilege (eg.admin functions) without nesting further tables or adding more cells
- have classes control whether page has 1, 2, 3 columns without needing multiple HTML templates
that's just some of the flexibility it offers for me, if you don't need that and you don't have clients who do, or visitors that might need a different type of access - and you're not going to "quantitatively gain" then I wouldn't fret it.
>> My visitors will never notice any difference unless they're technical,
.. or until they try to access it on their mobile phone and have to scroll down through all your navigation, ads, etc to get to the content?
there are certain cases like forums where it may well be easier to use a table for the main framework, but there should still be no need to nest, nest, nest think about the HTML to content ratio as mentioned above.
|There is no such thing as a CSS site |
Whatever, you know what I'm talking about, so there is such a thing. Layout flexibility and easy style changes make CSS sites a big step forward. They can be more work at first.
Tables load much slower than divs because the browser needs to read to the end of the table tag before displaying. Divs are good when you have heavy content pages as you will lose less surfers on dialup. Source ordering helps with this too.
Tables aren't evil, they are just old school. They still have their place.
As far as i know, table-driven websites generally have more static layouts than CSS-driven sites. With CSS, your website becomes more accessible to screen-readers, browsers on small screens like mobiles, etc. With CSS you can also define different layouts for printers, so that the navigation menu doesn't appear when you print a page (e.g. order confirmation or e-ticket), so no need to create a separate "printer-friendly" page. In short, with CSS you can make the same HTML code functional in all the different types of browsers in use these days.
A number of people have mentioned one of the key advantages of CSS over table-based layouts: flexibility. If you ask me, this flexibility stems from using the right tool for the right job. The arguments against CSS seem to almost entirely stem from browser incompatibility, which lessens the more time (and browsers) move on. Not being able to work effectively with either tables or CSS is not an argument in favour of one or the other.
|Why is using tables for layout evil? |
C'mon, that's a pretty tabloid headline for a thread claiming to seek balanced perspectives. What next, Freddie Starr ate my table?
C'mon, that's a pretty tabloid headline for a thread claiming to seek balanced perspectives.
I got you to reply didn't I?
The Table/CSS debate has gone on for a long time, and throwing a topic like "CSS vs Tables.. which should I choose" just isn't going to cut it if I wanted to get responses. Most forum readers would be asleep before the end of the title.
Moreover the title is a nod to several places I've been to online where webmasters who still use tables seem to be considered the throwbacks of a bygone era... amusing to look at and study but not of much practical use. That's if it's a nice discussion... I've also seen where table using webmasters are regarded as stubborn idiots who will never be true professionals. In such discussions it goes without saying that CSS is the defacto standard and tables are nothing more than a cheap way out, usually comparing websites which use them to myspace layouts and amateurish Joomla sites. I'm not saying WebmasterWorld is like that at all, quite the contrary, which is why I thought I might be able to open a dialog and get some decent discussion going without being called quaint.
I've never really considered mobile users, which I suppose I should though I don't expect them to buy anything over their mobile phone. I've checked my sites in my own mobile and they aren't spectacular but not unusable either. It is something to consider though when making the comparison between CSS and Tables, which can be said of many things in this thread so far. Thanks. :)
until you want a site-wide change...
Just give up on it. CSS is the way to go. Especially with the web more and more converging towards XML.
>>CSS is the way to go
Not if it makes more work and makes it harder, and more complicated for folks to update or add content to a site who don't even know what HTML is in the first place.
Sometimes in life there can be a choice between purity and practicality.
I'll go to CSS for layout when I don't need to put in browser specific fixes.
Tables are not evil - what/who gave you that idea?
Tables are just a solution, as is CSS. Use the appropriate solution for whatever requirements you have.
There are benefits to CSS (source ordered content, better mobile support etc), but they're still (for now) a relatively minor thing.
There are also benefits to tables (simplicity of coding, better cross-browser suport etc).
Take your pick. Neither is wrong.
|Tables work... |
until you want a site-wide change...
Not so. If your site has a type of page template that is based on tables, then you can make a site-wide change there. I recently made the content area of every page on a site wider by changing the table width in the template. Didn't have to touch the CSS at all!
The problem with CSS+divs is, it can be a real pain to simulate what tables give you automatically. If I'm being honest, I really think the designers of CSS did a poor job on this one. There has to be a better way than messing around with floats and whatnot, particularly when browsers have different interpretations. If a browser messes up displaying a table (this usually doesn't even happen), the result tends to be that things may be misaligned but still roughly where they should be on the page. When the browser messes up displaying divs, the result is very poor. Usually the content div doesn't float as intended and displays *underneath* the side column full of links and ads. I see this happen even on major, top-tier web sites.
my humble opinion:
there's nothing wrong with using a <table> once in a while for things other than non-tabular data. If you need a quick set of columns and rows, the <table> rocks. But if you find yourself nesting tables within tables within tables to achieve rounded corners or a stupid shadow effect, you deserve a smack upside the noggin with an Eric Meyer book
> It's much easier to do site wide design
> changes with CSS sites.
In todays world, the reality is that most new sites are dynamically produced on the fly. Site wide changes by changing one file is a ahem - a delusional fantasy so far from reality. There are no top CMS systems where "one change" would be applicable by any stretch of the imagination. On a modern site, you will have multiple software systems running multiple templates (phone, multi-browser, sometimes multi-languages), css (quirks, compat, layout fixes), ajax (multi-fixes and support), simple js calls, inserts/includes, widgets, and sub calls coming from multiple software sources and even multi-servers and multiple sites. That makes for an incredibly complex markup world. Putting styles in with the code that is generated on-the-fly is far easier maintenance that having to track down edits in multiple stylized files.
I also find it interesting, that one of the most popular languages of the last 10 years, has been PHP. What did it do? It combined program logic/flow, with presentation. Think about it...
Aside from easier maintenance and code generation, I still think, the biggest bonus to using tables is guaranteed compatibility.
|Why? My question is why should I? |
As a recovering table junkie, it appears to me it comes out of what you think is important about a web site's pages.
When we first start off in web development, it's all about presentation. This is what's so frustrating about a print designer trying to incorporate a web page design based on the brochures they did for a client - it has no connection to the way web sites really work, and usually winds up in an overbloated graphic-based online brochure that will only properly format in tables.
So if you never get the message that there is more to a web page /web site than presentation, your way of working is likely to never change. As long as the clients write the checks, you keep getting good feedback, why bother, right?
When you really start looking at the way web pages are digested by both browsers and search engines, at the issues of document semantics, SEO, web standards, and most importantly accessibility guidelines, it becomes very clear that this distinction is relevant: tables are for tabular intersecting data. Using them as a layout tool confuses screen readers and interferes with the semantics.
If you never get to this point or never consider it important, power to ya', what works is what works. :-)
|...as soon as I start digging into how to replicate a simple table layout in css I get discouraged...CSS is Quirky... Unsupported at times, and even when it is, you have to really tie it into a knot to make it work like a table. |
Funny you mention the work "quirky" - because it is very likely that is the largest root of your problem, using an invalid document type that throws browsers into Quirks mode rendering. Unless you understand how standards mode works versus quirks mode, this will send you off looking for hacks to make all the browsers play together. Start with understanding doctype [webmasterworld.com]. This is the "doorway" to getting a) CSS to function as you expect it to, and b) breaking down most of the cross-browser display issues.
A few short years ago, I cam to this board trapped in tabled layout. It was, really, the only reliable thing I knew, pretty much where you are. I had a strong knowledge of CSS, but struggled much as you do to get layouts to work without them. I'm happy to say, with the help of the info on this message board and a lot of hair-pulling persistence, for the last year not a single new design or redesign has contained a table unless it is tabular data. This includes forms, what I consider the toughest cookie to crack in a CSS-based layout. It can be done.
Once you see how it can be done, it gets easier, and this motivates you to forge onward. And one thing you may find surprising, I **do not,** under any circumstances, resort to CSS hacks or browser-specific conditionals to get one browser or another to play along. There is **always** a way to do it, even if it means backing up on Your Terrific Idea and rethinking how you develop it.
My reason for making the change? ACCESSIBILITY and document semantics. IMO presentation is not top of the pile. :-)
|I also find it interesting, that one of the most popular languages of the last 10 years, has been PHP. What did it do? I combined program logic/flow, with presentation. Think about it... |
actually don't make me think (yea I pinched that one), why not just explain your reasoning?
|The problem with CSS+divs is, it can be a real pain to simulate what tables give you automatically. |
I would agree with that. Tables can do source ordered code too BTW.
Personally, I like tables and I use css extensively with them. I even place the images by css. To me it is the best of both worlds. Simple, easy and quick to make changes. Couldn't do without my css and tables present the same in all browsers.
I thought tables were easy to use and I could pump out a new template for a CMS using tables in less than a couple of hours from start to finish.
Then one day I tried to introduce video to my site and figured I could do this by using my existing layout and combining some table "cells." After spending about eight hours on what I thought was a simple assignment, I gave up. Tables have limits.
Amazon uses tables. Google uses tables. WebmasterWorld uses tables.
I (mostly) use CSS but I'm acutely aware of what a PITA it is, testing is a nightmare, and I can't wait for CSS3 which will finally introduce column layout functionality.
Currently we're (mostly) just "abusing" floats so expect a new wave of puritanical zeal pushing a "floats are evil" meme when CSS3 arrives ;)
>>don't make me think
>>why not just explain your reasoning?
So the easiest entry point is the one that is the least abstract and the least abtract is the one where you don't have program logic in fifteen files, structural markup in five more (typical for a wordpress theme), and presentation definitions in a third set of files (which may be a set of one).
The least abstract point of entry, on the other hand, is one file, where PHP intermingles with HTML and I just define cell-spacing and cell-padding right on my tables and borders right in my image tags. I want *this* to change, so I make the change *here* not way over *there*. Simple. Don't make me think.
CSS is a tool for webpage layout which works.
Layout tables are a hack for webpage layout which work.
If you just want something which works, it doesn't matter much whether you use the tool or the hack to lay out your pages.
If you prefer not to use hacks, presumably you won't use layout tables.
Interestingly though, if we'd had a proper tool for layout when browsers first came out, then we'd never have needed a hack. And we wouldn't be having this conversation.
I'm not sure if this is still the case, but back in the IE6 and Firefox 0.6 days, tables were rendered all at once - that is, the entire content of the page had to download before anything would display.
This isn't the case with div's. So with a CSS layout, you can make a source-ordered layout where the main content downloads first. If it's the first few bytes in your code, then your actual content will display almost immediately, even on very slow connections.
Not to mention the search engine benefits of source-ordered content...
Plus, you can edit a single CSS file and totally change the look of your site, if you're so inclined.
And a CSS page is so easy to read and follow in your text editor, contrary to tables and nested tables and forgotten colspans and rowspans and all the rest of it.
Finally, the bugs aren't *that* tough to deal with, at least not in the real world, once you get used to what they are. Actually, a lot of it is just getting a semi-intuitive "feel" for how different browsers will handle any particular technique. It becomes second nature after awhile.
Personally (ab)using tables to achieve layout has a number of drawbacks that can be avoided by using CSS instead:
- hard to edit due to complex structures
- hard to change layout without touching the content
- hard to show on unexpected media (such as being hard to print)
- next to impossible for those in need of e.g. screenreaders
(just try what your site looks like in a text only browser to get an idea)
- significantly slower load times due to larger files, no sharable components, and progressive loading issues
- forces you to think in terms of a matrix to put things in, e.g. disallowing a layout flowing around a graphic
- difficulty in allowing the user to specify his favorite settings (needed, think those visitors needing larger fonts)
Tables in themselves are not evil, using it to do layout might very well be if you e.g. look at it from visitor with needs like a screen reader or somebody just needing a very large font.
|a CSS page is so easy to read and follow in your text editor |
When it comes to search engines, this observation holds a key. Table cells can break important semantic connections between various parts of the content, because they've often been kludged to get the look right in a visual browser. But a non-visual user agent, and that includes a search engine spider, does not easily capture that meaningful and potentially important relationship across table cells.
| This 101 message thread spans 4 pages: 101 (  2 3 4 ) > > |