I've picked up the idea that folks here dislike the use of tables for
layout.  I'm not saying that I disagree with that, but I do use tables
for layout... they work in every browser I've run into.  So please,
tell me why tables for layout is considered a bad thing, and what
other better options are available?

--
http://www.ren-prod-inc.com/hug_sof...?action=contact

Suddenly, without warning, hug exclaimed (23-Dec-05 11:04 PM):
> I've picked up the idea that folks here dislike the use of tables for
> layout.  I'm not saying that I disagree with that, but I do use tables
> for layout... they work in every browser I've run into.  So please,
> tell me why tables for layout is considered a bad thing, and what
> other better options are available?
>

Yes, they're still in common use.  My main reason for not using them is
they're not particularly accessible, especially if using nested tables.

The other reason is the move toward xhtml + css - the separation of
content and format.  It's nearly 1:30am here so I'll just leave it for
the experts to elaborate, much better than I ever could, especially in
the wee hours of the morning.

jmc

Writing in news:alt.www.webmaster
From the safety of the . cafeteria
hug <contact_info@sig_line.clickit> said:

> I've picked up the idea that folks here dislike the use of tables for
> layout.

bingo :)

> I'm not saying that I disagree with that, but I do use tables
> for layout... they work in every browser I've run into.

How do they work on my phone?  Does your page fold into a small screen
format in a satisfactory manner or do I need to dig out the stylus and
invoke horizontal scroll?

> So please,
> tell me why tables for layout is considered a bad thing,

Think, for a moment, of the pprimary reason for tables - they are designed
to show a realtionship between data elements in rows and columns.  Most
layout implementations have no such relationship.

The markup required adds a considerable load on the signal/noise ratio.

Maintenance is a headache (comparatively)


> and what
> other better options are available?

trivial markup - by which I mean discrete elements within your document
that say what they mean.

h1 to h6 define a cascading heading structure (aka document outline)
p defines a paragraph
ul/li defines a list of things

do you really need anything else to present your document?

ok, you'll want ...

img elements
a(nchor) elements

anything else?

well yes, but that's enough to get your content in front of your audience
in a meaningful manner.

now you'll want to apply some presentational thingies and that's where CSS
comes in.  Although it's possible to style a document using only the
elements above you will find it convenient to group sections of your
content.  For this you can use ...

div - defines a block (e.g. navigation)
span - defines an inline section (e.g. text you'd like to present in a
different colour)

both these say absolutely nothing about your document (or its content) and
can be considered 'noise'.  However, they are neutral as opposed to tables
which do imply relationships between elements.

Disclaimer: all the above is IMO only.  MMV and probably does.
--
William Tasso

Save the drama
for your Mama.

On Fri, 23 Dec 2005 16:04:29 -0700, hug
<contact_info@sig_line.clickit> wrote:

> I've picked up the idea that folks here dislike the use of tables for
> layout.  I'm not saying that I disagree with that, but I do use tables
> for layout... they work in every browser I've run into.  So please,
> tell me why tables for layout is considered a bad thing, and what
> other better options are available?
>

The problem, from my perspective, is in the use of convoluted nested
tables. Not in the use of simple tables.

There is also a great deal of bigotry about not using tables. Tables
are designed for presenting tabular data, rows and columns. In this
context they are perfectly acceptable.

CSS offers some positioning commands as extensions to basic HTML, but
these are not universally supported and can be problematic unless care
is taken, and can easily be broken by clients resizing their text size
and the like, (Note: 'can be', not 'always are').

Matt

--
The Probert Encyclopaedia - Beyond Britannica
http://www.probertencyclopaedia.com

jmc <NOnewsgroupsSPAM@NOjodiBODY.HOMEus> wrote:

>Suddenly, without warning, hug exclaimed (23-Dec-05 11:04 PM): 
>
>Yes, they're still in common use.  My main reason for not using them is
>they're not particularly accessible, especially if using nested tables.

I don't understand what you mean by "accessible" here.  Do you mean
that they're a XXXXX to maintain because of the complexity?  Or did
you have something else in mind?

>The other reason is the move toward xhtml + css - the separation of
>content and format.

Separation of content and format is usually a good thing.  Most of my
table code is generated by the server app based on the content of a
database.  Tables is about the best I've found so far, but there could
be something better, I don't claim to know everything.

--
http://www.ren-prod-inc.com/hug_sof...?action=contact

"William Tasso" <SpamBlocked@tbdata.com> wrote:

>Writing in news:alt.www.webmaster
> From the safety of the . cafeteria
>hug <contact_info@sig_line.clickit> said:
> 
>
>bingo :)
> 
>
>How do they work on my phone?  Does your page fold into a small screen
>format in a satisfactory manner or do I need to dig out the stylus and
>invoke horizontal scroll?
> 
>
>Think, for a moment, of the pprimary reason for tables - they are designed
>to show a realtionship between data elements in rows and columns.  Most
>layout implementations have no such relationship.
>
>The markup required adds a considerable load on the signal/noise ratio.
>
>Maintenance is a headache (comparatively)
>
> 
>
>trivial markup - by which I mean discrete elements within your document
>that say what they mean.
>
>h1 to h6 define a cascading heading structure (aka document outline)
>p defines a paragraph
>ul/li defines a list of things
>
>do you really need anything else to present your document?
>
>ok, you'll want ...
>
>img elements
>a(nchor) elements
>
>anything else?
>
>well yes, but that's enough to get your content in front of your audience
>in a meaningful manner.
>
>now you'll want to apply some presentational thingies and that's where CSS
>comes in.  Although it's possible to style a document using only the
>elements above you will find it convenient to group sections of your
>content.  For this you can use ...
>
>div - defines a block (e.g. navigation)
>span - defines an inline section (e.g. text you'd like to present in a
>different colour)
>
>both these say absolutely nothing about your document (or its content) and
>can be considered 'noise'.  However, they are neutral as opposed to tables
>which do imply relationships between elements.
>
>Disclaimer: all the above is IMO only.  MMV and probably does.

Boy this takes me back to the early '80s arguing with Truly about
content vs structure.

General documents are one thing.  e-Commerce stores are another thing.
For a "store" you want specific layout, you don't just want the thing
scrolling down to china.

I'm not a bad guy, I'm just somewhat stupid and extremely determined,
often a bad combination.  I'll offer an example here.

I need layout in three specific areas.  A section at the top for a
picture, a section on the left for a description, a section on the
right for buttons.  The description can be short or long.  Currently
my code generates a table to display that.  Is there a better method?

Let me take on last shot in this post at explaining where I'm coming
from.  I get the content from files, primarily a database.  The
back-end software views html as a "browser display language", it
generates html code that creates the desired display on most any
browser.  That's not really the same thing as a "document".

I am not averse to change, though I do tend to avoid rework when
possible.  If there's a better way I'd like to learn about it.

--
http://www.ren-prod-inc.com/hug_sof...?action=contact

comments@probertencyclopaedia.com (Matt Probert) wrote:

>On Fri, 23 Dec 2005 16:04:29 -0700, hug
><contact_info@sig_line.clickit> wrote:
> 
>
>The problem, from my perspective, is in the use of convoluted nested
>tables. Not in the use of simple tables.
>
>There is also a great deal of bigotry about not using tables. Tables
>are designed for presenting tabular data, rows and columns. In this
>context they are perfectly acceptable.
>
>CSS offers some positioning commands as extensions to basic HTML, but
>these are not universally supported and can be problematic unless care
>is taken, and can easily be broken by clients resizing their text size
>and the like, (Note: 'can be', not 'always are').
>
>Matt

Thanks Matt.  The convoluted tables in my sites tend to be generated
by a convoluted back-end program based on simple entries in a product
database.

--
http://www.ren-prod-inc.com/hug_sof...?action=contact

Suddenly, without warning, hug exclaimed (24-Dec-05 12:20 PM):
> jmc <NOnewsgroupsSPAM@NOjodiBODY.HOMEus> wrote:
>
> 
>
>
> I don't understand what you mean by "accessible" here.  Do you mean
> that they're a XXXXX to maintain because of the complexity?  Or did
> you have something else in mind?
>

Sorry, I was posting in the wee hours of the morning.  By "accessible" I
mean, "accessible to people with disabilities" - more specifically those
who use a screen reader to 'hear' the pages.  Tables for layout are, I
understand, difficult to translate.  Gets worse the more complicated
and/or nested they are.

jmc

Suddenly, without warning, Matt Probert exclaimed (24-Dec-05 10:41 AM):
> On Fri, 23 Dec 2005 16:04:29 -0700, hug
> <contact_info@sig_line.clickit> wrote:
>
> 
>
>
> The problem, from my perspective, is in the use of convoluted nested
> tables. Not in the use of simple tables.
>
Yes. Though as I get better at css, if it's simple in tables, it's
simple in CSS, though that didn't seem to be the case in the beginning.

> There is also a great deal of bigotry about not using tables. Tables
> are designed for presenting tabular data, rows and columns. In this
> context they are perfectly acceptable.
>

Of course they are.  I agree though, and still use them in this context.

> CSS offers some positioning commands as extensions to basic HTML, but
> these are not universally supported and can be problematic unless care
> is taken, and can easily be broken by clients resizing their text size
> and the like, (Note: 'can be', not 'always are').
>
Augh, tell me about it.  I'm still learning those pitfalls.

jmc

jmc <NOnewsgroupsSPAM@NOjodiBODY.HOMEus> wrote:

>Suddenly, without warning, hug exclaimed (24-Dec-05 12:20 PM): 
>
>Sorry, I was posting in the wee hours of the morning.  By "accessible" I
>mean, "accessible to people with disabilities" - more specifically those
>who use a screen reader to 'hear' the pages.  Tables for layout are, I
>understand, difficult to translate.  Gets worse the more complicated
>and/or nested they are.
>
>jmc

Interesting, I wonder why that is.  Is there a better way of obtaining
the layout you want than using tables?  It isn't that I have no
sympathy for the blind, but most people who visit ecommerce stores can
read visually and one must satisfy the masses while doing the best one
can not to discomfort the handicapped.  Blind people must love most
websites, filled with frames and graphics and animated videos.  As the
wicked witch said, "Oooooh, what a world!"

--
http://www.ren-prod-inc.com/hug_sof...?action=contact