Welcome to WebmasterWorld Guest from 22.214.171.124
Forum Moderators: phranque
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.
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.
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.
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!
I choose CSS wherever possible,
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.
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. :)
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.
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!
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. :-)
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.
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 ;)
>>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.
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.
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.
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.