Keep tables

[news frontiernet.net]

Why fix something that is not broken?

Keep using tables until it becomes OBVIOUS that there is a simpler CSS
solution for your needs.

So far, table based layouts are more easy to deploy, easier to troubleshoot
and more likely to work cross-browser.

 

[Mark Parnell]

Sometime around Mon, 08 Dec 2003 21:26:21 GMT, news frontiernet.net is
reported to have stated:

Why fix something that is not broken?

You don't. Why hang on to an ancient method of doing something when a far
better method is available?

Keep using tables

Of course. There is nothing wrong with tables. They are *perfect* for
marking up tabular data.

until it becomes OBVIOUS that there is a simpler CSS
solution for your needs.

But it *is* obvious. There are just those who (for whatever reason) resist
change.

So far, table based layouts are more easy to deploy,

Only if you are too lazy to learn CSS.

easier to troubleshoot
ROTFLOL!

and more likely to work cross-browser.

In some rare cases. Maybe. If you include NS4.

 

[David Dorward]

news frontiernet.net wrote:

Dear news,

What an unusual name you have.

Why fix something that is not broken?

Why indeed.

Keep using tables until it becomes OBVIOUS that there is a simpler CSS
solution for your needs.

Tables are broken when used for layout. They claim something about the data
which is not true. They use more bandwidth then needed. They limit the
ability of some browsers to incrementally render data. They don't allow for
different layouts for different media types. They ...

 

[Sreve R.]

news frontier.net wrote in message ...

Keep using tables until it becomes OBVIOUS that there is a simpler CSS
solution for your needs.

I'm right with you there buddy :~)

It's a bit like complex difficult to user-service fuel-injection on cars and
motorcycles compared to simple old easy-to-maintain carburettors. The carbed
cars and bikes will still go on for years and relaible to boot.

Steve :~)

 

[Jay]

Why fix something that is not broken?

No one tells you what to do with your web page. If you don't like the
opinions of other professionals, don't listen to them. It really is that
simple. This way you can keep your "follow me" rants to yourself.

Keep using tables until it becomes OBVIOUS that there is a simpler CSS
solution for your needs.

CSS is simpler. You just need to learn it.
Tables were not meant to be used for layout, they were meant to be used to
display tabular data.
Paragraph tags weren't meant to insert a double return, they were meant to
be used to distinguish paragraphs.

Use HTML tags the way they are supposed to be used. Your web pages will
validate and more browsers will be happy!!!

So far, table based layouts are more easy to deploy

Not really. They're sloppy and take up a lot of space in your .html file.
A CSS based layout is more organized in your markup.

easier to troubleshoot

Stop kidding yourself. A well established CSS is so much easier to
troubleshoot. If you have a layout problem on every page of a 500+ page web
site, are you still thinking that the table layout is easier to
troubleshoot? With CSS, one change on a single file affects every page.

and more likely to work cross-browser.

If you're concerned with old out-dated browsers like NS4x, sure. But take a
look at your log files...how many CSS NS4x browsers visit your web site?
NS4x browsers make up for less than 1% of our web site visitors each month.
Those users have been using this outdated version for so long that they know
how to open IE or another browser that works when they visit a web site that
NS4x can not render.

- J

 

[Voetleuce en f?nsievry]

"news frontiernet.net" <[email protected]> yelled "HEY PEOPLE, FOLLOW
ME" and said...

No one tells you what to do with your web page. If you don't like the
opinions of other professionals, don't listen to them. It really is that
simple. This way you can keep your "follow me" rants to yourself.

This is a very valid opinion.

I use HTML 3.2 with tables and font face tags. That said, I rarely
nest my tables more than one level deep, because if you want that kind
of control over the layout, you might as well use CSS (or PDF). And I
don't mind if my fonts look different in different browsers -- as long
as the content is readable and accessible. I sometimes use XHML 1.0
Transitional for the hell of it, and I always try to make my pages as
Anybrowser and Bobby compliant as possible, but other than that... why
jump on the follow me bandwagon?

CSS positioning is unpredictable unless you know that your user uses a
certain minimum and maximum size browser window. Sure, CSS scale
better than tables, but only within certain limits.

Say, where can I learn CSS if I'm using Opera 6?

CSS is simpler. You just need to learn it.

