This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Does it make sense to use the <table> tag on a “modern” website?
Everywhere I go I see don't use table layout, it's evil, even Google says that, so why one of the most visited websites, Google and Twitter, use it for their homepage?
I don't think it is any kind of mistake, or any other stupid problem.
The only reason I can think of is, that they want the page to look similar even if client doesn't support CSS, like with Lynx.
So why everyone say it is so bad, if the biggest websites on the internet use it.
In my opinion, there are some cases, like those mentioned above, where it is vitaly important to have the same look everywhere, than it is OK to use tables.
edit: The same question goes about html elements like <center>, or formatting text with attribute align and other "html attributes and elements used to substitute CSS functionality"
Page load time is king for these guys, and bandwidth usage is extreme.
I'd have to say they use tables for raw data speed, since they are serving up so much bandwidth every day.
Also, notice that they use inline styles in the page header to reduce the number of HTTP requests to help speed up page load time.
Table layout gets more grief than it deserves. It's easy for developers to use, it's consistent across nearly every web browser, and it allows you to easily add rows/columns with little to no effort.
The only downside is that it goes against the mantra that your document should only contain content, and your design should be contained separately (in a CSS file).
Google doesn't have to care about ranking high in search engines... ;)
Yep, agreed. Sometimes, just sometimes tables are just fine. Not everyone is writing websites that are targeted at every possible browser, that needs to support text to speech etc. In general, try to learn and grow your skills and use CSS positioning etc, but nothing bad will happen if someone uses a table to position things on a webpage.
Maybe this question should be community wiki, though?
It's evil, it's a pain, but rendering is pretty much guaranteed to be consistent across different browsers.
Table layout is working on most browsers. Google and others want to reach all user, not some or only modern users. Having different layouts or layout technologies is hard to maintain and costly in delivering content.
Table layout is not tricky. Its straight forward. You dont have to look for css hacks, browser incompatibilities or others.
Table layouts are bad. Because thy mix layout and content.
Twitter works pretty well from phones in web mode. Some web browsers are truly gruesome, so I assume Twitter does what it has to.
Given how poorly so many web sites work on phones, I'm more concerned about mobile compatibility than with the concerns of CSS evangelicals.
Three main reasons:
Tables are mainly bad for search engine reasons (there's also the issue of them messing up the DOM a bit, but that's not too bad). People don't search for Google on search engines, and people don't search for Twitter posts on generally either.
Tables render consistently on nearly every browser, including smartphones (which is a big concern for Twitter especially).
Tables consume less bandwidth. Both sites have immense data loads and need every bit of speed they can get.
Browser Support - These guys need to have their websites render perfectly on ALL web browsers (New, Old and Obscure). No matter who's using their websites and what OS/Browser their using, these websites need to work.
Each web browser supports it's own implementation of CSS and this causes a similar issue to that of the JavaScript DOM support in various browsers.
Page Load Time - Also their pages are optimized for Page load times. If it takes a user too long to load the page they'll just go somewhere else. There are still plenty of users without broadband, even a lot of mobile devices don't have very fast connections depending on where you are.
Related
With regards to mobile websites on smartphones;
Assuming that:
HTML code is rarely a huge amount of data
Compressed JS files are not so heavy
Images are often loaded via CSS (at least could always)
It's the same sequence (PHP + SQL = HTML) on server-side.
It seems way faster to do this way and quite easy to maintain.
And even if:
It's not graceful at all (hide Useless elements instead of generating a sharp and beautiful HTML code)
Useless code is loaded and treated.
Best practices for mobiles websites don't recommend to do this way.
Is it a good idea to rely only on different CSS to create a mobile version of a website? (Actually on different header templates, in order not to load useless JS)
It's probably a bad idea to serve HTML with elements that you know will be useless to your users.
Small amounts of kb make a difference on mobile download speed.
It means your CSS and Javscript need to be more complicated.
You users might see the content if the CSS or JS are slow loading.
It will take more processing power (I think CSS styles will still be applied to the hidden elements).
It's likely to be easier to manage on the server
But to answer the question "Is it a good idea to rely only on different CSS to create a mobile version of a website?";
Yes if you want your mobile users to have the same content as your large screen users. Which you probably should as this is normally what the users want.
No if you want to serve them different content.
Speaking for Belgium, I know a lot of people are still on Edge instead of 3G and loading a webpage takes some time. If we would have to load pages made your way, we would indeed be loading a lot of useless code, giving us quite a bad experience.
I'd suggest you stop being lazy and write your mobile websites the way they should be written. Think of your visitors and user experience; it honestly isn't that much of an effort.
I think you basically answered your own question already. Like BoltClock said, do what you want, but I sure wouldn't recommend doing things your way.
Forgetting about things that pertain exclusively to the developer like code maintainability and religion wars about semantics and what-not, my question is: what real world problems does using tables present to the user? Are there device that cannot understand a tabled layout properly? Does it decrease the page's relevance on search engines?
Of course I'm talking about a reasonable layout where tables are only used for things that in pure CSS/divs require hacks (and for tabular data obviously) -- not things like a hundred nested tables maybe even used instead of ul/li.
User agents (aka browsers) for the visually-impaired may use spoken descriptions of a webpage.
When the layout is done by table, the description of the page contents becomes a description of the table, which is unlikely to help understanding.
Tables are such old technology that they are reliably rendered on every device and in every program I know.
I am not encouraging the use of tables for layout unless really, really necessary (which it is in a few cases), but I do not believe a well done layout using tables for some aspects does automatically affect rendering negatively. Feel free to prove me wrong, though.
There may be problems for text to speech programs when a table is used instead of the semantically correct element, e.g. in ordered/unordered lists. But I believe that any text to speech or other accessibility software has provisions for this, otherwise it would not be usable on today's Internet.
There may also be cases in which a browser that needs to intelligently resize a web page (e.g. a mobile browser) has more trouble with tables than with other layout elements. But that depends very much on the individual layout and situation.
Here's a nice presentation that sums up the problems with tables pretty well: http://www.hotdesign.com/seybold/06problems.html
The main end-user argument I have about it is future-proofing, and page size (which relates to load time, which relates to user experience). If you are designing a page semantically, and using the minimal markup approach, then page sizes w/o table-based layout are almost always smaller than pages that use a table-based layout.
That's more bits on the wire on every request for that page, which (as stated) means longer load times, etc. min-html + external CSS sheet, however, works out to markedly faster load times for most production sites (see Yahoo's YSLOW guidance) due to the fact that there's usually a one to many relationship between CSS sheets and pages, which means that you are taking advantage of browser's caching capabilities (and potentially other intermediate devices caching as well).
The future-proofing comment is related to design changes. It's much easier to effect wholesale visual layout redesign from CSS with a min-markup page than it is to do so in most common table-based designs. See csszengarden.com for examples.
Obviously, YMMV in both cases. If you're really making the minimal use of tables (e.g. one table on a page, one row in that table, three TDs in that row, one for each column), then you probably don't have to worry about those things. That said, ime, it's better to learn the CSS techniques, or pay someone who knows them. Designs quickly become more complex than you think they will up front many times, and using tables as a quick fix soon becomes a slippery slope. Again, all said IME; YMMV.
I was looking at the www.google.com in Firebug and noticed something odd: The Google logo is centered using a center tag.
So I went and checked the page with the W3C validator and it found 48 errors. Now, I know there are times when you can't make a page valid, especially when we're talking about something like www.google.com and you want it to be as small as possible, but can someone please explain why they use the center tag?
I attended a panel at SXSW a few years ago called "F*ck Standards" which was all about breaking from standards when it makes sense. There was a Google engineer on the panel who talked about the Google home page failing validation, using deprecated tags, etc. He said it was all about performance. He specifically mentioned layout rendering with tables beating divs and CSS in this case. As long as the page worked for their users, they favored performance over standards.
This is a very simple page with high traffic so it makes sense. I imagine if you're building a complex app that this approach might not scale well.
From the horse's mouth.
Because it's just the easiest, most concise way to get the job done. <center> is deprecated, for sure, but as long as it's still supported, you're likely to still see them using it.
Shorter than margin:0 auto. Quicker to parse. It is valid HTML4. No external dependencies, so less HTTP requests.
Usability is NOT validity.
Google Search's biggest achievement has been to build a site which is easy to use, and can be widely used. Now, if Google achieved this with a page which does not validate, well, there's a lesson there to learn.
I think a better question to ask would be "why would Google make it validate if it works fine?" It makes no difference to the user.
There has been speculation and discussion about whether this is intentional; the basic test carried out in the first link does result in a smaller page, and even gzipped, through millions of page views it theoretically stacks up. I doubt that's the reason though: it was created, tested on many browsers at the time, it worked, and continues to work.
Google's breaks validation in many ways on their home page. The very likely real reason - they are all about speed and bandwidth costs. Look at the size of the home page HTML particularly after Gzip is applied at the packet level. They are clearly trying to avoid packet fragmentation (which will mean more bandwidth) and willing to do whatever it takes to get it (identifier shortening, quote removal, deprecated tags, white space removal, etc.
If you look at this just as a validity question, fine but they break the rules on purpose if you don't assume this of course you may jump to a negative conclusion. BTW you can further optimize their pages both in positive and negative manners but why once inside the typical packet size it is somewhat pointless.
They also use other deprecated presentational tags like font and u. My guess is it makes the page quicker to load then using an external stylesheet and allows it to work on more platforms.
It's deprecated, sure, but I think simplicity is the answer to your question.
I'm trying to compile a guide for students used to publishing in print who are learning web design.
Some obvious things which web developers know but they don't:
You can't rotate graphics in HTML
All objects have to be rectangular, you can't have a circular DIV
Many typographical effects in their repertoire can't be achieved
Some things which are tricky are:
Can they have variable opacity? Well, yes and no.
Can they have rounded corners? Maybe.
Some things which aren't technical difficulties, but which are problems:
Image file sizes: I have a student who wants to have a different large graphic header on every page of their site; that's not technically a problem, but it will mean a visitor has to wait for a new graphic to load every time they navigate
Accessibility: "why not just make everything a graphic, to overcome the limitations of HTML?"
Please help me fill out my list and add any hints or tips for people making this transition.
web is not print
Layouts can be fluid.
elements don't have to be absolutely positioned
web pages need to be checked in several browsers for compatibility
avoid divitis; from experience people coming from print into this field do everything by brute force instead of trying to think of elegant solutions for optimization and semantics purposes
print is consumed visually - the web is consumed by people with visual impairments as well. Don't forget lynx users no matter how small the market share is :)
semantics is important, learn about them
thats all i can think of right now...
Coming from someone who has done both print design and web design (and done a decent job at both, I think), it seems like you're off to a good start. Other thoughts:
Darko Z mentioned this but I think it's worth stressing that browser incompatbilities must be recognized and dealt with. In the print industry there are standard formats like PDF which guarantee that things will come out in print the way they look in design; besides, many publishers will directly accept the native file formats of the most popular design programs, like Adobe InDesign, Quark XPress, even MS Word (for the cheapskates ;-P). The point being that print designers are used to a "set it and forget it" approach where they assume that once they design something a certain way, it will stay designed. The fact that there are different web browsers which render the same web pages slightly differently is likely going to be a major pain in the butt for people used to the print world.
Addendum to the above: fonts. You can't use (or at least can't rely on) uncommon fonts in web design, for obvious reasons.
Screen real estate has to be used effectively because there's a limited amount of it. And I mean really limited - no matter how hard you try, you can't write HTML that will make someone's monitor expand 5 inches or put another screen on the back ;-) It's not like in print where people can peek back and forth between different pages of a book. Reading web pages is kind of like looking at parchment through binoculars; you have to design the pages with that limited field of view in mind.
Web page designs are dynamic and transient; they stay up for a while, they get boring, they get recycled/replaced with new designs. So you're not stuck with mistakes. But it also means you need to design with future changes in mind, e.g. by using CSS so you can change the look of whole classes of elements easily. There is some use of styles in print design but nowhere near as much as online.
Fonts and Text
You are limited to a small subset of
fonts
Fonts are viewed at different sizes
There is a readability limit for how
wide paragraphs should stretch (in a
fluid layout)
Write for readers of all types - Some
will skim, others will read in detail
Images
Sites are viewed at different
resolutions and screen sizes - Design accordingly
To achieve transparent backgrounds in
IE6, use PNG8 with alpha (IE6 doesn't
support varying levels of
transparency, it's either 100%
transparent or it's opaque)
Use CSS sprites
Images should not be used in place most of text
The img tag should be used for images
with semantic value and all layout
images should be CSS images
Every img tag needs to have the alt
attribute to validate
(X)HTML and CSS
Browser rendering varies greatly
Validate CSS and (X)HTML for a
greater probability that the design
will be cross-browser friendly
Don't use CSS hacks
Use the proper semantic markup
Pages should be able to work without
JavaScript enabled
Read Yahoo's guide for
performance and use YSlow
Dreamweaver's design mode doesn't
reflect how a page will appear in
real browsers
General Design
Simpler is often better in terms of
usability, accessibility, design, and
download size
Lists of greater than five or six
items should be broken up visually
Consistency is important - Don't
change your navigation, etc without
an extremely good reason
When choosing colors, keep those with
color-blindness in mind. This will
affect how you choose to convey
meaning by color.
Place the most important information
above the fold (the part of the
screen that shows without scrolling)
The web is interactive. This
drastically affects how you consume
and display information. You can hide and subsequently display information using tabs, accordion, and similar methods.
Think in terms of primary and
secondary calls of action. What do
you want the user to do? Where do you
want them to go next?
Some broad points:
1. Print is static, the web is interactive.
The essence of a print project is a fixed point in time, an idea captured on paper or some other substrate. Web projects are moving, changing experiences that represent both the ideas of their creators and their users.
2. Everything is uncertain.
You mention typography in your answer, it's probably worth broadening that to cover all aspects of appearance. The variety of operating systems and hardware available mean that its hard to determine how all your audience will experience your final design. Whilst some things must be compatible across all browsers, sometimes it is not worth the time and effort needed to make something pixel perfect in all systems.
3. Learn about programming.
Unless you've an aptitude for it, you don't need to learn how to program for the web. But it would still be a big help to gain some familiarity with web programming, as if you can't code, you'll need to work closely with someone who can and you need to be able to communicate effectively with them.
4. Create working prototypes
When something is static, it can be designed using a static format. To design something interactive like a website, you should be making use of moving prototypes that represent the kind of behaviour the final design will have. You can use paper to do this, or more sophisticated mockups using xhtml, css and javascript, or a dedicated prototyping program.
The user controls how they want to see content on the web, not you. Your design will not look the same to all people because some people may make it different on purpose.
Screens can be arbitrarily large or small
The web is interactive: usability trumps pretty-lookingness
Your page will be read by machines: make sure the data is easy to get at by scripts that can't read images / large blobs of text (aka "be semantic")
Remember to save your jpg files in RGB format not CMYK format. I regularly get sent jpgs that won't display on a web-site and every time it's because it's been saved in the wrong format from Photoshop.
This will become less of a problem as browsers support more image formats, but considering that 20%+ of users are still on IE6 for the sites we develop this will take a while to go away.
A lot of these are good rules of thumb for print designers who want to learn how to actually markup HTML and write CSS. But as a Web developer in the past, I'd frequently just take a designer's template and write the HTML and CSS for them. Whether or not that task was simple or difficult depended on the designer's awareness of the capabilities of CSS.
There was one pain point in particular that kept coming up. So for print designers moving to the web, the absolute number one rule to remember is:
Don't design any element to have an explicit, pixel-perfect height. You can restrict the width all you want, but changing fonts, preferred font sizes, and different text strings being pulled from the database on different pages means that text needs to be able to flow vertically without generating hideous, hard-to-use overflow scrollbars.
Designers who remember this can usually conjure up designs that are easy to cut up and integrate in a mostly semantic manner. Designers who forget this sometimes end up creating designs that have to be shoehorned into a 3 inch by 3 inch box, and that's when I reach for the vodka.
A given color or font will render differently in different browsers.
Especially when one browser is on Windows and the other is on Mac or Linux, etc.
I wrote a blog post about this a while ago - http://aloestudios.com/2008/08/dear-print-designer-doing-web-design/
So did my friend Mark - http://www.visual28.com/articles/tips-for-better-web-design
Jeffery Zeldman's book Taking Your Talent to the Web is specifically targeted to the question you have asked. It's been out for a few years...not sure if there's a 2nd or 3rd edition. Check it out.
My main advise is that you need to recognize that while you have dot precision in print applications, most of the time in web design your focus is to design and code a site that will accomplish your content and layout goals for any number of platforms, resolutions and color depths. Color depth has become less important than it was in the past.
This question already has answers here:
Why not use tables for layout in HTML? [closed]
(66 answers)
Closed 5 years ago.
I have been pondering on this over the last couple of days. I'm currently writing a web application (actually adding a screen to an existing, extensive application). I know that using "tables" for layout is a big no-no. But in this app, all of the pages use tables for layout. I decided to do my new page using divs instead.
But I came across 2 hurdles.
A lot of the layout stuff that I need to do were already done on the other pages and if I use divs instead, I cant reuse any of that (CSS's and JS and that kinda stuff). That leads to more work and pushes out my completion date.
Some of the more complex parts of the layout are really difficult to do using divs and are really easy to do using tables. Maybe its just me being "old-school"y as I am not much of a web/html kinda guy (I get by).
So, why can't I use tables? I'm not trying to be argumentative, just want to see if there are any compelling arguments beyond the "Its the right thing to do" type stuff. I know it is the right thing to do. I'd like to know why?
Implementing your layout with divs, spans, etc, offers a ton more flexibility over tables. Consider floating, auto wrapping of block content vs. horizontal scrolling, specifying where an element should exist on a page, etc. Content is just plain easier to manipulate via CSS when not using tables.
When using tables you're pretty locked in to a strict structure.
Now that doesn't mean it's absolutely the wrong thing to do. From your information I'd likely stick with the theme of the application for consistency sake and implement using tables. Make the best choice for the situation vs. following "the rules" on what's popular right now.
Hope that helps!
Ian
Doing css layouts make it easier to change the layout of your page later on.
Tables also make your html harder to read and edit.
According to this page..
make your redesigns more efficient and less expensive
help you maintain visual consistency throughout your sites
get you better search engine results when you minimize your markup and use header tags properly. This reduces ratio of code to content.
make your sites more accessible to all viewers and user agents.
your pages load faster, file sizes will be smaller because table information isn't needed in every page.
and give you a competitive edge (that is, job security) as more of the world moves to using Web standards.
I'm going to post a contrarian view, just so you have some ammo. I realize this doesn't answer your question (why not use tables) but it does address the other responses you will see.
The future of CSS never gets here (note: from 2005)
Everyone else uses tables and there are valid arguments against every response others have listed.
You might find some middle ground by using "display:table" to turn DIVs into TABLEs. Of course, you can't do this because IE doesn't support it until v8.
I read a good point somewhere: when people are referring to side-by-side columns of equal height as the "holy grail", something must be wrong with the layout engine.
I mean, just look at the unmaintainable contortions some people go through to make it work: negative margins, pixel counts that must correspond throughout five different rules, etc.
So be practical.
That said, most of my designs use pure CSS. Nearly everything can be done in CSS just as easily as with tables (or even easier.) Start with the assumption that DIVs can do it, and maybe fall back on 1 table for a tricky multi-column layout. Even then, someone has probably found a solution for your layout so search first.
They are also bad for accessibility reasons i.e. screen readers don't read them correctly, but this is only if the data you are representing is not tabular data.
Saying that, due to deadlines etc. (the real world) I've resorted to using them for form layout because it's just so much easier.
Because the tag <table> implies it should contain tabular data.
Like Peter said, the universe won't implode if you do create table-based layout, but semantically, this should be avoided.
Semantics become increasingly important, since web pages are not always shown in a desktop browser anymore. Web standards are developing in a way that HTML describes the semantic structure of the document, not the markup; and as said: using <table> tags for tabular data is semantically correct.
Interesting related reads:
Should Tables be avoided in HTML at any cost?
http://en.wikipedia.org/wiki/Semantic_Web
First, you can usually convert a table layout to divs without too much trouble once you know the necessary CSS.
But more to the point, some of the reasons why tables are bad:
Not all your users are going to see the page using the browser's rendering engine. Some are going to use a screen reader, which may assume that when it encounters a table, it should actually read the contents out as tabular data. Essentially, you should think of it as a coincidence that tables have a certain layout "look" in a browser.
tables can't be rendered until the table and all its children have been parsed. A div can be rendered independently of its children, so you avoid the page contents jumping up and down on the page as the page is parsed, and get to show contents sooner.
There are good and valid reasons to prefer tables, but when you're used to tables, there's also a certain learning curve, so if you're pressed for time, this might not be the time to make that switch.
If you have the kind of constraints you mentioned, deadline looming, large existing code base, then use tables, the universe won't implode, but in the long term using css and welformed markup will allow you to create a nicer, cleaner, more maintainable website.
Tables are pretty ugly if you want to support text to speech readers (if you've got any kind of accessibility requirements, you pretty much have to use tables for tables and nothing else).
There is an SEO aspect of this as well. For SEO, it's better to have your content at the top of the page than at the bottom. (Sadly, studies suggest appears that putting a menu first is actually a good idea for accessibility, so the two imperatives clash.)
If you are having trouble with cross-browser support, I can suggest that you develop using Firefox. Its support for CSS development is much better than other browsers, and it's more standards-compliant (and hence more predictable). Later on, you can patch up for down-level browsers.
And, as Peter says, the universe won't implode. But using CSS for layout is cleaner in the long term. Redesigning something with the layout hard-coded can be a real pain. Check out the CSS Zen Garden for examples of what you can do. Of course, in the future, we'll have CSS table layouts, the best of both worlds.
Tables also affect the behaviour of search engines. Using CSS instead of tables is actually an SEO technique as well. The reason I heard for this is that search engines stop indexing after a certain level of tags, and layout using tables can become very deeply nested.
Using CSS for layout, rather than HTML tables provides a level of separation between your page content and the layout of that content.
With tables, your HTML markup has both your content and layout intermingled within the HTML code. This means is you ever want to have a different layout for the same content, you'll need to edit the intermingled code heavily.
By using a CSS stylesheet over your HTML markup you separate the code that provides the content (HTML) from the code that provides the layout (CSS). This makes it far easier to completely change the layout aspect of a web page without having to edit the content code.
The best example of this is the CSS Zen Garden website.
All that said, it's still far easier to do some layout techniques in tables rather than CSS, so there's definitely a "balancing act" there. (For example, even Google uses tables in it's page layouts!)
By using tables for layout you tie the content to the formatting, this is the main point that most of the disadvantages come from. It messes up the source, complicates site-wide formatting updates that could be easily done with CSS, etc. Using tables for layout also often means slicing images on weird places just to fit them in the cells, yuck.
you can use tables, but divs have more advantages.
but it's all in perspective.
Like you say, you are precious for time, so probably (on short notice) tables will be the choice to make. However, if you manage to make it div-wise, you will have a more maintable page, which you can use to refactor the other pages as well.
Jeffrey Zeldman wrote a great book on this topic: Designing With Web Standards. This book should be mandatory reading for every web designer.
Here are some reasons why tables for design are bad
Tables generate more markup -> More bandwidth usage
Tables makes it harder for search engines to index your pages -> Your site becomes less "searchable"
Tables makes it harder to change and tweak the visible appearance of your site -> More costly redesigns
...But most importantly: using tables for design adds presentation logic to your markup
That is bad because you want to separate your presentation from your content! HTML should only define WHAT your content is, not HOW it should look.
If you obtain this level of separation your site will...
...be more accessible by different kinds of browsers and other kinds of user agents.
...make redesigns much easier
The best you do not listen to the fanatics of CSS. These purists live in some imaginary world and will feed you the arguments of some abstract purity, semantics and the rest. You would not want to have this kind of people in your team. For now I've only seen yellow-mouth students to run around with "pure CSS design" ideas. They'll show you examples of very primitive CSS-designed sites, ignoring you whenever you ask them how you can accomplish some complex enterprise software design with it. Experienced developers already know this perfection is not possible.
What should you do? Follow the KISS principle. If CSS can help you implement your particular design idea, fine, the problem is solved. If you need to resort to some relatively uncomplex hack, it may be okay. But when it comes to some huge piece of code with dozens of rules to make a basic thing, which you easily and naturally achieve with tables, drop it.
It serves no purpose to create an incredibly complex and sophisticated tricky CSS design that noone else (and yourself after a couple of months) will be able to understand and support.
As for the "easy redesign", unless you only want to change colors and fonts, you will enevitably have to restructure your markup whether it is done with tables or without them. In the latter case, a high portion of your markup will serve no purpose except implement CSS trickery which will be useless for you new redesign idea.
Honestly, it's not your fault that the people responsible for further development of HTML/CSS don't do their job properly. You should not waste your and other people's time trying to find workarounds for something that should have been there ages ago.
HTML/CSS is a good example of how poorly some committee could do their job and brake the development of technology as compared to a single company with resources and commitment.
"The right thing to do" depends on your situation.
Yes, divs offer more flexibility, but at the end of the day, do you really need it? As far as the number of lines of code goes, I have found that a simple table is often quite a bit smaller that an equivalent div design.
It's faster to put together, and it works as reliably as possible in pretty much all browsers, which means you don't have to write a zillion hacks to make it work consistently AND it doesn't break down when a new display engine comes out.
Using tables for display is technically a hack, but it does the job, is easy to understand and maintain and is to a large degree future proof, so for a simple layout, considering that the rest of the website already uses tables for layout, I would keep using tables.
Besides, turning a Table into a "div" table which uses the new "display=table" attributes can easily be done with a few regexes (if you rack your brains, you can probably even do it with a single pass). If you know your regexes, you can replace a table with divs through an entire website in a matter of minutes, so the whole issue of flexibility is really not that big: when (if) you actually need to use divs and CSS positioning, just run a few regex, and you are set. And if you need more control than what you can handle from regex, you can spend a couple hours to write a quick & dirty parser that will convert your tables to div exactly as you want them.
Bottom line is that despite the stigma, for simple layouts, tables still do the job, they do it fast and are reliable, and if you don't have to contend with CSS purists, you can save yourself a lot of work.
CSS layouts make it easier to alter the layout through stylesheets (separation of data from display).
Also, browsers often can't render a table until the </table> tag has been parsed. This can be a problem if you are using a table with a large amount of content. CSS layouts can often be rendered as they go.