There is now a reason to use tables and css for layout, instead of divs and css.

Employers now prefer the table method. Our technical school instructors are now teaching this, instead of div and css.

Why?

Job performance!

It takes an average of four times as long to create a page using divs and css, compared to using tables and css. This is because the page author must fool around with the div settings until it works. The table always works the first time.

The employer prefers getting more pages per day, as opposed to getting pages that please the W3C.

Simple div structures work, but if the structure contains a list or a table, div messes it up. Then you have to play with height, width, margin, border, padding, and other properties, just to get the structure to hold together in all browsers.

As an example, I wanted to create a simple structure consisting of text on the left and a small table on the right, all surrounded by a border. I tried the following in sequence:

Making a surrounding div for the border:
- I could not get the table to go to the right and stay inside the border.
- It wanted to put the table under the text instead.

Make a surrounding div for the border, with two divs inside:
- The div for the border became small vertically, with both the text and the table sticking out below the bottom border.

Making a surrounding div for the border, two divs inside, and floating the table div right:
- I could not get the table to stay inside the border.
- The div assumed the height of the text.
- Text following the div rendered to the right of the text in the div.

Making a surrounding div for the border, floating the text div left, and the table div right:
- The text and table stayed inside the div.
- The table was to the right, but below the text.
- The beginning of the following p tag was inside the border, below the text div.

Making a surrounding div for the border, and floating both inner divs left:
- The text and table stayed inside the div, in the proper orientation..
- The beginning of the following p tag text appeared to the right of the table, inside the border.

Make a surrounding div for the border, with two divs inside, and displaying them as table cells:
- This worked in both IE and FF, until I tested it with W3C, and discovered a typo.
- When I fixed the typo, it worked in Firefox.
- After the typo was fixed, IE agains started making the div for the border small vertically, with both the text and the table sticking out below the bottom border.

After messing with this for an hour, I replaced the divs with a table, and had it working in 3 minutes.

commented: Nice take/points. +18

I'm not exactly the best student but I've exerted more effort (than usual) in studying how divs behave and I am more comfortable (efficient) working with divs than with tables.

Even if I didn't have that advantage and it's easy to construct a page from scratch (from tables), trying to change the design or structure of a site based on tables is like college without coffee and pizza. Pure hell.

The table's boon (easy to command/ 'bend to your will') is also it's bane:
It's easier to manipulate because there isn't anything much to manipulate. You just tell it to hold some columns, rows, have a background, have paddings, borders, and margins. Be a certain height or width.

Everything is fixed.

Whereas, divs are so much more flexible. Can you imagine what wordpress would be like if it used tables to display its content? Will there be that much diversity to the designs and structures available to us? Can we switch the positions of the body, menu, and other parts of the page with just one CSS file if designs were based on tables?

Maybe. But it won't be that easy. Something about switching the actual contents of each column/row/cell. (I suspect this is the reason why Wordpress is more popular than Joomla)

It takes an average of four times as long to create a page using divs and css, compared to using tables and css. This is because the page author must fool around with the div settings until it works. The table always works the first time.

We seem to agree on that point: Table is quick the first time. But the internet isn't made to be static. It's supposed to change. Constantly. And those tedious table updates are going to add up in the future. Sacrificing the ability to maintain the site smoothly for the swiftness of setting-up is a tempting lure. But it causes a lot of headaches for later.

Employers now prefer the table method. Our technical school instructors are now teaching this, instead of div and css.

They've been teaching tables for years. Some people are hoping that this trend will die soon. Because it's wrong. You have these fresh graduates who can make table-based sites quickly and don't have the patience to work with divs because they don't see results quickly as compared to tables. However, just because something is quick and easy doesn't mean it's right.

It's our job as web designers or developers to give it our best shot. Learn about divs. Do not get sucked into a comfort zone.

We REALLY should keep up with the standards. It's part of our job. If we can't do it, then maybe we should pause, re-learn, and have another go at life.

If you're working in an IT company that keeps up to date, than you will have a programmer working alongside with a designer, so the programmer won't have to worry about this and just follow the guidelines of the designer.

