Related
I know it's told to use table for tabular data, but I see in many websites and CMS that they use div for showing database content, for example in admin area for editing them, shouldn't they use table for showing these data? What's the best way?
Use a table, since it's tabular data. Unordered, ordered, or dictionary lists should be used when you want to present data in a non-tabular fashion, like the list of questions on the front page of SO.
I will answer your question with another question :
Do you want your data to remain presentable if CSS are not available ?
Yes, definitively go for Tables
No, it's up to you, whichever makes you all warm and fuzzy inside ;-)
Typically you would use DIVs for page layout and TABLEs to display tabular data. In your question you ask about the admin areas for a CMS. If in the admin area they are displaying a grid that represents one or more tables in a database then yes it would probably be best displayed as a table.
However the distinction should be made based on how you are actually presenting the data. Just because the data started out as tabular data (in a database table) doesn't mean that it is inherintly tabular data. If you intend to display it in some other form then DIVs might be the better choice.
It completely depends on what type of data we are talking about. Unless you can give an example of the data, then you won't get a very good answer.
Edit: Per your comment, yes, use a table. If you're showing lists of things from a database then you should use a LIST. There is no golden rule -- the format you use should reflect the data coming from the database.
Table because it is data.
The best markup to use to present a piece of data is always that which is most semantically appropriate. This, of course, raises the question of exactly what is semantically appropriate. This is not a trivial question, and it depends entirely on the sort of data that you're presenting. If your data is tabular in nature, then you should definitely put it in a table. Most data is not tabular in nature, so it shouldn't go in a table.
The reason that using tables is discouraged is because they have historically been misused for non-semantic presentational purposes. Often, authors would place data that wasn't even remotely tabular in nature inside a table tag solely to get it to appear a certain way. This is poor practice, and one should instead create the desired appearance using CSS. This criticism, however, applies not to the use of tables in general, but merely to the use of tables for inappropriate content.
To address a couple of other things:
Don't worry about browsers without CSS. This isn't a problem in this day and age, unless you're using non-graphical browsers.
Search engines prefer semantic content. If tables are the proper semantics, then the search engines will prefer them.
Div is more widely supported by browsers, while table has some quirks and exceptions that make it cumbersome.
a div is more general purpose, you can do a lot with it, not just tables. take a close look at:
http://www.w3schools.com/tags/tag_DIV.asp
search engines more like div
I have a query In our application we have lots of HTML tags. During development many tags were not given any id because of no requirement.Now the QA team wants to automate the test cases using QTP. In most of the cases this tool doesn't recognizes because it does not find ids for most of the HTML tags.Now we are asked to add ids to all the HTML tags.
I want to know if there will be any effect adding id attribute to these tags. Even positive impact are welcome
I do not think there will be any either positive or negative effect : maybe the size of the HTML page will increase a bit, but probably not that much.
Still, are you sure you need to put "id" attributes on every HTML tag of your pages ? Wouldn't only a few of those be enough ? Like on form fields, on links, on error-messages ; and that's probably about it ?
One thing you must take care, though, is that "id", as in "identifers", must be unique ; which implies it might be good, before starting adding them, to define some kind of "id-policy", to say, for instance, that "ids for elements of that kind should be named that way".
And, for your next projects : have developpers add those when theyr're developping ;-)
(And following the policy, of course)
Now that I'm thinking about it : a positive effect might be that it'll be easier to write Javascript code interacting with your HTML document -- but that'll be true for next projects or evolutions for this one, when those id are already present in the HTML at the time developpers put the JS code in place...
Since there are no QTP related answers yet.
GUI recognition in QTP is object-oriented. In order to identify an object QTP needs a unique combination of object's properties, and checking them better to be as fast as possible - that is why HTML ID would be ideal.
Now, where it is especially critical - for objects that do not have other unique identifiers. The most typical example - html tables. Their contents is dynamic, their number on the page may vary. By adding HTML ID you allow recognition mechanism get straight to the right table.
Objects with other unique properties can be recognized well without HTML ID. For example, if you have a single "submit" link on the page QTP will successfully recognize it by inner text.
So the context-specific answer: don't start adding ids to every single tag. Ask automation guys to prepare a list of objects they have problem with. And add ids to those objects.
PS. It also depends on automation programming skills. There are descriptive programming and dynamic recognition methods. They allow retrieving the right objects even without ids provided.
As Albert said, QTP doesn't rely solely on elements' id, in fact due to the fact that many web applications generate different ids for each session, (as far as I remember) the id property isn't part of the default description for most web test objects.
QTP is pretty good at recognizing most simple web controls and if you're facing problems it may be the case that a Web Extensibility project will help you bridge the gap between the semantics of your web application and the raw HTML it is created in. If a complex control is recognized by QTP as a WebElement (which is actually the div that contains the span that drives the code) you will understandably have object recognition problems since there are many divs on the page but probably many less complex controls.
If you are talking about side-effects - NO. Adding ids won't cause any problems (apart from taking up some extra bytes of course)
If you really have the need to add ids, go ahead and add them.
http://www.w3.org/TR/html4/struct/links.html#anchors-with-id says: The id and name attributes share the same name space. This means that they cannot both define an anchor with the same name in the same document. It is permissible to use both attributes to specify an element's unique identifier for the following elements: A, APPLET, FORM, FRAME, IFRAME, IMG, and MAP. When both attributes are used on a single element, their values must be identical.
What work, if any, has been done to automatically determine the most important data within an html document? As an example, think of your standard news/blog/magazine-style website, containing navigation (with submenu's possibly), ads, comments, and the prize - our article/blog/news-body.
How would you determine what information on a news/blog/magazine is the primary data in an automated fashion?
Note: Ideally, the method would work with well-formed markup, and terrible markup. Whether somebody uses paragraph tags to make paragraphs, or a series of breaks.
Readability does a decent job of exactly this.
It's open source and posted on Google Code.
UPDATE: I see (via HN) that someone has used Readability to mangle RSS feeds into a more useful format, automagically.
think of your standard news/blog/magazine-style website, containing navigation (with submenu's possibly), ads, comments, and the prize - our article/blog/news-body.
How would you determine what information on a news/blog/magazine is the primary data in an automated fashion?
I would probably try something like this:
open URL
read in all links to same website from that page
follow all links and build a DOM tree for each URL (HTML file)
this should help you come up with redundant contents (included templates and such)
compare DOM trees for all documents on same site (tree walking)
strip all redundant nodes (i.e. repeated, navigational markup, ads and such things)
try to identify similar nodes and strip if possible
find largest unique text blocks that are not to be found in other DOMs on that website (i.e. unique content)
add as candidate for further processing
This approach of doing it seems pretty promising because it would be fairly simple to do, but still have good potential to be adaptive, even to complex Web 2.0 pages that make excessive use of templates, because it would identify similiar HTML nodes in between all pages on the same website.
This could probably be further improved by simpling using a scoring system to keep track of DOM nodes that were previously identified to contain unique contents, so that these nodes are prioritized for other pages.
Sometimes there's a CSS Media section defined as 'Print.' It's intended use is for 'Click here to print this page' links. Usually people use it to strip a lot of the fluff and leave only the meat of the information.
http://www.w3.org/TR/CSS2/media.html
I would try to read this style, and then scrape whatever is left visible.
You can use support vector machines to do text classification. One idea is to break pages into different sections (say consider each structural element like a div is a document) and gather some properties of it and convert it to a vector. (As other people suggested this could be number of words, number of links, number of images more the better.)
First start with a large set of documents (100-1000) that you already choose which part is the main part. Then use this set to train your SVM.
And for each new document you just need to convert it to vector and pass it to SVM.
This vector model actually quite useful in text classification, and you do not need to use an SVM necessarily. You can use a simpler Bayesian model as well.
And if you are interested, you can find more details in Introduction to Information Retrieval. (Freely available online)
I think the most straightforward way would be to look for the largest block of text without markup. Then, once it's found, figure out the bounds of it and extract it. You'd probably want to exclude certain tags from "not markup" like links and images, depending on what you're targeting. If this will have an interface, maybe include a checkbox list of tags to exclude from the search.
You might also look for the lowest level in the DOM tree and figure out which of those elements is the largest, but that wouldn't work well on poorly written pages, as the dom tree is often broken on such pages. If you end up using this, I'd come up with some way to see if the browser has entered quirks mode before trying it.
You might also try using several of these checks, then coming up with a metric for deciding which is best. For example, still try to use my second option above, but give it's result a lower "rating" if the browser would enter quirks mode normally. Going with this would obviously impact performance.
I think a very effective algorithm for this might be, "Which DIV has the most text in it that contains few links?"
Seldom do ads have more than two or three sentences of text. Look at the right side of this page, for example.
The content area is almost always the area with the greatest width on the page.
I would probably start with Title and anything else in a Head tag, then filter down through heading tags in order (ie h1, h2, h3, etc.)... beyond that, I guess I would go in order, from top to bottom. Depending on how it's styled, it may be a safe bet to assume a page title would have an ID or a unique class.
I would look for sentences with punctuation. Menus, headers, footers etc. usually contains seperate words, but not sentences ending containing commas and ending in period or equivalent punctuation.
You could look for the first and last element containing sentences with punctuation, and take everything in between. Headers are a special case since they usually dont have punctuation either, but you can typically recognize them as Hn elements immediately before sentences.
While this is obviously not the answer, I would assume that the important content is located near the center of the styled page and usually consists of several blocks interrupted by headlines and such. The structure itself may be a give-away in the markup, too.
A diff between articles / posts / threads would be a good filter to find out what content distinguishes a particular page (obviously this would have to be augmented to filter out random crap like ads, "quote of the day"s or banners). The structure of the content may be very similar for multiple pages, so don't rely on structural differences too much.
Instapaper does a good job with this. You might want to check Marco Arment's blog for hints about how he did it.
Today most of the news/blogs websites are using a blogging platform.
So i would create a set of rules by which i would search for content.
By example two of the most popular blogging platforms are wordpress and Google Blogspot.
Wordpress posts are marked by:
<div class="entry">
...
</div>
Blogspot posts are marked by:
<div class="post-body">
...
</div>
If the search by css classes fails you could turn to the other solutions, identifying the biggest chunk of text and so on.
As Readability is not available anymore:
If you're only interested in the outcome, you use Readability's successor Mercury, a web service.
If you're interested in some code how this can be done and prefer JavaScript, then there is Mozilla's Readability.js, which is used for Firefox's Reader View.
If you prefer Java, you can take a look at Crux, which does also pretty good job.
Or if Kotlin is more your language, then you can take a look at Readability4J, a port of above's Readability.js.
This question already has answers here:
Closed 13 years ago.
I am developing a "modern" website, and I'm having a lot of trouble getting the CSS to make everything line up properly. I feel like they layout would be a lot easier if I just used a table, but I've been avoiding <table> tags, because I've been told that they are "old-fashioned" and not the right way to do things.
Is it okay to use tables? How do I decide when a table is appropriate, and when I should use CSS instead? Do I just do whatever is easier?
The answer is yes, it's fine to use tables. The general rule of thumb is that if you are displaying tabular data, a table is probably a good way to go. You should generally try to style your table with css as much as you can though.
Also, this pie graph might help you:
alt text http://www.ratemyeverything.net/image/7292/0/Time_Breakdown_of_Modern_Web_Design.ashx
EDIT: Tables are fine. For displaying data. Just like my second sentence stated. The question was "is it ok to use tables". The answer is - yes, it is ok to use tables. It is not illegal.
Since even though it's implied to use tables for data in my general rule of thumb, apparently I must also state that the corollary is that it's not ok to use tables for anything else, even though the poster already seemed to grasp this concept. So, for the record, the general rule of thumb is to not use tables for laying out your site.
Tables should be used to represent tabular data. CSS should be used for presentation and layout.
This question has also been exhaustively answered here:
Why not use tables for layout in HTML?
Essentially - if you have tabular data, then use a table. There's really no need now to use tables for layout - sure, they were often considered 'easier' but semantically the page is horrid, they were often considered inaccessible.
See some discussion:
css-discuss
and a particularly comical URL - shouldiusetablesforlayout.com
In the 'modern' approach of tables it is not about using table tags or div tags, but about using the right tag for the right purpose.
The table tag is used for tabular data. There is nothing wrong with using it for that!
For using CSS, there are a lot of tutorials and guides (good and bad) around. Indicators of a bad tutorial are: lot of use of blocks (divs) that only make sense for the layout and not for the content. Good signs are the ones that advise to use the right tags for the right content and teach you how to make up that tags.
Tables are only appropriate for tabular data. Imagine you have to add some spreadsheet like data, where you have clear row/column headers, and some data inside those rows.
A product comparison, for example, is also a valid table item.
I believe that tables are OK for display of rectilinear data of arbitrary rows and/or columns. That's about it. Tables should not be used for layout purposes anymore.
In general, HTML markup should describe the structure and content of a web page—it should not be used to control presentational aspects such as layout and styling (that's what CSS is for). A <table> tag, like most have already said, should represent tabular data—something that would appear as a table of information.
The reason why people rag on tables so much is that in the old days, there was no such thing as CSS—all page layout was done directly in HTML. Tags were not thought of as describing content—all anyone really cared about was how a tag would make things look in a web browser. As a result of this, people figured that, since they could organize things into rows and columns, tables must be good for laying out elements of a web page. This became a really popular technique—in fact, I'd wager that using tables was considered the preferred method of laying out web pages for quite some time.
So when people tell you that tables are "old-fashioned," they are specifically referring to this abuse of the <table> tag that was so popular back in the old days. Like I said, there's nothing wrong with HTML tables themselves, but using them for web page layout just doesn't make sense nowadays.
(Plus, from a purely pragmatic standpoint, layouts done with HTML tables are very inflexible and hard to maintain.)
its ok to use tables when you are showing data in a grid / tabular format. however, for general structure of the site, its highly recommended that you use css driven div, ul, li elements to give you more lucid website.
If you anyways decide to work with tables, you must consider the following cons :
they are not SEO friendly
they are quite rigid in terms of their structure and at times difficult to maintain as well
you may be spending little extra time on div based website, but its worth every minute spent.
The whole "anti-Table" movement is a reaction to a time when deeply nested tables were the only method to layout pages, leading to HTML that was very hard to understand.
Tables are a valid method for tabular (data) layout, and if a table is the easiest way to implement a layout, then by any means use a table.
Table is always the right choice when you have the need to present data in a grid.
Quoting Sitepoints's book HTML Utopia: Designing Without Tables using CSS
If you have tabular data and the appearance of that data is less important than its appropriate display in connection with other portions of the same data set, then a table is in order. If you have information that would best be displayed in a spreadsheet such as Excel, you have tabular data.
I would say no for using tables to construct your layout. Tables make sense only for actual tabular data you need to represent. If you spend enough time figuring the CSS out you will find its easier then using tables for a layout. Just remember: Tables for displaying data. CSS for page layouts.
Tables are just that: Tables.
They are frowned upon because they should not be used for layout, as has been the fashionable thing to do before browsers could position stuff properly.
If what you want to markup is, in fact, a table, then use a table. Other than that, try to stay away.
One small thing: Aligning two parts of text to the exact same line that won't move apart (think, username and post date). There using a table is IMHO an option.
First get it working. Then get it perfect.
Get the layout done in some way before making it perfect or better.
How many people per day will go to the page you are working on? A million? or 20 ?
How much time are you going to spend on CSS issues instead of other issues? Does your boss want you to spend this much time on the issue? Does he/she know what you are doing?
Absolutely. I don't know where CSS zealots invented the idea that tables are not naturally used for "layout". Tables have been used for laying things out since their invention, whether those things be numbers, words, or pretty pictures. That's what they do. Moreover, table is part of all versions of (X)HTML so there are no deprecation concerns.
Absolutely.
All that HTML offers was originally intended for you to define the markup of your page. In my book, absolute and relative positions of elements on a page belong to markup. So both divs and tables are very much suited for this task. Pick up what works best for your particular need.
CSS adds many styling possibilities and also layout tricks but it complements HTML options not replaces them.
There is actually a very fine line between seeing something as a markup or styling issue. CSS proponents would say that with CSS you can relocate and reshuffle completely all big and little pieces of a page. I cannot however imagine putting header below, footer above and making things appear in reverse order.
Take an example. You design a notebook. You know where to place major components, mainboard, cooling system, keyboard, display and ports. You may certainly wish to rearrange a little bit port connectors, on whic side and in which sequence they appear, but you don't really expect to put display where the keyboard is, put keyboard on the lid, make fans blow to your face and have all connectors on the botom to be reached through holes on your desk.
Using tables can make it slightly difficult to rearrange elements on a page. This might be true. However, in most cases you know in advance how approximately your page should look like and you would not want to change everything drastically. if you can't say it before your begin your work you probably have no clear idea what you are doing and what for.
Moreover, only tables possess elastic properties, which allows the to stretch to the width/height of their content. Nothing else of HTML/CSS can be used to do that.
CSS design on one side allows you to create quite adjustable designs. On the other hand, it locks you out from designing a page adjustable to its content. Both wins and losses.
Table is also the only tool to make very complex and precise interfaces. For example, the page SO is very simple. It probably can be done with pure CSS. In the meantime, have you seen any enterprise-class software like CRMs, SRMs etc? That multitude of buttons, text field, check boxes, dropdownlists all precisely located on a screen? Good luck achieving that kind of complexity with just CSS. And these layouts migrate from desktop applications into web each day (keyword: software-as-a-service).
So choose what suits best your current need and don't trust those CSS lovers. Actually don't trust any fanatics at all.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why not use tables for layout in HTML?
Under what conditions should you choose tables instead of DIVs in HTML coding?
The whole "Tables vs Divs" thing just barely misses the mark. It's not "table" or "div". It's about using semantic html.
Even the div tag plays only a small part in a well laid out page. Don't overuse it. You shouldn't need that many if you put your html together correctly. Things like lists, field sets, legends, labels, paragraphs, etc can replace much of what a div or span is often used to accomplish. Div should be used primarily when it makes sense to indicate a logical division, and only appropriated for extra layout when absolutely necessary. The same is true for table; use it when you have tabular data, but not otherwise.
Then you have a more semantic page and you don't need quite as many classes defined in your CSS; you can target the tags directly instead. Possibly most importantly, you have a page that will score much better with Google (anecdotally) than the equivalent table or div-heavy page. Most of all it will help you better connect with a portion of your audience.
So if we go back and look at it in terms of table vs div, it's my opinion that we've actually come to the point where div is over-used and table is under-used. Why? Because when you really think about it, there are a lot of things out there that fall into the category of "tabular data" that tend to be overlooked. Answers and comments on this very web page, for example. They consist of multiple records, each with the same set of fields. They're even stored in a sql server table, for crying out loud. This is the exact definition of tabular data. This means an html table tag would absolutely be a good semantic choice to layout something like the posts here on Stack Overflow. The same principle applies to many other things as well. It may not be a good idea to use a table tag to set up a three column layout, but it's certainly just fine to use it for grids and lists... except, of course, when you can actually use the ol or ul (list) tags.
When the data I am presenting is, indeed, tabular.
I find it ridiculous that some web designers used divs on tabular data on some sites.
One other use I would have for it would be forms, particularly label : textbox pairs. This could technically be done in div boxes, but it's much, much easier to do this in tables, and one can argue that label:textbox pairs are in fact tabular in nature.
I used to do pure CSS but I abandoned that pursuit in favor of hybrid table/css approach as the most pragmatic approach. Ironically, it's also because of accessibility. Ever try doing CSS on Sidekick? What a nightmare! Ever seen how CSS-based websites are rendered on new browsers? Elements would overlap or just don't display correctly that I had to turn off the CSS. Ever try resizing CSS-based websites? They look awful and often detrimental to the blind if they use zooming features in the browser! If you do that with tables, they scale much better. When people talk about accessibility, I find that many have no clue and it annoys me because I am disabled and they aren't. Have they really worked with the blind? The deaf? If accessibility is a main concern, why the hell are 99% of videos not closed captioned? Many CSS purists use AJAX but fail to realize that AJAX often makes content inaccessible.
Pragmatically, it's ok to use a single table as a main layout as LONG as you provide the information in a logical flow if the cells are stacked (something you'd see on mobiles). The CSS theory sounds great but partially workable in real life with too many hacks, something that is against the ideals of "purity."
Since using the CSS with tables approach, I've saved so much time designing a website and maintanance is much easier. Fewer hacks, more intuitive. I get fewer calls from people saying "I inserted a DIV and now it looks all screwed up!" And even more importantly, absolutely NO accessibility issues.
Usually whenever you're not using the table to provide a layout.
Tables -> data
Divs -> layout
(mainly)
Note: At the time the question was asked, there were practical reasons for using tables for some layout purposes. This is not necessary anymore due to browser improvements, so I have updated the answer.
HTML <table>-elements should be used when the data logically has a two dimensional structure. If the data can be structured in rows and columns and you can meaningfully apply headers to both rows and columns, then you probably have tabular data.
I you only have a single row or single column of data, then it is not tabular data - it is just linear content. You need at least two rows and two columns before it can be considered tabular data.
Some examples:
Using tables for placing sidebars and page headers/footers. This is not tabular data but page layout. Something like css grid or flexbox is more appropriate.
Using tables for newspaper-style columns. This is not tabular data - you would still read it linearly. Something like css columns is more appropriate.
I would make a distinction between HTML for public websites (tables no-no-no, divs yes-yes-yes) and HTML for semi-public or private web applications, where I tend to prefer tables even for page layout.
Most of the respectable reasons why "Tables are bad" are usually an issue only for public websites, but not so much of a problem with webapps. If I can get the same layout and have a more consistent look across browsers by using a TABLE than a complicated CSS+DIV, then I usually go ahead and aprove the TABLE.
As many posters have already mentioned, you should use tables to display for tabular data.
Tables were introduced in HTML 3.2 here is the relevant paragraph from the spec on their usage:
[tables] can be used to markup tabular material or for layout purposes...
Agree with Thomas -- the general rule of thumb is if it makes sense on a spreedsheet, you can use a table. Otherwise not.
Just don't use tables as your layout for the page, that's the main problem people have with them.
I can see the argument for tables for forms, but there is a nicer alternative... you just have to roll up your sleeves and learn CSS.
for example:
<fieldset>
<legend>New Blog Post</legend>
<label for="title">Title:</label>
<input type="text" name="title" />
<label for="body">Body:</label>
<textarea name="body" rows="6" cols="40">
</textarea>
</fieldset>
You can take that html and layout the form either side-by-side labels, or labels on top of the textboxes (which is easier). Having the flexibility really helps. It's also less HTML than the table equivalent of either.
For some excellent examples of CSS forms, check out these excellent examples:
http://jeffhowden.com/code/css/forms/
http://www.sitepoint.com/article/fancy-form-design-css/
http://www.smashingmagazine.com/2006/11/11/css-based-forms-modern-solutions/
I will usually opt for tables to display form-type information (First Name, Last Name, Address, etc.) where lining labels and fields across multiple rows is important. DIVs I use for layout.
Of course the table is wrapped in a DIV :)
Tables were designed for tabular content, not for layout.
So, don't ever feel bad if you use them to display data.
I use tables in two cases:
1) Tabular data
2) Any time I want my layout to dynamically size itself to its contents
If your data can be laid out in a two-dimensional grid, use <table>. If it can't, don't. Using <table> for anything else is a hack (though frequently not one with proper alternatives, especially when it comes to compatibility with older browsers). Not using <table> for something that clearly should be one is equally bad. <div> and <span> aren't for everything; in fact, being completely meaningless on a semantic level, they are to be avoided at all costs in favor of more semantic alternatives.
On this subject, I thought this site was pretty funny.
1) For displaying tabular data. A calendar is one example of tabular data that isn't always obvious at first.
2) I work for a medical billing company, and nearly all of the layout for our internal work is done using CSS. However, from time to time we get paper forms from insurance companies that our billers have to use, and a program will convert them to an html format that they can fill out and print via the intranet. To make sure the forms are accepted they need to match the original paper version very closely. For these it's just simple to fall back to tables.
Tables are used for tabular data. If it makes sense to put it in a spreadsheet then use a table. Otherwise there is a better tag for you to be using such as div, span, ul, etc.
I believe just tabular content. For example, if you printed out a database table or spreadsheet-like data to HTML.
If you would like to have semantically correct HTML, then you should use tables only for tabular data.
Otherwise you use tables for everything you want, but there probably is a way to do the same thing using divs and CSS.
#Marius:
Is the layout tabular data? No, while it was standard a few years ago it's not now :-)
One other use I would have for it would be forms, particularly label : textbox pairs. This could technically be done in div boxes, but it's much, much easier to do this in tables, and one can argue that label:textbox pairs are in fact tabular in nature.
I tend to give the label a fixed width, or display it on the line above.
#Jon Limjap
For label : textbox, neither divs nor tables are appropriate: <dl>s are
One other use I would have for it
would be forms, particularly label :
textbox pairs. This could technically
be done in div boxes, but it's much,
much easier to do this in tables, and
one can argue that label:textbox pairs
are in fact tabular in nature.
I see that a fair amount, especially among MS developers. And I've done it a fair amount in the past. It works, but it ignores some accessibility and best-practice factors. You should use labels, inputs, fieldsets, legends, and CSS to layout your forms. Why? Because that's what they are for, it's more efficient, and I think accessibility is important. But that's just my personal preference. I think everyone should try it that way first before condemning it. It's quick, easy, and clean.
When ever a page containg tables is loaded by any browser it takes more time for the browser to render properly the tag. Where as if the div is used ,the browser takes less time as it is lighter. And more over we can apply the css to make the divs appear as table,
The tables are normally heavy wieght and div are light weight.
It is clear that the DIV are used for Layout but It happened to me to being "forced" to use spreadsheets to do a grid layout within a div structure for this reasons:
the addition of percentage values did not allow a proper alignment with the div, while the same values expressed on cells of tables gave the expected result.
So I think that tables are still useful not only for data, but also for the situation above, on top of that, tables are still W3C compliant browser and alternative browsers (for the disabled for example) interpret theirs correctly.
Divs are simple divisions, they are mean't to be used to group sections of the page that are in a semantic sense linked. They carry no implicit meaning other than that.
Tables were originally intended to display scientific data, such as lab results on screen. Dave Raggett certainly didn't intend them to become used to implement layout.
I find it keeps it fairly clear in your mind if you remember the above, if its something you would normally expect to read in a table, then that's the appropriate tag, if its pure layout, then use something else to accomplish your needs.