Where Is It Written That I Should Use CSS Positioning?

[Jack Hughes]

This argument has come up two or three times lately.

We have a web standards document at our company that say "Use valid
HTML 4; We don't recommend switching to DIV-based CSS-P for layout
just yet though, tables are a lot easier."

That's because we have a lot of developers who aren't ready to move to
CSS-P and DIVs just yet.

But I'm being told our policies were contradictory. If we're going to
use standards, then we should use CSS positioning not TABLE code.

But we _are_ using standards! We're using valid HTML with a DOCTYPE
and everything. We don't use the FONT tag (though even _that_ is still
valid in Transitional HTML, did you notice?) and all the formatting,
all the backgrounds and colors and images and fonts are in the style
sheet, not in the page.

What, after all, is the real difference between

-------- ------------------------ --------
| TD | | TD | | TD |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
-------- ------------------------ --------

and

-------- ------------------------ --------
| DIV | | DIV | | DIV |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
-------- ------------------------ --------

anyway? The content comes in the same order in the page, and if I
include a "skip to content" link that takes people to the centre TD,
who have I hurt?

Tables should only be used for Tabular content, I hear you say --
well, isn't the traditional layout tabular, in a way? A column of nav,
a column of content, a column of whatever on the right. They're in
three different categories. Are tables really only to be used for
statistics on the consumption of cabbage in East Berlin from 1993 to
1994?

I forgot my original question -- oh yeah, where is it written,
actually literally where in the W3 website or the spec is it written
that I must use CSS-P now or my code isn't using standards?

Because the woman who I was arguing with eventually just said "well,
you're going against the SPIRIT of it" and I said "I don't have a
Spirit Validator, just an HTML Validator".

Joking aside, what document _should_ my opponent have pointed me to -
where is "Thou Shalt Use CSS-P" written, who decreed it - or is it
just a cultural assumption made by modern web developers, a sibboleth?

[Brian]

Jack Hughes wrote:

This argument has come up two or three times lately.
Actually, in ciwah, it has come up far more than just two or three
times. Shame you didn't read those threads.
We have a web standards document at our company that say "Use valid
HTML 4;
That's suprising. Most companies are unaware of anything relating to
good authoring practices. May I ask which company this is?
We don't recommend switching to DIV-based CSS-P for layout just yet
though, tables are a lot easier."
I don't think tables are easier, but css positioning is not for the
faint of heart. Even if there were no bugs, it'd be hard, and there
are bugs, lots of them.
But I'm being told our policies were contradictory. If we're going
to use standards, then we should use CSS positioning not TABLE
code.
As of 2004, CSS is the proper tool for presentation of web documents.
HTML was never intended as a desktop publishing language. Efforts to
hammer it into one, especially via HTML 3.2, failed, leaving us with
transitional HTML for "legacy documents" and CSS for a more sensible
approach.
But we _are_ using standards! We're using valid HTML with a DOCTYPE
and everything.
Someone is confused. It's either you, or whoever told you this. An
HTML document is valid if and only if it conforms to the syntax of a
particular doc type definition. Since tables are part of several HTML
versions, any document which uses tables for any reason will validate.
What, after all, is the real difference between

-------- ------------------------ --------
| TD | | TD | | TD |
-------- ------------------------ --------
This markup claims there is tabular data in one row, and that each bit
of data is related to the other bits in some way. Therefore,
user-agents must present the data in such a way that the data makes
sense. In the ascii art example you provided, the ua has chosen a
logical presentation of a table, with the columns presented
side-by-side, as one might find in a book.
and

-------- ------------------------ --------
| DIV | | DIV | | DIV |
-------- ------------------------ --------
A div element should contain some division of content; beyond that,
div elements are semantically meaningless. Thus, the contents of a div
element are not necessarily related to the contents of another, even
where such div elements are presented, via CSS, side-by-side, as in
your second ascii art example.
The content comes in the same order in the page,
A table layout where the content "linearizes" is the less wrong way to
do things. Not abusing tables for layout is the right way to do things.
if I include a "skip to content" link that takes people to the
centre TD, who have I hurt?
Your mixing up several different issues. A "skip to content" link is
not related to table layouts, nor to validation.
Tables should only be used for Tabular content, I hear you say --
Does this mean you *did* read those other threads? If so, why did you
feel the need to start yet another go-round?
well, isn't the traditional layout tabular, in a way? A column of
nav, a column of content, a column of whatever on the right.
Who says that layout is traditional? What makes a layout traditional?
Perhaps you mean it is popular at the moment? That may be true, but it
is also subject to change.

In any case, it is not a table merely because it is laid out with some
bits next to other bits. A magazine article may have a sidebar with a
short, related article. The presentation of the sidebard is not a
table. It is layout where the related article is presented in a column
next to the main article. One might also choose to present the short,
related article at the bottom of the page, or on the next page. This
does not affect reader comprehension.

A table, by contrast, must be presented in some way that allows the
reader to make sense of the data. One cannot remove one column from a
table, move it to the next page, and expect readers to make sense of it.
Are tables really only to be used for statistics on the consumption
of cabbage in East Berlin from 1993 to 1994?
Of course not. They're also to be used for presenting sales of Lee
Perry cds in London; pollution levels in Mexico City; films produced
in India, France, and the U.S.; etc.
where is it written, actually literally where in the W3 website
or the spec is it written that I must use CSS-P now or my code
isn't using standards?
In the HTML 4 recommendation, of course.

http://www.w3.org/TR/html4/struct/tables.html

See the first section, "introduction to tables."
the woman who I was arguing with eventually just said "well, you're
going against the SPIRIT of it"
Abusing tables for their presentation is a violation of HTML...
and I said "I don't have a Spirit Validator, just an HTML
Validator".

....but such abuse of tables does not violate the syntax of the
language. The best article I've read on this topic is from J. Korpela:

http://www.cs.tut.fi/~jkorpela/html/validation.html
B. Pearson will be along shortly to try his best to confuse you with a
rant about the so-called history of html.

Good luck.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Markus Ernst]

"Jack Hughes" <ja********@yahoo.com> schrieb im Newsbeitrag
news:f4*************************@posting.google.co m...

This argument has come up two or three times lately.
[...]
I forgot my original question -- oh yeah, where is it written,
actually literally where in the W3 website or the spec is it written
that I must use CSS-P now or my code isn't using standards?

Äh - if you know the arguments, why do you ask again? You are free to use
whatever coding technique you feel comfortable with. You don't need the ok
of ciwah/ciwas regulars, do you?

This is neither about a "must" nor about religion, it is just essential to
know how things are intended to be by the people who developed them, and it
is great to know good arguments for and also against doing thins this or
that way. It just makes you free to decide which way you go and also it
gives you the ability to discuss this with your bosses, clients and
co-workers. So knowing about those issues makes you a professional. But it
is not necessary that you agree with all that is written here nor is it
necessary that anybody else agrees with your point of view.

--
Markus

[Andy Dingley]

ja********@yahoo.com (Jack Hughes) wrote in message news:<f4*************************@posting.google.c om>...

where is "Thou Shalt Use CSS-P" written

c.i.w.a.h

By a bunch of pinheads who only have the brains for one bandwagon, so
when they've jumped onto it, they can't accept any value in any other
way of doing it.

Understand what you're doing. Then make appropriate choices.

