homepage Welcome to WebmasterWorld Guest from 54.211.80.155
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / HTML
Forum Library, Charter, Moderators: incrediBILL

HTML Forum

    
Div vs Table
Table vs Div
abhishekmishra




msg:4312939
 7:23 am on May 16, 2011 (gmt 0)

Hi There,
Which one is the best for SEARCH ENGINE
prospective "Div Or Table"...?

 

buckworks




msg:4313051
 1:04 pm on May 16, 2011 (gmt 0)

A good guideline:

Use tables for information that needs to be presented in rows and columns.

Use divs for everything else.

Seo_Mike




msg:4313121
 3:17 pm on May 16, 2011 (gmt 0)

Divs and CSS give much faster page load times. Divs are the way to build your pages, using tables is becoming less relevant by the day.
I only used Divs and Css and my code is cleaner and easier to maintain.

rocknbil




msg:4313175
 4:34 pm on May 16, 2011 (gmt 0)

"Best for search engine" is not real relevant, there are many old table-based web sites that do well.

Tables must completely render, top to bottom, from <table> to </table> in your source code before the browser will display them. I doubt this has much effect on search engines because they slurp up your content without rendering - but this can and often does have an effect on how fast they render for your users.

However, if you want to build pages that give semantic meaning to all devices rendering it - which includes search engines - you use semantic markup to describe the content.

This means we use "divs" only to divide page sections up and meaningful elements everywhere else. Content is a series of paragraphs. Navigations are a list (ul) of links (or <nav>, HTML 5.) Tables are used for tabular data, a display of two dimensional intersecting data.

This also has impact on accessibility as well - a page reader will expect tabular data in a tabled layout and it leads to very confusing interpretation of your page because it reads across the column in rows. It gets even works with nested tables, which usually go hand in hand.

Div, span, <br>, and others are all empty elements. They have no semantic meaning. Using them indiscriminately is as bad (in terms of semantics) as using a table for layout and leads to div-itis. :-) When you go to add any of these, ask the question: will this describe my content or is a <p>, <ul><li>, or other element a better description of what it will contain? Chances are very good you can, and can style it any way you want.

tedster




msg:4313201
 5:08 pm on May 16, 2011 (gmt 0)

With regard to search engines, using tables for layout can run into this type of problem:

The content in two table cells may be related to each other IN MEANING when the page is rendered visually...

But in the source code, those two bits of content may be widely separated by all kinds of table mark-up and other table cells. Because of this, the intended semantic connection is lost to machine intelligence that is trying to score the page.

lucy24




msg:4313308
 9:55 pm on May 16, 2011 (gmt 0)

Tables must completely render, top to bottom, from <table> to </table> in your source code before the browser will display them.

Unless you do {table-layout: fixed;}. I can count on the fingers of one hand the number of times I've used it myself, mainly because I forget the option exists. But for genuine tables-- the kind with headers and a bunch of numbers in many, many rows-- it can save the user-agent a lot of time and work.

But in the source code, those two bits of content may be widely separated by all kinds of table mark-up and other table cells.

Doesn't the same apply to divs? If you've got two long side-by-side elements, the code will still give you everything in the first column before moving on to the second.

tedster




msg:4313327
 10:11 pm on May 16, 2011 (gmt 0)

Doesn't the same apply to divs?

Yes, it can - and that is something to be aware of when you create any mark-up. In my experience, it is a much more frequent pitfall in table-based layouts.

webprutser




msg:4314390
 10:49 pm on May 18, 2011 (gmt 0)

It's a pity, though understandable, that the discussion was moved. Some arguments were discussed on an other page yet.

As stated on the other page, I don't care what tables were meant for originally. If they are a good tool, I'll be happy to use them. Since I read about the idea that tables should no longer be used for designing websites (only use them when you have data that should be put in a table), I'd like to know why, before I say goodbye to tables for this purpose.

I use tables to position my elements and CSS to add styling. There are <p>'s in my tables, as well as an <ul>'s.
My code is no mess, no nested tables, easy to read, etc. I see many table-less-websites on the internet with loads of <div>'s that are complete puzzles to me. The reason why I still use tables is my experiences with trying to put the elements at the right place. I get the most exotic results without tables.
I postponed diving into this problem and meanwhile was getting doubts about the necessity of doing so. Why not leave things as they were?
I want to see if I can find a good reason to choose for table-less lay-out in future and that's why I'm interested in this discussion.

I found a first argument in rocknbil's comment:
"a page reader will expect tabular data in a tabled layout and it leads to very confusing interpretation of your page because it reads across the column in rows".
That sounds logic to me. You could wonder how many of your visitors use page readers, on the other hand why not make things as easy as possible for those few visitors who do.

Loading times of tables ... what differences are we talking about? Significant?

tedster




msg:4314419
 11:54 pm on May 18, 2011 (gmt 0)

webpruster, I'm with you and long have been. I prefer a basic grid, laid out with table cells - and the rest of it is pure CSS unless real tabular data comes into the picture. It's a lot easier to get cross-browser happiness that way (even today), and from a practical viewpoint, sites are a lot quicker to develop and maintain.

The big deal is those insanely nested tables, the bloated mark-up, etc. However, I'm pragmatic and I'm all for what works, not what's academically correct. When I did more actual website design and development a few years ago, I went for almost half a year having everyone in the company create only CSS-P websites. I'd say each contract took triple the time to get it right.

That said, a lot of people prefer tables because that's really all they know. And that's the wrong reason. Their mark-up is probably going to suck no matter which approach they take.

rocknbil




msg:4314866
 6:38 pm on May 19, 2011 (gmt 0)

I want to see if I can find a good reason to choose for table-less lay-out in future and that's why I'm interested in this discussion.


It's been debated many many times here - made a convert out of me. Here's a couple juicy ones, most of which have good sound reasoning.

Why are tables evil? [webmasterworld.com] (They're not - every tool has an application; see SuzyUK's first comments)
Another [webmasterworld.com]
Another [webmasterworld.com]

Many more with a Google on tables layout site:webmasterworld.com

Forms where the hardest part for me. I started here:

Tableless forms [webmasterworld.com]

Tableless forms get easier [webmasterworld.com]

webprutser




msg:4315189
 11:35 am on May 20, 2011 (gmt 0)

Thanks for the new input, tedster and rocknbil.
I've done some reading in the "historical posts". A lot of mixing up of tables and css, as if those can't be combined, but I read it as "positioning by css" and it seems I'm not exactly the only one who struggles with that part of css.

When I first read the theory of it, it was called the boxmodel, it sounded all very logic to me, it still does. Why it turns out to be so hard in practice I don't know, it seems very odd that so many people who have experience with websites yet and know how to shape things with tables get stuck on positioning with div's. I tend to say "if you make a tool so hard to use, I'm not interested in using it as long as I have a good alternative (this discussion of course, is about how good this alternative really is). First improve your tool, than I'll give it a try."

I must admit I don't know where we are with CSS3 at the moment and wonder if anyone knows if that has improved things from this perspective. Something else I read - and read before - is XML, but I'm too inexperienced to see if it would make sense to put my time on that track.

The discussions gave me some arguments to consider table-less design: page readers, loading times and mobile phones (on that last one I read different points of views, but that's a matter of testing my own website).
It also gave me arguments to don't make an entire switch to table-less sites.
The best of both worlds would also be an option to me. Make one table with as less tr's and td's as I can, only for the main positioning. If I get rid of heights and widths as well, I have no more styling info in my html, it would all be in the CSS-file.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / HTML
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved