convert a table to a <div> controlled layout

[Jukka K. Korpela]

Scripsit Adrienne Boswell:

No, HTML was not originally formatted with tables.

Right. We didn't use any tables but sat on the ground, and we used stone
tools to carve markup.

In the beginning
there was no table element

That's true, because the original designers of HTML didn't bother
copying the simple table idea from the SGML Handbook (probably one of
the simplest ideas in that book, with nice syntactic shortcuts that make
the clumsy HTMLisms look a bit ridiculous).

The HTML 3.0, they were introduced

Nope, tables were formally introduced in RFC 1942, "HTML Tables", in
1996. In practice they were introduced in Netscape 1.1 in April 1995.

"HTML 3.0" never existed except as an incomplete draft, which expired in
September 1995.

Stylesheets became a recommendation in December of 1996.

Right. The first implementation worth mentioning was IE 4 in October
1997. (IE 3 had an unintentional parody of CSS support.)

HTML 3.0,
which introduced tables, became a recommendation in January of 1997.

No, it was HTML 3.2, a largely watered-down version, but it is customary
in the web business to use misleading version numbering. (Similarly, CSS
2.1 is a _restricted_ variant of CSS 2.0.)

 

[Adrienne Boswell]

I am relatively new to this (I am primarily a php/application
programmer) so, jumping in, can someone answer these questions for me?

1 - I see the structure in the URL above and it is straightforward.
What about the CSS stuff like why padding is used as it is and what is
"div div"? Does "div div" refer to a div inside a div?

Yes, div div is a div inside of a div.

2 - Why are "smart people moving away from tables for layout"?

1. Nested tables are a nightmare.
2. Using an external stylesheet makes global changes almost instant.
3. Separating style from markup means faster download time.
4. CSS is able to do things that plain HTML just cannot do. A good
example is hover.

As a programmer, I am sure you often make use of includes. Think of a
stylesheet as an include - set it and forget it.

Tables absolutely have their place - for tabular data. Use the right
tool for the job - tables for tabular data, lists for lists, headings
for headings, etc.

 

[Bergamot]

<div>s are
more limited than tables because the "align=" is deprecated for <div>s
and a workaround with margins and text-align is needed.

False. Look up margin:auto.

That centering hack you refer to only applies to ancient browsers, or IE
in quirks mode. Margin:auto works fine for other browsers.

So, given that,
why move to <div>s.

That's a boring debate that's been thrashed around countless times. Go
look in the group archives or use your favorite search engine for more
info. Look up quirks mode, too, if you're interested.

 

[Bergamot]

I was thinking specifically of IE6. I recently ran across this very
problem BECAUSE of IE6.

No, it was because of quirks mode. IE6 in standards mode handles
margin:auto just fine.

 

[Travis Newbury]

Leave it as a <table>. From all we can tell from your post, it's
entirely appropriate for this table to be a <table>.

There are many "<div> based" layouts that could be used here. Choosing
the most appropriate would require more background knowledge of the
problem than you have given us. In the absence of such information,
<table> is the best choice.

If your course tutor has just reached the "ALL tables are bad" stage
of CSS coding, then find a more up to date course.

Bravo!

 

[Jonathan N. Little]

Adrienne Boswell wrote:

How so? I religiously indent properly and so never have had problems
with nested tables. Also, a good editor will catch proper bracketing.
If not, then validation picks it up. So, how is it a "nightmare"?

Okay, now this topic has been discussed not less than a *million times*
but here is a realistic example.

Web site with a typical top banner, left menu, right content, bottom
footer. You use a table to lay all this out, then nested tables to
position the logo image with respect to company text on top banner.
Another nested table for the nav links, a few more for the content...
Good! You repeat this for the dozen or so pages -- (just a small company).

Company now wants to spruce up the website. New logo, new colors, the
works! They want the new snazzy logo to be in the upper-left. No more
vertical menu, but one horizontal one across the top. Oh and also
rearrange all the product images and descriptions so instead of having
the pictures to the left and descriptions to the right, have each item
boxed with a border and descriptions below.

Okay, with tables you have to totally redo the entire website. Adjusting
the tables, maybe rowspans and colspans...arrgh...redo would be easier.
But then you have to reproof your copy, might make a typo right?

Now if the site had been done with semantic markup and separate
spreadsheets: banner is a div, nav links in a ul list, headings, and
paragraphs, etc... it may be possible to make all the changes with only
editing the one stylesheet! Or maybe with minimal markup editing, new
image here, class name there, maybe a container element there. No
changes to the content text so no need to reproof your copy...

Now marketing is not sure about the "new look", optional stylesheets
could easily be created to supply options with little effort. Attached a
different stylesheet and the whole website, poof, has a new look.

No comparison on the maintenance argument, however with that said, for
this approach to pay off you *have* to approach the design differently
than the old 90s "sketch out a grid on paper--slice 'n dice image--stuff
some tables" method of web design.

Yes, I can understand that. There is also a flip side to that coin. You
may not want overly global changes -- but it is a good point.


Really? Can you expand upon this point please?

"I want all the paragraphs in the item descriptions to have indented text"

CSS one-liner:
div.descriptions p { text-indent: 3em; }

No zillion FONT elements, no &nbsp; or space GIFs..

"Oh and we want the text red!"

div.descriptions p { text-indent: 3em; color: red; }

 

[Andy Dingley]

2 - Why are "smart people moving away from tables for layout"?

This is an honest question of the experts).

In all seriousness, go read a book. In particular, Lie & Bos'
"Cascading Style Sheets", which is readable, accurate and teaches good
style. If you want a HTML primer first, try "Head First HTML with CSS
& XHTML".

Both of these books are worth paying your own money for, especially
Lie & Bos which you'll use as a reference for years afterwards.

This isn't a question for which there's a short, snappy, convincing
answer. It's also not a new question. So Usenet isn't going to be the
best place to elicit one. You won't find short answers especially
convincing, your "experts" will largely have more pressing things to
do than to write a long one.

 

[Jim S]

Okay, now this topic has been discussed not less than a *million times*
but here is a realistic example.

Web site with a typical top banner, left menu, right content, bottom
footer. You use a table to lay all this out, then nested tables to
position the logo image with respect to company text on top banner.
Another nested table for the nav links, a few more for the content...
Good! You repeat this for the dozen or so pages -- (just a small company).

Company now wants to spruce up the website. New logo, new colors, the
works! They want the new snazzy logo to be in the upper-left. No more
vertical menu, but one horizontal one across the top. Oh and also
rearrange all the product images and descriptions so instead of having
the pictures to the left and descriptions to the right, have each item
boxed with a border and descriptions below.

Okay, with tables you have to totally redo the entire website. Adjusting
the tables, maybe rowspans and colspans...arrgh...redo would be easier.
But then you have to reproof your copy, might make a typo right?

Now if the site had been done with semantic markup and separate
spreadsheets: banner is a div, nav links in a ul list, headings, and
paragraphs, etc... it may be possible to make all the changes with only
editing the one stylesheet! Or maybe with minimal markup editing, new
image here, class name there, maybe a container element there. No
changes to the content text so no need to reproof your copy...

Now marketing is not sure about the "new look", optional stylesheets
could easily be created to supply options with little effort. Attached a
different stylesheet and the whole website, poof, has a new look.

No comparison on the maintenance argument, however with that said, for
this approach to pay off you *have* to approach the design differently
than the old 90s "sketch out a grid on paper--slice 'n dice image--stuff
some tables" method of web design.


"I want all the paragraphs in the item descriptions to have indented text"

CSS one-liner:
div.descriptions p { text-indent: 3em; }

No zillion FONT elements, no &nbsp; or space GIFs..

"Oh and we want the text red!"

div.descriptions p { text-indent: 3em; color: red; }

Can I join in?
I might like to have my site built using divs instead of nested tables, but
so far have found it a task too far.
I moved from frames to what I have "because it is not the done thing" and
anyhow it makes printing and referring difficult.
I have two main types of page: the menu and the graphic.
menu: http://www.jimscot.myby.co.uk/Local_History/LH_000_thumbnails.html
single picture with links
http://www.jimscot.myby.co.uk/Local_History/LH_030_Mariners'_Homes.html
several pictures with links
http://www.jimscot.myby.co.uk/Local_History/LH_040_graffiti.html
This how I want them to look!
They all work off one stylesheet, which mainly sets up the tables, but also
makes the buttons, borders and font sizes.
How would doing away with tables help me?

 

[Jim S]

I think he already answered you. The broad brush you do with divs. You
make container divs. It is a matter of blocking out whole areas.
Inside of an area, where you might want to present an actual table, you
would use tables. For the menu block you would use the ul/li structure,
for example.

Jonathan, if I misread you please feel free to correct me. BTw, there
is an excellent site that explains all of this.

Where?
I didn't understand a word of that so you see the magnitude of the problem
<g>

 

[dorayme]

I might like to have my site built using divs instead of nested tables, but
so far have found it a task too far.

This how I want them to look!
They all work off one stylesheet, which mainly sets up the tables, but also
makes the buttons, borders and font sizes.
How would doing away with tables help me?

Take a look at your code, all your html and all your css and surely you
can see the advantage in having *something* like this instead:

<http://netweaver.com.au/alt/jim.html>

 

[Jim S]

Take a look at your code, all your html and all your css and surely you
can see the advantage in having *something* like this instead:

<http://netweaver.com.au/alt/jim.html>

Oh, don't get me wrong; I can see the advantage, but I started with
MSPublisher and have gradually worked my way through various Web
Applications to where I am now. It's just that I have never got the hang of
arranging what is basically a Photo Album, using the method that you and
others recommend. Certainly you two folks have made more sense of it than
those who have tried before. However it will be a marathon task to change
all 770+ pages

 

[nice.guy.nige]

While the city slept, Jukka K. Korpela feverishly typed:

Scripsit Adrienne Boswell:


Right. We didn't use any tables but sat on the ground, and we used
stone tools to carve markup.

That's more than Brucie had... he just had his pointy stick! ;-)

Cheers,
Nige

 

[dorayme]

Oh, don't get me wrong; I can see the advantage, but I started with
MSPublisher and have gradually worked my way through various Web
Applications to where I am now. It's just that I have never got the hang of
arranging what is basically a Photo Album, using the method that you and
others recommend. Certainly you two folks have made more sense of it than
those who have tried before. However it will be a marathon task to change
all 770+ pages

Fair enough, but don't overestimate the work. If you look at the url I
made for you, you will see a tiny bit of css in the head. This you will
have in an external file (adding or changing it to suit yourself). Once
you have done that, you have covered *all* the pages that have single
photos as far as CSS is concerned.

The rest of the single photo pages need very little change from the
template cued from my url's html bits (in 'body').

You can also put in the navigation via an include.

Good luck anyway.

 

[Nik Coughlin]

While the city slept, Jukka K. Korpela feverishly typed:


That's more than Brucie had... he just had his pointy stick! ;-)

I miss Brucie.

The archive is missing the images unfortunately

http://web.archive.org/web/20061206122400/http://editor.usenetshit.info/

 

[Jim S]

Fair enough, but don't overestimate the work. If you look at the url I
made for you, you will see a tiny bit of css in the head. This you will
have in an external file (adding or changing it to suit yourself). Once
you have done that, you have covered *all* the pages that have single
photos as far as CSS is concerned.

The rest of the single photo pages need very little change from the
template cued from my url's html bits (in 'body').

You can also put in the navigation via an include.

Good luck anyway.

So you reckon that this
http://www.jimscot.pwp.blueyonder.co.uk//jims_page_js.htm
is a better way of doing it?

I have not been able to put the last line of text between the two buttons,
in case I need to prevent going off the bottom of the page, nor how to
ensure that the buttons are really in the bottom corners to prevent the
user chasing them up and down the screen
I can see me having trouble with my index page and other menus.

 

[dorayme]

So you reckon that this
http://www.jimscot.pwp.blueyonder.co.uk//jims_page_js.htm
is a better way of doing it?