Blanket application of CSS everywhere is probably slightly better than
an equally consistent use of 1x1.gif, but neither is as good as doing
the right things, as circumstance demands.

Three column layout in CSS sucks, because float is dubious and so is
width or margin:auto. Go for the three column table, because it's
good, it's simple and it works. OTOH, a 5 column table because you
don't understand margins or padding isn't good.

If you work on authoring for mobile devices, you'll start to really
see benefits from dumping table-bloat.


We sometimes forget just how clued-up the readers of c.i.w.a.h are -
even the idiots. You'll be flamed hereabouts for the most trivial of
errors, yet out in the big world of corporate site building the level
of technical expertise and practice is still pitiful. I've got a
problem at the moment where I feed content form <corporate #1> to
<corporate #2> and they're cheefully stripping ampersand entities and
all sorts from the content, then wondering why I complain that it's no
longer valid HTML - "But it looks OK in my browser" they whine.

[Karl Groves]

"Jack Hughes" <ja********@yahoo.com> wrote in message
news:f4*************************@posting.google.co m...

What, after all, is the real difference between

-------- ------------------------ --------
| TD | | TD | | TD |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
-------- ------------------------ --------

and

-------- ------------------------ --------
| DIV | | DIV | | DIV |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
-------- ------------------------ --------

Actually, the comparison is

<table>
<tr>
<td></td><td></td><td></td>
</tr>
</table>

and

<div></div><div></div><div></div>

And when you get down to it, I'm 100% positive that your table is much more
complicated than that whereas the <div> based layout is not.

Making The Business Case For Web Standards
http://www.karlcore.com/articles/article.php?id=23

Karl

[Barry Pearson]

Jack Hughes wrote:

This argument has come up two or three times lately. [snip] I forgot my original question -- oh yeah, where is it written,
actually literally where in the W3 website or the spec is it written
that I must use CSS-P now or my code isn't using standards? [snip] Joking aside, what document _should_ my opponent have pointed me to -
where is "Thou Shalt Use CSS-P" written, who decreed it - or is it
just a cultural assumption made by modern web developers, a sibboleth?

The short answer to your question is "nowhere important". I believe that the
objectives are getting forgotten.

When designing "infrastructure", such as an operating system, or application
middleware, or the set of recommendations for the web, you had better design
it so that people using it can separate out lots of concerns. It is a good
idea to have a web where authors, and users, can handle different issues, in
different places, with different recommendations & technologies.

But that it not a requirement that those people actually *use* all those
different things in that way. That is up to them, or the people they are
answerable to. Or perhaps the law influences the decision.

The purpose of a web site is to communicate with the audience. The techniques
used must be evaluated against that purpose. Do layout tables hinder the
communication, perhaps because of the user's technology? Or do they help, by
enabling the author to build an effective site faster? Do layout tables make
the pages inefficient? Will they prevent important change needed for future
communication? These questions can be answered.

Experts should be able to assist with the analysis. A problem is that some
people opposed to layout tables appear to believe their own propaganda! Here
are some example:

"Layout tables make pages bloated & inefficient". Do the sums. They add
perhaps about 25 bytes per item being positioned. So, using them to achieve 3
columns may add about 75 bytes to the page. (*Bad* layout tables can be
dreadful! So can bad anything).

"Layout tables make your pages inaccessible". The Web Accessibility Initiative
came to a different conclusion in April 1999, and this is no longer a useful
assumption. (The key is whether they linearise well. In fact, the
linearisation of tableless pages is also important).

"Layout table freeze your layout as it is". I've seen it said that if you use
a layout table to put your site navigation on the right, you are stuck with it
on the right. But here is a page that uses a simple layout table to put the
site navigation table on the right:
http://www.childsupportanalysis.co.uk/
And here is that page, with the same table, and just 2 additional CSS rules
(embedded in the <head>). They put the site navigation on the left. No tricks,
no script, just valid HTML 4.01 Strict & CSS2:
http://www.childsupportanalysis.co.uk/reversed.htm

A better approach to this topic would be to be more objective, to help authors
answer their questions. If an author decides to go ahead with a layout table,
then how can the author use a good layout table, not a bad one? (You are
unlikely to be able to change the page layout significantly if you start with
a bad layout table).

It's only mark-up. It isn't sin!

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Shawn K. Quinn]

Jack Hughes wrote:

This argument has come up two or three times lately.

We have a web standards document at our company that say "Use valid
HTML 4; We don't recommend switching to DIV-based CSS-P for layout
just yet though, tables are a lot easier."
If your content actually *is* a table, as in something you could caption as
"Table 1" in a book, then yes, keep it in a table. Otherwise, it's abuse of
table markup.
That's because we have a lot of developers who aren't ready to move to
CSS-P and DIVs just yet.

But I'm being told our policies were contradictory. If we're going to
use standards, then we should use CSS positioning not TABLE code.
That's correct.
But we _are_ using standards! We're using valid HTML with a DOCTYPE
and everything. We don't use the FONT tag (though even _that_ is still
valid in Transitional HTML, did you notice?) and all the formatting,
all the backgrounds and colors and images and fonts are in the style
sheet, not in the page.
Misusing <table> for a layout grid is just as unacceptable as misusing
<blockquote> as an "indent text command".
What, after all, is the real difference between

-------- ------------------------ --------
| TD | | TD | | TD | [snip] and

-------- ------------------------ --------
| DIV | | DIV | | DIV | [snip] anyway? The content comes in the same order in the page, and if I
include a "skip to content" link that takes people to the centre TD,
who have I hurt?
The former is structurally inaccurate. Some browsing situations may also
need to handle tables differently from running text and text enclosed in
<div>. Your layout box disguised as <table> may well be treated like an
actual data table, even if you do not intend that.
Tables should only be used for Tabular content, I hear you say --
well, isn't the traditional layout tabular, in a way?
No, the structure of content doesn't change just because you want the page
layout to be a certain way.
I forgot my original question -- oh yeah, where is it written, actually
literally where in the W3 website or the spec is it written that I must
use CSS-P now or my code isn't using standards?

http://www.w3.org/TR/html401/struct/tables.html#h-11.1

"Tables should not be used purely as a means to layout document content as
this may present problems when rendering to non-visual media. Additionally,
when used with graphics, these tables may force users to scroll
horizontally to view a table designed on a system with a larger display. To
minimize these problems, authors should use style sheets to control layout
rather than tables."

(The word "control" probably should have been "suggest" here.)

--
Shawn K. Quinn

[Neal]

On 14 Jun 2004 21:52:02 -0700, Jack Hughes <ja********@yahoo.com> wrote:

The content comes in the same order in the page

Actually, no. With table layout I must have the left column, then the
center, then the right. With CSS layout I can make the page degrade to ANY
order.

[Alan J. Flavell]

On Tue, 15 Jun 2004, Shawn K. Quinn wrote:

(The word "control" probably should have been "suggest" here.)

"Propose" is perhaps a more neutral - and hence more generally
acceptable - term for it.

Anyway, why all this fuss about "positioning"? For most purposes, a
bit of flexible sizing and judicious floating works well across a
range of browsers, and does little harm irrespective of whether it's
actioned or not.

Some of the attempts I've seen to position lumps of stuff out of the
flow, however, have failed miserably in real-world situations - all
too often resulting in substantive content getting hidden behind some
insignificant navigation menu or similar. In web page design, often
enough, "less can be more" if the right choices are made. No, I'm not
a graphic designer, don't look to me for demonstrations, but I know
what I've seen.