I'm not exactly the best student but I've exerted more effort (than usual) in studying how divs behave and I am more comfortable (efficient) working with divs than with tables.

I keep thinking I have it mastered, but then I go to use it, and it sneaks out and does something else. Or it works on one browser and not another. The worst thing is when a browser update makes the site change the way it displays.

Whereas, divs are so much more flexible. Can you imagine what wordpress would be like if it used tables to display its content?

No, because I don't use it.

Will there be that much diversity to the designs and structures available to us? Can we switch the positions of the body, menu, and other parts of the page with just one CSS file if designs were based on tables?

I'm not talking about designing an entire page with tables, but positioning two or three stubborn elements that refuse to go into the right places with divs. If there is a real table (a worksheet of numbers) on the page, the divs go crazy.

I am talking about positioning a photo to the right of each paragraph of text, and having all of the photos, and all of the right margins of the texts lined up perfectly.

And I don't WANT the positions of things to change. I want the page to scroll if the window is too small.

We seem to agree on that point: Table is quick the first time. But the internet isn't made to be static. It's supposed to change. Constantly.

Maybe that's why the divs don't work. I had several pages that worked on every browser, until I upgraded to IE7. Then I had to rewrite the pages again to work on IE7.

I don't want everything to change constantly. That's one of the things I do not like about the Internet. Every time I go back to a page to get information, they changed it, and I have to hunt for the info all over again.

And those tedious table updates are going to add up in the future.

What updates? I'm not publishing a newspaper. I'm presenting educational material that does not change.

It' the tedious div updates I have to make whenever a browser upgrade makes the pages I did write with divs malfunction.

They've been teaching tables for years. Some people are hoping that this trend will die soon. Because it's wrong. You have these fresh graduates who can make table-based sites quickly and don't have the patience to work with divs because they don't see results quickly as compared to tables. However, just because something is quick and easy doesn't mean it's right.

They went BACK to teaching tables.

They did this because the EMPLOYERS are sick of employees wasting time failing to get divs to work and rewriting pages after browser upgrades make them fall apart. Employers are not accepting the graduates who are taught divs.

The method they are teaching involves using a table for a row of items that need to be kept together in a horizontal row, not the entire site. Table is a reliable way to do this. Div is totally unreliable at doing this. (If you know how to do this in a way that survives window resizes, different resolutions, and browser upgrades without using pixels or other absolute measures, please tell the rest of us.)

It's our job as web designers or developers to give it our best shot. Learn about divs. Do not get sucked into a comfort zone.

Unfortunately, the employer is not going to like wasting his money while the employee learns to make the pages work again after a browser upgrade messes the whole site up. The employer wants the site up and running. He does NOT want the site to be the most elegantly crafted, at the cost of it malfunctioning every time a standard changes or a browser is upgraded. It costs him money.

We REALLY should keep up with the standards. It's part of our job. If we can't do it, then maybe we should pause, re-learn, and have another go at life.

Part of the problem is that they won't leave the standards alone. Things that work today fail tomorrow.

I have already had to rebuild my entire private web site of 200+ pages three times, because they won't leave the standards alone:

1. Converting to xhtml and css, conforming to the W3C verifier (most of the time spent changing tags to lowercase, adding closing li tags, and converting br & hr tags to self closing form).

2. Making the site position objects relatively and removing formatting tables where practical (many of the pages were made before css styles were available, when table was necessary to make page margins).

3. Fixing things that changed when Firefox changed to version 2 and IE changed to 7 (mostly the divs that started malfunctioning when they contain tables), while simultaneously fixing a bunch of things the W3C validator started flagging that it allowed before (mostly unescaped quote marks and ampersands in the text).

I may have to redo things again, because I just found out that pt is not the relative font size style (em is).

Tell me how many man-hours are wasted every time the standards change again, or a browser upgrade makes things fall apart.

Interesting read, thanks for that.

I always use tables and have never found the time to adopt css. But then I've only created web-pages in frontpage.

:-P

I agree, I'm just starting out in web design, at the moment i'm using div's however i admit i find them generally hard to control.

Thanks for the read

Can someone write a set of rules that always works for divs?

If you're working in an IT company that keeps up to date, than you will have a programmer working alongside with a designer, so the programmer won't have to worry about this and just follow the guidelines of the designer.

The IT companies here want to hire only one employee for both.

I have over 600 pages on my site php generated from sql tables and includes
changing layouts of all takes about a minute,
changing layout of one page only, takes much longer than changing all of them

Can someone write a set of rules that always works for divs?

This would be the CSS standard... ;-)

Unfortunately, because of the ever changing way the browsers implement the standard, this would be very hard to do. If they would all comply it would be easy.

This would be the CSS standard... ;-)

Unfortunately, because of the ever changing way the browsers implement the standard, this would be very hard to do. If they would all comply it would be easy.


Almost all browsers (including IE since 6) do comply with most of the standards. It is not hard to write CSS that works in all browsers. It means avoiding some things that IE doesn't do correctly, and occasionally letting IE produce a less-than-optimal (but still usable) page.

I'm talking about using div to make a page that doesn't fall apart if someone (or the browser) looks at it wrong.

I'm talking about divs that don't go crazy when you put a list or a table inside.

I'm talking about divs that can be made to expand to fill their containers without using absolute measures.

I'm talking about structures that don't take several hours of tweaking to make them work.

I'm talking about being able to use the same methods and always getting the same results.

I'm talking about using div to make a page that doesn't fall apart if someone (or the browser) looks at it wrong.


Yes, so am I.

I'm talking about divs that don't go crazy when you put a list or a table inside.


Me, too.

I'm talking about divs that can be made to expand to fill their containers without using absolute measures.


If you use absolute measures they cannot expand.

I'm talking about structures that don't take several hours of tweaking to make them work.


Agreed: <DIV>

I'm talking about being able to use the same methods and always getting the same results.


Agreed: <DIV>

Why do you want to never use tables and only use divs?

(BTW: no-one ever answers this with a decent -- rarely even an accurate -- answer. infact, most people go and answer a completely different question, and if you dont have an answer to this question because it doesn't apply to you, then contending the original points on whatever grounds is arguing at cross-purposes: because I don't believe that MidiMagic is saying only use tables)

In every other part of software development, heck, in almost every other field, period: people use the tool that best fits the job, and rarely think twice about it. there's no for-loop appreciators club, or cult of the saucepan.. although, come to think of it, there probably is...

the occasional "goto" never really harmed anyone; and likewise, the occasional table is sometimes both 'justifiable' and the 'best choice'.

saucepans work well as as long as you dont try and use them as for loops; divs work well and are totally 'easy': as long as you don't try and make a table-like layout with them. if you do, then you suffer from a lack of one of the following information bridges:

- the one that keeps the column widths the same
- the one that keeps the row heights the same

you can hack in one of those, but not both. it should be evident from the specification of HTML and CSS that you can't.

there's a reason why most (perhaps all?) GUI toolkits have some kind of low-level 'table layout'. if it was possible to compose that functionality via other means, there'd be no need for that low level layout.

..........


but anyway, IMHO, the next HTML should get rid of all of the elements (and their silly names ), create two new elements 'block' and 'inline', and have everything specified by CSS:

<block style="table-rows:2; table-cols:2">
  <block><inline>top left table cell!</inline></block>
  <block style="background-image:'some_image.png;'"/>
  <block><inline>omgz</inline></block>
  <block><inline>bottom right table cell</block>
</block>

solve everyone's problems, huh? if you care to, you could even implement this hot new language yourself (albeit statically) using some clever XSLT.

something for the weekend?

Tables are perfect for tabular data
You can create a javascript to sort a table and view the info any way you like
tables for layout just for spacing, not so good

I kind of agree with midimagic even though I don't want to.
Tables were meant to display content: div's were designed to control layout. 2 separate things but not mutually exclusive.
Firstly, I'm sick of hearing that 'change is good'. Who decided that while I slept? Consistency is good, having the time to get really good at something is good, being balanced and feeling secure is good.

Having said that, we are all remember right at the forefront of the internet. It really hasn't been around that long, (The popular interweb I'm talking about) therefore there's bound to be change to some degree until it's decided just what it is. Who says WC3 is correct and MS aren't?

Anyway does it all really matter?

I have created some sites in basic HTML, I've done some in ASP, I've laid them out in tables and CSS, div's and CSS, tables and html and used includes where appropriate and whatever else way I saw fit for each site.

They're all tools to use and I use whichever one of them gets the job done in the same way I sometimes belt something with my heavy pliers, because I can't be bothered to go get the hammer. If the result is how I want it who cares how I achieved it?

If you're going to have standards, then everyone must adhere to them, including those arrogant browser writers. Otherwise, I'll do the best job I can using the most appropriate tools for the job.

I agree that using tables solely for spacing probably isn't the best way to go about things.

But, I firmly believe that using tables for creating robust related columns and rows of any type is 'the right thing to do' (i.e., not just tables of raw, sortable/headed, data): mostly because there is a lack of a viable alternative.

Obviously the 'ideal' is to have one HTML nodeset look completely different and still function for it's original purpose simply by flipping a style... but that only really works in specific, quite simple settings.

But, I firmly believe that using tables for creating robust related columns and rows of any type is 'the right thing to do' (i.e., not just tables of raw, sortable/headed, data): mostly because there is a lack of a viable alternative.


Of course! That's what tables are for.

Obviously the 'ideal' is to have one HTML nodeset look completely different and still function for it's original purpose simply by flipping a style... but that only really works in specific, quite simple settings.


In fact, it can work with fairly complicated layouts.

Then maybe we are looking for the wrong solution.

The reason the W3C wants tables kept to tabular data is that web readers for the blind announce the row and column of every table cell.

So is there a way to put a style in to get the web reader to shut up about the rows and columns when the table is used to keep a layout from falling apart?

Alternately, we need dtr and dtd tags that behave like the tr and td tags of a table, to get the div ducks all in a row (or column).

Originally Posted by MidiMagic
I'm talking about using div to make a page that doesn't fall apart if someone (or the browser) looks at it wrong.

Yes, so am I.

How is this achieved? When you shrink the browser window, or use a different screen resolution, the divs won't stay put.

I'm talking about divs that don't go crazy when you put a list or a table inside.

Me, too.

How is this achieved? Whenever I try it, the list won't stay together, or the table pokes outside the div.

I'm talking about divs that can be made to expand to fill their containers without using absolute measures.

If you use absolute measures they cannot expand.

They certainly do not respond to the width and height styles correctly. I had divs inside of table cells to further format the contents. They never would expand beyond the size of the text they contained.

I had to use absolute measures {height: .75in; width: 1.5in;} to get the div to expand to the size of the containing table cell. 100% height and width did not work.

The table cells were of fixed height because one cell in each row contained an image.

I'm talking about structures that don't take several hours of tweaking to make them work.

Agreed: <DIV>

It won't work. Every time I try to make what seems to be a straightforward structure from div tags, something goes blooey in the browser. and it falls apart: Either stuff leaks out of the div, or the object contained in the div is put elsewhere.

I made a simple div just to put a colored box with a border around some text and a table. The table refused to stay inside the div. Either the div got very small and stayed above the table containing the text, or the table stuck out of the div on one side or the bottom. This was WITHOUT any size styles, other than that the table was to be 50 percent wide and aligned right. The div behaved as if only the text was inside it. The code validated with W3C.

It worked right if I substituted a one-cell table for the div, applying the same styles to the table.

I'm talking about being able to use the same methods and always getting the same results.

Agreed: <DIV>

It doesn't work.

I had a nice two-column div structure that stayed together nicely under all circumstances. Then, just to add emphasis, I replaced an ordered list with a small table. I made sure the table would fit into the containing div that used to contain the list. Nothing else changed. But the div structure fell apart.

tables are so oldskool and hard to encode sometimes. but with divs., its a lot easier to code, and easy as well to fix if theres a problem with it. great post.

How is this achieved? When you shrink the browser window, or use a different screen resolution, the divs won't stay put.


They will if you do it correctly.

How is this achieved? Whenever I try it, the list won't stay together, or the table pokes outside the div.


Do you have an example? Please post a URL.

They certainly do not respond to the width and height styles correctly.


They certainly do!

I had divs inside of table cells to further format the contents. They never would expand beyond the size of the text they contained.


Your problem is very likely the use of tables.

Again, can you provide an example of the problem?

I had to use absolute measures {height: .75in; width: 1.5in;} to get the div to expand to the size of the containing table cell. 100% height and width did not work.


If you use absolute measures, the div cannot expand. Why would you expect it to?

The table cells were of fixed height because one cell in each row contained an image.


It sounds as if you are using a table for non-tabular purposes; that's a recipe for disaster.

It won't work. Every time I try to make what seems to be a straightforward structure from div tags, something goes blooey in the browser. and it falls apart: Either stuff leaks out of the div, or the object contained in the div is put elsewhere.


Example? My experience does not agree with yours. What are you doing wrong?

I made a simple div just to put a colored box with a border around some text and a table. The table refused to stay inside the div. Either the div got very small and stayed above the table containing the text, or the table stuck out of the div on one side or the bottom. This was WITHOUT any size styles, other than that the table was to be 50 percent wide and aligned right. The div behaved as if only the text was inside it. The code validated with W3C.


Validating is a prerequisite for a working page, but it doesn't guarantee it.

Dont use tables for layout

It confuses the hell out of screenreaders, and employers risk getting sued for not making thier sites accessible.

That's a myth. Screenreaders aren't confused by tables, they just read them in a specific way. Weird markup order and other 'unusual' div constructs can confuse screenreaders just as much, sometimes more.

Originally Posted by MidiMagic View Post

How is this achieved? When you shrink the browser window, or use a different screen resolution, the divs won't stay put.

They will if you do it correctly.

You keep saying that, but you don't tell the correct way. Are you saving it so you can copyright and sell it?

How is this achieved? Whenever I try it, the list won't stay together, or the table pokes outside the div.

Do you have an example? Please post a URL.

I didn't put up the bad page on the web. I fixed it with a table.

Here is the bad page:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Stuff</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />

<style type="text/css">

.cenx {text-align: center;}
.ceni {clear: both;}
.bxfix {margin: 0; border: none; padding: 0;}

