grid structures: TABLE/TR/TD vs. DIV

phil-news-nospam (AT) ipal (DOT) net wrote:

On Fri, 05 May 2006 08:10:01 +0100 Steve Pugh <steve (AT) pugh (DOT) net> wrote:

| Consider your blocks of text that you want to arrange in a grid. Now
| take the block of text that's at the intersection of the third row and
| the second column. What does that fact that it's at that intersection
| _mean_?

That can depend. It might be more important that it is in the second
column.

So you can swap the items in the third row, second column and fifth
rowm second column, without changing the meaning of the page?

That's almost certaibly not a data table and hence should not be
marked up with HTML table elements.

| In a table it means something. e.g. it means that it's the printer
| sales figure for France (row) in May 2005 (column); or that the black
| queen is on square C6 (which is why I think the chessboard is a valid
| table).
|
| But it just means that this block of text is in the third row and the
| second column, then there are no table semantics. And hence HTML
| tables should not be used, but CSS display: table-* can be used to
| give the appearance a table like grid effect.

I saw a demonstration of display: table-* that did not do the job.
Maybe that demonstration was defective and you can provide a better
one?

I'd need to know in which way it "did not do the job".

| It's all about the semantics. A table has semantics whereby any piece
| of content belongs to a row and column and that belonging has a set
| meaning. A 'grid' just has the same appearance but none of the
| semantics.

I've found more than one kind of semantics for a grid.

A grid has no semantics.

One demo page
I was showed an invisible grid with thumbnail pictures. When the size
of the displayable area was shrunk, the object on the right moved to
the next lower row and on the left. For some kinds of semantics this
would be fine (and I've done stuff like that, too). But for others it
is not.

If it's just an image gallery then in terms of semantics that's not a
problem. In terms of layout it might not match the designer's vision
and then it becomes an issue of usability v. design fidelity in the
edge case or users with narrow browser windows.

| One way to decide whether your data belongs in a table or not is to
| consider whether every row and column could be given a heading, i.e.
| could you include a <th> for each row and column?

In some cases they could be. Or it could be implied and not actually
shown (which I think you intended to include by your choice of the word
"could").

Or by the bit a little later where I say "It's not always necessary to
then go and put these headings in the page (though it's usually a very
good idea to do so)"

The important thing is that if it's a table then at least one, and
often both, of rows or columns must have some sort of easily labelled
relationship.

| One that will be meaningful, so that if an aural browser read out
| [heading for row 3, heading for column 2, content of cell at
| intersection of row 3 and column 2] it would make sense.
|
| It's not always necessary to then go and put these headings in the
| page (though it's usually a very good idea to do so) but if you don't
| have any headings for your rows or columns then there's a good chance
| that semantically you don't have a data table and hence you should be
| looking at CSS tables not HTML tables.

However, what I ahve in mind right now needs to have the layout semantics
of TABLE/TR/TD.

"Layout semantics". That doesn't really make sense. Some semantics
demand a particular layout (though for most data tables you can rotate
by 90 degrees - i.e. swap rows and columns - and maintain the
semantics) and in general the layout may give visual hints towards the
underlying semantics (unless the author has done something stupid like
make all of H1 - H6 appear the same) but the semantics and the
presentation are different things.

I've seen some examples that correct the flow problem
(e.g. they made the right column stay at the right)

For a table, where the data in a row must stay in a row otherwise the
meaning is distorted, that is essential. For a layout where the
meaning is the same but the presntation is different that is totally
optional.

but they had other
issues which I don't know can be corrected (in part because I have seen
that problem in a _lot_ of web pages, so I worry that it could be an issue
of CSS).

What is this other problem?

| Of course this is somewhat academic as IE6 doesn't support CSS tables,
| so if your design really demands a grid then you must either abuse
| HTML tables or change the design.

For a long time I avoided CSS altogether because of the browser upgrade
barrier. Firefox has managed to break that barrier because:
1. It seems to be a very compliant implementation
2. It's portable (Linux, BSD, Unix, Mac, and Windows)
3. It didn't bloat too much in relation to machine capability of the day
Basically, it means I feel good about recommending to everyone that they
use Firefox. Had IE also met all these requirements for just Windows, and
Firefox not been ported to Windows, I could have accepted recommending IE
for Windows users and Firefox for everyone else. But at least there is a
browser I can recommend (and it happens to be the same one for all).

I would largely agree (I use Opera myself and the same points can be
said about that browser). However, IE is still at least 80% of the
population, so it can not be ignored. Otherwise CSS tables would be a
semantics neutral layout grid solution.

Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve (AT) pugh (DOT) net> <http://steve.pugh.net/>

Show me CSS2 coding that will produce tables with the same semantics that
TABLE/TR/TD has, and maybe I could believe it's an implementatuon issue.

For another issue with CSS, take a block of text in a _single_ DIV element
and using CSS only, style that block so it appears with a drop shadow effect
without changing the HTML at all. I had to add extra DIV elements to get it
to work, and found that a couple other people doing the same thing did it
the same way (though I went a step further and added yet another DIV to make
an effect that raised and lowered the shadow effect based on hover). Better
CSS would allow doing anything like that wihtout changing HTML at all. If
the style needs more container context, then CSS should be able to logically
include that.

Here's one of the pages I was experimenting with:
http://phil.ipal.org/usenet/ciwas/20...in-tables.html
Be careful with the top right and bottom left corners as they can result in
the raising/lowering effect oscillating if you position the pointer on the
pixels that move away.

I think you underestimate what's possible with CSS:

http://www.paradice-insight.us/tests/drop-shadow.html

It has it's problems, but shows that you _can_ adress complex (HTML)
tasks 'successfull' in CSS, also it shows that CSS develops into the
right direction anyway.
Regarding your 'table-problem' there is the grid-supporting
'display'-attribute in CSS3 which is better suited for grid than tables
are (try to make floating L- or U-forms with tables).

Ciao
Niels

That data could just as easily come out as:

apple banana bread cherry hazelnut
mango orange pear potato tomato

or as:

apple banana bread
cherry hazelnut mango
orange pear potato
tomato

This example is not what I have been talking about.

But I'll talking about it briefly, anyway. I'd like to have a COLUMN
orientation version of that, which would come out like this:

apple bread hazelnut orange potato
banana cherry mango pear tomato

or in a narrower window like:

apple cherry orange tomato
banana hazelnut pear
bread mango potato

or even:

apple hazelnut potato
banana mango tomato
bread orange
cherry pear

There are some things where this would work better, such as a list of
files in a folder/directory. But it would be style ... something to
decide how to present. Does CSS have a way to say to list stuff this
way? In case someone doesn't see what I'm showing, just look at the
alphabetical sequence of these "food items".

You're changing language-semantics here, this is
direction: ltb (gravity left, order top-to-bottom)
float: top
whereas western style is 'tlr'.

Also it goes into the direction of:

http://www.quirksmode.org/css/multicolumn.html

Both have the same 'problem', the restrictor is _height_
not _width_, but that's only natural behaviour (consistent
with the definition of direction in both cases).