[Barry Pearson]

Neal wrote:

On 14 Jun 2004 21:52:02 -0700, Jack Hughes <ja********@yahoo.com>
wrote:

The content comes in the same order in the page

Actually, no. With table layout I must have the left column, then the
center, then the right. With CSS layout I can make the page degrade
to ANY order.

Not true (about the tables). There are various ways, for example using CSS2,
or the "table trick", of having content order different from visual order.

And with CSS layout, things can sometimes get restricted. For example, if I
want a footer below the rest of the content, I would typically use floats, not
absolute positioning. And then I have to put things into the content in the
right order to get the floats to work. (This is especially a problem if one of
the columns is "remaining-width", because of a flexible-width layout, and
can't be floated).

With both techniques, once the content gets at all complicated, the wrapping &
nesting & sequencing of the top-level elements of the document tree become
important. In that sense, a table is "stereotyped wrapping & nesting".

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Brian]

Andy Dingley wrote:

ja********@yahoo.com (Jack Hughes) wrote

where is "Thou Shalt Use CSS-P" written

c.i.w.a.h

By a bunch of pinheads who only have the brains for one bandwagon

And since you're here, I suppose I can include you among the pinheads?

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Christoph Paeper]

*Neal* <ne*****@yahoo.com>:

On 14 Jun 2004 21:52:02 -0700, Jack Hughes <ja********@yahoo.com> wrote:

The content comes in the same order in the page

Actually, no. With table layout I must have the left column, then the
center, then the right. With CSS layout I can make the page degrade to ANY
order.

That point is void, because you can also use

table#layout,
table#layout>*, table#layout>tr>*, /* line can be left out if not XHTML */
table#layout>*>tr, table#layout>*>tr>* {
display: block;
}

in combination with any CSS you would apply to 'div's or other, more
appropriate elements.

Especially for media="handheld" something based on this can make a lot of
sense, despite the table being abused for layout or not.

--
»Das Schwierige am Diskutieren ist nicht, den eigenen Standpunkt zu verteidigen,
sondern ihn zu kennen.«
Andre Maurois

[Jack Hughes]

Thank you all for your contributions.

I don't normally haunt c.i.w.a.s. so I was unprepared for the cries of
"why start this again?" and "read the FAQ" and the infighting. But,
that's cool.

I asked, in a longwinded way, a very simple question, roughly:

Where is it written down that I shouldn't use tables?
Which exact document?"

and I got the answer, which is:

http://www.w3.org/TR/html4/struct/tables.html

where it says:

Tables should not be used purely as a means to layout document
content as this may present problems when rendering to non-visual
media.

which offends me rather, but only because "layout" isn't one word when
used as a verb.

The funny thing of course is that none of the people telling me I was
an unrepentant TABLE-using sinner could quote that chapter and verse.
They all proceeded on the basis that "everyone knows".

So the even-shorter answer is, "it's a W3 recommendation for HTML 4".

[Sherm Pendley]

Jack Hughes wrote:

which offends me rather, but only because "layout" isn't one word when
used as a verb.

You'll be offended alot on usenet then. ;-)

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

[Barry Pearson]

Jack Hughes wrote:
[snip]

I asked, in a longwinded way, a very simple question, roughly:

Where is it written down that I shouldn't use tables?
Which exact document?"

and I got the answer, which is:

http://www.w3.org/TR/html4/struct/tables.html

where it says:

Tables should not be used purely as a means to layout document
content as this may present problems when rendering to non-visual
media. [snip] So the even-shorter answer is, "it's a W3 recommendation for HTML 4".

The above statement was based on the state of the art in December 1997. (And
note that it *preceded* the CSS recommendation that introduced positioning!)

In 1998, IBM announced its Home Page Reader, which was a speaking browser
rather than a screen reader, and raised the quality of rendering of tables to
blind people. In April 1999, the W3C's Web Accessibility Initiative reviewed
its advice, and since then has added a qualification about the need for a
table to linearise.

There has been plenty written about the topic of building accessible web sites
since 1997, and you don't need to rely on an old statement based on old
technology.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Chris Morris]

"Barry Pearson" <ne**@childsupportanalysis.co.uk> writes:

In 1998, IBM announced its Home Page Reader, which was a speaking browser
rather than a screen reader, and raised the quality of rendering of tables to
blind people. In April 1999, the W3C's Web Accessibility Initiative reviewed
its advice, and since then has added a qualification about the need for a
table to linearise.

It's *not* speech browsers/screen readers that have the most problems
with table layouts, though. Provided that they linearise sensibly,
obviously.

Where the problems come is with narrow-width visual browsers that
support tables. w3m, links in text-mode, openwave, etc.

Openwave is a fairly commonly used mobile-phone rendering
engine. There's an emulator available for download [1]. It does not
like table layouts. For example, the old, but generally still usable
table layout at http://www.dur.ac.uk/ works in most browsers
reasonably well. In Openwave, the actual text gets compressed into
columns about 2 letters wide. It's basically unusable. Images of text
tend to get shrunk to far smaller than they need to be too. The CSS
based layout at http://www.dur.ac.uk/its/ works far better.

Openwave doesn't support horizontal scroll at all. w3m and links
do. Table layouts tend to go past their usual 80-character
limit. Horizontal scrolling in text browsers is not well
implemented. Again, very difficult to use. In certain situations, it's
possible to miss the fact that the right side of the page exists; more
commonly, with a 3-column table layout, the middle column will never
all be visible at once.

[1] http://developer.openwave.com/

--
Chris

[Keith Bowes]

Jack Hughes wrote:

We have a web standards document at our company that say "Use valid
HTML 4; We don't recommend switching to DIV-based CSS-P for layout
just yet though, tables are a lot easier."
Perhaps tables are easier (though I think tables are annoying,
especially if you follow WCAG), but I don't see the similarity. CSS-P
is for positioning elements, but tables are for tabular data. An easier
solution and one that's more accessible for text browsers than table
abuse: CSS floats.

But we _are_ using standards! We're using valid HTML with a DOCTYPE
and everything. We don't use the FONT tag (though even _that_ is still
valid in Transitional HTML, did you notice?) and all the formatting,
all the backgrounds and colors and images and fonts are in the style
sheet, not in the page.
Well, not using tables for layout is more of an accessibility than
standards-compliance issue. But about Transitional HTML, that was
designed for transitioning from HTML 3.2 to HTML 4.0 for browsers with
buggy CSS support seven years ago; I have all confidence that the
situation has improved a great deal (using CSS-P at all in 1997 was for
best-viewed-with sites only).

Tables should only be used for Tabular content, I hear you say --
well, isn't the traditional layout tabular, in a way?
No, it isn't. It's in columns, but there's no correlation of the data
between the columns. It may have a couple similarities, but the
attributes that make a table are absent.

I forgot my original question -- oh yeah, where is it written,
actually literally where in the W3 website or the spec is it written
that I must use CSS-P now or my code isn't using standards?
The HTML 4 spec, the CSS specs, the accessibility guidelines specs, etc
all reference that using markup for layout or presentation is best avoided.

Because the woman who I was arguing with eventually just said "well,
you're going against the SPIRIT of it" and I said "I don't have a
Spirit Validator, just an HTML Validator".

