I'm trying to replace <table>s with <div>s as much as possible.
However, I can't figure out how to do the following…
<table>
<tr>
<td valign="top" width="100%">some data that will 'stretch'</td>
<td valign="top" width="300">some data that won't 'stetch'</td>
</tr>
</table>
Anyone?
TIA,
Toby Austin 61  24387  bo**************@hotmail.com (Toby Austin) wrote: I'm trying to replace <table>s with <div>s as much as possible.
However, I can't figure out how to do the following…
<table>
<tr>
<td valign="top" width="100%">some data that will 'stretch'</td>
<td valign="top" width="300">some data that won't 'stetch'</td>
</tr>
</table>
Show us what you are actually trying to do (using real content).
--
Spartanicus bo**************@hotmail.com (Toby Austin) wrote: I'm trying to replace <table>s with <div>s as much as possible.
However, I can't figure out how to do the following…
<table>
<tr>
<td valign="top" width="100%">some data that will 'stretch'</td>
<td valign="top" width="300">some data that won't 'stetch'</td>
</tr>
</table>
Show us what you are actually trying to do (using real content).
--
Spartanicus
Toby Austin wrote: I'm trying to replace <table>s with <div>s as much as possible.
However, I can't figure out how to do the following.
<table>
<tr>
<td valign="top" width="100%">some data that will 'stretch'</td>
<td valign="top" width="300">some data that won't 'stetch'</td>
</tr>
</table>
2 <div>s. Give them ids such as "content" and "sidebar".
Position the "sidebar", using { float: right } or { position: absolute }. It
has { width: 300px }.
Let the "content" just flow into position without positioning it. Don't set a
width.
Give the "content" a { margin-right: 310px }. Its stuff will then stay clear
of the sidebar.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Toby Austin wrote: I'm trying to replace <table>s with <div>s as much as possible.
However, I can't figure out how to do the following.
<table>
<tr>
<td valign="top" width="100%">some data that will 'stretch'</td>
<td valign="top" width="300">some data that won't 'stetch'</td>
</tr>
</table>
2 <div>s. Give them ids such as "content" and "sidebar".
Position the "sidebar", using { float: right } or { position: absolute }. It
has { width: 300px }.
Let the "content" just flow into position without positioning it. Don't set a
width.
Give the "content" a { margin-right: 310px }. Its stuff will then stay clear
of the sidebar.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Barry Pearson ne**@childsupportanalysis.co.uk wrote: Toby Austin wrote: I'm trying to replace <table>s with <div>s as much as possible.
However, I can't figure out how to do the following.
<table>
<tr>
<td valign="top" width="100%">some data that will 'stretch'</td>
<td valign="top" width="300">some data that won't 'stetch'</td>
</tr>
</table>
2 <div>s. Give them ids such as "content" and "sidebar".
Position the "sidebar", using { float: right } or { position: absolute }. It
has { width: 300px }.
Let the "content" just flow into position without positioning it. Don't set a
width.
Give the "content" a { margin-right: 310px }. Its stuff will then stay clear
of the sidebar.
however...there is generally no point attempting to recreate an old table
layout using css...why not create a new layout that uses the strengths of
css rather than use it to imitate the strengths of tables?
--
eric www.ericjarvis.co.uk
"live fast, die only if strictly necessary"
Barry Pearson ne**@childsupportanalysis.co.uk wrote: Toby Austin wrote: I'm trying to replace <table>s with <div>s as much as possible.
However, I can't figure out how to do the following.
<table>
<tr>
<td valign="top" width="100%">some data that will 'stretch'</td>
<td valign="top" width="300">some data that won't 'stetch'</td>
</tr>
</table>
2 <div>s. Give them ids such as "content" and "sidebar".
Position the "sidebar", using { float: right } or { position: absolute }. It
has { width: 300px }.
Let the "content" just flow into position without positioning it. Don't set a
width.
Give the "content" a { margin-right: 310px }. Its stuff will then stay clear
of the sidebar.
however...there is generally no point attempting to recreate an old table
layout using css...why not create a new layout that uses the strengths of
css rather than use it to imitate the strengths of tables?
--
eric www.ericjarvis.co.uk
"live fast, die only if strictly necessary"
Eric Jarvis wrote: Barry Pearson ne**@childsupportanalysis.co.uk wrote: Toby Austin wrote: > I'm trying to replace <table>s with <div>s as much as possible.
> However, I can't figure out how to do the following.
[snip] 2 <div>s. Give them ids such as "content" and "sidebar".
Position the "sidebar", using { float: right } or { position:
absolute }. It has { width: 300px }.
Let the "content" just flow into position without positioning it.
Don't set a width.
Give the "content" a { margin-right: 310px }. Its stuff will then
stay clear of the sidebar.
however...there is generally no point attempting to recreate an old
table layout using css...why not create a new layout that uses the
strengths of css rather than use it to imitate the strengths of
tables?
The OP simply wanted to put 2 lots of stuff side-by-side. That is sensible in
lots of cases. For example, it is a way of enabling the user to see the main
content & supplementary information in the viewport without (vertical)
scrolling between them.
I suspect that the original table was simply an attempt to achieve this layout
concept. Now, the OP wants to do it without tables. But the layout concept
remains valid.
Columns are very important. They enable the user, within seconds, to identify
where all the most important parts of the page are. And then to get to all of
them with just vertical scolling, for which there are various mechnical aids.
(I use a cordless batteryless mouse with a scroll-wheel).
The point is *not* to use the strengths of CSS! It is to achieve the objective
of communicating with the audience. And that may well be achieved with
side-by-side columns, that can jointly be accessed via vertical scrolling.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Eric Jarvis wrote: Barry Pearson ne**@childsupportanalysis.co.uk wrote: Toby Austin wrote: > I'm trying to replace <table>s with <div>s as much as possible.
> However, I can't figure out how to do the following.
[snip] 2 <div>s. Give them ids such as "content" and "sidebar".
Position the "sidebar", using { float: right } or { position:
absolute }. It has { width: 300px }.
Let the "content" just flow into position without positioning it.
Don't set a width.
Give the "content" a { margin-right: 310px }. Its stuff will then
stay clear of the sidebar.
however...there is generally no point attempting to recreate an old
table layout using css...why not create a new layout that uses the
strengths of css rather than use it to imitate the strengths of
tables?
The OP simply wanted to put 2 lots of stuff side-by-side. That is sensible in
lots of cases. For example, it is a way of enabling the user to see the main
content & supplementary information in the viewport without (vertical)
scrolling between them.
I suspect that the original table was simply an attempt to achieve this layout
concept. Now, the OP wants to do it without tables. But the layout concept
remains valid.
Columns are very important. They enable the user, within seconds, to identify
where all the most important parts of the page are. And then to get to all of
them with just vertical scolling, for which there are various mechnical aids.
(I use a cordless batteryless mouse with a scroll-wheel).
The point is *not* to use the strengths of CSS! It is to achieve the objective
of communicating with the audience. And that may well be achieved with
side-by-side columns, that can jointly be accessed via vertical scrolling.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Barry Pearson ne**@childsupportanalysis.co.uk wrote: Eric Jarvis wrote: Barry Pearson ne**@childsupportanalysis.co.uk wrote: Toby Austin wrote:
> I'm trying to replace <table>s with <div>s as much as possible.
> However, I can't figure out how to do the following. [snip] 2 <div>s. Give them ids such as "content" and "sidebar".
Position the "sidebar", using { float: right } or { position:
absolute }. It has { width: 300px }.
Let the "content" just flow into position without positioning it.
Don't set a width.
Give the "content" a { margin-right: 310px }. Its stuff will then
stay clear of the sidebar.
however...there is generally no point attempting to recreate an old
table layout using css...why not create a new layout that uses the
strengths of css rather than use it to imitate the strengths of
tables?
The OP simply wanted to put 2 lots of stuff side-by-side. That is sensible in
lots of cases. For example, it is a way of enabling the user to see the main
content & supplementary information in the viewport without (vertical)
scrolling between them.
absolutely agreed...however the fact that it was presented as a code
snippet of table layout implies the OP isn't as yet prepared to take the
plunge and start thinking in terms of "raw design concepts" taken straight
to css...something I believe they will find far easier and more effective
than interposing old table techniques as an intermediary stage
--
eric www.ericjarvis.co.uk
"live fast, die only if strictly necessary"
Barry Pearson ne**@childsupportanalysis.co.uk wrote: Eric Jarvis wrote: Barry Pearson ne**@childsupportanalysis.co.uk wrote: Toby Austin wrote:
> I'm trying to replace <table>s with <div>s as much as possible.
> However, I can't figure out how to do the following. [snip] 2 <div>s. Give them ids such as "content" and "sidebar".
Position the "sidebar", using { float: right } or { position:
absolute }. It has { width: 300px }.
Let the "content" just flow into position without positioning it.
Don't set a width.
Give the "content" a { margin-right: 310px }. Its stuff will then
stay clear of the sidebar.
however...there is generally no point attempting to recreate an old
table layout using css...why not create a new layout that uses the
strengths of css rather than use it to imitate the strengths of
tables?
The OP simply wanted to put 2 lots of stuff side-by-side. That is sensible in
lots of cases. For example, it is a way of enabling the user to see the main
content & supplementary information in the viewport without (vertical)
scrolling between them.
absolutely agreed...however the fact that it was presented as a code
snippet of table layout implies the OP isn't as yet prepared to take the
plunge and start thinking in terms of "raw design concepts" taken straight
to css...something I believe they will find far easier and more effective
than interposing old table techniques as an intermediary stage
--
eric www.ericjarvis.co.uk
"live fast, die only if strictly necessary"
Eric Jarvis wrote: Barry Pearson ne**@childsupportanalysis.co.uk wrote: Eric Jarvis wrote: > Barry Pearson ne**@childsupportanalysis.co.uk wrote:
>> Toby Austin wrote:
>> > I'm trying to replace <table>s with <div>s as much as possible.
>> > However, I can't figure out how to do the following.
[snip] > however...there is generally no point attempting to recreate an old
> table layout using css...why not create a new layout that uses the
> strengths of css rather than use it to imitate the strengths of
> tables?
The OP simply wanted to put 2 lots of stuff side-by-side. That is
sensible in lots of cases. For example, it is a way of enabling the
user to see the main content & supplementary information in the
viewport without (vertical) scrolling between them.
absolutely agreed...however the fact that it was presented as a code
snippet of table layout implies the OP isn't as yet prepared to take
the plunge and start thinking in terms of "raw design concepts" taken
straight to css...something I believe they will find far easier and
more effective than interposing old table techniques as an
intermediary stage
Absolutely agreed. (Gosh!)
It is very important to get back to the raw objectives. Too many people
specify their requirements in terms of technology and/or implementation,
instead of objectives to be satisfied.
That table-layout may well have simply been an old implementation of the real
objectives. Now, perhaps, the OP is trying to get an up-to-date implementation
of those objectives.
The problem is that it can be difficult to convey objectives here. I sometimes
sketch layout concepts in PowerPoint, with boxes & arrows, to try to
understand eye-movements around the layout. But how would I convey that?
(Perhaps in a different NG?)
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Eric Jarvis wrote: Barry Pearson ne**@childsupportanalysis.co.uk wrote: Eric Jarvis wrote: > Barry Pearson ne**@childsupportanalysis.co.uk wrote:
>> Toby Austin wrote:
>> > I'm trying to replace <table>s with <div>s as much as possible.
>> > However, I can't figure out how to do the following.
[snip] > however...there is generally no point attempting to recreate an old
> table layout using css...why not create a new layout that uses the
> strengths of css rather than use it to imitate the strengths of
> tables?
The OP simply wanted to put 2 lots of stuff side-by-side. That is
sensible in lots of cases. For example, it is a way of enabling the
user to see the main content & supplementary information in the
viewport without (vertical) scrolling between them.
absolutely agreed...however the fact that it was presented as a code
snippet of table layout implies the OP isn't as yet prepared to take
the plunge and start thinking in terms of "raw design concepts" taken
straight to css...something I believe they will find far easier and
more effective than interposing old table techniques as an
intermediary stage
Absolutely agreed. (Gosh!)
It is very important to get back to the raw objectives. Too many people
specify their requirements in terms of technology and/or implementation,
instead of objectives to be satisfied.
That table-layout may well have simply been an old implementation of the real
objectives. Now, perhaps, the OP is trying to get an up-to-date implementation
of those objectives.
The problem is that it can be difficult to convey objectives here. I sometimes
sketch layout concepts in PowerPoint, with boxes & arrows, to try to
understand eye-movements around the layout. But how would I convey that?
(Perhaps in a different NG?)
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Barry Pearson ne**@childsupportanalysis.co.uk wrote: Eric Jarvis wrote: Barry Pearson ne**@childsupportanalysis.co.uk wrote: Eric Jarvis wrote:
> Barry Pearson ne**@childsupportanalysis.co.uk wrote:
>> Toby Austin wrote:
>> > I'm trying to replace <table>s with <div>s as much as possible.
>> > However, I can't figure out how to do the following. [snip] > however...there is generally no point attempting to recreate an old
> table layout using css...why not create a new layout that uses the
> strengths of css rather than use it to imitate the strengths of
> tables?
The OP simply wanted to put 2 lots of stuff side-by-side. That is
sensible in lots of cases. For example, it is a way of enabling the
user to see the main content & supplementary information in the
viewport without (vertical) scrolling between them.
absolutely agreed...however the fact that it was presented as a code
snippet of table layout implies the OP isn't as yet prepared to take
the plunge and start thinking in terms of "raw design concepts" taken
straight to css...something I believe they will find far easier and
more effective than interposing old table techniques as an
intermediary stage
Absolutely agreed. (Gosh!)
It is very important to get back to the raw objectives. Too many people
specify their requirements in terms of technology and/or implementation,
instead of objectives to be satisfied.
That table-layout may well have simply been an old implementation of the real
objectives. Now, perhaps, the OP is trying to get an up-to-date implementation
of those objectives.
The problem is that it can be difficult to convey objectives here. I sometimes
sketch layout concepts in PowerPoint, with boxes & arrows, to try to
understand eye-movements around the layout. But how would I convey that?
(Perhaps in a different NG?)
sometimes it's difficult to find the right language to convey it...however
it's worth the effort...the biggest flaw in most web sites is that there
has been too little thought about what the site is trying to
achieve...understandable since most designers and developers are most
comfortable with the graphical/visual or programming/technical aspects of
the job...but it's very easy to be tempted into doing the bits one is most
familiar with before the objectives are properly established
my biggest fear about the way the web is going at present is that there is
far too much direct copying for a new medium like this...the chances are
that most things done one any web site anywhere could be dramatically
improved on...but that will only happen when designers and developers look
at new and better ways to achieve an objective rather than trying to
emulate somebody else's solution
--
eric www.ericjarvis.co.uk
"in the beginning was the word, and the word was
'try switching the damn thing on first'"
Barry Pearson ne**@childsupportanalysis.co.uk wrote: Eric Jarvis wrote: Barry Pearson ne**@childsupportanalysis.co.uk wrote: Eric Jarvis wrote:
> Barry Pearson ne**@childsupportanalysis.co.uk wrote:
>> Toby Austin wrote:
>> > I'm trying to replace <table>s with <div>s as much as possible.
>> > However, I can't figure out how to do the following. [snip] > however...there is generally no point attempting to recreate an old
> table layout using css...why not create a new layout that uses the
> strengths of css rather than use it to imitate the strengths of
> tables?
The OP simply wanted to put 2 lots of stuff side-by-side. That is
sensible in lots of cases. For example, it is a way of enabling the
user to see the main content & supplementary information in the
viewport without (vertical) scrolling between them.
absolutely agreed...however the fact that it was presented as a code
snippet of table layout implies the OP isn't as yet prepared to take
the plunge and start thinking in terms of "raw design concepts" taken
straight to css...something I believe they will find far easier and
more effective than interposing old table techniques as an
intermediary stage
Absolutely agreed. (Gosh!)
It is very important to get back to the raw objectives. Too many people
specify their requirements in terms of technology and/or implementation,
instead of objectives to be satisfied.
That table-layout may well have simply been an old implementation of the real
objectives. Now, perhaps, the OP is trying to get an up-to-date implementation
of those objectives.
The problem is that it can be difficult to convey objectives here. I sometimes
sketch layout concepts in PowerPoint, with boxes & arrows, to try to
understand eye-movements around the layout. But how would I convey that?
(Perhaps in a different NG?)
sometimes it's difficult to find the right language to convey it...however
it's worth the effort...the biggest flaw in most web sites is that there
has been too little thought about what the site is trying to
achieve...understandable since most designers and developers are most
comfortable with the graphical/visual or programming/technical aspects of
the job...but it's very easy to be tempted into doing the bits one is most
familiar with before the objectives are properly established
my biggest fear about the way the web is going at present is that there is
far too much direct copying for a new medium like this...the chances are
that most things done one any web site anywhere could be dramatically
improved on...but that will only happen when designers and developers look
at new and better ways to achieve an objective rather than trying to
emulate somebody else's solution
--
eric www.ericjarvis.co.uk
"in the beginning was the word, and the word was
'try switching the damn thing on first'"
Eric Jarvis wrote: Barry Pearson ne**@childsupportanalysis.co.uk wrote:
[snip] The problem is that it can be difficult to convey objectives here. I
sometimes sketch layout concepts in PowerPoint, with boxes & arrows,
to try to understand eye-movements around the layout. But how would
I convey that? (Perhaps in a different NG?)
sometimes it's difficult to find the right language to convey
it...however it's worth the effort...the biggest flaw in most web
sites is that there has been too little thought about what the site
is trying to achieve...understandable since most designers and
developers are most comfortable with the graphical/visual or
programming/technical aspects of the job...but it's very easy to be
tempted into doing the bits one is most familiar with before the
objectives are properly established
Agreed. I draw up a profile of my audience for a new website. What sorts of
people, what sorts of user systems, what the relative importances are? (For
example, with one of my websites I identified that a significant part of my
audience may be using public libraries. But with another, the most important
audience was using high-end systems with calibrated monitors).
my biggest fear about the way the web is going at present is that
there is far too much direct copying for a new medium like this...the
chances are that most things done one any web site anywhere could be
dramatically improved on...but that will only happen when designers
and developers look at new and better ways to achieve an objective
rather than trying to emulate somebody else's solution
I agree with this. I believe publishers & developers shoud be judged by the
marketplace, and in some cases the courts. (Eg. accessibility). People should
feel free to experiment, and sometimes crash & burn.
The objective of a website is to communicate with the audience. Everything
else is a means to that end. We need to keep discovering new ways to
communicate, and re-evaluate old ways to see if they should be discarded.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Eric Jarvis wrote: Barry Pearson ne**@childsupportanalysis.co.uk wrote:
[snip] The problem is that it can be difficult to convey objectives here. I
sometimes sketch layout concepts in PowerPoint, with boxes & arrows,
to try to understand eye-movements around the layout. But how would
I convey that? (Perhaps in a different NG?)
sometimes it's difficult to find the right language to convey
it...however it's worth the effort...the biggest flaw in most web
sites is that there has been too little thought about what the site
is trying to achieve...understandable since most designers and
developers are most comfortable with the graphical/visual or
programming/technical aspects of the job...but it's very easy to be
tempted into doing the bits one is most familiar with before the
objectives are properly established
Agreed. I draw up a profile of my audience for a new website. What sorts of
people, what sorts of user systems, what the relative importances are? (For
example, with one of my websites I identified that a significant part of my
audience may be using public libraries. But with another, the most important
audience was using high-end systems with calibrated monitors).
my biggest fear about the way the web is going at present is that
there is far too much direct copying for a new medium like this...the
chances are that most things done one any web site anywhere could be
dramatically improved on...but that will only happen when designers
and developers look at new and better ways to achieve an objective
rather than trying to emulate somebody else's solution
I agree with this. I believe publishers & developers shoud be judged by the
marketplace, and in some cases the courts. (Eg. accessibility). People should
feel free to experiment, and sometimes crash & burn.
The objective of a website is to communicate with the audience. Everything
else is a means to that end. We need to keep discovering new ways to
communicate, and re-evaluate old ways to see if they should be discarded.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Barry Pearson wrote: I believe publishers & developers shoud be judged by the marketplace
Not all web sites are about commerce.
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
Barry Pearson wrote: I believe publishers & developers shoud be judged by the marketplace
Not all web sites are about commerce.
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote in message
news:MkDfc.30$mQ3.12@newsfe1-win...
It is very important to get back to the raw objectives. Too many people
specify their requirements in terms of technology and/or implementation,
instead of objectives to be satisfied.
This is true of any area. People come to architects with descriptions of
what rooms they want and how big they should be and how they should be laid
out, rather than a list of their underlying needs and a description of key
aspects of their lifestyles. People visit their physicians equipped with a
self-diagnosis rather than a list of symptoms.
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote in message
news:MkDfc.30$mQ3.12@newsfe1-win...
It is very important to get back to the raw objectives. Too many people
specify their requirements in terms of technology and/or implementation,
instead of objectives to be satisfied.
This is true of any area. People come to architects with descriptions of
what rooms they want and how big they should be and how they should be laid
out, rather than a list of their underlying needs and a description of key
aspects of their lifestyles. People visit their physicians equipped with a
self-diagnosis rather than a list of symptoms.
Brian wrote: Barry Pearson wrote:
I believe publishers & developers shoud be judged by the marketplace
Not all web sites are about commerce.
No, but the marketplace here is more than just the markets that commercial
websites are selling into.
It is a marketplace for ideas, authors, tools, extensions, templates,
tutorials, books, etc. Remember the context from the articles you responded
to. It was Eric & I discussing the need for innovation instead of
emulation/copying.
Courts will impose some constraints. Commercial failure may get rid of some of
the bad ideas, given time. But I would hope that people will keep pushing the
boundaries forward, without unnecessary constraints. As I said: "People should
feel free to experiment, and sometimes crash & burn."
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Brian wrote: Barry Pearson wrote:
I believe publishers & developers shoud be judged by the marketplace
Not all web sites are about commerce.
No, but the marketplace here is more than just the markets that commercial
websites are selling into.
It is a marketplace for ideas, authors, tools, extensions, templates,
tutorials, books, etc. Remember the context from the articles you responded
to. It was Eric & I discussing the need for innovation instead of
emulation/copying.
Courts will impose some constraints. Commercial failure may get rid of some of
the bad ideas, given time. But I would hope that people will keep pushing the
boundaries forward, without unnecessary constraints. As I said: "People should
feel free to experiment, and sometimes crash & burn."
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote in message news:<MkDfc.30$mQ3.12@newsfe1-win>... Eric Jarvis wrote: Barry Pearson ne**@childsupportanalysis.co.uk wrote: Eric Jarvis wrote:
> Barry Pearson ne**@childsupportanalysis.co.uk wrote:
>> Toby Austin wrote:
>> > I'm trying to replace <table>s with <div>s as much as possible.
>> > However, I can't figure out how to do the following. [snip] > however...there is generally no point attempting to recreate an old
> table layout using css...why not create a new layout that uses the
> strengths of css rather than use it to imitate the strengths of
> tables?
The OP simply wanted to put 2 lots of stuff side-by-side. That is
sensible in lots of cases. For example, it is a way of enabling the
user to see the main content & supplementary information in the
viewport without (vertical) scrolling between them.
absolutely agreed...however the fact that it was presented as a code
snippet of table layout implies the OP isn't as yet prepared to take
the plunge and start thinking in terms of "raw design concepts" taken
straight to css...something I believe they will find far easier and
more effective than interposing old table techniques as an
intermediary stage
Absolutely agreed. (Gosh!)
It is very important to get back to the raw objectives. Too many people
specify their requirements in terms of technology and/or implementation,
instead of objectives to be satisfied.
That table-layout may well have simply been an old implementation of the real
objectives. Now, perhaps, the OP is trying to get an up-to-date implementation
of those objectives.
The problem is that it can be difficult to convey objectives here. I sometimes
sketch layout concepts in PowerPoint, with boxes & arrows, to try to
understand eye-movements around the layout. But how would I convey that?
(Perhaps in a different NG?)
You are both sort of right in that I simply described the problem by
using a table because I thought it would be the easiest way to get the
problem across. If I'd been able to describe it using div tags then I
may have chosen to have done so that way (but then I would not have
needed to ask the question in the first place!)
Anyway, the effect that I am trying to achieve is exactly as has been
described: Two columns, one with the content on left, and one with
some sort of sidebar on the right. I can easily do it using a table,
but thought I would try to do away with tables as I *do* want to 'take
the plunge' and use a css approach.
When I saw the solution, it seemed obvious, but looking at it, I have
not described the problem fully: The solution is fine, except if the
sidebar and content contain images. Then, if the user makes the window
smaller than the combined sizes of the images, the content drops below
the sidebar. With a table, this does not happen. So back to my table
example, how do I do the following using div tags...
<table>
<tr>
<td valign="top" width="100%"><img src="whatever" width="400">some
text etc. that will stretch</td>
<td valign="top" width="300"><img src="whatever" width="300"></td>
</tr>
</table>
....so that the columns will still be side by side, even if the user
sizes the window to less than 700.
Thanks again,
Toby Austin
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote in message news:<MkDfc.30$mQ3.12@newsfe1-win>... Eric Jarvis wrote: Barry Pearson ne**@childsupportanalysis.co.uk wrote: Eric Jarvis wrote:
> Barry Pearson ne**@childsupportanalysis.co.uk wrote:
>> Toby Austin wrote:
>> > I'm trying to replace <table>s with <div>s as much as possible.
>> > However, I can't figure out how to do the following. [snip] > however...there is generally no point attempting to recreate an old
> table layout using css...why not create a new layout that uses the
> strengths of css rather than use it to imitate the strengths of
> tables?
The OP simply wanted to put 2 lots of stuff side-by-side. That is
sensible in lots of cases. For example, it is a way of enabling the
user to see the main content & supplementary information in the
viewport without (vertical) scrolling between them.
absolutely agreed...however the fact that it was presented as a code
snippet of table layout implies the OP isn't as yet prepared to take
the plunge and start thinking in terms of "raw design concepts" taken
straight to css...something I believe they will find far easier and
more effective than interposing old table techniques as an
intermediary stage
Absolutely agreed. (Gosh!)
It is very important to get back to the raw objectives. Too many people
specify their requirements in terms of technology and/or implementation,
instead of objectives to be satisfied.
That table-layout may well have simply been an old implementation of the real
objectives. Now, perhaps, the OP is trying to get an up-to-date implementation
of those objectives.
The problem is that it can be difficult to convey objectives here. I sometimes
sketch layout concepts in PowerPoint, with boxes & arrows, to try to
understand eye-movements around the layout. But how would I convey that?
(Perhaps in a different NG?)
You are both sort of right in that I simply described the problem by
using a table because I thought it would be the easiest way to get the
problem across. If I'd been able to describe it using div tags then I
may have chosen to have done so that way (but then I would not have
needed to ask the question in the first place!)
Anyway, the effect that I am trying to achieve is exactly as has been
described: Two columns, one with the content on left, and one with
some sort of sidebar on the right. I can easily do it using a table,
but thought I would try to do away with tables as I *do* want to 'take
the plunge' and use a css approach.
When I saw the solution, it seemed obvious, but looking at it, I have
not described the problem fully: The solution is fine, except if the
sidebar and content contain images. Then, if the user makes the window
smaller than the combined sizes of the images, the content drops below
the sidebar. With a table, this does not happen. So back to my table
example, how do I do the following using div tags...
<table>
<tr>
<td valign="top" width="100%"><img src="whatever" width="400">some
text etc. that will stretch</td>
<td valign="top" width="300"><img src="whatever" width="300"></td>
</tr>
</table>
....so that the columns will still be side by side, even if the user
sizes the window to less than 700.
Thanks again,
Toby Austin
Toby Austin bo**************@hotmail.com wrote:
Anyway, the effect that I am trying to achieve is exactly as has been
described: Two columns, one with the content on left, and one with
some sort of sidebar on the right. I can easily do it using a table,
but thought I would try to do away with tables as I *do* want to 'take
the plunge' and use a css approach.
When I saw the solution, it seemed obvious, but looking at it, I have
not described the problem fully: The solution is fine, except if the
sidebar and content contain images. Then, if the user makes the window
smaller than the combined sizes of the images, the content drops below
the sidebar. With a table, this does not happen. So back to my table
example, how do I do the following using div tags...
<table>
<tr>
<td valign="top" width="100%"><img src="whatever" width="400">some
text etc. that will stretch</td>
<td valign="top" width="300"><img src="whatever" width="300"></td>
</tr>
</table>
...so that the columns will still be side by side, even if the user
sizes the window to less than 700.
overflow: scroll; in the stylesheet...either for a containing div or for
the right hand element
--
eric www.ericjarvis.co.uk
"live fast, die only if strictly necessary"
Toby Austin bo**************@hotmail.com wrote:
Anyway, the effect that I am trying to achieve is exactly as has been
described: Two columns, one with the content on left, and one with
some sort of sidebar on the right. I can easily do it using a table,
but thought I would try to do away with tables as I *do* want to 'take
the plunge' and use a css approach.
When I saw the solution, it seemed obvious, but looking at it, I have
not described the problem fully: The solution is fine, except if the
sidebar and content contain images. Then, if the user makes the window
smaller than the combined sizes of the images, the content drops below
the sidebar. With a table, this does not happen. So back to my table
example, how do I do the following using div tags...
<table>
<tr>
<td valign="top" width="100%"><img src="whatever" width="400">some
text etc. that will stretch</td>
<td valign="top" width="300"><img src="whatever" width="300"></td>
</tr>
</table>
...so that the columns will still be side by side, even if the user
sizes the window to less than 700.
overflow: scroll; in the stylesheet...either for a containing div or for
the right hand element
--
eric www.ericjarvis.co.uk
"live fast, die only if strictly necessary"
Barry Pearson wrote: Brian wrote: Not all web sites are about commerce.
No, but the marketplace here is more than just the markets that commercial
websites are selling into.
It is a marketplace for ideas,
I don't think ideas are "sold," except in advertising. And I don't think
"selling ideas" via advertising is part of a vibrant democracy.[1]
Furthermore, I don't think advertising works on the web, at least not at
the moment, because advertising uses a passive recipient model, while
the web is more of a mental and intellectual engagement.
When I visit a site on Latin literature of medieval French poetry, I am
not in a marketplace, anymore than when I read Caesar's _De Bello
Gallico_ or Marie de France's "Le Fresne."
Courts will impose some constraints. Commercial failure may get rid of some of
the bad ideas, given time.
For many sites, "commercial failure" is not really part of the picture,
since commerce never plays a part in their creation or upkeep.
OT
[1] In the States, as I heard last night on the radio, people learn more
about candidates via political ads then via the news. Such discourse
treats people not as citizens, but as consumers. On a practical level,
it leads to a situation where most voters do not know the political
positions of any of the candidates, including the one they voted for.
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
Barry Pearson wrote: Brian wrote: Not all web sites are about commerce.
No, but the marketplace here is more than just the markets that commercial
websites are selling into.
It is a marketplace for ideas,
I don't think ideas are "sold," except in advertising. And I don't think
"selling ideas" via advertising is part of a vibrant democracy.[1]
Furthermore, I don't think advertising works on the web, at least not at
the moment, because advertising uses a passive recipient model, while
the web is more of a mental and intellectual engagement.
When I visit a site on Latin literature of medieval French poetry, I am
not in a marketplace, anymore than when I read Caesar's _De Bello
Gallico_ or Marie de France's "Le Fresne."
Courts will impose some constraints. Commercial failure may get rid of some of
the bad ideas, given time.
For many sites, "commercial failure" is not really part of the picture,
since commerce never plays a part in their creation or upkeep.
OT
[1] In the States, as I heard last night on the radio, people learn more
about candidates via political ads then via the news. Such discourse
treats people not as citizens, but as consumers. On a practical level,
it leads to a situation where most voters do not know the political
positions of any of the candidates, including the one they voted for.
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
Toby Austin wrote: "Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote in message
news:<MkDfc.30$mQ3.12@newsfe1-win>... Eric Jarvis wrote:
[snip] You are both sort of right in that I simply described the problem by
using a table because I thought it would be the easiest way to get the
problem across. If I'd been able to describe it using div tags then I
may have chosen to have done so that way (but then I would not have
needed to ask the question in the first place!)
I wonder, if you think the best description is via a table, whether you should
simply use a table? Right from their start in about 1993, tables were
intended, inter alia, for laying out complex material in rows & columns. The
idea, that it is wrong to use tables for this, is quite a modern one, and not
supported by the recommendations or the historical evidence. You may be a
victim of misdirection.
"A brief history of tables"
http://www.barry.pearson.name/articl...es/history.htm
Anyway, the effect that I am trying to achieve is exactly as has been
described: Two columns, one with the content on left, and one with
some sort of sidebar on the right. I can easily do it using a table,
but thought I would try to do away with tables as I *do* want to 'take
the plunge' and use a css approach.
CSS is good. Using CSS to do what it wasn't intended for starts to get a bit
risky. CSS2 is about boxes, it isn't about columns. (They may be in CSS3, and
perhaps we will see that in about a decade). Trying to achieve columns via
CSS2 currently tends to need hacks & workarounds & ingenuity.
When I saw the solution, it seemed obvious, but looking at it, I have
not described the problem fully: The solution is fine, except if the
sidebar and content contain images. Then, if the user makes the window
smaller than the combined sizes of the images, the content drops below
the sidebar. With a table, this does not happen. So back to my table
example, how do I do the following using div tags...
Chuckle! It always helps to state the *real* problem, fully! It is vitally
important that you decide what you want to happen if the stuff you want
side-by-side simply cannot fit in the viewport. There is no magic - if they
can't fit, they *won't* fit.
<table>
<tr>
<td valign="top" width="100%"><img src="whatever" width="400">some
text etc. that will stretch</td>
<td valign="top" width="300"><img src="whatever" width="300"></td>
</tr>
</table>
...so that the columns will still be side by side, even if the user
sizes the window to less than 700.
Try this. It won't work as well as tables in all browsers, but that is what
you live with when you use CSS positioning.
<body>
<div id="wrapper">
<div id="sidebar">Fixed width stuff</div>
<div id="content">Variable width stuff</div>
</div>
</body>
#wrapper {
position: relative;
}
#sidebar {
width: 300px;
position: absolute;
right: 0;
top: 0;
overflow: auto;
}
#content {
margin-right: 310px;
}
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Toby Austin wrote: "Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote in message
news:<MkDfc.30$mQ3.12@newsfe1-win>... Eric Jarvis wrote:
[snip] You are both sort of right in that I simply described the problem by
using a table because I thought it would be the easiest way to get the
problem across. If I'd been able to describe it using div tags then I
may have chosen to have done so that way (but then I would not have
needed to ask the question in the first place!)
I wonder, if you think the best description is via a table, whether you should
simply use a table? Right from their start in about 1993, tables were
intended, inter alia, for laying out complex material in rows & columns. The
idea, that it is wrong to use tables for this, is quite a modern one, and not
supported by the recommendations or the historical evidence. You may be a
victim of misdirection.
"A brief history of tables"
http://www.barry.pearson.name/articl...es/history.htm
Anyway, the effect that I am trying to achieve is exactly as has been
described: Two columns, one with the content on left, and one with
some sort of sidebar on the right. I can easily do it using a table,
but thought I would try to do away with tables as I *do* want to 'take
the plunge' and use a css approach.
CSS is good. Using CSS to do what it wasn't intended for starts to get a bit
risky. CSS2 is about boxes, it isn't about columns. (They may be in CSS3, and
perhaps we will see that in about a decade). Trying to achieve columns via
CSS2 currently tends to need hacks & workarounds & ingenuity.
When I saw the solution, it seemed obvious, but looking at it, I have
not described the problem fully: The solution is fine, except if the
sidebar and content contain images. Then, if the user makes the window
smaller than the combined sizes of the images, the content drops below
the sidebar. With a table, this does not happen. So back to my table
example, how do I do the following using div tags...
Chuckle! It always helps to state the *real* problem, fully! It is vitally
important that you decide what you want to happen if the stuff you want
side-by-side simply cannot fit in the viewport. There is no magic - if they
can't fit, they *won't* fit.
<table>
<tr>
<td valign="top" width="100%"><img src="whatever" width="400">some
text etc. that will stretch</td>
<td valign="top" width="300"><img src="whatever" width="300"></td>
</tr>
</table>
...so that the columns will still be side by side, even if the user
sizes the window to less than 700.
Try this. It won't work as well as tables in all browsers, but that is what
you live with when you use CSS positioning.
<body>
<div id="wrapper">
<div id="sidebar">Fixed width stuff</div>
<div id="content">Variable width stuff</div>
</div>
</body>
#wrapper {
position: relative;
}
#sidebar {
width: 300px;
position: absolute;
right: 0;
top: 0;
overflow: auto;
}
#content {
margin-right: 310px;
}
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Barry Pearson wrote: Right from their start in about 1993, tables were intended, inter
alia, for laying out complex material in rows & columns.
"A brief history of tables"
Do you simply cut and paste this foolishness from a message
template whenever you repeat it? Or do you rewrite the same words each time?
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
Barry Pearson wrote: Right from their start in about 1993, tables were intended, inter
alia, for laying out complex material in rows & columns.
"A brief history of tables"
Do you simply cut and paste this foolishness from a message
template whenever you repeat it? Or do you rewrite the same words each time?
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
Barry Pearson wrote:
Right from their start in about 1993, tables were intended, inter
alia, for laying out complex material in rows & columns.
Oh, wait! This time, you inserted a Latin phrase in the middle. (Oooh,
Latin!) So it *is* different. Well good for you!
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
Barry Pearson wrote:
Right from their start in about 1993, tables were intended, inter
alia, for laying out complex material in rows & columns.
Oh, wait! This time, you inserted a Latin phrase in the middle. (Oooh,
Latin!) So it *is* different. Well good for you!
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
Barry Pearson wrote: Brian wrote:
Barry Pearson wrote:
Right from their start in about 1993, tables were intended, inter
alia, for laying out complex material in rows & columns.
Oh, wait! This time, you inserted a Latin phrase in the middle.
(Oooh, Latin!) So it *is* different. Well good for you!
Inter Alia is the name of a feeder airline supply the main airport
hubs in Italy.
What did you think it was?
Latin.
inter: among, between, during
alia: by another way
(You didn't capitilize it the first time, so I didn't think it was
proper noun.)
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
Brian wrote: Barry Pearson wrote: Brian wrote: Barry Pearson wrote:
Right from their start in about 1993, tables were intended, inter
alia, for laying out complex material in rows & columns.
Do you simply cut and paste this foolishness from a message
template whenever you repeat it?
It is the truth. I repeat it as required.
I note that you never attempt to supply evidence to the contrary.
Before replying to your references below, I'll emphasise my statement above.
It is clear, unambiguous, and well-supported by evidence on the web. I suspect
that instead of responding to what I said, you are responding to completely
different things. The links I use are in:
"A brief history of tables"
http://www.barry.pearson.name/articl...es/history.htm
I'll discuss here: "Right from their start in about 1993, tables were
intended, inter alia, for laying out complex material in rows & columns". I'll
do so bit by bit.
"Right from their start in about 1993..."
See Raggett's HTML+ proposal:
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html
That was published in 1993, the earliest proposal for HTML tables I can find.
I'll continue to use that document below.
"...complex material..."
See:
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_39.html
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_12.html
"Cells may contain, text, multiple paragraphs, lists and headers".
"Paragraphs can include the following: ... Images which act as single
characters and which can be vertically aligned relative to the text line in
which they are embedded ... Hypertext Links based on the URL or URN notations"
"laying out ... in rows & columns"
Do I *really* have to spell this out? The tags & attributes of table-mark-up
are in terms of rows & columns! It is a simple fact. (tr, colspan. rowspan;
and what do you think "width" & "height" mean?). Check what a dictionary says
about rows & columns.
Let's add some more. "Layout - where?"
See:
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_4.html
"HTML+ .... embodies a pageless model making it suitable for efficient
rendering on a wide range of display types including VT100 terminals, X11,
Windows 3.1 and the Macintosh".
What has changed since then? Let's see:
HTML3.2
http://www.w3.org/TR/REC-html32
Tables "HTML 3.2 includes a widely deployed subset of the specification given
in RFC 1942 and can be used to markup tabular material or for layout
purposes".... "TABLE can be nested"
And, of course, this will continue into the future. The XHTML Table Module
defines the content of a cell as "(PCDATA | Flow)*", which is pretty well
anything.
http://groups.google.com/groups?selm...55%40attbi_s03
Nothing in that contradicts anything above.
http://groups.google.com/groups?selm...02%40attbi_s03
What has that got to do with anything?
http://groups.google.com/groups?selm...61%40attbi_s52
That doesn't address the argument here. Assertion without evidence.
http://groups.google.com/groups?selm...23%40attbi_s01
Assertion without evidence.
And that's just one thread. Here's one from another thread:
http://groups.google.com/groups?selm...58%40attbi_s01
You consistently employ circular arguments! Instead of providing
counter-evidence, you use the tactic that if I disagree with you I must be
wrong! Tough!
How about another?
http://groups.google.com/groups?selm...21%40attbi_s01
More of the same.
Which you couldn't, of course!
You can't, of course, because the evidence for what I said above is
irrefutable. In fact, you don't even appear to be addressing my statement
above. You appear to be attacking some totally different proposition. So I'll
repeat my statement:
"Right from their start in about 1993, tables were intended, inter alia, for
laying out complex material in rows & columns".
Which I did. And so did many others. But at this point, I've stopped
trying to present arguments. It's wasted breath.
Until you can supply counter-evidence, of course you are wasting your breath!
You would need, first, to address my statement, and second, to provide
evidence that contradicted it. I believe such evidence doesn't exist.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Barry Pearson wrote: Before replying to your references below,
Then we agree that I *have* actually engaged in debate about this. But
I'm not going to continue. I won't feed the troll and more than I have.
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
Barry Pearson scribbled something along the lines of: Brian wrote:
Barry Pearson wrote:
Brian wrote:
Barry Pearson wrote:
>Right from their start in about 1993, tables were intended, inter
>alia, for laying out complex material in rows & columns.
Do you simply cut and paste this foolishness from a message
template whenever you repeat it?
It is the truth. I repeat it as required.
I note that you never attempt to supply evidence to the contrary.
Before replying to your references below, I'll emphasise my statement above.
It is clear, unambiguous, and well-supported by evidence on the web. I suspect
that instead of responding to what I said, you are responding to completely
different things. The links I use are in:
"A brief history of tables"
http://www.barry.pearson.name/articl...es/history.htm
I'll discuss here: "Right from their start in about 1993, tables were
intended, inter alia, for laying out complex material in rows & columns". I'll
do so bit by bit.
"Right from their start in about 1993..."
See Raggett's HTML+ proposal:
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html
That was published in 1993, the earliest proposal for HTML tables I can find.
I'll continue to use that document below.
"...complex material..."
See:
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_39.html
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_12.html
"Cells may contain, text, multiple paragraphs, lists and headers".
"Paragraphs can include the following: ... Images which act as single
characters and which can be vertically aligned relative to the text line in
which they are embedded ... Hypertext Links based on the URL or URN notations"
"laying out ... in rows & columns"
Do I *really* have to spell this out? The tags & attributes of table-mark-up
are in terms of rows & columns! It is a simple fact. (tr, colspan. rowspan;
and what do you think "width" & "height" mean?). Check what a dictionary says
about rows & columns.
Let's add some more. "Layout - where?"
See:
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_4.html
"HTML+ .... embodies a pageless model making it suitable for efficient
rendering on a wide range of display types including VT100 terminals, X11,
Windows 3.1 and the Macintosh".
You *do* realize HTML+ was not even a proposal? It was a discussion
document. That's pretty much the lowest status a W3C document can have
and means it has no meaning it all other than provide a basis for
discussion.
What has changed since then? Let's see:
HTML3.2
http://www.w3.org/TR/REC-html32
Tables "HTML 3.2 includes a widely deployed subset of the specification given
in RFC 1942 and can be used to markup tabular material or for layout
purposes".... "TABLE can be nested"
Sure, "for layout purposes", it said that. However it also added the
following:
"Note that the latter role typically causes problems when rending to
speech or to text only user agents."
They allowed the use for layout, but they already put a warning up.
You missed something out, tho:
http://www.w3.org/TR/html4/struct/tables.html#h-11.1 reads:
"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."
See how the mentioning of layout tables has been dropped.
Now let's read a bit further:
"*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*."
If you're thinking this isn't important because SHOULD would define a
mere suggestion, please read the RFC's definition of SHOULD.
Also note that the Modularization of XHTML / XHTML 1.1 recommendations
and DTDs don't mention a layout function of tables anymore at all:
http://www.w3.org/TR/xhtml-modulariz...s.html#sec_5.6.
Note that it only says:
"This module declares element types and attributes used to provide table
markup similar to HTML 4, including features that enable better
accessibility for non-visual user agents."
Which refers to the HTML 4 recommendation on which I commented earlier.
And, of course, this will continue into the future. The XHTML Table Module
defines the content of a cell as "(PCDATA | Flow)*", which is pretty well
anything.
Yes and no. You failed to quote the normative introduction in the
current XHTML 2.0 draft:
"The Tables Module provides elements for marking up tabular information
in a document."
See that there's no meaning of anything which sounds like layout anymore
AT ALL.
The fact about any kind of information can be tabular data doesn't mean
a table can serve a layout function. It just means the same as what the
HTML 4.01 spec read:
"The HTML table model allows authors to arrange data -- text,
preformatted text, images, links, forms, form fields, other tables,
etc.[..]"
<snip>
Various one-line responses to linked postings
</snip>
I note that you never attempt to supply evidence to the contrary.
Which you couldn't, of course!
You can't, of course, because the evidence for what I said above is
irrefutable. In fact, you don't even appear to be addressing my statement
above. You appear to be attacking some totally different proposition.
Well, I've pretty much pointed out why you're wrong by now.
So I'll
repeat my statement:
"Right from their start in about 1993, tables were intended, inter alia, for
laying out complex material in rows & columns".
They were intended to provide a means to present tabular data and were
_allowed_ to be used as a means to provide a layout. They are not
anymore and with every recommendation they have been restricted to data
(not layout) more and more.
Which I did. And so did many others. But at this point, I've stopped
trying to present arguments. It's wasted breath.
Until you can supply counter-evidence, of course you are wasting your breath!
You would need, first, to address my statement, and second, to provide
evidence that contradicted it. I believe such evidence doesn't exist.
Counter-evidence provided. Statement addressed. Evidence exists.
--
Alan Plum, WAD/WD, Mushroom Cloud Productions http://www.mushroom-cloud.com/
Ashmodai wrote:
Before I answer your points, I'll repeat my statement that is under discussion
here: "Right from their start in about 1993, tables were intended, inter alia,
for laying out complex material in rows & columns".
My reason for repeating this is that I suspect you mostly don't address that
statement. You appear to be arguing against some other points. I intend to
keep dragging this discussion back to that statement. Barry Pearson scribbled something along the lines of:
[snip] "Right from their start in about 1993..."
See Raggett's HTML+ proposal:
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html
That was published in 1993, the earliest proposal for HTML tables I
can find. I'll continue to use that document below.
"...complex material..."
See:
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_39.html
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_12.html
"Cells may contain, text, multiple paragraphs, lists and headers".
"Paragraphs can include the following: ... Images which act as single
characters and which can be vertically aligned relative to the text
line in which they are embedded ... Hypertext Links based on the URL
or URN notations"
"laying out ... in rows & columns"
Do I *really* have to spell this out? The tags & attributes of
table-mark-up are in terms of rows & columns! It is a simple fact.
(tr, colspan. rowspan; and what do you think "width" & "height"
mean?). Check what a dictionary says about rows & columns.
Let's add some more. "Layout - where?"
See:
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_4.html
"HTML+ .... embodies a pageless model making it suitable for
efficient rendering on a wide range of display types including VT100
terminals, X11, Windows 3.1 and the Macintosh".
You *do* realize HTML+ was not even a proposal? It was a discussion
document. That's pretty much the lowest status a W3C document can have
and means it has no meaning it all other than provide a basis for
discussion.
What has W3C got to do with this? Raggett published the HTML+ proposal in
November 1993. W3C came into being in October 1994. W3C established the
recommendation for HTML 3.2 in January 1997. It said tables "can be used to
markup tabular material or for layout purposes". Tables *long* preceded W3C!
They were proposed, and implemented, and took-off in the world, before W3C
said anything useful about them.
As far as I can tell, that 1993 Raggett proposal helped establish the table
mark-up that was implemented in browsers in 1994/5, and was published in pages
across the web in 1995/6, and hence was incorporated into the W3C HTML3.2
recommendation in 1997.
What has changed since then? Let's see:
HTML3.2
http://www.w3.org/TR/REC-html32
Tables "HTML 3.2 includes a widely deployed subset of the
specification given in RFC 1942 and can be used to markup tabular
material or for layout purposes".... "TABLE can be nested"
Sure, "for layout purposes", it said that. However it also added the
following:
"Note that the latter role typically causes problems when rending to
speech or to text only user agents."
So what? WAI sorted that out in April 1999.
http://www.w3.org/WAI/GL/wai-pr-issues#layout-tables
Since April 1999, the only useful statement about layout tables is that they
should linearise. And most do, apparently.
http://joeclark.org/book/sashay/seri...Chapter10.html
They allowed the use for layout, but they already put a warning up.
You missed something out, tho:
http://www.w3.org/TR/html4/struct/tables.html#h-11.1 reads:
"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."
See how the mentioning of layout tables has been dropped.
You appear to think that layout tables are somehow very different from other
tables. Not true. They are simply *tables*! They are about laying out
material, such as text, images, links, forms, form fields, other tables, etc,
in rows and columns. Which is what I keep saying. (And what your quote above
*also* said!)
I'll repeat what I said many times for comparison with what you just quoted:
"Right from their start in about 1993, tables were intended, inter alia, for
laying out complex material in rows & columns". You have just supported that
statement! Thank you. You will *never* be able to disprove it!
Now let's read a bit further:
"*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*."
See above. WAI superceded that in April 1999.
And just look how stupid that W3C statement is! It is dated 24 December 1997.
At that time, what CSS had been recommended? CSS1, of course. And what did the
CSS1 recommendation say? "CSS1 does not offer: ... a layout language". So the
HTML4 recommendation made a "should" statement that was *impossible* at the
time!
If you're thinking this isn't important because SHOULD would define a
mere suggestion, please read the RFC's definition of SHOULD.
See above - it appears to mean "we feel free to say "should" even though there
is no recommendation on the planet capable of achieving that "should".
I suggest you read the page below. You will find that things were not as you
believe they were:
"A brief history of tables"
http://www.barry.pearson.name/articl...es/history.htm
Also note that the Modularization of XHTML / XHTML 1.1 recommendations
and DTDs don't mention a layout function of tables anymore at all:
http://www.w3.org/TR/xhtml-modulariz...s.html#sec_5.6.
Who cares? Can't you see - layout tables use a *subset* of the standard table
mark-up. As far as the recommendations are concerned, they are
indistinguishable from other forms of table mark-up, (except, perhaps, for
their simplicity). Therefore, they cannot be subjected to a different
specification. So specifications cannot usefully talk about them.
That is why they will *never* be discriminated against by browsers. Have you
ever seen a reliable way of discriminating between a layout table and some
other sort? Have you ever seen a business rationale showing why any bit of
technology should be developed to support any such arbitrary discrimination?
On the whole, the difference exists only in your mind. So the recommendations
can't say anything about it.
Note that it only says:
"This module declares element types and attributes used to provide
table markup similar to HTML 4, including features that enable better
accessibility for non-visual user agents."
Which refers to the HTML 4 recommendation on which I commented
earlier.
Which was superceded in April 1999.
http://www.w3.org/WAI/GL/wai-pr-issues#layout-tables
And, of course, this will continue into the future. The XHTML Table
Module defines the content of a cell as "(PCDATA | Flow)*", which is
pretty well anything.
Yes and no. You failed to quote the normative introduction in the
current XHTML 2.0 draft:
"The Tables Module provides elements for marking up tabular
information in a document."
And does it define "tabular information" in a way that would enable any web
technology to behave differently for tabular information versus any other
sort? No! Anyone could mark-up whatever they like as a table, look you right
in the eye and say "this is tabular information", and you would be totally
impotent to do anything about it. This suggests that the concept of a layout
table exists in your mind, and the minds of a few other people, but may not
exist in the *real* world!
See that there's no meaning of anything which sounds like layout
anymore AT ALL.
See above. XHTML is incapable of discriminating between various types of
table. So the proposals cover them all.
The fact about any kind of information can be tabular data doesn't
mean a table can serve a layout function. It just means the same as
what the HTML 4.01 spec read:
"The HTML table model allows authors to arrange data -- text,
preformatted text, images, links, forms, form fields, other tables,
etc.[..]"
Yup! And it doesn't say anything that would rule out the use of tabes for
layout purposes. There is *nothing* in W3C recommendations that says that you
can only use table mark-up when there is a semantic relationship among the
rows & columns. How could there be? It would be *impossible* to make the
judgement!
It would be like saying "paragraph can only be used where the content of the
paragraph satisfies linguistic standards for paragraphs"! Of course that would
be stupid! What <p>...</P> actually means is "treat that as you would a
paragraph". And what <table>...</table> actually means is "treat this as you
would a table".
If an author marks-up something as a table, what right has anyone or anything
to decide otherwise? (Yes, they can express an opinion, of course).
[snip] You can't, of course, because the evidence for what I said above is
irrefutable. In fact, you don't even appear to be addressing my
statement above. You appear to be attacking some totally different
proposition.
Well, I've pretty much pointed out why you're wrong by now.
You haven't made a single point that refutes my statement "Right from their
start in about 1993, tables were intended, inter alia, for laying out complex
material in rows & columns".
[snip] "Right from their start in about 1993, tables were intended, inter
alia, for laying out complex material in rows & columns".
They were intended to provide a means to present tabular data and were
_allowed_ to be used as a means to provide a layout. They are not
anymore and with every recommendation they have been restricted to
data (not layout) more and more.
Not true. And until someone can identify a way of discriminating between
different types of tables, it *can't*, and *won't*, ever be true.
Layout tables are tables. It is as simple as that.
[snip] Until you can supply counter-evidence, of course you are wasting
your breath! You would need, first, to address my statement, and
second, to provide evidence that contradicted it. I believe such
evidence doesn't exist.
Counter-evidence provided. Statement addressed. Evidence exists.
See above. You haven't provided a single bit of counter-evidence. Because it
doesn't exist! I'll repeat my statement: "Right from their start in about
1993, tables were intended, inter alia, for laying out complex material in
rows & columns".
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Barry Pearson scribbled something along the lines of: Ashmodai wrote:
Before I answer your points, I'll repeat my statement that is under discussion
here: "Right from their start in about 1993, tables were intended, inter alia,
for laying out complex material in rows & columns".
My reason for repeating this is that I suspect you mostly don't address that
statement. You appear to be arguing against some other points. I intend to
keep dragging this discussion back to that statement.
Please get some grip of the real world and begin to learn that you
cannot address every statement directly. In many cases the solution is a
LITTLE more complicated.
Try and address the statement "Computer games cause violence" directly.
Of course "In about 19993 tables were intended [..] for laying out
complex material in rows and columns", but the statement "right from
their start" implies they are still intended for that purpose, which is
not the case and that is what I'm proving to you.
<snip/> What has W3C got to do with this? Raggett published the HTML+ proposal in
November 1993. W3C came into being in October 1994. W3C established the
recommendation for HTML 3.2 in January 1997. It said tables "can be used to
markup tabular material or for layout purposes". Tables *long* preceded W3C!
They were proposed, and implemented, and took-off in the world, before W3C
said anything useful about them.
As far as I can tell, that 1993 Raggett proposal helped establish the table
mark-up that was implemented in browsers in 1994/5, and was published in pages
across the web in 1995/6, and hence was incorporated into the W3C HTML3.2
recommendation in 1997.
If you accept the W3C as a standards authority, then you also have to
accept their standards.
With the release of HTML 3.2 the IETC's influence on the HTML language
ceased to exist. The W3C released an RFC [1] which obsoleted [2] the one
in which HTML 2.0 was specified. As of that point the W3C took care of
the development of the HTML language family as it previously did the
IETF by releasing the first HTML standard (HTML 2.0 wasn't the first
language, but the first released standard).
HTML 4.0 followed after HTML 3.2, then the HTML 4.01 standard replaced
HTML 4.0 and then the W3C released the first XHTML standard.
HTML 4.01 is therefore more important for the (up-to-date) definition of
what tables in HTML are meant to do than its predecessors.
<snip/>Sure, "for layout purposes", it said that. However it also added the
following:
"Note that the latter role typically causes problems when rending to
speech or to text only user agents."
So what? WAI sorted that out in April 1999.
http://www.w3.org/WAI/GL/wai-pr-issues#layout-tables
Since April 1999, the only useful statement about layout tables is that they
should linearise. And most do, apparently.
http://joeclark.org/book/sashay/seri...Chapter10.html
The full quote is "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." [3]
Note that the last Working Draft to the WCAG 2.0 reads the following:
"structural elements and attributes are used as defined in the
specification"
If you use HTML 3.2, feel free to use layout tables, otherwise use them
for what the standard explicitly permits.
I will not go on about how you contradict yourself here in referring to
the W3C after implying the W3C can't define the purpose of tables as
they didn't invent them.
<snip/>
http://www.w3.org/TR/html4/struct/tables.html#h-11.1 reads:
"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."
See how the mentioning of layout tables has been dropped.
You appear to think that layout tables are somehow very different from other
tables. Not true.
Yes they are. There's a semantic differences between a data table and a
layout table. If you use the table semantically, that's okay. If you
just use it to archeive a visual effect, that's not.
Tables may have a caption, headers, etc. However there is always a
semantic relationship between a cell and the row or a cell and a column.
If that isn't what you want, then don't use a table ferchrisakes.
It wouldn't make sense to have multiple paragraphs joined as an
unordered list simply because you want a dot in front of each paragraph
either.
They are simply *tables*! They are about laying out
material, such as text, images, links, forms, form fields, other tables, etc,
in rows and columns. Which is what I keep saying. (And what your quote above
*also* said!)
Right. Simply tables.
There's a huge difference between arranging data and creating a visual
presentation. Wanna know which one? Arranging data is about arranging
them semantically, creating a visual presentation doesn't require that.
If you can create a visual presentation with correct semantics, that's
okay for me.
<snip summary="same quote as usual"/>Now let's read a bit further:
"*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*."
See above. WAI superceded that in April 1999.
See above. WAI 2.0 clarifies that.
And just look how stupid that W3C statement is! It is dated 24 December 1997.
At that time, what CSS had been recommended? CSS1, of course. And what did the
CSS1 recommendation say? "CSS1 does not offer: ... a layout language". So the
HTML4 recommendation made a "should" statement that was *impossible* at the
time!
That was why in 1999 they removed it. W3C isn't stupid, they are just a
bit ahead of their time and their WGs also tend to interact a little too
little.
If you're thinking this isn't important because SHOULD would define a
mere suggestion, please read the RFC's definition of SHOULD.
See above - it appears to mean "we feel free to say "should" even though there
is no recommendation on the planet capable of achieving that "should".
That's okay. That simply means you "should not do that, but if there's
no other way to do it, then please do it so" (which is the RFC
definition of SHOULD NOT / SHOULD anyway).
Now there is another way.
I suggest you read the page below. You will find that things were not as you
believe they were:
"A brief history of tables"
http://www.barry.pearson.name/articl...es/history.htm
I read it and I read some other parts of your site too. I also read the
claim the image layout you use would only be possible with three divs
and I don't agree.
http://www.barry.pearson.name/photog...99_09_08_3.htm
This is your code:
<div class="outer">
<div class="middle">
<div class="inner">
<h1><img src="ch99_09_08_3.jpg" height="617" alt="Buildings in Pudong
New Area, Shanghai, China" width="700"></h1>
</div>
</div>
</div>
Which is insane, because you use three divs and a block element for the
simply border effect.
Try using this:
<div class="border">
<h1><img src="ch99_09_08_3.jpg" height="617" alt="Buildings in Pudong
New Area, Shanghai, China" width="700"></h1>
</div class="border">
As you can see I've dropped the pointless two divs.
The point is that you only need to apply an outset border style to the
..border div and an inset border style to the h1 element.
Simply set a margin for the h1 or a padding for the div. If you want
another space between the h1 and the image, apply a margin or padding on
either of them.
Don't claim you know the standards if you don't know how to apply them.
I also noted you use a ridiculous table for the info to the image and
another one for the page info.
Please use a definition list for the image info. It is quite obvious a
definition list fits the purpose better than a table here.
If you read into the CSS spec a little you might also find a sane way to
do the page info table on the bottom without a table element.
Also note that the Modularization of XHTML / XHTML 1.1 recommendations
and DTDs don't mention a layout function of tables anymore at all:
http://www.w3.org/TR/xhtml-modulariz...s.html#sec_5.6.
Who cares? Can't you see - layout tables use a *subset* of the standard table
mark-up. As far as the recommendations are concerned, they are
indistinguishable from other forms of table mark-up, (except, perhaps, for
their simplicity). Therefore, they cannot be subjected to a different
specification. So specifications cannot usefully talk about them.
No, you mistake the DTD for the recommendation here. Just because the
DTD's code says it may be any "flow" element or PCDATA, that doesn't
mean the content may be of any nature. The DTD itself cannot tell you to
use only semantic content, the human readable recommendation can.
That's why the WCAG for example isn't machine-validatable.
That is why they will *never* be discriminated against by browsers. Have you
ever seen a reliable way of discriminating between a layout table and some
other sort?
Have you ever seen a reliable way of discriminating between a landscape
picture and a porn image? No? Oh wonders.
Also note browsers will support tag soup for a long time, that means
they support even worse things than non-semantic markup.
Have you ever seen a business rationale showing why any bit of
technology should be developed to support any such arbitrary discrimination?
On the whole, the difference exists only in your mind. So the recommendations
can't say anything about it.
The difference between semantics and presentation exist in people's
minds, yes, but semantic markup is a concept and recommendations can
enforce concepts.
Note that it only says:
"This module declares element types and attributes used to provide
table markup similar to HTML 4, including features that enable better
accessibility for non-visual user agents."
Which refers to the HTML 4 recommendation on which I commented
earlier.
Which was superceded in April 1999.
http://www.w3.org/WAI/GL/wai-pr-issues#layout-tables
Ah, yes? We're talking about Modularization of XHTML here. The latest
version is dated 2001. WCAG 1 on the other hand is dated 1999.
And, of course, this will continue into the future. The XHTML Table
Module defines the content of a cell as "(PCDATA | Flow)*", which is
pretty well anything.
Yes and no. You failed to quote the normative introduction in the
current XHTML 2.0 draft:
"The Tables Module provides elements for marking up tabular
information in a document."
And does it define "tabular information" in a way that would enable any web
technology to behave differently for tabular information versus any other
sort? No! Anyone could mark-up whatever they like as a table, look you right
in the eye and say "this is tabular information", and you would be totally
impotent to do anything about it. This suggests that the concept of a layout
table exists in your mind, and the minds of a few other people, but may not
exist in the *real* world!
Common sense dictates what can and cannot be tabular information.
There's nothing which stricly is tabular information, it's just a
question of whether it can be expressed within the sementics provided by
a table.
Having a page footer expressed as a table simply because it consists of
three columns doesn't carry any semantics.
See that there's no meaning of anything which sounds like layout
anymore AT ALL.
See above. XHTML is incapable of discriminating between various types of
table. So the proposals cover them all.
See above. Does not.
The fact about any kind of information can be tabular data doesn't
mean a table can serve a layout function. It just means the same as
what the HTML 4.01 spec read:
"The HTML table model allows authors to arrange data -- text,
preformatted text, images, links, forms, form fields, other tables,
etc.[..]"
Yup! And it doesn't say anything that would rule out the use of tabes for
layout purposes. There is *nothing* in W3C recommendations that says that you
can only use table mark-up when there is a semantic relationship among the
rows & columns. How could there be? It would be *impossible* to make the
judgement!
There's nothing in it that says you can use table for sole layout
purposes, either.
It would be like saying "paragraph can only be used where the content of the
paragraph satisfies linguistic standards for paragraphs"! Of course that would
be stupid! What <p>...</P> actually means is "treat that as you would a
paragraph". And what <table>...</table> actually means is "treat this as you
would a table".
Well, you wouldn't mark up an image or a table as a paragraph. Why would
you mark up a paragraph as a two-cell table then (other than just for
presentational purposes)?
If an author marks-up something as a table, what right has anyone or anything
to decide otherwise? (Yes, they can express an opinion, of course).
You are mistaking following internet standards and conventions for
restricting the right to express one's opinion there.
If I see something that uses the semantic relations of a list, I can say
it is a list. If I see something that has the semantic relations of a
table, it is a table. If it's got the semantics of a pink squirrel, well
guess what I'll say.
You are free to write all you want to write, but you should not use
languages in a way different to how they are meant to be used.
If you want layout tables, please go ahead and write your pages
according to the HTML 3.2 standard or the HTML+ discussion document
even. If you don't like either, make your own language and call it "HTML
4.01 + Layout Tables" or whatever you want to call it.
XHTML explicitly allows you to make your own XHTML family member (i.e.
any language which is mostly XHTML can have the XHTML namespace). XML
even allows you to make your own markup language.
Go ahead! It's the direction most web authors might eventually look in
anyway.
[snip]
You can't, of course, because the evidence for what I said above is
irrefutable. In fact, you don't even appear to be addressing my
statement above. You appear to be attacking some totally different
proposition.
Well, I've pretty much pointed out why you're wrong by now.
You haven't made a single point that refutes my statement "Right from their
start in about 1993, tables were intended, inter alia, for laying out complex
material in rows & columns".
See initial explanation on why I _can't_ directly address your statement.
[snip]
"Right from their start in about 1993, tables were intended, inter
alia, for laying out complex material in rows & columns".
They were intended to provide a means to present tabular data and were
_allowed_ to be used as a means to provide a layout. They are not
anymore and with every recommendation they have been restricted to
data (not layout) more and more.
Not true. And until someone can identify a way of discriminating between
different types of tables, it *can't*, and *won't*, ever be true.
As I said, it's about semantics.
Layout tables are tables. It is as simple as that.
Layout tables CAN be tables. They mustn't. They are if they carry the
semantic relations of a table. If they don't, then not.
[snip]
Until you can supply counter-evidence, of course you are wasting
your breath! You would need, first, to address my statement, and
second, to provide evidence that contradicted it. I believe such
evidence doesn't exist.
Counter-evidence provided. Statement addressed. Evidence exists.
See above. You haven't provided a single bit of counter-evidence. Because it
doesn't exist! I'll repeat my statement: "Right from their start in about
1993, tables were intended, inter alia, for laying out complex material in
rows & columns".
I will hire a contract killer if you dare repeating a quote instead of
bringing up actual evidence in response to a statement again.
I have a peaceful suggestion tho.
We apparently agree that layout tables are tables in the presentational
sense. That is, they look table-ish. We also might agree that a table is
a table if its elements have a semantic relationship which is like the
one of table elements.
Could we therefore conclude that layout tables -- although their
validity can legally be questioned because the W3C's working groups
contradict each other there a little -- are tables in the HTML 4.01 (or
XHTML for that matter) sense (or 'have the table nature' ::snikers::)
only if they are used according to their semantics, whether they (also)
lay out a website or not?
I'm not saying you are essentially wrong. I'm saying neither of us
essentially right, but I still insist that layout tables should (looking
at the direction the recs are going and the semantic web activity) be
avoided where possible (i.e. where not essential for backwards
compatibility or other reasons like avoiding excessive DIVitis) and
slowly abandoned once CSS reaches a (widely supported) state in which
the same layout can easily be archieved without them.
Do we agree enough to stop this nonsense there?
[1] http://www.rfc-editor.org/rfc/rfc2854.txt (issued by the W3C)
[2] http://www.w3.org/MarkUp/ :
"Note that with the release of RFC 2854, RFC 1866 [i.e. HTML 2.0] has
been obsoleted and its current status is HISTORIC."
[3] http://www.w3.org/TR/WCAG10-HTML-TECHS/#tables-layout
--
Alan Plum, WAD/WD, Mushroom Cloud Productions http://www.mushroom-cloud.com/
On Sun, 18 Apr 2004 00:49:24 +0100, Barry Pearson
<ne**@childsupportanalysis.co.uk> wrote: Ashmodai wrote:
Before I answer your points,
See, it's not top posting...
You haven't made a single point that refutes my statement "Right from
their
start in about 1993, tables were intended, inter alia, for laying out
complex
material in rows & columns".
Because that statement is so vague and basically true no one can
truthfully refute it. The error is in extending this to mean that laying
out pages with tables is a fine thing to do.
Table markup was indeed intended for laying out complex TABULAR material
in rows and columns. That's why they called it TABLE markup.
Tables express relationships in rows and columns. All items in one column
have something in common, all items in one row do as well. Page layout
tables do not follow this convention.
Tabular data is data which can be arranged in this manner of columns and
rows expressing a shared trait. There is no sense in arguing that table
markup is not intended for tabular data because it's an absolutely
ignorant argument to make.
By leaving out the fact that the "complex material" which goes into table
markup must be tabular, you use a vaguely true statement to support your
spurious contentions.
Neal wrote: On Sun, 18 Apr 2004 00:49:24 +0100, Barry Pearson
<ne**@childsupportanalysis.co.uk> wrote:
[snip] You haven't made a single point that refutes my statement "Right from
their start in about 1993, tables were intended, inter alia, for laying
out complex material in rows & columns".
Because that statement is so vague and basically true no one can
truthfully refute it.
You are on the way! It isn't vague - it is specific enough that it could in
principle be falsified on various grounds. But in practice, the evidence
overwhelmingly supports it, so it is indeed basically true. (It isn't an
accident that the evidence supports it! I constructed that statement after
searching for early, and later, statements about what tables were intended
for).
In a complex topic, and especially one where there are huge differences of
opinion, a well-recognised approach is to establish a "baseline" of things
that can simply be accepted by all. Then the discussion can focus on the areas
of difference. My statement above was intended to be part of such a baseline -
something where everyone could say "we all know that, now let's talk about
what we don't agree on". My whole page "A brief history of tables" was
intended to be such a baseline. That is why it has so many external links
(about 60), many of them to W3C (about 25), and why it typically quotes from
those sources using copy-&-paste rather than risk transcription errors and
distortions via paraphrasing.
The error is in extending this to mean that
laying out pages with tables is a fine thing to do.
[snip]
Whether or not it is fine to do so depends on the consequences in any specific
case. Consequences can be examined and evaluated. There will often be some
guesswork, and some subjective judgements. Then publishers & authors need to
make their own decisions, and live with them. I think what is needed is
good-quality guidance on making those judgements. I have seen little guidance
that stands up to scrutiny. Most guidance appears to attempt to prove a
particular point of view.
The evaluation can be considered in (at least) 2 areas: the effectiveness of
the communication with the audience, now and in the future; and the project
parameters such as cost, risk, and time.
The reason for examining the recommendations, as I have done, is to make
predictions about how effective tables are likely to be. Will a compliant
browser choke on a layout table? Perhaps throw all the content away? Perhaps
render the content upside-down or in the opposite order? Perhaps treat an
element within a layout table in a totally different way from how that same
element is treated outside such a table? Perhaps only render simple content,
and discard complex (multi-element) content?
(Those questions are very different from whether or not a compliant browser
must render them as rows & columns. Of course it doesn't have to. It may speak
the content instead, or disable the tables to fit the content on a small
screen).
There do not appear to be any such problems. They are not deprecated. (You can
use a layout table in valid XHTML 1.1). The formatting & rendering models are
good enough for people to assume that content will be linearisied. (A browser
that does choke on a layout table in one of the above ways would probably have
serious problems in the marketplace!) So evaluation can move on to other
things, such as accessibility, potential for change, project cost, etc. This
is basic engineering.
(Interestingly, using blockquote to indent text *is* explicitly deprecated in
one part of the HTML 4.01 recommendation! Now, what does that *formally* mean?
What will happen in future?)
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/ This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Xah Lee |
last post by:
with strict HTML spec, can one have <p> tags inside table's <td> tag?
also, in strict XHTML, can one have <p> tages inside <div>?
Thanks.
Xah
xah@xahlee.org
∑ http://xahlee.org/
|
by: Alan Hoyle |
last post by:
I was using a <table border> to generate borders around some
info/images, and decided to follow the w3c guidelines and convert it
to CSS boxes with borders since it wasn't really tabular data.
...
|
by: slim |
last post by:
hi again all,
i am still working on the website as mentioned in earlier threads and
have hit another snag...
http://awash.demon.co.uk/index.php
http://awash.demon.co.uk/vd.css
the php is...
|
by: listaction |
last post by:
Hi Folks,
can you help me by explaining how the code below can be translated
using <div> and achieve the same effect?
Thanks,
LA
<html>
<body>
<table bgcolor="#000000" width="100%"...
|
by: Alan Silver |
last post by:
Hello,
I would like to know if it is possible to use a panel, but prevent it
from adding a <div> tag to the HTML. The reason I want to do this is
that I am using a panel to enable me to...
|
by: Mark |
last post by:
Dear folks,
In Javascript, is it possible to get all id names within, say, a
<div></divpair? Like the array of "document.images", I mean.
The reason I ask, is that I have a calender whose...
|
by: Davo |
last post by:
Hi Folks,
There seems to be something about not using tables for layout, but use divs
instead. I'm not sure if I've got this right. If the output looks like what
you want, then it shouldn't...
|
by: slartybartfast |
last post by:
I'm new(ish) to css, comfortable using tables, but trying real hard to move away.
Please see http://84.9.125.31/developer/css_test/test5.html
NB This issue is with IE & Opera - I've tried IE...
|
by: harryusa |
last post by:
I am trying to center 2 images concentrically which are z-indexed to lay on top of each other making an image with a border from another image that has a transparent center. I need the images to be...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
