advice re convincing someone to avoid table layouts

[Michael Rozdoba]

I'm far from a CSS expert, but what I see of it I really like & I love
keeping content & style separate. I also hate the way table layout
produces convoluted bulky code.

However when asked why one should use CSS rather than tables,
particularly when tables work & browser support of CSS can be dodgy,
especially in IE, I usually fail to come up with a concise & convincing
argument :/

I've been having this long running discussion with a lecturer at college
& so far I've not convinced him to be less content with table layout.

Can anyone help?

I need something I can talk to him about, or show him, but which won't
require he go off & spend an hour or more reading or looking into, as I
doubt he'd bother on the strength of what I've said to him, iyswim?

--
Michael
m r o z a t u k g a t e w a y d o t n e t

[Benjamin Niemann]

Michael Rozdoba wrote:

I'm far from a CSS expert, but what I see of it I really like & I love
keeping content & style separate. I also hate the way table layout
produces convoluted bulky code.

However when asked why one should use CSS rather than tables,
particularly when tables work & browser support of CSS can be dodgy,
especially in IE, I usually fail to come up with a concise & convincing
argument :/

I've been having this long running discussion with a lecturer at college
& so far I've not convinced him to be less content with table layout.

Can anyone help?

I need something I can talk to him about, or show him, but which won't
require he go off & spend an hour or more reading or looking into, as I
doubt he'd bother on the strength of what I've said to him, iyswim?

Do you know the book "Designing with Web Standards" by Jeffrey Zeldman?
(Well, I was a bit disappointed when I read it, because I hoped to read more
about technical details...) The first halve of is well suited to be ripped
out and handed to manager folks or who ever needs to be convinced of the
benefits of CSS design.
Some keys that Zeldman can explain much better than I could:
- Maintainablity
- Accessability
- Search engine optimization
- Support for unusual or future browsers and devices
- ...

One quote that I liked most (well, from my memory, so not exactly quoted):
"designing accessible websites (e.g. to blind people) is important, because
there is one blind visitor that nobody want to piss off: googlebot".

--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://www.odahoda.de/

[Michael Rozdoba]

Benjamin Niemann wrote:

Do you know the book "Designing with Web Standards" by Jeffrey Zeldman?
No.
(Well, I was a bit disappointed when I read it, because I hoped to read more
about technical details...) The first halve of is well suited to be ripped
out and handed to manager folks or who ever needs to be convinced of the
benefits of CSS design.
Some keys that Zeldman can explain much better than I could:
- Maintainablity
I've stated that. He didn't seem convinced.
- Accessability
This one is obviously important & I've tried to argue the case, but
maybe I just didn't do a good job - with the exception of deeply nested
tables which he wouldn't advocate generally anyway, he seemed to think,
aiui, that tables shouldn't pose a problem to accessibility - eg as long
as content is laid out in the order it would be read, a speech based
browser wouldn't have a problem.
- Search engine optimization
I've mentioned that, but could push it more.
- Support for unusual or future browsers and devices
Again, I have mentioned the former, but with little success. - ...

One quote that I liked most (well, from my memory, so not exactly quoted):
"designing accessible websites (e.g. to blind people) is important, because
there is one blind visitor that nobody want to piss off: googlebot".

Yup, tried that one too. I think the response was as for accessibility
above :/

I'll see if I can find a copy of the book, thanks.

--
Michael
m r o z a t u k g a t e w a y d o t n e t

[Barbara de Zoete]

On Sun, 20 Mar 2005 15:06:18 +0000, Michael Rozdoba <mr**@nowhere.invalid> wrote:

Benjamin Niemann wrote:

[ a lot of valid arguments; none of which seemed to have worked for OP so far ]

Yup, tried that one too. I think the response was as for accessibility above :/

I'll see if I can find a copy of the book, thanks.