I have not been able to put the last line of text between the two buttons,
in case I need to prevent going off the bottom of the page, nor how to
ensure that the buttons are really in the bottom corners to prevent the
user chasing them up and down the screen
I can see me having trouble with my index page and other menus.

Well, lets take things slowly, Jim. First let us deal with the single
pic pages and we will talk about the rest later.

For a start, the buttons can never get lost if you have them as I put
them. Where can they go? What do you mean chase them up and down the
screen? I am in Australia and everything is very stable here. They are
always under the pic, no user has to chase them or look to his possibly
huge monitor to find them tucked into corners.

If you want them in the corners, that is simple, put the "nav" div just
outside the "wrapper" div, just before the closing body tag. Do you want
a demo of this or can you follow my meaning here?

About the last line of text between the buttons, what do you mean? You
did not have any text "between" the buttons at your supplied URL.

 

[Beauregard T. Shagnasty]

So you reckon that this
http://www.jimscot.pwp.blueyonder.co.uk//jims_page_js.htm
is a better way of doing it?

That layout looks pretty good to me, except for the centred text. That's
hard to read, as the eye has to hunt for the start of the next line. I'd
recommend regular left-justified text (ragged-right), like dorayme
showed in her sample.

 

[Jim S]

Well, lets take things slowly, Jim. First let us deal with the single
pic pages and we will talk about the rest later.

For a start, the buttons can never get lost if you have them as I put
them. Where can they go? What do you mean chase them up and down the
screen? I am in Australia and everything is very stable here. They are
always under the pic, no user has to chase them or look to his possibly
huge monitor to find them tucked into corners.

If you want them in the corners, that is simple, put the "nav" div just
outside the "wrapper" div, just before the closing body tag. Do you want
a demo of this or can you follow my meaning here?

I just tried that and of course on my 17" monitor, it made little
difference. I also found the way to put a single line between the buttons
while I was at it, but more of that later.

What is difficult for me is to visualise what the pages would look like in
a bigger screen. I began writing for 800x600, hence the pictures size.
As I upped the monitor size I have tried to adapt, but a personal hate for
me is pictures that need scrolling right or left. The next personal choice
would be that the single picture page does not go below the screen height
so that the 'buttons' are hidden.
To explain my earlier 'chase' thingy: if my buttons are in the corners of
the screen, then anyone flicking through, does not need to move the mouse.
With tables I can put the buttons at the bottom of the outside columns and
the text in the centre column looks after itself.

About the last line of text between the buttons, what do you mean? You
did not have any text "between" the buttons at your supplied URL.

It may not have been between the buttons for you, but it was for me and
that prevented the page from having to be scrolled to find the buttons.

Perhaps my problem is that I am writing the page so it looks good at my
end. I did learn to check different browsers when folks berated me because
I wasn't standards compliant. I'm retired so need to learn to adapt (slowly
it seems).

 

[Jim S]

That layout looks pretty good to me, except for the centred text. That's
hard to read, as the eye has to hunt for the start of the next line. I'd
recommend regular left-justified text (ragged-right), like dorayme
showed in her sample.

I say potato.....
I like the centred text, but I see your point, oh ye of massive screens.
Perhaps the solution is to break the text up into chunks (like wot using a
cell does <G>), but that will drive the page off the bottom of smaller
screens unless I use a smaller font size.

 

[Beauregard T. Shagnasty]

I say potato.....

...and I say potahto...

I like the centred text, but I see your point, oh ye of massive
screens.

My massive screen doesn't matter. The browser window is only about 900px
wide.

Perhaps the solution is to break the text up into chunks (like wot
using a cell does <G>), but that will drive the page off the bottom
of smaller screens

I'm sure you could Google up a reference about ragged-left text being
harder to read than aligned-left text. Centred text for captions looks
fine for short one-liners.

The same applies to justified text, such as newspapers tend to use. When
there are larger words in the narrow columns, you end up with uneven
spacing between words, which also disrupts the flow of the eye.

unless I use a smaller font size.

Ohnooo. You know better than that, Jim.