But if I have 2-dimentional data, then this is not the thing to be doing.
So I'm still back to using TABLE/TR/TD, etc., for the 2-D stuff.

Ciao
Niels

On Fri, 05 May 2006 19:37:07 +0100 Steve Pugh <steve (AT) pugh (DOT) net> wrote:

phil-news-nospam (AT) ipal (DOT) net wrote:

On Fri, 05 May 2006 08:10:01 +0100 Steve Pugh <steve (AT) pugh (DOT) net> wrote:

| Consider your blocks of text that you want to arrange in a grid. Now
| take the block of text that's at the intersection of the third row and
| the second column. What does that fact that it's at that intersection
| _mean_?

That can depend. It might be more important that it is in the second
column.

So you can swap the items in the third row, second column and fifth
rowm second column, without changing the meaning of the page?

In some such cases, sure. Maybe not in others. It depends on which site
and the nature of that content.

That's almost certaibly not a data table and hence should not be
marked up with HTML table elements.

But until I see a way to make it work correctly in CSS, I fall back to
what does work, and will still use TABLE elements, regardless of any
debate over whether the meaning is appropriate.

| In a table it means something. e.g. it means that it's the printer
| sales figure for France (row) in May 2005 (column); or that the black
| queen is on square C6 (which is why I think the chessboard is a valid
| table).
|
| But it just means that this block of text is in the third row and the
| second column, then there are no table semantics. And hence HTML
| tables should not be used, but CSS display: table-* can be used to
| give the appearance a table like grid effect.

I saw a demonstration of display: table-* that did not do the job.
Maybe that demonstration was defective and you can provide a better
one?