.boxi {margin: 3em; border: solid 2px #0000cc;
           padding: 1em; background-color: #ffaaaa;}

.boxd {margin: 0; border: none; padding: 0;
            width: 50%; background-color: #aaffaa; float: left;} 

.boxe {margin: 0; border: none; padding: 0;
           width: 50%; background-color: #aaaaff; float: right;} 

.celfil {margin: 0; border: 1px black solid;
          padding: .25 em; background-color: #eeeeaa;
          width: 100%; height: 100%;}

.wfl {width: 100%;}

img {margin: 0; border: none; padding: 0;}
body {background-color: #bbffbb; padding: 2%; font-family: sans-serif;}

</style>
</head>
<body>

<div class="boxi">
  <div class="boxd">
    <p>The text I want to keep on the left. The text I want to keep on the left.
    The text I want to keep on the left.  The text I want to keep on the left.
    The text I want to keep on the left. The text I want to keep on the left.
    The text I want to keep on the left. The text I want to keep on the left.
    The text I want to keep on the left. The text I want to keep on the left.
    The text I want to keep on the left. The text I want to keep on the left.</p>
  </div>
  <div class="boxe">
    <table>
      <tr>
        <th><div class="celfil">Code number</div></th>
        <th><div class="celfil">Replacement<br />Text</div></th>
      </tr>
      <tr>
        <td>10</td><td>Text string number 1</td>
      </tr>
      <tr>
        <td>20</td><td>Text string number 2</td>
      </tr>
      <tr>
        <td>30</td><td>Text string number 3</td>
      </tr>
      <tr>
        <td>40</td><td>Text string number 4</td>
      </tr>
      <tr>
        <td>50</td><td>Text string number 5</td>
      </tr>
      <tr>
        <td>60</td><td>Text string number 6</td>
      </tr>
    </table>
  </div>
</div>

</body>
</html>

I took out the float: left; in the boxd style, and it got worse.

When I took the floats out of both boxd and boxe, it put the table under the text.

They certainly do not respond to the width and height styles correctly.

They certainly do!

See above. They do not.

I had divs inside of table cells to further format the contents. They never would expand beyond the size of the text they contained.

Your problem is very likely the use of tables.

Again, can you provide an example of the problem?

The table is a table of numbers and data.

See the example above. The yellow boxes are supposed to fill the table cells. They do not.

I had to use absolute measures {height: .75in; width: 1.5in;} to get the div to expand to the size of the containing table cell. 100% height and width did not work.

If you use absolute measures, the div cannot expand. Why would you expect it to?

I had to use the absolute measure to get it to expand to fill the container. It refused to expand to fit the container otherwise.

See the yellow boxes generated by the code above. They refuse to expand to fit the container.

It sounds as if you are using a table for non-tabular purposes; that's a recipe for disaster.

See for yourself (I replaced the proprietary data with simple text, but it is a numeric table).

It won't work. Every time I try to make what seems to be a straightforward structure from div tags, something goes blooey in the browser. and it falls apart: Either stuff leaks out of the div, or the object contained in the div is put elsewhere.

Example? My experience does not agree with yours. What are you doing wrong?

Run the code above to see it.

I made a simple div just to put a colored box with a border around some text and a table. The table refused to stay inside the div. Either the div got very small and stayed above the table containing the text, the table stuck out of the div on one side or the bottom, or the table dropped under the text. This was WITHOUT any size styles, other than that the table was to be 50 percent wide and aligned right. The div behaved as if only the text was inside it. The code validated with W3C.

That's a myth. Screenreaders aren't confused by tables, they just read them in a specific way. Weird markup order and other 'unusual' div constructs can confuse screenreaders just as much, sometimes more.

It's the users of the screenreaders who get confused. they are blind.

Indeed.

But absolute positioning (I mean moving the displayed order of things while keeping the actual markup in a different order) is worse for a screenreader user than a (simple) table.. e.g.

<table>
<tr>
<td>this is all going to be read</td>
<td colspan="3">in the correct order</td>
</tr>
<tr>
<td>although, perhaps the rows, and</td>
<td>the columns might be announced</td>
<td>by some screenreaders</td>
<td>using certain settings</td>
</tr>
</table>

But...

<div>&nbsp;</div>
<div>in backwards order</div>
<div style="position:absolute;left:0;top:0;">this will probably be announced</div>

although, it would appear to be in the correct order to a sighted user.


Is this what you want: http://cfaj.freeshell.org/testing/MidiMagic.html?

Yes - sort of. That's what I want it to look like. But it renders the real contents of the table cells differently in different browsers that way. I need another box inside the table cell to get rid of the incompatibility.

It's sort of what I ended up doing (I used classes, because there are other tables on the page), but it does not solve the problem of the div not expanding to fill its container. It just removes the div from inside the table cells, rather than making it expand.

Now make it work WITH the divs in the table cells, and the attributes attached to the divs, not the cells. This exactly shows my point: the div does not obey the styles.

The divs were there to solve a browser intercompatibility problem involving the real contents of the divs. Putting the attributes on the table cells causes the incompatibility to appear. But the divs failed too.

My current page has three nested tables to make it work the same on all browsers.

Yes - sort of. That's what I want it to look like. But it renders the real contents of the table cells differently in different browsers that way.


Can you provide screenshots that demonstrate that?

If there is a problem, it should be fixable with CSS.

I need another box inside the table cell to get rid of the incompatibility.


No, you don't. That's probably what is causing your problems.