CSS is very complex and because there are so many browsers out there,
it becomes exponentially difficult to figure out whether what you've
learnt by trial and error is just your browser's interpretation of it
or what the standard really says it should do. That was the beauty of
HTML 3.2 (and only two browsers) -- anyone could learn by doing, but
nowadays you can't do that any more because you can't be sure whether
your browser really, really, really does the right thing.

With CSS, one change on a single file affects every page.

....providing you put the CSS in a seperate file. But even if you put
your CSS code in every HTML page, you can still use Find/Replace tools
to bulk change your code if you code consistently.

In the end, what matters is not that browsers are happy, but that
*users* can read your page quickly and efficiently. Go for the common
denominator rather than the esoteric, unless you have a big budget.

 

[Leif K-Brooks]

CSS positioning is unpredictable unless you know that your user uses a
certain minimum and maximum size browser window. Sure, CSS scale
better than tables, but only within certain limits.

As long as they're using something above 100x100 (and your table-abusing
pages won't be very happy there either), it will be fine. Or can you
prove me wrong?

CSS is very complex and because there are so many browsers out there,
it becomes exponentially difficult to figure out whether what you've
learnt by trial and error is just your browser's interpretation of it
or what the standard really says it should do. That was the beauty of
HTML 3.2 (and only two browsers) -- anyone could learn by doing, but
nowadays you can't do that any more because you can't be sure whether
your browser really, really, really does the right thing.

Browsers broke the HTML 3.2 standard (and simply interpreted it their
way, some standards can be correclty done in various ways) too.

 

[Barry Pearson]

Why fix something that is not broken?

Keep using tables until it becomes OBVIOUS that there is a simpler CSS
solution for your needs.

So far, table based layouts are more easy to deploy, easier to
troubleshoot and more likely to work cross-browser.

Chuckle! So you felt like starting World War 3 just before Christmas! And you
are getting the predictable responses. (Troll?)

 

[Barry Pearson]

[Whoops! Accidentally sent an earlier version too soon.]

Why fix something that is not broken?

Keep using tables until it becomes OBVIOUS that there is a simpler CSS
solution for your needs.

So far, table based layouts are more easy to deploy, easier to
troubleshoot and more likely to work cross-browser.

Chuckle! So you felt like starting World War 3 just before Christmas!
(Trolling?) And you are getting the predictable responses.

Like your "opponents", you are over-generalising. Deciding whether to use
table-layout or tableless-layout isn't a simple either-or decision. You might
want to make some use of tables within an overall tableless-layout. It is very
likely that even if you use table-layout for the major "boxes", you can
benefit from tableless-layout within those boxes. Hybrid approaches have a lot
of merit.

For a whole range of tasks, table-layout is indeed easier, and certainly more
mature. And, of course, table-layout isn't even deprecated. It works well in
4.01 Strict, 1.0 Strict, even 1.1. It will continue to be supported by popular
general purpose user agents for a decade or two. Including those intended for
accessibility and/or small screens.

Some attempts to use CSS positioning, to do things that tables can do easily,
are laboured and full of hacks. One of my concerns is that some people don't
even recognise that these hacks in CSS, and sometimes contorted mark-up, are
what would be expected of something that is being pushed beyond its current
limits. (If they had been in a "product", the product may not be considered
ready for general release!) I think it would be more useful if people backed
off from their extreme positions and tried to study where those real limits
are. (They change each year or two). I've been trying that for my own
purposes, but I don't claim it is leading edge:
http://www.barry.pearson.name/articles/layout_5_3/tableless_flexible_00.htm

Multiple flexible columns appear to on the boundary between "do this if you
are confident" and "don't try this without a doctor present". Columns were
recognised even in 1993 as a particular problem with layout that may need
special help, and there is a "columns" module in CSS3 that may help. I still
haven't found evidence that the designers of CSS2 actually believed they were
avoiding the need for table-layout.

(The answer to "tables were not intended for layout" is "so what?" But
considering how much description there is around of how user agents may layout
tabular data in tables, I don't even believe the assertion that tables were
not intended for layout. They were, just as much other mark-up was).

 

[Leif K-Brooks]

And, of course, table-layout isn't even deprecated.

To be deprecated, something has to appear in a standard in the first
place. The standard does speak against tables for layout, though:

"Tables should not be used purely as a means to layout document content
as this may present problems when rendering to non-visual media." from
http://www.w3.org/TR/html4/struct/tables.html#h-11.1

It works well in 4.01 Strict, 1.0 Strict, even 1.1. It will continue to be
supported by popular general purpose user agents for a decade or two.
Including those intended for accessibility and/or small screens.

They "work" simply because of luck. There is nothing wrong with browsers
which render tabled layouts correctly, but there would be nothing wrong
with them if they rendered tables differently (rows being up-and-down,
say) either.

(The answer to "tables were not intended for layout" is "so what?" But
considering how much description there is around of how user agents may layout
tabular data in tables, I don't even believe the assertion that tables were
not intended for layout. They were, just as much other mark-up was).

The best way to know what the designers of HTML intented is to read the
standard. It clearly states what tables were and were not designed for.

 

[Barry Pearson]

To be deprecated, something has to appear in a standard in the first
place. The standard does speak against tables for layout, though:

I was making the point that no one is about to stop table-layout from working.
The key is that it doesn't actually need extra features. It simply uses
features that are there anyway. There is no algorithm that I now of that will
even reliably detect that some *is* using table-layout. That is why it is
safe.

"Tables should not be used purely as a means to layout document
content as this may present problems when rendering to non-visual
media." from http://www.w3.org/TR/html4/struct/tables.html#h-11.1

That was published in 1999. So, should a person reading that in 1999 have
immediately stopped using tables for layout, and used CSS instead? No - that
was an aspiration, not a rule with immediate effect. The world wasn't ready in
1999 to consistently use CSS positioning instead of table-layout.

Does the document say "this comes into effect in 2003"? Or is there some other
W3C recommendation that says this - a "commencement order"? No - in fact,
there is still talk in parts of the W3C web site about the need for extra
features to replace table-layout. In 2000 W3C was defending its own use of
table-layout.

http://lists.w3.org/Archives/Public/w3c-wai-gl/2001JanMar/0463.html

http://lists.w3.org/Archives/Public/site-comments/2000Jul/0040.html

So why do some people appear to believe that these statements from W3C are
something we should be doing *now*, rather than at some unspecified time, or
"when you judge it is ready for your particular case"? Why *now*?

They "work" simply because of luck. There is nothing wrong with
browsers which render tabled layouts correctly, but there would be
nothing wrong with them if they rendered tables differently (rows
being up-and-down, say) either.

No, it works because there is a convention in the West, that *long* preceded
the web, that tabular data should be laid out in a horizontal & vertical grid.
People using table-layout didn't say "let's use tables, and hope that tables
lay things out in a grid". They said "we want to lay things out in a grid, now
what works like that - ah, tables". They wouldn't have used tables unless
tables naturally worked in the right way.

As the W3C says: "The HTML table model has evolved from studies of existing
SGML tables models, the treatment of tables in common word processing
packages, and a wide range of tabular layout techniques in magazines, books
and other paper-based documents". They then talk a lot about left to right &
top to bottom layout recommendations. All the table-layout people are doing is
exploiting the fact that W3C and the user agent developers did some sensible
work on how to layout material marked-up with <table>. After, of course,
devising <table> as a way of marking-up material that conventionally would be
laid out in such a grid format in the first place! These were not accidents.

http://www.w3.org/TR/html4/appendix/notes.html#notes-tables

The best way to know what the designers of HTML intented is to read
the standard. It clearly states what tables were and were not
designed for.

As I said - so what? (Some of our roads were designed for chariots). They
work, and will continue to do so. Because they were intended to enable people
to mark-up material so that typically a user agent with a large-enough
viewport would lay them out in grid format. I have seen no evidence that they
were supposed *not* to work for layout purposes. I don't think there was ever
a proposal intended to stop them being used for this purpose.

I see the W3C statements as *not* saying "table-layout is wrong", but instead
saying "CSS is the target way of solving these problems". In other words,
interpret them as a carrot - "this is better", not a stick - "this is
naughty".

Since 1999, non-visual user agents appear to have got better at handling
tables. I've been using IBM Home Page Reader, and it was able to "linearise"
through tables. Opera's small screen mode shows that user agents in principle
have the option of mapping table-layout onto small screens. So things have
moved on a bit since 1999. In 5 years time, they will have moved on more, and
some of the browser problems we have at the moment with CSS positioning will
be less important. The balance between when to use table-layout and when not
to changes year by year. There may not be a clear date at which we can say
"*now* it the time to stop using table-layout". Support for both table-layout
& tableless-layout is improving.

 