She was right. Validators can only check a document against the formal
syntax of a DTD. To produce a truly standards-compliant document, you
have to be aware of the standards-based ideology: HTML for semantics,
CSS for presentation, JavaScript only when necessary, plug-ins never.

[Chris Morris]

Keith Bowes <do****@spam.me> writes:

She was right. Validators can only check a document against the
formal syntax of a DTD. To produce a truly standards-compliant
document, you have to be aware of the standards-based ideology: HTML
for semantics, CSS for presentation, JavaScript only when necessary,
plug-ins never.

Mostly agreed, but:

There's nothing intrinsically wrong with the use of Javascript or
plug-ins provided that there's a way to get at the content (or as much
of the content as is possible [1]) without them, and provided that
when JS is enabled / the plugin is available the thing used in this
way operates accessibly.

[1] If you have a plugin that allows the display of user-rotatable 3D
objects, duplicating all of this just with HTML is impossible. But
some images (with appropriate alt text) showing the object from
important angles would be a good fallback.

--
Chris

[Barry Pearson]

Keith Bowes wrote:

Jack Hughes wrote: [sni]

Tables should only be used for Tabular content, I hear you say --
well, isn't the traditional layout tabular, in a way?

Yes. Tabular data is what is found in tables. It becomes tabular data the
instant you put it into a table. It was not tabular data before that instant.

(Unless you have an agenda to try to stop people using tables for what they
intended for - laying out material, possibly complex, in rows & columns. Then
you will eventually find, or invent, a definition to support your position).
No, it isn't. It's in columns, but there's no correlation of the data
between the columns. It may have a couple similarities, but the
attributes that make a table are absent.

[snip]

There is no consensus that tabular data has to such have correlation of data.
Some people claim that it is part of the definition, while other definitions
don't include that. The W3C recommendations for HTML don't appear to state the
requirement of correlation of data. I am not aware of a W3C definition of
tabular data, although there is so much material on their site that I'm sure
someone will have done so, probably informally rather than as part of a
recommendation.

Here are some definitions of "data". "Data" does not have the narrow meaning
that some here appear to think it has.
http://thesaurus.reference.com/search?q=data
http://www.techweb.com/encyclopedia/...term?term=data
http://www.thefreedictionary.com/data
http://www.yourdictionary.com/ahd/d/d0035100.html

Here are some definitions of "tabular":
http://www.yourdictionary.com/ahd/t/t0005800.html
http://thesaurus.reference.com/search?q=tabular
http://www.thefreedictionary.com/tabular

The only result I can get from this is something like "machine-processable
information arranged in rows & columns". But I guess 100s of other definitions
are possible. It simply isn't sensible to get hung up on real-world
definitions. It is better simply to look at the recommendations. What
constraints does the HTML recommendation make about what is valid table
mark-up? What do browsers support? (What else is relevant?)

Now, if it had been called <array>, I would have had a different view!

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Chris Morris]

"Barry Pearson" <ne**@childsupportanalysis.co.uk> writes:

Keith Bowes wrote:

Jack Hughes wrote: [sni]

Tables should only be used for Tabular content, I hear you say --
well, isn't the traditional layout tabular, in a way?
Yes. Tabular data is what is found in tables. It becomes tabular data the
instant you put it into a table. It was not tabular data before that instant.

Into a 'table', yes. Into a '<table>', no.

The below is tabular data whether it's done in HTML with <table>,
<pre>, or stylesheet positioning.

A B C
30 20 10
15 45 17
0 35 19

The following isn't tabular data whether it's formatted in HTML with
<table>, <pre>, or stylesheet positioning.

Lorem ipsum Some more text here in a different bit
whatever it that isn't in latin or any approximation
is ........ to it.
No, it isn't. It's in columns, but there's no correlation of the data
between the columns. It may have a couple similarities, but the
attributes that make a table are absent.

[snip]

There is no consensus that tabular data has to such have correlation
of data.

The only result I can get from this is something like
"machine-processable information arranged in rows & columns". But I
guess 100s of other definitions are possible. It simply isn't
sensible to get hung up on real-world definitions.
True, because otherwise you'd be suggesting that <span> was the
appropriate markup for documents about bridges and hands.
It is better simply to look at the recommendations. What
constraints does the HTML recommendation make about what is valid table
mark-up?
http://www.w3.org/TR/html401/struct/tables.html
Subsection 1:
"Tables should not be used purely as a means to layout document
content as this may present problems when rendering to non-visual
media. Additionally, when used with graphics, these tables may force
users to scroll horizontally to view a table designed on a system with
a larger display."

The first part is less of a problem if it linearises, the second part
is a problem even then. Even without graphics it can be a problem.
What do browsers support? (What else is relevant?)
Most browsers support tables. They obviously don't care what you put
into each cell, because that would require understanding the meaning
of the content (semi-)independently of the markup.
Now, if it had been called <array>, I would have had a different view!

Why?

--
Chris

[Brian]

Barry Pearson wrote:

Jack Hughes wrote:

http://www.w3.org/TR/html4/struct/tables.html

Tables should not be used purely as a means to layout
document content as this may present problems when
rendering to non-visual media.

There has been plenty written about the topic of building
accessible web sites since 1997,

But nothing to supercede HTML 4, which is rather unambiguous on the
matter. Except to you, of course. There seems to be no end to the
mental gymnastics you're willing to do to reach the opposite conclusion.
and you don't need to rely on an old statement based on old
technology.

HTML 4 is the most recent HTML recommendation.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Brian]

Barry Pearson wrote:

Tabular data is what is found in tables. It becomes tabular data
the instant you put it into a table. It was not tabular data before
that instant.
A classic case of begging the question.
(Unless you have an agenda to try to stop people using tables for
what they intended for
For data, of course. That's why we have <TD> for table *data*.
Now, if it had been called <array>, I would have had a different
view!

array != table

Ok, I've fed the troll enough for today.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Barry Pearson]

Chris Morris wrote:

"Barry Pearson" <ne**@childsupportanalysis.co.uk> writes: [snip]

Yes. Tabular data is what is found in tables. It becomes tabular
data the instant you put it into a table. It was not tabular data
before that instant.

Into a 'table', yes. Into a '<table>', no.

Yes to both. Remember just what you can put into a table cell. Approximately
anything that you can put into the body of a document. (I don't know what
differences there are between them in the specification). That applied pretty
well from the start, and apparently will still apply with XHTML 2.0. Attempts
to constrict the specification are typically artificial and somewhat abitrary
ones, apparently designed to browbeat people into not using layout tables.

If you try to distinguish between HTML tables & others, (and why not, since
they are somewhat different?), then it becomes much harder to find a
definition of what can't go into <table>. Obviously, it then has to be part of
an HTML definition. And, as far as I can tell, the HTML recommendations have
not gone that far.
The below is tabular data whether it's done in HTML with <table>,
<pre>, or stylesheet positioning. [snip] The following isn't tabular data whether it's formatted in HTML with
<table>, <pre>, or stylesheet positioning.

That is simply your *opinion*, and that of some other people. There is *not* a
consensus, even though some anti-layout-table people wish there were. And some
other definitions don't make sense either.

There is a definition going around about "such as you'd find in a
spreadsheet". Now I have been writing and using lots of spreadsheets for many
years, and find all sorts of arrangements in spreadsheets. Sometimes they are
just ways of doing very complicated sums based on several input parameeters.
Sometimes they *do* indeed have semantically related data, but in those cases,
the cells tend to have formulae in them. There are a couple of mine at the
following:
http://www.childsupportanalysis.co.u...alculators.htm

I understand *your* definition. But there are others. And there is no W3C
definition of tabular data that I am aware of. However many times you and
others quote that out-of-date statement about layout tables, it does not add
to the definition of tabular data. The definitions outside the recommendations
appear to be whatever is useful or convenient for whoever is defining them.

[snip]

It is better simply to look at the recommendations. What
constraints does the HTML recommendation make about what is valid
table mark-up?

http://www.w3.org/TR/html401/struct/tables.html
Subsection 1:
"Tables should not be used purely as a means to layout document
content as this may present problems when rendering to non-visual
media. Additionally, when used with graphics, these tables may force
users to scroll horizontally to view a table designed on a system with
a larger display."

The first part is less of a problem if it linearises, the second part
is a problem even then. Even without graphics it can be a problem.

I had someone criticise one of my thumbnail galleries using what appeared to
be a screen-shot or similar image of what appeared to be a text-only phone.
How seriously do you think I took it? Conversely, I test my pages using Opera
small screen mode, and find that it does a pretty good job, with both
linearised tables, and images. The technique for disabling tables is so simple
that my guess is that it will be common in future.

If someone's concern is to warn authors of their need to evaluate the impact
on their audience of what some technologies do with tables, that is fine.
Explain it, then let the author decide. The decision lies with the author and
publisher, absed on their audience. And if it is an accessibility issue,
courts can decide. There is no justification for others to do anything other
than provide sufficient information for the author to decide.

A recent report in the UK about accessibility problems of web sites didn't
identify any instances caused by layout tables. But will that stop people
criticising layout tables? Of course not! Nothing will - it is a holy war, not
an objective discussion about consequences.

[snip]

Now, if it had been called <array>, I would have had a different
view!

Why?

Because I am familiar with the use of arrays in programming, and the manner in
which (for example) processing may be performed in a loop, indexing along the
dimensions of the array. If you are doing the same bit of processing on
somearray(i, 3) as on somearray(i, 4), etc, then there must be a similarity
between them. They are designed for the purpose. Arrays in programming often
come in more than 2 dimensions, and normally don't have names such as "row" &
column" that are clearly to do with laying things out horizontally &
vertically.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Chris Morris]

"Barry Pearson" <ne**@childsupportanalysis.co.uk> writes:

Chris Morris wrote:

"Barry Pearson" <ne**@childsupportanalysis.co.uk> writes: [snip]

http://www.w3.org/TR/html401/struct/tables.html
Subsection 1:
"Tables should not be used purely as a means to layout document
content as this may present problems when rendering to non-visual
media. Additionally, when used with graphics, these tables may force
users to scroll horizontally to view a table designed on a system with
a larger display."

The first part is less of a problem if it linearises, the second part
is a problem even then. Even without graphics it can be a problem.

I had someone criticise one of my thumbnail galleries using what
appeared to be a screen-shot or similar image of what appeared to be
a text-only phone. How seriously do you think I took it?

I'm going to guess "not very". Fine. It's a thumbnail gallery, it's
obviously not suited to small screen or text-only rendering. However,
most sites do not have anything inherent in the (majority of the)
content that should stop them displaying on a small screen.
Conversely, I test my pages using Opera small screen mode, and find
that it does a pretty good job, with both linearised tables, and
images. The technique for disabling tables is so simple that my
guess is that it will be common in future.
It's not a question of 'technique for disabling tables' - which is as
simple as writing a browser that doesn't understand <table>, etc. The
problem is with browsers that do understand them - it *is* useful in
w3m and links to have data tables laid out in columns as opposed to
the lynx way of just interpreting </td><td> as ' ' and <tr> as newline
- so disabling tables loses a lot of tabular data.

Now, it'd be great if w3m or links linearised layout tables and kept
data tables intact. But I don't see how they can tell the difference.

What Opera's small screen mode does a very bad job of is data tables,
even simple ones, because it simply space-separates <td>s and
newline-separates <tr>s as does Lynx. Which means that if the data can
include spaces you get ambiguity.
If someone's concern is to warn authors of their need to evaluate the impact
on their audience of what some technologies do with tables, that is fine.
Explain it, then let the author decide. The decision lies with the author and
publisher, absed on their audience. And if it is an accessibility issue,
courts can decide. There is no justification for others to do anything other
than provide sufficient information for the author to decide.
'Based on their audience'? I had no idea that these mobile phone UAs
even existed until I saw their UA strings in an access log. The
audience was not defined by their browser technology. Perhaps for your
'high-resolution photography' sites it is, but that's the exception
rather than the rule, IMO.
A recent report in the UK about accessibility problems of web sites
didn't identify any instances caused by layout tables.
That's because the accessibility report focused solely on
disabilities, and table layout - provided it linearises - isn't
usually a problem with modern assistive technologies. I prefer to take
a wider view that if a site doesn't work well on a particular
(reasonably standards-compliant) browser, that's also inaccessible,
even if the user has no disabilities.

Now, if it had been called <array>, I would have had a different
view!

Why?

Because I am familiar with the use of arrays in programming, and the
manner in which (for example) processing may be performed in a loop,
indexing along the dimensions of the array. If you are doing the
same bit of processing on somearray(i, 3) as on somearray(i, 4),
etc, then there must be a similarity between them. They are designed
for the purpose.
Arrays in programming often come in more than 2 dimensions, and

Well, most display media only have two dimensions if that.
normally don't have names such as "row" & column" that are clearly
to do with laying things out horizontally & vertically.

I'm familiar with the term 'table' from printed documents.
"See Table 1 for foo" - the common use in any other medium of 'table'
is for a data table. I would never describe the layout (in rows and
columns) of a newspaper page as 'tabular data', even though it could be
duplicated using <table>.

In every other visual display medium, table means data table. Now, I
know the web is not print, or TV, or whatever. But we don't suddenly
invent new meanings for paragraph, or emphasis, or list, just because
it's on the web.

--
Chris

[Barry Pearson]

Brian wrote:

Barry Pearson wrote: [snip]

(Unless you have an agenda to try to stop people using tables for
what they intended for

Which is, of course, for laying out material, sometimes complex , in rows &
columns. Which is, of course, why "rows" and "columns", (or abbreviations of
them), appear in the names of the elements.
For data, of course. That's why we have <TD> for table *data*.

[snip]

Here are some definitions of "data". "Data" does not have the narrow meaning
that you appear to think it has:

http://thesaurus.reference.com/search?q=data
http://www.techweb.com/encyclopedia/...term?term=data
http://www.thefreedictionary.com/data
http://www.yourdictionary.com/ahd/d/d0035100.html

And, of course, you can go and check the W3C recommendations, and see just
what it *explicitly* allows. "The HTML table model allows authors to arrange
data -- text, preformatted text, images, links, forms, form fields, other
tables, etc. -- into rows and columns of cells". (HTML 4). Pretty well
anything!

Why are you so anxious to stop authors using layout tables? Do they threaten
the web? ("No" to that). Are they a threat to disabled people? ("No" to that).
Are they a threat to you? Are they an affront to you? Are you a control freak
who wants to stop authors doing things the easy way? (Don't answer that last
question. I hope, and I will assume unless you answer otherwise, that you are
not. But, at least think about it for a second, just in case!)

Is the following the current meaning of "should not"? (As used in the HTML 4
statement about layout tables).
"Key words for use in RFCs to Indicate Requirement Levels"
ftp://ftp.isi.edu/in-notes/rfc2119.txt

"SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that there may
exist valid reasons in particular circumstances when the particular behavior
is acceptable or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior described with
this label."

Note that "the full implications should be understood and the case carefully
weighed" is precisely what I have been saying on this topic for months.
Understand & evaluate the consequences with respect to the objectives of your
web site, to communicate with the audience, in the context of the law & other
relevant factors, then make the decision and accept the consequences. And note
that this phrase does *not* prohibit this particular use. That would need
"MUST NOT". HTML 4 & HTML 4.01 have *never* prohibited the use of layout
tables. Never.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Chris Morris]