I'd need to know in which way it "did not do the job".

I've seen several different examples over the past few days and cannot
say which is which anymore. I don't bother to try to remember all the
details of things where the other party isn't trying to follow through
on those issues. I just dismiss it and remember that some greater number
of examples still don't work.

Of course, if you are wanting make something work, and follow through
to get it working in all ways, I'm certainly willing to give feedback.

But here are some of the issues I have seen:

1. It must be a separate CSS file that works regardless of how many
different columns the HTML marked up content has.

2. It must not "float" any items down to following "rows" (what appears
to be a row).

3. Text (and everything else) must not bleed out from the bounds of the
cell. If the font size is too large, it must keep either whole words,
or at least whole character glyphs, within the cell, even if that means
the total width forces horizontal scrolling.

There may be other issues. In all, the way TABLE/TR/TD elements work in
HTML must be retained.

| It's all about the semantics. A table has semantics whereby any piece
| of content belongs to a row and column and that belonging has a set
| meaning. A 'grid' just has the same appearance but none of the
| semantics.

I've found more than one kind of semantics for a grid.

A grid has no semantics.

Sure it does. But there's no real value in debating words. What I want
is what a grid is with the semantics that I see with TABLE/TR/TD elements.

To me, it's a grid if it meets certain criteria. I call those criteria
the semantics of a grid. But maybe it might be clearer to shift the
usage over to something like "rigid grid".