[Hywel Jenkins]

news frontier.net wrote in message ...

I'm right with you there buddy :~)

It's a bit like complex difficult to user-service fuel-injection on cars and
motorcycles compared to simple old easy-to-maintain carburettors. The carbed
cars and bikes will still go on for years and relaible to boot.

Steve :~)

<curious>
Why is your sender name "Sreve R." and not "Steve R."?
</curious>

 

[Steve R.]

Hywel Jenkins wrote in message ...

Why is your sender name "Sreve R." and not "Steve R."?

Simple answer - I was showing my neighbour how to change the settings for
'news' and 'email' so he could post a few messages from my PC on another
newsgroup in his name. When I hurriedly changed it back I messed up as I
didn't check the spelling with my specs on :~(

All sorted now.

Steve :~)

 

[jake]

To be deprecated, something has to appear in a standard in the first
place. The standard does speak against tables for layout, though:

"Tables should not be used purely as a means to layout document content
as this may present problems when rendering to non-visual media." from
http://www.w3.org/TR/html4/struct/tables.html#h-11.1

[snip

"....... Authors should use style sheets for layout and positioning.
However, when it is necessary to use a table for layout, the table must
linearize in a readable order. When a table is linearized, the contents
of the cells become a series of paragraphs (e.g., down the page) one
after another. Cells should make sense when read in row order and should
include structural elements (that create paragraphs, headings, lists,
etc.) so the page makes sense after linearization......."
from:
http://www.w3.org/TR/WCAG10-HTML-TECHS/#tables-layout

Clearly the w3c sees that table layout will be a fact of life for many
years to come until CSS positioning and layout becomes a more mature
product in terms of cross-browser compatibility and the demise of
browsers that have little or no CSS support. The important thing is to
ensure that the content linearises properly.


regards.

 

[Mark Parnell]

Sometime around Tue, 9 Dec 2003 22:38:26 +0000, jake is reported to have
stated:

However, when it is necessary to use a table for layout, the table must

Note "when it is *necessary*..."

It's just that everyone has different opinions as to when that actually is.

I am very pro-CSS-based layouts. At the same time, I realise that there may
still be cases where a table-based layout may still be necessary.

But a lot of authors use table-based layouts when it could be done easily
and reliably in CSS. They are still very over-used. CSS support has come a
long way in the last few years, and most sites could be done in CSS without
problems (except in NS4, of course).

Most authors just don't want to have to learn a new technology.

 

[jake]

Sometime around Tue, 9 Dec 2003 22:38:26 +0000, jake is reported to have
stated:

Note "when it is *necessary*..."

It's just that everyone has different opinions as to when that actually is.

I find it satisfying to develop a page using CSS that looks OK across a
range of browsers (even though I know I could have done it more quickly
using a table-based layout). Maybe that's why I limit myself to a
2-column layout.

I am very pro-CSS-based layouts. At the same time, I realise that there may
still be cases where a table-based layout may still be necessary.

Sure. When more than a 2 (or maybe a 3) column layout is necessary -- or
a layout has to be 'pixel-perfect' across a range of browsers for
commercial reasons.

But a lot of authors use table-based layouts when it could be done easily
and reliably in CSS.

Very true.

They are still very over-used. CSS support has come a
long way in the last few years, and most sites could be done in CSS without
problems (except in NS4, of course).

Although even NS4 understands a fair amount of CSS, and it's not
difficult to make the page look good (even with a 2-column layout) if
you think your work justifies it. Personally, I don't see major problems
in supplying a second stylesheet to provide at least the basic styling
for pages under NS4.

Most authors just don't want to have to learn a new technology.

This would seem to be the case. Although to be fair, if your job depends
on it, it is going to be a brave man who is going to attempt a 3 or 4
column layout with cross-browser precision when the art director or PR
man is looking over his shoulder and he's up against a deadline ;-)

regards.

 

[Barry Pearson]

Mark Parnell wrote:
[snip]

I am very pro-CSS-based layouts. At the same time, I realise that
there may still be cases where a table-based layout may still be
necessary.

But a lot of authors use table-based layouts when it could be done
easily and reliably in CSS. They are still very over-used. CSS
support has come a long way in the last few years, and most sites
could be done in CSS without problems (except in NS4, of course).

Most authors just don't want to have to learn a new technology.

I wouldn't call CSS-positioning aka tableless-layout "new technology". I'll
come back to that point below.

CSS itself counts as "new technology". But the overwhelming majority of pages
I see each week on the web use *both* table-layout & CSS. (I look at a lot of
news sites, but also government & academic sites & others). So *lots* of
authors have made the move to CSS, to varying degrees. (I'm sure we all agree
about the major benefits of CSS). I have been browing a lot with the following
local style which outlines tables with a blue dotted line, so I can see at a
glance where they are using tables:
table { border: 1px dotted blue; }

I doubt if many people go from no-CSS to tableless-layout in one jump. It took
me about 10 months from starting to use CSS to uploading my first (very
simple) tableless-layout pages. Months after that, I still use table-layout
for most pages, and will probably do so for years.

I don't see the step to tableless-layout as "new technology". I see it as
*stopping* using an older & mature tool - layout-tables. Then the question
becomes "what is the point of stopping?" I have been examining the various
claims that people make about what the point is. I have tried building pages
in different ways, then examining the differences. I don't believe the claims
typically stand up to scrutiny. I have uploaded some examples of this work
(still "work in progress") at:
http://www.barry.pearson.name/articles/layout_5_3/tableless_flexible_00.htm

I spent many years in the R&D department of an IT company, helping to design
mainframe systems and large-scale computer systems. I am used to reading and
writing specifications, and working with planners & marketers with the release
& rollout strategies of combinations of products for building systems. The
immaturity of CSS-positioning came as a bit of a surprise when I tried to use
it. We wouldn't have let it out of the labs in its current state, unless an
important customer had an urgent need and we chose to hold their hand while
they deployed it.

The hardest thing for me to adapt to was that it was insufficient to read &
understand the specification & follow it & validate & check with a couple of
significantly-different browsers. Some other browser, perhaps running on a
platform I don't have access to for testing purpose, would trip me up. This is
the sort of hassle that authors don't want. I want to concentrate on content,
not those complications.

I now do 2 things in parallel. I conduct "experiments" (such as the above URL
& the links from it) rather like the "R" part of R&D. But my main published
web pages use mature methods, such as (in about 2/3rds of cases) table-layout.
Instead of worrying about the rights & wrongs of layout-tables, I concern
myself instead with ensuring that my pages obey the specifications, and
validate. (Ditto the CSSs). My chosen level for future work is 4.01 Strict. I
am confident that this will protect my investment.

I suspect that there are many web authors out there who have similar views.
They can afford to "wait & see", because no one is about to pull the rug from
under layout-tables. They will be working in a decade or more.

 

[Toby A Inkster]

We wouldn't have let [CSS] out of the labs in its current state, unless
an important customer had an urgent need and we chose to hold their hand
while they deployed it.

The hardest thing for me to adapt to was that it was insufficient to
read & understand the specification & follow it & validate & check with
a couple of significantly-different browsers. Some other browser,
perhaps running on a platform I don't have access to for testing
purpose, would trip me up.

It sounds to me that it's not CSS that shouldn't have been let out of the
labs, but the browsers.

 

[Barry Pearson]

We wouldn't have let [CSS] out of the labs in its current state,
unless an important customer had an urgent need and we chose to hold
their hand while they deployed it.

The hardest thing for me to adapt to was that it was insufficient to
read & understand the specification & follow it & validate & check
with a couple of significantly-different browsers. Some other
browser, perhaps running on a platform I don't have access to for
testing purpose, would trip me up.

It sounds to me that it's not CSS that shouldn't have been let out of
the labs, but the browsers.

You changed that to "[CSS]". What I said was:

"... the release & rollout strategies of combinations of products for building
systems. The immaturity of CSS-positioning came as a bit of a surprise when I
tried to use it. We wouldn't have let it out of the labs in its current state
...."

I was talking about "CSS-positioning", especially in the context of
"combinations of products for building systems".

So, yes, I was talking about the tools (authoring tools & user agents) as well
as the specification, documentation, and training, etc.

But I wasn't talking about "CSS" in the sense of all aspects of CSS - just
CSS-positioning.