"Barry Pearson" <ne**@childsupportanalysis.co.uk> writes:

Here are some definitions of "data". "Data" does not have the narrow meaning
that you appear to think it has:
'Table' can mean many different things too. However, the meaning of
table that means 'horizontal surface on legs raised off the ground'
isn't particularly relevant.
And, of course, you can go and check the W3C recommendations, and see just
what it *explicitly* allows. "The HTML table model allows authors to arrange
data -- text, preformatted text, images, links, forms, form fields, other
tables, etc. -- into rows and columns of cells". (HTML 4). Pretty well
anything!
All of those things could legitimately be in a data table,
though. Nested tables is one I haven't seen an example of in data
tables, though.
Is the following the current meaning of "should not"? (As used in the HTML 4
statement about layout tables).
[RFC 'SHOULD NOT']
Seems reasonable.
HTML 4 & HTML 4.01 have *never* prohibited the use of layout
tables. Never.

No. HTML 4 doesn't prohibit <body bgcolor='#000000' text='#000000'>
either. It probably has a 'should choose colours with sufficient
contrast' somewhere. Nowhere does it say you MUST NOT do something
like that.

It's intended, I think, to be a fairly flexible specification. Best
practice at implementing pages within it is a different matter. With
the rise of narrow-width browsers, and the rise of mainstream browsers
that support CSS fairly well (even IE 6 is adequate for most
purposes), I see no reason to use layout tables for anything other
than exceptional cases [1].

Hmm. I possibly also take a different view of RFC-style 'SHOULD NOT'
to you. I view it as 'MUST NOT, *unless* it's absolutely essential', I
think you view it as slightly more permissive than that.

[1] On the other hand, given that in *most* current browsers they
aren't a problem, I wouldn't advocate replacing them on old pages for
the sake of it - save it for the next time the site was getting a new
look anyway.

--
Chris

[Barry Pearson]

Brian wrote:

Barry Pearson wrote:

Jack Hughes wrote:

http://www.w3.org/TR/html4/struct/tables.html

Tables should not be used purely as a means to layout
document content as this may present problems when
> rendering to non-visual media.

There has been plenty written about the topic of building
accessible web sites since 1997,

But nothing to supercede HTML 4, which is rather unambiguous on the
matter.

[snip]

Unambiguous indeed:

"SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that there may
exist valid reasons in particular circumstances when the particular behavior
is acceptable or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior described with
this label." (Not "MUST NOT").
ftp://ftp.isi.edu/in-notes/rfc2119.txt

HTML 4 & HTML 4.01 have never prohibited the use of layout tables. And neither
have either of them ever defined "tabular data"!

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[PeterMcC]

Jack Hughes wrote in
<f4*************************@posting.google.com>

It's right here on a post-it note next to my mouse mat - "Jack Hughes should
use CSS positioning" - I can send you a jpeg if you want.

I wish they were all that easy :)

--
PeterMcC
If you feel that any of the above is incorrect,
inappropriate or offensive in any way,
please ignore it and accept my apologies.

[Barry Pearson]

Chris Morris wrote:

"Barry Pearson" <ne**@childsupportanalysis.co.uk> writes: [snip]

And, of course, you can go and check the W3C recommendations, and
see just what it *explicitly* allows. "The HTML table model allows
authors to arrange data -- text, preformatted text, images, links,
forms, form fields, other tables, etc. -- into rows and columns of
cells". (HTML 4). Pretty well anything!

All of those things could legitimately be in a data table,
though. Nested tables is one I haven't seen an example of in data
tables, though.

Ah! Here is an example. A commentary of something that inclded a table:
http://www.childsupportanalysis.co.u...iament_new.htm

[snip]

HTML 4 & HTML 4.01 have *never* prohibited the use of layout
tables. Never.

No. HTML 4 doesn't prohibit <body bgcolor='#000000' text='#000000'>
either. It probably has a 'should choose colours with sufficient
contrast' somewhere. Nowhere does it say you MUST NOT do something
like that.

True. But I write HTML 4.01 Strict, which *does* prohibit those. But it
doesn't prohibit layout tables. Let's be clear. The following do not prohibit
layout tables. HTML 4.01 Strict. XHTML 1.0 Strict. XHTML 1.1. (I have tested
each of those). And they are also permitted within the current draft of XHTML
2.0.

Layout tables are in a totally different category from deprecated elements.
They are simply *not* deprecated. There is no credible proposal or programme
to make them deprecated, or to prohibit them. How can there be, when they use
a subset of the mark-up for data tables, which cannot be deprecated?

Layout tables may be criticised on emotional grounds, but not on technical or
practical grounds. They are here to stay, for decades. You might as well
object to Marks & Spencer "ready meals", because they are not real cooking! Or
"Chicken Ticka Masala" because it isn't authentically Indian. So what? You
have a right to your opinion. And everyone has the right to ignore your
opinion. You will make a key breakthrough when you recognise that, however
strongly you hold you opinions, they simply are *opinions*. No more. They are
the source of endless debates in Usenet which may never have much impact in
the real world.
It's intended, I think, to be a fairly flexible specification. Best
practice at implementing pages within it is a different matter. With
the rise of narrow-width browsers, and the rise of mainstream browsers
that support CSS fairly well (even IE 6 is adequate for most
purposes), I see no reason to use layout tables for anything other
than exceptional cases [1].
Then don't use them! Your decision. It is also your decision whether or not to
use Javascript. Or Flash. Or XHTML rather than HTML.

And every author is entitled to their own decision. I hope they won't try to
force you to use layout tables. I hope you won't try to stop anyone else using
them. Each author has a clear right to choose, and to live with the
consequences. Let's simply expose the consequences, to the best of our
abilities.
Hmm. I possibly also take a different view of RFC-style 'SHOULD NOT'
to you. I view it as 'MUST NOT, *unless* it's absolutely essential', I
think you view it as slightly more permissive than that.

[snip]

I see no need to "view" it. I just take it as it is written:

"SHOULD NOT - This phrase, ... mean that there may exist valid reasons in
particular circumstances when the particular behavior is acceptable or even
useful, but the full implications should be understood and the case carefully
weighed before implementing any behavior described with this label."
http://www.ietf.org/rfc/rfc2119.txt

Let's all just take it as written! Surely we can at least agree with what is
*written*?

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Brian]

Barry Pearson wrote:

Brian wrote:

For data, of course. That's why we have <TD> for table *data*.
Here are some definitions of "data". "Data" does not have the
narrow meaning that you appear to think it has:

http://thesaurus.reference.com/search?q=data
http://www.techweb.com/encyclopedia/...term?term=data
http://www.thefreedictionary.com/data
http://www.yourdictionary.com/ahd/d/d0035100.html

None of these shed any new light on the use of table. They do,
however, allow you to continue your delusion that you're some sort of
quasi web academic.

The point of a table is that the data in on TD has a relationship with
data in a TD in the same row, and with TD elements in the same column.
And, of course, you can go and check the W3C recommendations, and
see just what it *explicitly* allows. "The HTML table model allows
authors to arrange data -- text, preformatted text, images, links,
forms, form fields, other tables, etc. -- into rows and columns of
cells". (HTML 4). Pretty well anything!

Of course. Because anything can be tabular data. But just because
anyting *can be* tabular data doesn't mean that everything *is*
tabular data.

Wait, didn't I say I had spent enough time today feeding the troll?

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Matt Kruse]

Brian wrote:

The point of a table is that the data in on TD has a relationship with
data in a TD in the same row, and with TD elements in the same column.

"a relationship" is very vague.
A 3-column, 1-row table used for layout contains three cells of data. The
data are all related, because they are all portions of the overall content
of the page. There are no additional rows, so being related in columns
doesn't apply. Or do you want to further-define "a relationship"?

Using CSS for layout has a number of dependencies and quirks. If those can
be sucessfully worked through for the browsers which you support, then it is
excellent. If the dependencies and quirks are too difficult to work through
for the supported browsers, then table layout works great.

People who see the issue as black-and-white miss the wonderful world of
gray.

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/

[Barry Pearson]

Brian wrote:

Barry Pearson wrote: [snip]

Here are some definitions of "data". "Data" does not have the
narrow meaning that you appear to think it has:

http://thesaurus.reference.com/search?q=data
http://www.techweb.com/encyclopedia/...term?term=data
http://www.thefreedictionary.com/data
http://www.yourdictionary.com/ahd/d/d0035100.html [snip] The point of a table is that the data in on TD has a relationship with
data in a TD in the same row, and with TD elements in the same column.

No. That is simply your opinion. No more. Why do you even care? What does it
matter to you? It doesn't hurt you. It doesn't hurt the web. It doesn't hurt
disabled people. It won't be hurting the publisher. Nor the users. Nor the
shareholders.
And, of course, you can go and check the W3C recommendations, and
see just what it *explicitly* allows. "The HTML table model allows
authors to arrange data -- text, preformatted text, images, links,
forms, form fields, other tables, etc. -- into rows and columns of
cells". (HTML 4). Pretty well anything!

Of course. Because anything can be tabular data. But just because
anyting *can be* tabular data doesn't mean that everything *is*
tabular data.

[snip]

You simply haven't got an argument, have you? You have no useful evidence. You
have no definition supplied by W3C. W3C doesn't deliver the killer-blow that
you would like to see.You deny definitions that are not supplied by W3C. You
simply have your wishful thinking, and perhaps some hope that this matter will
go away. And, of course, it won't.

The reason it won't go away is what I said above. It doesn't hurt the web. It
doesn't hurt disabled people. And it demonstrably works. It will still work in
decades time if & when XHTML 2.0 becomes common. And there will probably still
be a minority of people wishing that a miracle will happen and stop all those
people using such a simple and effective method of laying out complex material
in rows & columns!

Chuckle!

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Brian]

Matt Kruse wrote:

A 3-column, 1-row table used for layout contains three cells of
data.
Well, no. It has 3 <td> elements which should contain table data.
The data are all related, because they are all portions of
the overall content of the page.
This is more "begging the question." Since a table layout is contained
in one page, a table layout is, by your definition, not layout at all
but a data table. I don't buy it.
There are no additional rows, so being related in columns doesn't
apply. Or do you want to further-define "a relationship"?
Sure. Change the presentation from rows and columns to something else,
like moving one column to a section at the bottom of the page, with
several paragraphs in between. Does the page still make sense? In data
tables, removing a column and putting it elsewhere in the page makes
it difficult or impossible for the user to make sense of the data. In
layout tables, there no change in comprehension, only in presentation.
Using CSS for layout has a number of dependencies and quirks.
What does this have to do with data tables?
If those can be sucessfully worked through for the browsers which
you support, then it is excellent. If the dependencies and quirks
are too difficult to work through for the supported browsers, then
table layout works great.
Hang on, if the tables are automatically data tables, then there is no
need for practical considerations like browsers' css bugs. Or are you
conceding that layout tables do not, after all, present tabular data?
People who see the issue as black-and-white miss the wonderful
world of gray.

The discussion is whether table layout is the correct markup. It is
not.

If, knowing that, you decide that css positioning is too hard, and
that you're going to use table layout anyway, go for it. Noone is
stopping you. But you won't convince me that it's the correct markup.

[1] You used to be able to reverse columns and rows. But I can no
longer find a menu item to do that. Perhaps it has been removed from
new spreadsheet programs.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Matt Kruse]

Brian wrote:

Hang on, if the tables are automatically data tables, then there is no
need for practical considerations like browsers' css bugs. Or are you
conceding that layout tables do not, after all, present tabular data?
You're being argumentative. You know the intent of what I'm saying and what
others are saying.

Obviously, there is a difference between a table of data that we would see
in text books or reports, and tables used for layout and page organization.
They both use the same tool, but contain different information.

IMO, using everything for what it was 'intended' to be used for is a sure
way to stop innovation. Just because something wasn't the 'intent' doesn't
make it wrong or something that should be discouraged. In fact, just the
opposite.

I think that if anyone is intelligent enough to be posting in this thread,
then they probably understand the roots of html, css, and how the web has
evolved over the years. If you want to stick to plain vanilla html without
considering browsers and how to enhance appearance for the vast majority of
users, then that's fine. But most people don't want boring, ugly pages. Some
liberty must be taken with the 'pure' approach to create a good presentation
that still looks good in older browsers, and that's a fine approach too.

People who see the issue as black-and-white miss the wonderful
world of gray.

The discussion is whether table layout is the correct markup. It is
not.

That's what you _think_ the discussion is.
'Correct' is irrelevant. What works is the better question.

When the 'correct' way of doing things suffers from compatability problems
and implementation quirks, and reduces quality of pages on older browsers,
then it's not very practical.
If, knowing that, you decide that css positioning is too hard, and
that you're going to use table layout anyway, go for it. Noone is
stopping you. But you won't convince me that it's the correct markup.

It's not that CSS positioning is too hard, it's just that it doesn't always
_work_, and it's not very backwards-compatible. Are you going to use an
'ideal' solution that looks bad in older browsers and may only give the
presentation you want in a handful of browsers, or use an older solution
which will display correctly in the majority of browsers and look good in
all of them? Most people choose the latter.

I remember when <table> was first introduced. People immediately started
using them for layout. It takes a while before old habits die, and they
usually only do so when a better alternative is available :)

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/

[Brian]

Matt Kruse wrote:

Brian wrote:

if the tables are automatically data tables, then there
is no need for practical considerations like browsers' css bugs.
Or are you conceding that layout tables do not, after all,
present tabular data?
You're being argumentative. You know the intent of what I'm saying
and what others are saying.