One demo page
I was showed an invisible grid with thumbnail pictures. When the size
of the displayable area was shrunk, the object on the right moved to
the next lower row and on the left. For some kinds of semantics this
would be fine (and I've done stuff like that, too). But for others it
is not.

If it's just an image gallery then in terms of semantics that's not a
problem. In terms of layout it might not match the designer's vision
and then it becomes an issue of usability v. design fidelity in the
edge case or users with narrow browser windows.

To me, the image gallery in such a case is a list (of images that may be
captioned individually and may be hyperlinekd) which is presented in a
convenient form (but could also be presented in an inconvenient form).
I have seen image galleries entirely vertical, and that way annoying.
But it's really not any different than a list, other than what happens to
be in the elements of the list. Choosing to let the list flow horizontally
is usually a good idea. The good image galleries do that.

But I wasn't talking about an image gallery when I was bringing up the
overall table issue.

| One way to decide whether your data belongs in a table or not is to
| consider whether every row and column could be given a heading, i.e.
| could you include a <th> for each row and column?

In some cases they could be. Or it could be implied and not actually
shown (which I think you intended to include by your choice of the word
"could").

Or by the bit a little later where I say "It's not always necessary to
then go and put these headings in the page (though it's usually a very
good idea to do so)"

The important thing is that if it's a table then at least one, and
often both, of rows or columns must have some sort of easily labelled
relationship.

One thing I have found is that there is some variation among people who
have written in this and other threads about what is a table. Most will
agree that the kind of data found in a spreadsheet is appropriate. But
I can tell you that I've seen some really bizarre spreadsheet files in
some places. Some other people seem to be more accepting of just about
anything in each of the cells, and still call it a table as long as there
simply is the row/column relationship (with the implication that the table
elements in HTML would be OK).

| One that will be meaningful, so that if an aural browser read out
| [heading for row 3, heading for column 2, content of cell at
| intersection of row 3 and column 2] it would make sense.
|
| It's not always necessary to then go and put these headings in the
| page (though it's usually a very good idea to do so) but if you don't
| have any headings for your rows or columns then there's a good chance
| that semantically you don't have a data table and hence you should be
| looking at CSS tables not HTML tables.

However, what I ahve in mind right now needs to have the layout semantics
of TABLE/TR/TD.

"Layout semantics". That doesn't really make sense. Some semantics
demand a particular layout (though for most data tables you can rotate
by 90 degrees - i.e. swap rows and columns - and maintain the
semantics) and in general the layout may give visual hints towards the
underlying semantics (unless the author has done something stupid like
make all of H1 - H6 appear the same) but the semantics and the
presentation are different things.

Actually, the rotation would retain the relationship; it would just be
in a less convenient form.

I've seen some examples that correct the flow problem
(e.g. they made the right column stay at the right)

For a table, where the data in a row must stay in a row otherwise the
meaning is distorted, that is essential. For a layout where the
meaning is the same but the presntation is different that is totally
optional.

In a table, the data must also stay in the column. In some cases swapping
whole columns across all rows is OK. In some cases (not necessarily the
same set of cases just mentioned) swapping whole rows across all columns
is OK. In other cases, any swapping is not OK.

but they had other
issues which I don't know can be corrected (in part because I have seen
that problem in a _lot_ of web pages, so I worry that it could be an issue
of CSS).

What is this other problem?

See the list I gave above. The biggest one I was thinking about while
writing that was the bleeding of text out of the cell.

| Of course this is somewhat academic as IE6 doesn't support CSS tables,
| so if your design really demands a grid then you must either abuse
| HTML tables or change the design.

For a long time I avoided CSS altogether because of the browser upgrade
barrier. Firefox has managed to break that barrier because:
1. It seems to be a very compliant implementation
2. It's portable (Linux, BSD, Unix, Mac, and Windows)
3. It didn't bloat too much in relation to machine capability of the day
Basically, it means I feel good about recommending to everyone that they
use Firefox. Had IE also met all these requirements for just Windows, and
Firefox not been ported to Windows, I could have accepted recommending IE
for Windows users and Firefox for everyone else. But at least there is a
browser I can recommend (and it happens to be the same one for all).

I would largely agree (I use Opera myself and the same points can be
said about that browser). However, IE is still at least 80% of the
population, so it can not be ignored. Otherwise CSS tables would be a
semantics neutral layout grid solution.

.... once I see a CSS table that works just like an HTML table for all the
aspects that are important to me (there might be some aspect of HTML tables
I'm not aware of or don't remember because it wasn't important to me, and
such an aspect could be left out of a CSS table and it would not bother me).

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

On 5 May 2006 12:28:38 -0700 niels.froehling (AT) seies (DOT) de wrote:

That data could just as easily come out as:

apple banana bread cherry hazelnut
mango orange pear potato tomato

or as:

apple banana bread
cherry hazelnut mango
orange pear potato
tomato

This example is not what I have been talking about.

But I'll talking about it briefly, anyway. I'd like to have a COLUMN
orientation version of that, which would come out like this:

apple bread hazelnut orange potato
banana cherry mango pear tomato

or in a narrower window like:

apple cherry orange tomato
banana hazelnut pear
bread mango potato

or even:

apple hazelnut potato
banana mango tomato
bread orange
cherry pear

There are some things where this would work better, such as a list of
files in a folder/directory. But it would be style ... something to
decide how to present. Does CSS have a way to say to list stuff this
way? In case someone doesn't see what I'm showing, just look at the
alphabetical sequence of these "food items".

You're changing language-semantics here, this is
direction: ltb (gravity left, order top-to-bottom)
float: top
whereas western style is 'tlr'.

That's not something I've ever heard of.

Also it goes into the direction of:

http://www.quirksmode.org/css/multicolumn.html

Both have the same 'problem', the restrictor is _height_
not _width_, but that's only natural behaviour (consistent
with the definition of direction in both cases).

I don't really see any "problem" there. The multi-column stuff looks good.
I've curious why this wasn't in earlier versions of CSS. I'll bet that
when it is widely available, it will get used a lot.

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

On 5 May 2006 11:50:43 -0700 niels.froehling (AT) seies (DOT) de wrote:

Show me CSS2 coding that will produce tables with the same semantics that
TABLE/TR/TD has, and maybe I could believe it's an implementatuon issue.

For another issue with CSS, take a block of text in a _single_ DIV element
and using CSS only, style that block so it appears with a drop shadow effect
without changing the HTML at all. I had to add extra DIV elements to get it
to work, and found that a couple other people doing the same thing did it
the same way (though I went a step further and added yet another DIV to make
an effect that raised and lowered the shadow effect based on hover). Better
CSS would allow doing anything like that wihtout changing HTML at all. If
the style needs more container context, then CSS should be able to logically
include that.

Here's one of the pages I was experimenting with:
http://phil.ipal.org/usenet/ciwas/20...in-tables.html
Be careful with the top right and bottom left corners as they can result in
the raising/lowering effect oscillating if you position the pointer on the
pixels that move away.

I think you underestimate what's possible with CSS:

http://www.paradice-insight.us/tests/drop-shadow.html

That middle one oscillates when you move the pointer just into the bottom
of it. I fixed the effect in my drop shadow boxes by enclosing everything
in an invisible outer box (DIV) that had the :hover on it's selector.