Why don't you create your own case study situation: Put up a page with some nice
content. Create it with valid structural and semantical markup and design the
look and feel with CSS. Know what? Give that one page several stylesheets to
show your point of ease of maintainability (fast change of look possible). Then
take the same content and put it in a tables page. Design with what ever
technique it takes (I wouldn't know since I don't do table for layout), probably
only one or two very similar layouts possible.
- Trigger Google for the pages whereabouts and wait a while, sit back, see who
wins.
- Contact that one elderly lady you know who surfs the net, and find out if she
finds one over the other page more comfortable navigating.
- Challange the Thomas that gives you a hard time to redesign either page, and
be honest about the pro's and con's.
- Play with the pages in Lynx to find out what is easiest to navigate.

et cetera Be creative. If verbal arguments don't seem to land on deck, try real
evidence.
--
,-- --<--@ -- PretLetters: 'woest wyf', met vele interesses: ----------.
| weblog | http://home.wanadoo.nl/b.de.zoete/_private/weblog.html |
| webontwerp | http://home.wanadoo.nl/b.de.zoete/html/webontwerp.html |
|zweefvliegen | http://home.wanadoo.nl/b.de.zoete/html/vliegen.html |
`-------------------------------------------------- --<--@ ------------'

[Alan J. Flavell]

On Sun, 20 Mar 2005, Michael Rozdoba wrote:

This one is obviously important & I've tried to argue the case, but
maybe I just didn't do a good job - with the exception of deeply
nested tables which he wouldn't advocate generally anyway, he seemed
to think, aiui, that tables shouldn't pose a problem to
accessibility - eg as long as content is laid out in the order it
would be read, a speech based browser wouldn't have a problem.

This is also a rod which the WAI made, with which to beat its own
back. When WAI guidelines 1.0 were drafted for their release in 1999,
they included a section which said:

5.3 Do not use tables for layout unless the table makes sense when
linearized.

Those who have a vested interest in preserving old-fashioned
techniques in the face of better options, continue to conveniently
ignore that the item goes on to say:

Note. Once user agents support style sheet positioning, tables
should not be used for layout.

Remember: that advice is now about 6 years old. While it's true that
not every detail of CSS positioning is well supported (nor even well
understood by authors and by the writers of web authoring software!),
there -are- enough useful options which work well and which have fewer
negative consquences than (mis)use of tables to achieve mere
positional layout.

Furthermore, in that time there has developed more diversity in the
kinds of presentation situation, particularly in the direction of
smaller screens (handhelds etc.) which are seriously hampered by being
told to present material in a way that was designed specifically for
the designer's own large-screen display. So it's not just between
fully-formatted-to-the-designer's-requirements on the one hand and
fully-linearised for the speaking browser or indexing bot on the other
hand; it's a whole spectrum of different presentation situations.
Which can be rather well handled by the fluid design approach, while
the table-layout model stubbornly produces its predictable results
over some range of presentation situations while making itself quite a
nuisance when it's inappropriate.

As I've found out in discussions myself, these table-layout supporters
always have an argument ready, for justifying their use of table
layout to themselves. I'm afraid any attempt to convince them
otherwise is like talking to a brick wall. They tend to just keep
coming back to the litany of "does what I want for the *majority* of
readers" and "my table makes sense when linearised" - even using that
actual WAI guideline to support their entrenched stance.

AFAICS, one just has to design one's way around and past them. Perhaps
in another 6 years they'll notice that the web has moved on without
them.

One quote that I liked most (well, from my memory, so not exactly
quoted): "designing accessible websites (e.g. to blind people) is
important, because there is one blind visitor that nobody want to
piss off: googlebot".

Yup, tried that one too. I think the response was as for
accessibility above :/

Yup, that figures, I'm afraid. Sorry to be so negative about it.

[Spartanicus]

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

Furthermore, in that time there has developed more diversity in the
kinds of presentation situation, particularly in the direction of
smaller screens (handhelds etc.) which are seriously hampered by being
told to present material in a way that was designed specifically for
the designer's own large-screen display. So it's not just between
fully-formatted-to-the-designer's-requirements on the one hand and
fully-linearised for the speaking browser or indexing bot on the other
hand; it's a whole spectrum of different presentation situations.
Which can be rather well handled by the fluid design approach, while
the table-layout model stubbornly produces its predictable results
over some range of presentation situations while making itself quite a
nuisance when it's inappropriate.

Imo using tables or not for layout is not the real issue.

Layouts that work well on the desktop and on small screen devices are
single column layouts. Layouts that use more than one column rarely work
properly on a wide range of viewport widths. This also applies to "css"
layouts that use separate "screen" and "handheld" stylesheets due to the
poor support for the handheld media type and it's intrinsic limitations.
The same also applies to css table layouts.

For sites that use a multi column layout the use of a "css" layout
almost always introduces problems that do not occur with table layouts
(be they css or html tables). More complex layouts create less problems
when made with tables than with IE compatible "css" layouts.

This complexity of the layout, and the associated issue of inserting
repeated content across pages has a far greater effect on the quality of
a page than the choice of table vs "css" layout.

The reality is that the current css spec has virtually no support for
creating proper layouts, nor for media and/or viewport width dependant
inclusion of elements such as convenience navbars and repeated content.

Until we have those options, applying the KISS principle will do more
for the quality than avoiding tables for layout.

--
Spartanicus

[Alan J. Flavell]

On Sun, 20 Mar 2005, Spartanicus wrote:

Imo using tables or not for layout is not the real issue. [...]
This complexity of the layout, and the associated issue of inserting
repeated content across pages has a far greater effect on the quality of
a page than the choice of table vs "css" layout.
You make a very good point. Sometimes it's too easy to get lost in
the detail of a discussion and lose sight of the larger context.

Those accustomed to making paper brochures etc. have got accustomed to
the need to cram a maximum of content into the given physical space.
Then they tend to do the same with their web pages.
The reality is that the current css spec has virtually no support
for creating proper layouts, nor for media and/or viewport width
dependant inclusion of elements such as convenience navbars and
repeated content.
Maybe you exaggerate a bit in the interests of making your point, but
I was thinking more in terms of, for example, floated elements which
can float themselves into a wider range of presentation situations,
than of several purpose-targetted stylesheets which are supposed to be
applied depending on screen/handheld/projector/whatever.

But whichever approach you aim at in your stylesheet, the important
thing to do in the HTML (at least as a principle - I've been doing web
for too long now, and have all kinds of collected historical rubbish
in my web pages, so please don't go looking there at random for a
model) is to mark up the elements of the content for what they are in
structural terms - sequenced in appropriate sequence - but leaving the
presentation details to the combined efforts of the browser and the
spreadsheet(s).
Until we have those options, applying the KISS principle will do
more for the quality than avoiding tables for layout.

I'd vote for that principle even /when/ you have "those options", TBH.

all the best

[Spartanicus]

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

Those accustomed to making paper brochures etc. have got accustomed to
the need to cram a maximum of content into the given physical space.
Then they tend to do the same with their web pages.
What I'm referring to is afaics mainly used on web pages, it's the
common practice of presenting the main features of a site on every page,
often inserted in top, side and bottom bars with the unique page content
in the middle. It can be argued that this invites the user to explore
more of the site and spend more time on it, especially when they enter
on a sub page. If done properly (and often it's not), then this is not
to distracting in the visual domain when the viewport is large enough to
accommodate it. This non unique page content however becomes a huge
hindrance when the page is accessed linearly, or on small viewports.

Navbars also fall into this category when they are used to invite the
user to casually browse the main features of a site (and not as the only
way to navigate a site).

The reality is that the current css spec has virtually no support
for creating proper layouts, nor for media and/or viewport width
dependant inclusion of elements such as convenience navbars and
repeated content.

Maybe you exaggerate a bit in the interests of making your point, but
I was thinking more in terms of, for example, floated elements which
can float themselves into a wider range of presentation situations,

Floats are imo a real turd in the css arsenal, the definition of their
behaviour in the spec is nigh impossible to understand, this aspect has
imo contributed significantly to the large number of floating bugs that
browsers suffer from, both issues combine to make using them a
frustrating experience. There is the issue of potential overlapping of
floated elements when the viewport is to narrow if they are used left
*and* right, and there is the problem of floats needing to be positioned
before other block level elements if you want to display them next to a
block level element such as a header (thereby screwing up proper content
order). This also applies to a left floated layout side box/bar.
But whichever approach you aim at in your stylesheet, the important
thing to do in the HTML (at least as a principle - I've been doing web
for too long now, and have all kinds of collected historical rubbish
in my web pages, so please don't go looking there at random for a
model) is to mark up the elements of the content for what they are in
structural terms - sequenced in appropriate sequence - but leaving the
presentation details to the combined efforts of the browser and the
spreadsheet(s).

Sure, only I'd use a stylesheet instead of a speadsheet ;-)

But as you know people often approach this the wrong way round, thus the
side bar *has* to go left, even though this typically screws up the
content order.

Until we have those options, applying the KISS principle will do
more for the quality than avoiding tables for layout.

I'd vote for that principle even /when/ you have "those options", TBH.

When implemented in css you'd in theory have the option to prevent for
example repetitive page content to be included on every page via your
user stylesheet. But imo it's unlikely that we'll ever see such a
feature in css, and if it does become an option people would likely
abuse it to no end.

--
Spartanicus

[Alan J. Flavell]

On Sun, 20 Mar 2005, Spartanicus wrote:

presentation details to the combined efforts of the browser and the
spreadsheet(s).
Sure, only I'd use a stylesheet instead of a speadsheet ;-)

Oops, I was on autopilot after dealing with something completely
different. Sorry! - but you caught my drift regardless...
But as you know people often approach this the wrong way round, thus the
side bar *has* to go left, even though this typically screws up the
content order.

I certainly -do- know that. I personally would much rather have it on
the right (or at the end when the content is serialised), for pages
that are meant to contain substantive content. (Menu/overview pages
are of course a different matter).

all the best

[Michael Rozdoba]

Barbara de Zoete wrote:

Why don't you create your own case study situation: Put up a page with
some nice content. Create it with valid structural and semantical
markup and design the look and feel with CSS. Know what? Give that one
page several stylesheets to show your point of ease of maintainability
(fast change of look possible). Then take the same content and put it
in a tables page. Design with what ever technique it takes (I wouldn't
know since I don't do table for layout), probably only one or two very
similar layouts possible.
- Trigger Google for the pages whereabouts and wait a while, sit back,
see who wins.

A time consuming but interesting approach which I hadn't thought of
taking to this extent. Thanks. I might have a go at that over the summer
as it could fit in with some other things I'll have to do then, web wise.

[snip further good demo suggestions]

--
Michael
m r o z a t u k g a t e w a y d o t n e t

[Michael Rozdoba]

Alan J. Flavell wrote:

On Sun, 20 Mar 2005, Michael Rozdoba wrote:

[reference to 'linearised tables are fine' argument] This is also a rod which the WAI made, with which to beat its own
back. When WAI guidelines 1.0 were drafted for their release in 1999,
they included a section which said:

5.3 Do not use tables for layout unless the table makes sense when
linearized.

Those who have a vested interest in preserving old-fashioned
techniques in the face of better options, continue to conveniently
ignore that the item goes on to say:

Note. Once user agents support style sheet positioning, tables
should not be used for layout.
I quoted that at him, though I couldn't recall the precise source.
Remember: that advice is now about 6 years old.
Ah now, the truth & relevance of that I had overlooked :/
While it's true that
not every detail of CSS positioning is well supported (nor even well
understood by authors and by the writers of web authoring software!),
there -are- enough useful options which work well and which have fewer
negative consquences than (mis)use of tables to achieve mere
positional layout.
The more I think about this, the more I feel there's something missing
in my understanding of the table layout advocate.

I know people become entrenched in behaviours & belief systems, but I
can't help but feel there's something specific to this case that's
hidden in the minutiae which will explain why it can be so difficult to
convince such people of the superiority of the css case.

I generally hold that if one is correct in ones views, this can be
communicated if one has a good enough understanding of why the other
holds their view in the first instance. That's despite being regarded as
extremely cynical in respect of human nature.
Furthermore, in that time there has developed more diversity in the
kinds of presentation situation, particularly in the direction of
smaller screens (handhelds etc.) which are seriously hampered by being
told to present material in a way that was designed specifically for
the designer's own large-screen display.
I'll come back to this in a later post (having read the existing thread
already).
As I've found out in discussions myself, these table-layout supporters
always have an argument ready, for justifying their use of table
layout to themselves. I'm afraid any attempt to convince them
otherwise is like talking to a brick wall.
Yes. It's very interesting; frustrating of course too.
They tend to just keep
coming back to the litany of "does what I want for the *majority* of
readers" and "my table makes sense when linearised" - even using that
actual WAI guideline to support their entrenched stance.
I like the choice of word 'litany'. Indeed. Hmm, need to give this more
thought.
AFAICS, one just has to design one's way around and past them. Perhaps
in another 6 years they'll notice that the web has moved on without
them.
Well, waiting for non-believers to expire will always be one way to win
an argument, assuming you first sterilise the belief system. Not as
satisfying though :)

[google is blind... response: but my table is linearised]
Yup, that figures, I'm afraid. Sorry to be so negative about it.

I sense that's based on experience ;) Thanks for sharing it.

--
Michael
m r o z a t u k g a t e w a y d o t n e t

[Michael Rozdoba]

Spartanicus wrote:

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:
[snip]
Imo using tables or not for layout is not the real issue.

Layouts that work well on the desktop and on small screen devices are
single column layouts. Layouts that use more than one column rarely work
properly on a wide range of viewport widths.
[snip]
This complexity of the layout, and the associated issue of inserting
repeated content across pages has a far greater effect on the quality of
a page than the choice of table vs "css" layout.
A very welcome reminder. Thank you.

It's so very easy, especially for me when my ire is up, to become too
narrowly focused.
The reality is that the current css spec has virtually no support for
creating proper layouts, nor for media and/or viewport width dependant
inclusion of elements such as convenience navbars and repeated content.

The medium is young. Print has had a wee bit longer to evolve without
perhaps the same degree of critical appraisal. I'm hopeful.

[KISS]

--
Michael
m r o z a t u k g a t e w a y d o t n e t

[Michael Rozdoba]

Alan J. Flavell wrote:

Those accustomed to making paper brochures etc. have got accustomed
to the need to cram a maximum of content into the given physical
space. Then they tend to do the same with their web pages.

I suppose I'd realised that but hadn't focused on it. It's an obvious
failing & potential trap. That said, what works in print has been well
studied. It's perhaps less clear how to design for the web in order to
transfer as much of ones information as possible into the user. I wonder
if there are any existing studies? 'No' wouldn't surprise me.

I expect most of this material is old hat to the regulars of ciwa*,
however I'm still encountering new ideas for which I'm very glad. Thanks
to everyone in this thread for giving me a lot to think about.

--
Michael
m r o z a t u k g a t e w a y d o t n e t

[Darin McGrew]

Michael Rozdoba <mr**@nowhere.invalid> wrote:

It's perhaps less clear how to design for the web in order to
transfer as much of ones information as possible into the user. I wonder
if there are any existing studies? 'No' wouldn't surprise me.

Jakob Nielsen's Alertbox column <http://useit.com/alertbox/> has been
addressing usability on the WWW for nearly a decade. Many of the articles
refer to usability studies.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

Why is "abbreviated" such a long word?

[Michael Rozdoba]

Darin McGrew wrote:

Michael Rozdoba <mr**@nowhere.invalid> wrote:

It's perhaps less clear how to design for the web in order to
transfer as much of ones information as possible into the user. I wonder
if there are any existing studies? 'No' wouldn't surprise me.

Jakob Nielsen's Alertbox column <http://useit.com/alertbox/> has been
addressing usability on the WWW for nearly a decade. Many of the articles
refer to usability studies.

Thanks, I'll take a look. Though the issue doesn't necessarily equate
with usability I imagine at the very least there must be overlap.

--
Michael
m r o z a t u k g a t e w a y d o t n e t

[Chris Morris]

Michael Rozdoba <mr**@nowhere.invalid> writes:

Benjamin Niemann wrote:

- Maintainablity

I've stated that. He didn't seem convinced.

If he uses a preprocessor or server-side template system to put
together his pages, he might not notice so much. Is he already using
stylesheets for the CSS1 bits? (colours, borders, etc)

- Accessability

This one is obviously important & I've tried to argue the case, but
maybe I just didn't do a good job - with the exception of deeply
nested tables which he wouldn't advocate generally anyway, he seemed
to think, aiui, that tables shouldn't pose a problem to accessibility
- eg as long as content is laid out in the order it would be read, a
speech based browser wouldn't have a problem.

And, he's right, largely. ;)

While having layout tables lying around can make it slightly more
confusing to navigate a data table on the same page, generally layout
tables don't cause a massive problem for audio browsing *provided*
that they linearise properly.

The accessibility issue for layout tables is on narrow width displays
that support grid display of tables. So, WebTV and successors, many
phone browsers (except the Opera-based ones, I think), w3m, links(2),
any graphical browser at a viewport width sub-500px [1], etc.

[1] More or less, depending on the layout.

Either you get horizontal scrolling which is bearable for a data table
but horrible for a layout table (especially when you have to scroll
sideways for every single line) you get columns of text one or two
characters wide. Try reading more than a word or two in that. It's
bearable for data tables, just about, but if three paragraphs get
compressed like that, it's not.

Layout tables can cause massive accessibility problems in some
cases. Non-visual cases are largely okay once linearisation is sorted
out, though, compared to some problems with narrow-width displays.

- Search engine optimization

I've mentioned that, but could push it more.

The smaller filesize and cleaner code will make it easier for them to
find the relevant bits. I suspect layout tables is one of the more
marginal ones, though - up until the point where someone makes a
data-table focused search engine.

Still, the smaller filesize - only having to download the layout
information once - will be a big help in general.

--
Chris

[Michael Rozdoba]

Chris Morris wrote:

Michael Rozdoba <mr**@nowhere.invalid> writes:

Benjamin Niemann wrote:

- Maintainablity
I've stated that. He didn't seem convinced.

If he uses a preprocessor or server-side template system to put
together his pages, he might not notice so much. Is he already using
stylesheets for the CSS1 bits? (colours, borders, etc)

I haven't actually asked tbh - my only experience is via several modules
in a course whose content he isn't responsible for. Mostly the
discussions come about as I slag^w comment on the university
'responsible' for the module content (eg an intro web design module last
year which taught no css) & he offers a partial defence.

ATM I'm creating a shopping site selling about fifty products - only
we're not expected to create our own dynamic content, have no database
support & aren't supposed to use a database. They expect a static site.

This is meant to be intermediate web development. It involved reading
some stuff on accessibility which I already knew & using Dreamweaver,
which I'd rather not. No css has been taught & no server or client side
scripting (despite other modules involving programming). Apparently the
Uni had problems trying to include backend stuff in a previous year, so
dropped it from our module - that was one of the stories.

Sorry to rant, but the subject really winds me up. In the end I tend to
go my own way & teach myself something. Our static site will use rather
a lot of php & will not realise pulling data out of a flat file could be
construed as database access.

- Accessability

This one is obviously important & I've tried to argue the case, but
maybe I just didn't do a good job - with the exception of deeply
nested tables which he wouldn't advocate generally anyway, he seemed
to think, aiui, that tables shouldn't pose a problem to accessibility
- eg as long as content is laid out in the order it would be read, a
speech based browser wouldn't have a problem.

And, he's right, largely. ;)

While having layout tables lying around can make it slightly more
confusing to navigate a data table on the same page, generally layout
tables don't cause a massive problem for audio browsing *provided*
that they linearise properly.

Thanks for the comments. I really must investigate more clients.
Currently I only bother with a few recent versions of Firefox, Opera &
IE (though Opera does a nice job of simulating a small screen
environment) - & occasionally Konqueror.
The accessibility issue for layout tables is on narrow width displays
that support grid display of tables. So, WebTV and successors, many
phone browsers (except the Opera-based ones, I think), w3m, links(2),
any graphical browser at a viewport width sub-500px [1], etc.

[1] More or less, depending on the layout.

Either you get horizontal scrolling which is bearable for a data table
but horrible for a layout table (especially when you have to scroll
sideways for every single line) you get columns of text one or two
characters wide. Try reading more than a word or two in that. It's
bearable for data tables, just about, but if three paragraphs get
compressed like that, it's not.

Thanks. This looks like a very useful argument which shouldn't be too
hard to demonstrate :)

--
Michael
m r o z a t u k g a t e w a y d o t n e t