I can only read what you write. And your arguements are shifting
rather quickly.
Obviously, there is a difference between a table of data that we
would see in text books or reports, and tables used for layout and
page organization.
Well, that's the point, isn't it? The first is data tables, and they
exist on the web, too. The second is layout tables. You claimed in
your last message in this thread that all tables on the www are by
definition data tables since they present data from a single document.
I don't see how you can call me to task for what you wrote.
IMO, using everything for what it was 'intended' to be used for is
a sure way to stop innovation.
If you're looking for what's new and innovative, then surely CSS is
far sexier.
Just because something wasn't the 'intent' doesn't make it wrong or
something that should be discouraged.
Ok. But neither is the opposite proposition -- that an unintended use
of a technology should be encouraged -- automatically true. HTML was
not intended as a desktop publishing language. You can try to make it
one, but it will never be quite what Quark Express or Pagemaker is.
The www's strengths lie elsewhere, and no amount of wishing will
change that.
If you want to stick to plain vanilla html without considering
browsers and how to enhance appearance for the vast majority of
users, then that's fine.
Straw man argument. I never suggested any such thing, and my sites
suggest something quite different. (See sig for one.)

The discussion is whether table layout is the correct markup. It
is not.

That's what you _think_ the discussion is.

With all due respect, the op asked where it was written that tables
were not to be used for layout. That sure looks like a discussion
about the correct use of table markup to me.
When the 'correct' way of doing things suffers from compatability
problems and implementation quirks, and reduces quality of pages on
older browsers, then it's not very practical.
That is not about the proper use of table markup, but a practical
argument about the difficulities of CSS. FWIW, I agree: CSS is hard,
there are a lot of bugs, and it makes authoring hard. In fact, it puts
it out of reach of amateurs, and that's unacceptable for the www. But
none of this changes the fact that table markup was intended for
tables, not for presentation.

This is not the only element abused for its presentation. For years,
authors used <blockquote> to indent text. It is no longer done, and
noone -- not even Barry Pearson -- argues that anyone should. Why not?
The reason is quite simple: creating an indentation is trivial with
CSS, so authors use CSS instead of <blockquote> to create an indent.
By contrast, positioning with CSS is hard, really hard, so people use
<table> instead. Fine. But then they insist that there's nothing
really wrong with that, that <table> was *meant* for layout. I'm
sorry, but I cannot agree.
It's not that CSS positioning is too hard, it's just that it
doesn't always _work_

Forgive me, but how is that different? If I'm misunderstanding you,
it's because you are not writing very clearly.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Matt Kruse]

Brian wrote:

IMO, using everything for what it was 'intended' to be used for is
a sure way to stop innovation.

If you're looking for what's new and innovative, then surely CSS is
far sexier.

Indeed, if it was actually implemented consistently and correctly. I love
CSS and use it extensively, but I do know where it's limits are...

It's not that CSS positioning is too hard, it's just that it
doesn't always _work_

Forgive me, but how is that different? If I'm misunderstanding you,
it's because you are not writing very clearly.

I'm saying there are situations where requirements simply can't be met using
CSS. Not that the CSS solution is hard to find -- it's just not possible.

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/

[Chris Morris]

"Barry Pearson" <ne**@childsupportanalysis.co.uk> writes:

Chris Morris wrote:

"Barry Pearson" <ne**@childsupportanalysis.co.uk> writes: [snip]

HTML 4 & HTML 4.01 have *never* prohibited the use of layout
tables. Never.

No. HTML 4 doesn't prohibit <body bgcolor='#000000' text='#000000'>
either. It probably has a 'should choose colours with sufficient
contrast' somewhere. Nowhere does it say you MUST NOT do something
like that.

True. But I write HTML 4.01 Strict, which *does* prohibit those.

But not the CSS equivalent. HTML 4.01 Strict doesn't *prohibit* using
<h1> instead of <p>, though, or many other silly things. The spec is
broad - that doesn't mean that everything it lets you do is advisable.
But it doesn't prohibit layout tables.
I've not been saying it does. I'm not sure anyone has been.
Layout tables are in a totally different category from deprecated elements.
So, HTML 4 spec on deprecated elements.
http://www.w3.org/TR/html401/conform.html#deprecated
"In general, authors should use style sheets to achieve stylistic and
formatting effects rather than HTML presentational attributes."

Note it's only a 'should' - which in RFC terms is the exact opposite
of 'should not'. So, one:
(should) (not use) (deprecated elements)
(should not) (use) (tables for layout)
and
(should) (not use) is equivalent to (should not) (use) by the RFC
definitions.
They are simply *not* deprecated. There is no credible proposal or programme
to make them deprecated, or to prohibit them. How can there be, when they use
a subset of the mark-up for data tables, which cannot be deprecated?
They can't be prohibited by the DOCTYPE, no. But neither can using
<blockquote> for indentation, or using headings to make text bold.

The spec *could* legitimately say "Tables must not be used for
layout". A validator couldn't tell the difference, obviously, but
validators don't check every part of the spec. They've chosen not to.
Layout tables may be criticised on emotional grounds, but not on technical or
practical grounds.
Since when has "They cause display problems in browsers X, Y and Z"
been an emotional ground rather than a technical and practical one?
They are here to stay, for decades.
So is <font>. Persistence is no measure of quality. :)
You might as well object to Marks & Spencer "ready meals", because
they are not real cooking!
No, I object to them because of
http://www.marksandspencer.com/disallowed.html ;)

It's intended, I think, to be a fairly flexible specification. Best
practice at implementing pages within it is a different matter. With
the rise of narrow-width browsers, and the rise of mainstream browsers
that support CSS fairly well (even IE 6 is adequate for most
purposes), I see no reason to use layout tables for anything other
than exceptional cases [1].

Then don't use them! Your decision. It is also your decision whether
or not to use Javascript. Or Flash. Or XHTML rather than HTML.

Yes...
And every author is entitled to their own decision. I hope they
won't try to force you to use layout tables. I hope you won't try to
stop anyone else using them. Each author has a clear right to
choose, and to live with the consequences. Let's simply expose the
consequences, to the best of our abilities.

Given that no-one (as far as I know) has been threatening to 'send the
boys round' if you (or anyone else) uses layout tables, I'm not sure
what, other than "making people aware of possible consequences", this
has been about?

Hmm. I possibly also take a different view of RFC-style 'SHOULD NOT'
to you. I view it as 'MUST NOT, *unless* it's absolutely essential', I
think you view it as slightly more permissive than that.

[snip]

I see no need to "view" it. I just take it as it is written:

"SHOULD NOT - This phrase, ... mean that there may exist valid reasons in
particular circumstances when the particular behavior is acceptable or even
useful, but the full implications should be understood and the case carefully
weighed before implementing any behavior described with this label."
http://www.ietf.org/rfc/rfc2119.txt

Let's all just take it as written! Surely we can at least agree with what is
*written*?

"but the full implications should be understood".

Do you understand the *full* *implications* of using layout tables? I
know I don't, and I wrote enough of them before switching to CSS
layouts. That is a _very_ strong phrase if interpreted entirely
literally.

Given that no-one knows the full implications of anything, that makes
SHOULD NOT equivalent to MUST NOT. Well, that's clearly not the
author's intent. So there's room for interpretation over what SHOULD
NOT means.

--
Chris