It has it's problems, but shows that you _can_ adress complex (HTML)
tasks 'successfull' in CSS, also it shows that CSS develops into the
right direction anyway.
Regarding your 'table-problem' there is the grid-supporting
'display'-attribute in CSS3 which is better suited for grid than tables
are (try to make floating L- or U-forms with tables).

When will CSS3 be widely usable?

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

| You're changing language-semantics here, this is
| direction: ltb (gravity left, order top-to-bottom)
| float: top
| whereas western style is 'tlr'.

That's not something I've ever heard of.

It isn't reality, sadly. You may find an in depth discussion
about vertical text-flow here:

http://fantasai.inkedblade.net/style...vertical-text/

Pardon for not using the appropriate acronym, I wrote out of
my memory, it's "rtl" (left + top-down) and "ltr" (top + left-right).
Because all of this it quiet a mess, "float: top;" in "rtl" should
be the correct floating-equivalent of "float: left;" in "ltr", but as
you may see in:

http://www.w3.org/TR/css3-roadmap/
3.6 Box model / vertical -> Floating boxes to top/bottom of page

has no description, so I'm assuming that it will be named 'top'.

Ciao
Niels

| Regarding your 'table-problem' there is the grid-supporting
| 'display'-attribute in CSS3 which is better suited for grid than tables
| are (try to make floating L- or U-forms with tables).

When will CSS3 be widely usable?

When something called 'consensus' will become widely
accepted ...
If I remember right CSS3 is not even a draft of concept.
Anyway, for me it's strange that 'text/css' is the only styling-
form available. I guess for some sites 'text/gamess' is more
appropriate (no offense! I really think different concepts need
different realizations, for ex. games are not really using qt3
for controling). An explanation can be that the CSS-idea is
so much manifest that you can't even _plug-in_ other styling-
languages into a browser (not to speak of scripting-languages,
I would love to have Rexx in FireFox).

Ciao
Niels

On 5 May 2006 16:07:16 -0700 niels.froehling (AT) seies (DOT) de wrote:

languages into a browser (not to speak of scripting-languages,
I would love to have Rexx in FireFox).

<offtopic topic="comp.programming">
It would be nice to have a universal programming API in various languages
for access to libraries of code to implement various scripting languages
so that a browser, or any other program, could make use of scripting tools.
A few languages do have some interfaces. But there is no universal one
that I've ever heard of that would allow an application like a browser to
access each different scripting language library with the same common API.
OTOH, given some of the APIs I've seen out there, it would probably end up
becoming another mess. Many of those APIs use methods (callbacks, longjmp)
that inhibit layering another library around it.
</offtopic>

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

phil-news-nospam (AT) ipal (DOT) net wrote:

On Fri, 05 May 2006 19:37:07 +0100 Steve Pugh <steve (AT) pugh (DOT) net> wrote:
| phil-news-nospam (AT) ipal (DOT) net wrote:
|>On Fri, 05 May 2006 08:10:01 +0100 Steve Pugh <steve (AT) pugh (DOT) net> wrote:

|>| It's all about the semantics. A table has semantics whereby any piece
|>| of content belongs to a row and column and that belonging has a set
|>| meaning. A 'grid' just has the same appearance but none of the
|>| semantics.
|
|>I've found more than one kind of semantics for a grid.
|
| A grid has no semantics.

Sure it does. But there's no real value in debating words. What I want
is what a grid is with the semantics that I see with TABLE/TR/TD elements.

The semantics of a table are "This is a table, there are relationships
between the items in the rows and columns as specified by the row and
column headers". Those semantics remain the same regardless of whether
the table is presented as a 2d grid on a screen/piece of paper, read
out in some way by a speech browser, linearised by a braile device,
stripped to its component pieces by a script and inserted into a
database, etc.

A grid does not have those semantics. A grid just has presentation, it
says nothing about what the dat _is_ but everything about how the data
_looks_.

I strongly suspect that you are not using the word semantics in the
same way as the rest of us. Which lets me make a terrible
meta-something joke and ask you "what do you mean by semantics?" ;-)

To me, it's a grid if it meets certain criteria. I call those criteria
the semantics of a grid. But maybe it might be clearer to shift the
usage over to something like "rigid grid".

Probably for the best.

Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <steve (AT) pugh (DOT) net> <http://steve.pugh.net/>