469,270 Members | 1,164 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,270 developers. It's quick & easy.

grid structures: TABLE/TR/TD vs. DIV

Is there really any advantage to using DIV elements with float style
properies, vs. the old method of TABLE and TR and TD?

I'm finding that by using DIV, it still involves the same number of
elements in the HTML to get everything just right. When you consider
the class attribute on the DIV elements, there's not much size savings
anymore for using DIV.

There are other disadvantages to not using TABLE/TR/TD, such as the
lack of ability to merge cells, and keeping rows and columns aligned
with each other under varying content.

Content should be in HTML and style in CSS. So how is that affected
by whether the HTML markup has TABLE/TR/TD or just DIV.

Note that I am not talking about the use of additional tables and cells
to create stylistic effects in the grid, such as spacing between cells.
This can be done in CSS regardless of whether the elemnts involved are
TABLE/TR/TD or just DIV.

I bet someone has already written "Tables considered harmful". But is
it really justified?

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Apr 30 '06
117 17387
On Sat, 06 May 2006 10:38:02 +0100 Steve Pugh <st***@pugh.net> wrote:
| ph**************@ipal.net wrote:
|>On Fri, 05 May 2006 19:37:07 +0100 Steve Pugh <st***@pugh.net> wrote:
|>| ph**************@ipal.net wrote:
|>|>On Fri, 05 May 2006 08:10:01 +0100 Steve Pugh <st***@pugh.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 table should also imply that certain alterations in appearance or
presentation are not permitted. What term would you use for data that
is not tabular in nature, but requires exactly the same presentation?
| 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?" ;-)

If the semantics of a grid is only about presentation, then it is an
incomplete statement about what I want to have in my layout.

Certainly a grid presentation is still a grid presentation if the cells
of a table are randomly scattered about, and the dimensions are not the
same between the grid and the table.

I wasn't talking about just presentation in _my_ semantics of a grid.
But because you aren't willing to understand what _my_ semantics are,
I'm faced with the challenge of finding a term within your vocabulary
that does have the semantics I want. I'm not sure there is one, but
the term table is the closest I can think of at the moment.
|>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.

What I get out of using TABLE/TR/TD elements in HTML is the closest to what
I want. Examples shown and found using CSS have been further away from it.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 6 '06 #101
Steve Pugh <st***@pugh.net> wrote:
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.

<ph**************@ipal.net> wrote: A table should also imply that certain alterations in appearance or
presentation are not permitted.


What alterations do you think should not be permitted? Keep in mind that
the meaning of the table structure will be the same in any of the
presentation forms mentioned by Steve:

- a 2d grid on a screen/piece of paper
- read out in some way by a speech browser
- linearised by a braile device
- component pieces inserted into a database
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"If you find yourself in a hole, stop digging." - Will Rogers
May 6 '06 #102
ph**************@ipal.net wrote:
On Sat, 06 May 2006 10:38:02 +0100 Steve Pugh <st***@pugh.net> wrote:
| ph**************@ipal.net wrote:
|>On Fri, 05 May 2006 19:37:07 +0100 Steve Pugh <st***@pugh.net> wrote:
|>| ph**************@ipal.net wrote:
|>|>On Fri, 05 May 2006 08:10:01 +0100 Steve Pugh <st***@pugh.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 table should also imply that certain alterations in appearance or
presentation are not permitted.
No that's not a table. A table is still a table if it's being
presented aurally instead of visually.

A table means that certain alterations of the data and markup aren't
permitted. i.e. you can't swap row 2, column 3 with row 3, column 5.
The fact that this leads to certain presentational constraints in
certain media is a consequence not a starting point.
What term would you use for data that
is not tabular in nature, but requires exactly the same presentation?
Maybe I'd call it an image? On the WWW I'd almost certainly call it
broken.
| 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?" ;-)

If the semantics of a grid is only about presentation, then it is an
incomplete statement about what I want to have in my layout.
Could you try that sentence again in English? The grid has no
semantics, and semantics are never about presentation so the first
clause is hopeless, and I'm not sure which statement you are referring
to in the second clause.
Certainly a grid presentation is still a grid presentation if the cells
of a table are randomly scattered about, and the dimensions are not the
same between the grid and the table.
Sorry, I think I need an example.
I wasn't talking about just presentation in _my_ semantics of a grid.
Then what are the semantics of your grid? Without referencing anything
to do with the presentation please explain what semantics your 'grid'
has. What does the 'grid' mean? This meaning should be invariant of
the media used to present the 'grid' so it must remain the same when
presented aurally for example.
But because you aren't willing to understand what _my_ semantics are,
I'm very willing, but other than saying that you want the same
presentation as a table you haven't been willing to say what your
requirements are.
I'm faced with the challenge of finding a term within your vocabulary
that does have the semantics I want. I'm not sure there is one, but
the term table is the closest I can think of at the moment.
Grid seems to be doing just fine. You want the a rigid grid for
presentation purposes. That is clear. You also seem to think that this
rigid grid has some form of semantics ina ddition to its
presentational apsects but you haven't elaborated on what these
semantics are.

What does <grid>data</grid> mean that plain data does not mean?
|>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.

What I get out of using TABLE/TR/TD elements in HTML is the closest to what
I want. Examples shown and found using CSS have been further away from it.


You want a rigid layout grid. We get that. We got that many, many
posts ago. We have explained that you can get such a rigid grid with
CSS tables but that they are not safe to use in the wild as IE doesn't
support them. But putting concerns about IE to one side and
concentrating on the theoretical...

All the rest of this sound and fury has been a struggle to understand
what you mean by semantics (as it is clear that you do not mean what
the rest of us mean) and what these 'semantics' of a grid are, once we
understand what the semantics you require are can suggest the most
appropriate HTML to convey those semantics, and then we can apply CSS
on top of that to give you the rigid grid presentation.

That's how it works - HTML for semantics and CSS for presentation.

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

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
May 6 '06 #103
On Sat, 06 May 2006 11:01:11 +0100 Steve Pugh <st***@pugh.net> wrote:
| ph**************@ipal.net wrote:
|
|>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.
|
| That becomes tricky if you want the table columns to have equal widths
| (I'm assuming that the table should be 100% wide and not some fixed
| pixel width). If the column widths are in the CSS then some
| assimputions need to be made about the number of columns. If the
| column widths are inline in the HTML then you start to bloat your
| code.

I don't need to have each of the table columns of equal width. It would
work if they were, but it is not required. However, it would be preferrable
to have the HEIGHTS of each column, when there is only _one_ row, to be
made equal. When there are multiple rows, keeping the columns aligned is
usually a requirement, so adjusting the columns widths in this case would
require compromising across all the rows.

The following examples show adjustment to columns widths taking place:

http://phil.ipal.org/usenet/ciwas/20...n-table-1.html
http://phil.ipal.org/usenet/ciwas/20...n-table-2.html

If the 2nd one went a little further to where the column heights leveled
out, that would be fine by me.

For those w/o Firefox who want to see:

http://phil.ipal.org/usenet/ciwas/20...in-table-1.png
http://phil.ipal.org/usenet/ciwas/20...in-table-2.png
| The example I'm using gets around this by setting two classes on the
| parent div. One sets up all the basic table presentation, and the
| other sets up the column widths.

I'm not opposed to using a markup with DIV and classes in lieu of a
markup with TABLE/TR/TD (maybe also with classes). The issue is with
the way the layout behaves with DIV as seen in examples others have
given (at least as rendered on my browser). Maybe there is some way
in CSS to fix that, but I have no idea what that might be, and the
examples certainly didn't try to use it.

At this point I am using TABLE/TR/TD because it is what works.
|>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.
|
| These come as standard with CSS tables just as they do with HTML
| tables. Whatever examples you saw were probably using floats rather
| than CSS tables.

Many people have said I need to use floats. Not sure why. But I did
see one that used tables, and it had problems. I've lost track of where
that one is, now.
| Both can be worked around to a certain extent when using floats by use
| of min-width styles (so that includes IE 7 but not Ie 6) but will
| still break down in extreme cases.

I don't want to specify widths in the CSS because the CSS does not know
what the content will be, or how many columns. With TABLE/TR/TD I can
just toss out as many columns as I want, within reason (e.g. 100 columns
is certainly not going to do very well) and it will display reasonably
well. If widths have to be specified, it is the producer of that data
that would know how many, and the widths would have to be output from
there (maybe as in-line CSS?).
|>There may be other issues. In all, the way TABLE/TR/TD elements work in
|>HTML must be retained.
|
| Even the things that make tables a poor choice for web page layout
| (the very rigidity you desire, oo er missus).
|
| http://steve.pugh.net/test/css-table-demo.html

This one doesn't bleed or fold over.
| Note that all the cells in each row have the same height regardless of
| the height of their contents. That each row stays together no matter
| how narrow the window becomes and that the content always stays inside
| the cells. The HTML is minimal, the CSS likewise.

I removed the width specifications your demo had, and the columns took
up reasonable widths in a balanced way. So maybe that isn't needed.

Since you put the box borders on the cells themselves, it's not going
to be easy to put multiple boxes in the same cell to make this work
with one table row.

One issue: I tried to cut back on the padding inside the boxes, and
specified padding 1px, but that didn't change it. Here is what I
trimmed your CSS down to:

<style type="text/css">
div.grid {display: table; width: 100%; border-spacing: 1em;}
div.grid ul {display: table-row;}
div.grid li {display: table-cell; padding: 1px; background: #d7d7d7; border: 1px solid black;}
</style>
<!--[if IE ]>
<style type="text/css">
div.grid ul {display: block; clear: left; margin: 0; padding: 0;}
div.grid li {float: left; margin: 1em 0.5em;}
</style>
<![endif]-->

| My choice of ul for the rows and li for the cells was arbitrary but
| ensures that thre's some measure of presentation even in IE which
| doesn't support display: table.

Interesting.
| Works as desired in FireFox and Opera and I hope it works in
| Safari/Konqueror as well. IE, even IE 7, is a lost cause. Maybe in IE
| 8.

But if it works in IE <8 with TABLE/TR/TD, and if I want to present to
users of IE, then I have to do it this way. Label it as a hack; that
won't bother me.

There are cases where I'm satisfied with a page that won't work in IE.
And there are cases where I want it to work in IE.

And I'd like to use the "if IE" test in conjunction with a test for a
"microsoft.com" client domain, to enlarge the "get Firefox to see this
page correctly" button :-)
| I've included a short block of code inside an IE conditional comment
| that gives IE a basic floated layout instead. This demonstrates quite
| clearly some of the shortcomings with floats for this sort of layout
| and why MS really need to pull their finger out and implement CSS
| tables (only eight years and counting since the spec was published).

One wonders where that finger has been over the past couple of decades.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 6 '06 #104
On Sat, 06 May 2006 11:01:11 +0100 Steve Pugh <st***@pugh.net> wrote:

| http://steve.pugh.net/test/css-table-demo.html

This seems to work, now. I think part of this is by removing the widths
and part by having some additional boxes (DIV elements) within the cells
to bound the text better. Anyway, here's what I ended up with:

http://phil.ipal.org/usenet/ciwas/20...-hotbox-1.html

Getting this to work in IE, though, is probably hopeless, given so many
things it doesn't support that are really useful.

For those who don't have Firefox, the above can be seen here:

http://phil.ipal.org/usenet/ciwas/20...-hotbox-1a.png
http://phil.ipal.org/usenet/ciwas/20...-hotbox-1b.png

where the 2nd one has the top left box being hovered.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 6 '06 #105
On Sat, 06 May 2006 18:48:03 +0100 Steve Pugh <st***@pugh.net> wrote:
| ph**************@ipal.net wrote:
|>On Sat, 06 May 2006 10:38:02 +0100 Steve Pugh <st***@pugh.net> wrote:
|>| ph**************@ipal.net wrote:
|>|>On Fri, 05 May 2006 19:37:07 +0100 Steve Pugh <st***@pugh.net> wrote:
|>|>| ph**************@ipal.net wrote:
|>|>|>On Fri, 05 May 2006 08:10:01 +0100 Steve Pugh <st***@pugh.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 table should also imply that certain alterations in appearance or
|>presentation are not permitted.
|
| No that's not a table. A table is still a table if it's being
| presented aurally instead of visually.
|
| A table means that certain alterations of the data and markup aren't
| permitted. i.e. you can't swap row 2, column 3 with row 3, column 5.
| The fact that this leads to certain presentational constraints in
| certain media is a consequence not a starting point.

It's the consequence I want.

I don't know why you though I meant it was a starting point.
|> What term would you use for data that
|>is not tabular in nature, but requires exactly the same presentation?
|
| Maybe I'd call it an image? On the WWW I'd almost certainly call it
| broken.

Why would it be broken?

I see no reason to have a constraint on _what_ you can put in a table.
If it's a number, fine. If it's a block text, why should that matter?
|>| 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?" ;-)
|>
|>If the semantics of a grid is only about presentation, then it is an
|>incomplete statement about what I want to have in my layout.
|
| Could you try that sentence again in English? The grid has no
| semantics, and semantics are never about presentation so the first
| clause is hopeless, and I'm not sure which statement you are referring
| to in the second clause.

We clearly are NOT think of the same thing with the word "grid". But I
don't know how to find a word you know that has the same meaning when I
think of the word "grid". Maybe there's not _one_ word that would work.
|>Certainly a grid presentation is still a grid presentation if the cells
|>of a table are randomly scattered about, and the dimensions are not the
|>same between the grid and the table.
|
| Sorry, I think I need an example.

It's like a table, with no required relationships. It's when you put
the two together you get all the semantics combined. Of course since
you don't recognize the word "grid" the way I do, this won't mean
anything to you.
|>I wasn't talking about just presentation in _my_ semantics of a grid.
|
| Then what are the semantics of your grid? Without referencing anything
| to do with the presentation please explain what semantics your 'grid'
| has. What does the 'grid' mean? This meaning should be invariant of
| the media used to present the 'grid' so it must remain the same when
| presented aurally for example.

The grid is a 2 dimensional structure, primarily whole in both dimensions
(e.g. no columns with fewer rows and no rows with fewer columns).
|>But because you aren't willing to understand what _my_ semantics are,
|
| I'm very willing, but other than saying that you want the same
| presentation as a table you haven't been willing to say what your
| requirements are.

I want what I get with TABLE/TR/TD.
|>I'm faced with the challenge of finding a term within your vocabulary
|>that does have the semantics I want. I'm not sure there is one, but
|>the term table is the closest I can think of at the moment.
|
| Grid seems to be doing just fine. You want the a rigid grid for
| presentation purposes. That is clear. You also seem to think that this
| rigid grid has some form of semantics ina ddition to its
| presentational apsects but you haven't elaborated on what these
| semantics are.
|
| What does <grid>data</grid> mean that plain data does not mean?

I have no idea what you are trying to refer to.
|>|>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.
|>
|>What I get out of using TABLE/TR/TD elements in HTML is the closest to what
|>I want. Examples shown and found using CSS have been further away from it.
|
| You want a rigid layout grid. We get that. We got that many, many
| posts ago. We have explained that you can get such a rigid grid with
| CSS tables but that they are not safe to use in the wild as IE doesn't
| support them. But putting concerns about IE to one side and
| concentrating on the theoretical...

And I finally got things to work right with CSS tables, at least in Firefox.
I'm not sure why other examples of CSS tables failed. But they were simpler
and did not have some of the extras I had because I did stuff like shadow
boxes inside each cell. Maybe these extra boxes succeeded in confining the
text flow or layout to inside the cell.

Those who gave previous examples didn't succeed in making it work the same
way as TABLE/TR/TD does. Your example did. And it was simple enough that
I was able to add my other stuff to it successfully.
| All the rest of this sound and fury has been a struggle to understand
| what you mean by semantics (as it is clear that you do not mean what
| the rest of us mean) and what these 'semantics' of a grid are, once we
| understand what the semantics you require are can suggest the most
| appropriate HTML to convey those semantics, and then we can apply CSS
| on top of that to give you the rigid grid presentation.
|
| That's how it works - HTML for semantics and CSS for presentation.

There are, however, semantics for the things found in the CSS "language".
That's not semantics of the document, but rather, semantics of how those
things will cause the browser to render the document.

Maybe this has been the difference; you're referring to the semantics of
the document, and I'm referring to the semantics of the specifications.
It's the specifications that I'm having so much trouble with right now,
so that is what I am focusing on.

So why is there "table" in HTML _and_ "table" in CSS? Is "table" a kind
of presentation? Someone thought so if they put it in CSS.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 6 '06 #106
ph**************@ipal.net wrote:
On Sat, 06 May 2006 18:48:03 +0100 Steve Pugh <st***@pugh.net> wrote:
| ph**************@ipal.net wrote:
|>On Sat, 06 May 2006 10:38:02 +0100 Steve Pugh <st***@pugh.net> wrote:
|>| ph**************@ipal.net wrote:
|>|>On Fri, 05 May 2006 19:37:07 +0100 Steve Pugh <st***@pugh.net> wrote:
|>|>| ph**************@ipal.net wrote:
|>|>|>On Fri, 05 May 2006 08:10:01 +0100 Steve Pugh <st***@pugh.net> wrote:
|>| | A table means that certain alterations of the data and markup aren't
| permitted. i.e. you can't swap row 2, column 3 with row 3, column 5.
| The fact that this leads to certain presentational constraints in
| certain media is a consequence not a starting point.

It's the consequence I want.

I don't know why you though I meant it was a starting point.
Because the appearance seems to be all you care about.
So it seems to be both the start and the end.
|> What term would you use for data that
|>is not tabular in nature, but requires exactly the same presentation?
|
| Maybe I'd call it an image? On the WWW I'd almost certainly call it
| broken.

Why would it be broken?
Because the WWW is media independent and if a certain exact
presentation is required then that is something that can not exist on
the WWW. What does your grid look like in an aural browser?
I see no reason to have a constraint on _what_ you can put in a table.
If it's a number, fine. If it's a block text, why should that matter?
Anything can go into a table so long as it's tabular data. That can be
text, images, anything. So long as it has a relationship with the
other items of data in the same row and column then it's tabular data.
Who ever suggested that it can't be a block of text?

|>If the semantics of a grid is only about presentation, then it is an
|>incomplete statement about what I want to have in my layout.
|
| Could you try that sentence again in English? The grid has no
| semantics, and semantics are never about presentation so the first
| clause is hopeless, and I'm not sure which statement you are referring
| to in the second clause.

We clearly are NOT think of the same thing with the word "grid".
The second definition at http://www.answers.com/grid&r=67 works for
me: "Something resembling a framework of crisscrossed parallel bars,
as in rigidity or organization"
|>Certainly a grid presentation is still a grid presentation if the cells
|>of a table are randomly scattered about, and the dimensions are not the
|>same between the grid and the table.
|
| Sorry, I think I need an example.

It's like a table, with no required relationships.
Bingo. That's the context I've been using it in this thread. Like a 2d
representation of a table in presentation, but without the table
semantics.
It's when you put
the two together you get all the semantics combined.
Eh? Put what two together? A grid and a table? A grid, as we are using
the word here, is a presentation, it has no semantics.

A table has semantics, but I thought that you wanted something with
the typical table presentation in 2d media (i.e. a grid) but with some
different semantics that you stubbornly refuse to elucidate.
Of course since
you don't recognize the word "grid" the way I do, this won't mean
anything to you.
What makes you think I don't recognise the word grid? I've see it
often enough in your recent posts. I've used in my posts, despite your
insinuations above you and I have been using grid with the same
meaning as far as I can see.

You're rapidly approaching Luigi levels of obliviousness.
|>I wasn't talking about just presentation in _my_ semantics of a grid.
|
| Then what are the semantics of your grid? Without referencing anything
| to do with the presentation please explain what semantics your 'grid'
| has. What does the 'grid' mean? This meaning should be invariant of
| the media used to present the 'grid' so it must remain the same when
| presented aurally for example.

The grid is a 2 dimensional structure, primarily whole in both dimensions
(e.g. no columns with fewer rows and no rows with fewer columns).
We've already established the presentation of a grid. No need to
repeat it again. But that still doesn't explain what semantics you
think a grid has, all you've done here is explain, yet again, is give
the presentation.

What does a grid mean? Not what does it look like. What does it mean?
|>But because you aren't willing to understand what _my_ semantics are,
|
| I'm very willing, but other than saying that you want the same
| presentation as a table you haven't been willing to say what your
| requirements are.

I want what I get with TABLE/TR/TD.
You get the presentation you want. We established that about a dozen
posts ago. But what are the semantics that you want?
|>I'm faced with the challenge of finding a term within your vocabulary
|>that does have the semantics I want. I'm not sure there is one, but
|>the term table is the closest I can think of at the moment.
|
| Grid seems to be doing just fine. You want the a rigid grid for
| presentation purposes. That is clear. You also seem to think that this
| rigid grid has some form of semantics ina ddition to its
| presentational apsects but you haven't elaborated on what these
| semantics are.
|
| What does <grid>data</grid> mean that plain data does not mean?

I have no idea what you are trying to refer to.
<p>data</p> has the semantics that the data is a paragraph, i.e. a
self contained block of text normally concerned with a single topic.

<h1>data</h1> has the semantics that the data is a level one heading.

<td>data</td> has the semantics that the data is a cell in a table,
with relationships to the other cells in the same row and column.

So, what are the semantics of a grid? What would a hypothetical
<grid>data</grid> element say about the data? That's what we have been
trying to establish all along, what are the semantics that you want to
give to your data?
| All the rest of this sound and fury has been a struggle to understand
| what you mean by semantics (as it is clear that you do not mean what
| the rest of us mean) and what these 'semantics' of a grid are, once we
| understand what the semantics you require are can suggest the most
| appropriate HTML to convey those semantics, and then we can apply CSS
| on top of that to give you the rigid grid presentation.
|
| That's how it works - HTML for semantics and CSS for presentation.

There are, however, semantics for the things found in the CSS "language".
That's not semantics of the document, but rather, semantics of how those
things will cause the browser to render the document.
The "semantics" of the CSS display: table-* properties are "make this
look _like_ a typical 2d rendering of a table".
Maybe this has been the difference; you're referring to the semantics of
the document,
What else would I be referring to in the context of authoring for the
WWW?
and I'm referring to the semantics of the specifications.
It's the specifications that I'm having so much trouble with right now,
so that is what I am focusing on.
HTML is for semantics.
CSS is for presentation.
So why is there "table" in HTML _and_ "table" in CSS? Is "table" a kind
of presentation? Someone thought so if they put it in CSS.


The table in HTML is to markup data with table semantics.
The table in CSS is to markup data with table like presentation.

The built in style sheets in browsers give CSS table presentation to
HTML tables, so you don't need to specify the CSS itself in your
author stylesheet.

But if you want to create something that looks like a table, but
isn't, semantically speaking, a table you use the CSS to give the
table presentation to some other HTML element - one who's semantics
does match the data in question.

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

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
May 6 '06 #107
In article <e3*********@news2.newsguy.com>, <ph**************@ipal.net> wrote:
And I finally got things to work right with CSS tables, at least in Firefox.


Phil, would you mind showing how? And did you test it with IE6?

I still use simple tables in many of my layouts because I have never
been able to get CSS to work to my satisfaction. Even specifying
table elements in CSS don't behave as I would expect them to, in all
browsers.

Frankly, I don't see much difference between <td>...</td> and
<div>...</div>.

-A
May 6 '06 #108
On Sat, 06 May 2006 23:54:28 +0100 Steve Pugh <st***@pugh.net> wrote:
| ph**************@ipal.net wrote:
|>On Sat, 06 May 2006 18:48:03 +0100 Steve Pugh <st***@pugh.net> wrote:
|>| ph**************@ipal.net wrote:
|>|>On Sat, 06 May 2006 10:38:02 +0100 Steve Pugh <st***@pugh.net> wrote:
|>|>| ph**************@ipal.net wrote:
|>|>|>On Fri, 05 May 2006 19:37:07 +0100 Steve Pugh <st***@pugh.net> wrote:
|>|>|>| ph**************@ipal.net wrote:
|>|>|>|>On Fri, 05 May 2006 08:10:01 +0100 Steve Pugh <st***@pugh.net> wrote:
|>|>|
|
|>| A table means that certain alterations of the data and markup aren't
|>| permitted. i.e. you can't swap row 2, column 3 with row 3, column 5.
|>| The fact that this leads to certain presentational constraints in
|>| certain media is a consequence not a starting point.
|>
|>It's the consequence I want.
|>
|>I don't know why you though I meant it was a starting point.
|
| Because the appearance seems to be all you care about.
| So it seems to be both the start and the end.

It's all that I am raising as an issue here right now. There are other
things besides appearance. But those are not the current issue that led
me to make the original post.
|>|> What term would you use for data that
|>|>is not tabular in nature, but requires exactly the same presentation?
|>|
|>| Maybe I'd call it an image? On the WWW I'd almost certainly call it
|>| broken.
|>
|>Why would it be broken?
|
| Because the WWW is media independent and if a certain exact
| presentation is required then that is something that can not exist on
| the WWW. What does your grid look like in an aural browser?

Not all content is suitable for all media. What does you voice look
like on a visual browser to a deaf person?
|>I see no reason to have a constraint on _what_ you can put in a table.
|>If it's a number, fine. If it's a block text, why should that matter?
|
| Anything can go into a table so long as it's tabular data. That can be
| text, images, anything. So long as it has a relationship with the
| other items of data in the same row and column then it's tabular data.

And this rule applies whether it's a TABLE element in HTML or CSS tables?
| Who ever suggested that it can't be a block of text?

Other respondents in this newsgroup.

OK, so it's a block of text then. I'll try to remember who to send them
to if they try to say any different. You can set them straight.
|>|>If the semantics of a grid is only about presentation, then it is an
|>|>incomplete statement about what I want to have in my layout.
|>|
|>| Could you try that sentence again in English? The grid has no
|>| semantics, and semantics are never about presentation so the first
|>| clause is hopeless, and I'm not sure which statement you are referring
|>| to in the second clause.
|>
|>We clearly are NOT think of the same thing with the word "grid".
|
| The second definition at http://www.answers.com/grid&r=67 works for
| me: "Something resembling a framework of crisscrossed parallel bars,
| as in rigidity or organization"

I like the organization part of that.
|>|>Certainly a grid presentation is still a grid presentation if the cells
|>|>of a table are randomly scattered about, and the dimensions are not the
|>|>same between the grid and the table.
|>|
|>| Sorry, I think I need an example.
|>
|>It's like a table, with no required relationships.
|
| Bingo. That's the context I've been using it in this thread. Like a 2d
| representation of a table in presentation, but without the table
| semantics.

Since you widened the scope of what is tabular data, then doesn't that
imply the semantics of tabular data, if I use that which is within the
scope of tabular data?
|> It's when you put
|>the two together you get all the semantics combined.
|
| Eh? Put what two together? A grid and a table? A grid, as we are using
| the word here, is a presentation, it has no semantics.

OK, now that I know you are referring to the semantics of the document,
I see what you mean.
| A table has semantics, but I thought that you wanted something with
| the typical table presentation in 2d media (i.e. a grid) but with some
| different semantics that you stubbornly refuse to elucidate.

We were talking about semantics in different contexts.
|> Of course since
|>you don't recognize the word "grid" the way I do, this won't mean
|>anything to you.
|
| What makes you think I don't recognise the word grid? I've see it
| often enough in your recent posts. I've used in my posts, despite your
| insinuations above you and I have been using grid with the same
| meaning as far as I can see.

Someone else suggested grid a while back, and so I started using it.
| You're rapidly approaching Luigi levels of obliviousness.

No meaning to me from that.
|>|>I wasn't talking about just presentation in _my_ semantics of a grid.
|>|
|>| Then what are the semantics of your grid? Without referencing anything
|>| to do with the presentation please explain what semantics your 'grid'
|>| has. What does the 'grid' mean? This meaning should be invariant of
|>| the media used to present the 'grid' so it must remain the same when
|>| presented aurally for example.
|>
|>The grid is a 2 dimensional structure, primarily whole in both dimensions
|>(e.g. no columns with fewer rows and no rows with fewer columns).
|
| We've already established the presentation of a grid. No need to
| repeat it again. But that still doesn't explain what semantics you
| think a grid has, all you've done here is explain, yet again, is give
| the presentation.

Semantics in terms of what the definition of behaviour would be if there
were a specification literally of "grid" in CSS. There isn't, so what
those semantics are is wide open consideration.

The context of how I used "semantics" in the just previous paragraph is
not the semantics of a document that would be specified, but rather, the
semantics of the elements of the specifications in a "language" like CSS.
| What does a grid mean? Not what does it look like. What does it mean?
|
|>|>But because you aren't willing to understand what _my_ semantics are,
|>|
|>| I'm very willing, but other than saying that you want the same
|>| presentation as a table you haven't been willing to say what your
|>| requirements are.
|>
|>I want what I get with TABLE/TR/TD.
|
| You get the presentation you want. We established that about a dozen
| posts ago. But what are the semantics that you want?

I don't think there is anything in HTML that can truly give me the
semantics of the document itself, the way I want.
|>|>I'm faced with the challenge of finding a term within your vocabulary
|>|>that does have the semantics I want. I'm not sure there is one, but
|>|>the term table is the closest I can think of at the moment.
|>|
|>| Grid seems to be doing just fine. You want the a rigid grid for
|>| presentation purposes. That is clear. You also seem to think that this
|>| rigid grid has some form of semantics ina ddition to its
|>| presentational apsects but you haven't elaborated on what these
|>| semantics are.
|>|
|>| What does <grid>data</grid> mean that plain data does not mean?
|>
|>I have no idea what you are trying to refer to.
|
| <p>data</p> has the semantics that the data is a paragraph, i.e. a
| self contained block of text normally concerned with a single topic.
|
| <h1>data</h1> has the semantics that the data is a level one heading.
|
| <td>data</td> has the semantics that the data is a cell in a table,
| with relationships to the other cells in the same row and column.
|
| So, what are the semantics of a grid? What would a hypothetical
| <grid>data</grid> element say about the data? That's what we have been
| trying to establish all along, what are the semantics that you want to
| give to your data?

I wasn't using "grid" in the context of being HTML markup to be used to
indicate the semantics of the document.
|>| All the rest of this sound and fury has been a struggle to understand
|>| what you mean by semantics (as it is clear that you do not mean what
|>| the rest of us mean) and what these 'semantics' of a grid are, once we
|>| understand what the semantics you require are can suggest the most
|>| appropriate HTML to convey those semantics, and then we can apply CSS
|>| on top of that to give you the rigid grid presentation.
|>|
|>| That's how it works - HTML for semantics and CSS for presentation.
|>
|>There are, however, semantics for the things found in the CSS "language".
|>That's not semantics of the document, but rather, semantics of how those
|>things will cause the browser to render the document.
|
| The "semantics" of the CSS display: table-* properties are "make this
| look _like_ a typical 2d rendering of a table".

Maybe they should have chosen a different term in place of "table".
But, neveretheless, it is there, and it can be made to work, though it
seems a few other people don't have the knack for it (but, you do).
|>Maybe this has been the difference; you're referring to the semantics of
|>the document,
|
| What else would I be referring to in the context of authoring for the
| WWW?

The specification of the languages (CSS and HTML) themselves.
|>and I'm referring to the semantics of the specifications.
|>It's the specifications that I'm having so much trouble with right now,
|>so that is what I am focusing on.
|
| HTML is for semantics.
| CSS is for presentation.

But, the term semantics is applicable to understanding any language,
be it CSS, HTML, XML, C, Python, Java, COBOL, English, etc.
|>So why is there "table" in HTML _and_ "table" in CSS? Is "table" a kind
|>of presentation? Someone thought so if they put it in CSS.
|
| The table in HTML is to markup data with table semantics.
| The table in CSS is to markup data with table like presentation.

You left the door pretty wide for using HTML tables, though.
| The built in style sheets in browsers give CSS table presentation to
| HTML tables, so you don't need to specify the CSS itself in your
| author stylesheet.
|
| But if you want to create something that looks like a table, but
| isn't, semantically speaking, a table you use the CSS to give the
| table presentation to some other HTML element - one who's semantics
| does match the data in question.

I think that leaves things pretty well open to the wild to debate
whether some contents/document is a table. Some others would not
agree with you about anything being allowed if it had the row and
column relationships that you seemed to a few paragraphs above.
It might be presented as a table; but _is_ it a table? Who knows.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 7 '06 #109
On Sat, 6 May 2006 23:33:10 +0000 (UTC) axlq <ax**@spamcop.net> wrote:
| In article <e3*********@news2.newsguy.com>, <ph**************@ipal.net> wrote:
|>And I finally got things to work right with CSS tables, at least in Firefox.
|
| Phil, would you mind showing how? And did you test it with IE6?

http://phil.ipal.org/usenet/ciwas/20...-hotbox-1.html

I did not test it in any version of IE.
| I still use simple tables in many of my layouts because I have never
| been able to get CSS to work to my satisfaction. Even specifying
| table elements in CSS don't behave as I would expect them to, in all
| browsers.

It may be a case of the additional containers I used. I have not done
much more experimenting with this, yet.
| Frankly, I don't see much difference between <td>...</td> and
| <div>...</div>.

Apparently the only real differences are:

1. The default presentation properties of TABLE/TR/TD, which supposedly
could be given to DIV/DIV/DIV (I'm not sure that what I did actually
accomplished that).

2. The implications of what the content means, based on the choice of
using TABLE/TR/TD vs. DIV/DIV/DIV. The browser won't _know_ any
such meaning. But presentation specifications (style) for some
media could be different, and the same for other media.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 7 '06 #110
On Sat, 6 May 2006 23:33:10 +0000 (UTC) axlq <ax**@spamcop.net> wrote:

| I still use simple tables in many of my layouts because I have never
| been able to get CSS to work to my satisfaction. Even specifying
| table elements in CSS don't behave as I would expect them to, in all
| browsers.

The following file _seems_ to be the default (or a copy thereof) style
for HTML in Firefox 1.5.0.3: /usr/lib/firefox-1.5.0.3/res/html.css
on my Linux system. It might be located elsewhere on your system. My
guess is that if you emulate what is used here for the table elements,
it could give you exactly the same presentation. That is, if there are
no special exceptions in the application program code to vary it for
those elements. I'm going to play around with this at some point in
time.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 7 '06 #111
ph**************@ipal.net wrote:
On Sat, 06 May 2006 23:54:28 +0100 Steve Pugh <st***@pugh.net> wrote:
| ph**************@ipal.net wrote:
|>On Sat, 06 May 2006 18:48:03 +0100 Steve Pugh <st***@pugh.net> wrote:
|>| ph**************@ipal.net wrote: |>|> What term would you use for data that
|>|>is not tabular in nature, but requires exactly the same presentation?
|>|
|>| Maybe I'd call it an image? On the WWW I'd almost certainly call it
|>| broken.
|>
|>Why would it be broken?
|
| Because the WWW is media independent and if a certain exact
| presentation is required then that is something that can not exist on
| the WWW. What does your grid look like in an aural browser?

Not all content is suitable for all media. What does you voice look
like on a visual browser to a deaf person?
My voice is presentation. But my words are content. Hence I would put
my words into an HTML document and leave the details of my voice to a
CSS stylesheet.
|>I see no reason to have a constraint on _what_ you can put in a table.
|>If it's a number, fine. If it's a block text, why should that matter?
|
| Anything can go into a table so long as it's tabular data. That can be
| text, images, anything. So long as it has a relationship with the
| other items of data in the same row and column then it's tabular data.

And this rule applies whether it's a TABLE element in HTML or CSS tables?
CSS doesn't have elements and doesn't have (document) semantics. The
'rule' above applies to HTML tables. CSS tables are purely for
presentation and can be applied to anything.
| Who ever suggested that it can't be a block of text?

Other respondents in this newsgroup.
Care to post the messages IDs?
OK, so it's a block of text then. I'll try to remember who to send them
to if they try to say any different. You can set them straight.
Feel free. But please point them towards an actual post of mine rather
than just trying to paraphrase my words or quote part of them out of
context. I suspect that the chances are that I and they will agree
and that it is you who has yet again failed to grasp the distinction.
|>It's like a table, with no required relationships.
|
| Bingo. That's the context I've been using it in this thread. Like a 2d
| representation of a table in presentation, but without the table
| semantics.

Since you widened the scope of what is tabular data, then doesn't that
imply the semantics of tabular data, if I use that which is within the
scope of tabular data?
No. The semantics of what is a table are as have been given several
times. There must be a relationship along the rows and down the
columns.

<table>
<thead>
<tr>
<th scope="col">Stock Number</th>
<th scope="col">Item Name</th>
<th scope="col">Item Description</th>
<th scope="col">Picture</th>
<th scope="col">Unit Cost</th>
</tr>
</thead>
<tbody>
<tr>
<td>467657</td>
<td>Clue Stick</td>
<td><p>For beating people who seem incapable of getting a clue via
any other means. 42.5cm with average radius of 2.1cm. Made of solid
oak.</p></td>
<td><a href="/pics/467657.jpg"><img src="/thumbs/467657.jpg"
alt="Clue Stick"></a></td>
<td>15.80</td>
</tr>
.....
</tbody>
</table>

See? There are still relationships between the cells even though they
contain different types of data. The only real debate here is whether
one should make the first cell of each row a th rather than td.

If the paragraph in column 3 and the image in column 4 weren't related
to the stock number in column 1 then it would not be a table.
| You're rapidly approaching Luigi levels of obliviousness.

No meaning to me from that.
Google for Luigi in alt.html. You remind me of him.
I don't think there is anything in HTML that can truly give me the
semantics of the document itself, the way I want.
Which is why HTML gives you the semantically neutral div and span
elements to as hooks to hang semantics-free presentation on.
|>| That's how it works - HTML for semantics and CSS for presentation.
|>
|>There are, however, semantics for the things found in the CSS "language".
|>That's not semantics of the document, but rather, semantics of how those
|>things will cause the browser to render the document.
|
| The "semantics" of the CSS display: table-* properties are "make this
| look _like_ a typical 2d rendering of a table".

Maybe they should have chosen a different term in place of "table".
Would you also suggest that they should have avoided the word list in
display: list-item and list-style-type?

Every element in HTML has a presentation that is more or less the same
across graphical browsers. The writers of CSS 2 decided that thaat
default presentation had to be expressable in CSS. For most elements
standard properties like margin and display: block could be used, but
for lists and even more so for tables a set of new properties had to
be created to replicate the default presentation.

Maybe a study of http://www.w3.org/TR/CSS21/sample.html would be
instructive as to why CSS exists in the form it does?
But, neveretheless, it is there, and it can be made to work, though it
seems a few other people don't have the knack for it (but, you do).
Other people were probably trying to make something that worked in the
real world where IE dominates.
|>So why is there "table" in HTML _and_ "table" in CSS? Is "table" a kind
|>of presentation? Someone thought so if they put it in CSS.
|
| The table in HTML is to markup data with table semantics.
| The table in CSS is to markup data with table like presentation.

You left the door pretty wide for using HTML tables, though.
I'm not opening or closing any doors. I've said all along that as IE
doesn't support the relevant CSS you have to make a choice between
using semantically false tables or changing your design (or living in
a fantasy world where IE doesn't exist).
| The built in style sheets in browsers give CSS table presentation to
| HTML tables, so you don't need to specify the CSS itself in your
| author stylesheet.
|
| But if you want to create something that looks like a table, but
| isn't, semantically speaking, a table you use the CSS to give the
| table presentation to some other HTML element - one who's semantics
| does match the data in question.

I think that leaves things pretty well open to the wild to debate
whether some contents/document is a table.
Yes, there is room for debate and even disagreement. Your chessboard
is a good example. It doesn't really match my simplified descript of
having relationships across the rows and dow the columns, but still
has many table like qualities to it. A more common example is a form -
placing all the labels in one column and all the inputs in another.
Some others would not
agree with you about anything being allowed if it had the row and
column relationships that you seemed to a few paragraphs above.
It might be presented as a table; but _is_ it a table? Who knows.


I think you've missed the point again. The row and column
relationships must say somthing about the data in cell X,Y so that by
looking along row X and column Y we learn something more about that
piece of data.

Using a table to lay out a grid whereby each column contained news
stories from different regions wouldn't be a table in my mind.

But if each row specified a time period (and hence each cell could
contain multiple news stories,) then that would be a table. It
wouldn't matter in which order a speech browser read out the stories
so lng

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

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
May 7 '06 #112
On Sun, 07 May 2006 11:52:37 +0100 Steve Pugh <st***@pugh.net> wrote:
| ph**************@ipal.net wrote:
|>On Sat, 06 May 2006 23:54:28 +0100 Steve Pugh <st***@pugh.net> wrote:
|>| ph**************@ipal.net wrote:
|>|>On Sat, 06 May 2006 18:48:03 +0100 Steve Pugh <st***@pugh.net> wrote:
|>|>| ph**************@ipal.net wrote:
|
|>|>|> What term would you use for data that
|>|>|>is not tabular in nature, but requires exactly the same presentation?
|>|>|
|>|>| Maybe I'd call it an image? On the WWW I'd almost certainly call it
|>|>| broken.
|>|>
|>|>Why would it be broken?
|>|
|>| Because the WWW is media independent and if a certain exact
|>| presentation is required then that is something that can not exist on
|>| the WWW. What does your grid look like in an aural browser?
|>
|>Not all content is suitable for all media. What does you voice look
|>like on a visual browser to a deaf person?
|
| My voice is presentation. But my words are content. Hence I would put
| my words into an HTML document and leave the details of my voice to a
| CSS stylesheet.

That's going to be some very complex presentation. And it would make it
quite easy for someone to just change the words in the content and have
your voice saying whatever they want.

Maybe we should just carry this concept one step further and have the
content be in no specific language, and leave the language up to the
presentation.

This whole separation of content and presentation I think is being carried
way too far, at least in the context of requiring that everything be in
such a form. I don't think it's a big problem for text. But for things
like images and sounds and smells, I believe it's going too far.
|>|>I see no reason to have a constraint on _what_ you can put in a table.
|>|>If it's a number, fine. If it's a block text, why should that matter?
|>|
|>| Anything can go into a table so long as it's tabular data. That can be
|>| text, images, anything. So long as it has a relationship with the
|>| other items of data in the same row and column then it's tabular data.
|>
|>And this rule applies whether it's a TABLE element in HTML or CSS tables?
|
| CSS doesn't have elements and doesn't have (document) semantics. The
| 'rule' above applies to HTML tables. CSS tables are purely for
| presentation and can be applied to anything.

What is the meaning of "table"? It sounds like HTML and CSS are trying to
have only partial implementations of what that means.

I don't see the point. I do see an advantage to using CSS because it lets
you specify one the properties of things appearing many times. By the
whole philosophy that is going on with it isn't somethin gI agree with.
|>| Who ever suggested that it can't be a block of text?
|>
|>Other respondents in this newsgroup.
|
| Care to post the messages IDs?

Why would I keep a record of that, for what seemed, at that time, something
with no great controversy? Do you keep a record of every message ID of
everything you discuss when it's about something you are not an expert in
just in case someone later on says "oh, that's not true, give me the message
ID of that"? That's just not a common, or practical practice, any more
than expecting you to police every thread (otherwise I could say "why were
you not there to refute it on the spot").
|>OK, so it's a block of text then. I'll try to remember who to send them
|>to if they try to say any different. You can set them straight.
|
| Feel free. But please point them towards an actual post of mine rather
| than just trying to paraphrase my words or quote part of them out of
| context. I suspect that the chances are that I and they will agree
| and that it is you who has yet again failed to grasp the distinction.

Or maybe they didn't phrase it well. That's common on Usenet.
|>|>It's like a table, with no required relationships.
|>|
|>| Bingo. That's the context I've been using it in this thread. Like a 2d
|>| representation of a table in presentation, but without the table
|>| semantics.
|>
|>Since you widened the scope of what is tabular data, then doesn't that
|>imply the semantics of tabular data, if I use that which is within the
|>scope of tabular data?
|
| No. The semantics of what is a table are as have been given several
| times. There must be a relationship along the rows and down the
| columns.
|
| <table>
| <thead>
| <tr>
| <th scope="col">Stock Number</th>
| <th scope="col">Item Name</th>
| <th scope="col">Item Description</th>
| <th scope="col">Picture</th>
| <th scope="col">Unit Cost</th>
| </tr>
| </thead>
| <tbody>
| <tr>
| <td>467657</td>
| <td>Clue Stick</td>
| <td><p>For beating people who seem incapable of getting a clue via
| any other means. 42.5cm with average radius of 2.1cm. Made of solid
| oak.</p></td>
| <td><a href="/pics/467657.jpg"><img src="/thumbs/467657.jpg"
| alt="Clue Stick"></a></td>
| <td>?15.80</td>
| </tr>
| ....
| </tbody>
| </table>
|
| See? There are still relationships between the cells even though they
| contain different types of data. The only real debate here is whether
| one should make the first cell of each row a th rather than td.

One should make a header be TH. If a header is applicable to a row,
then put one there. And I don't see how the first cell has anything
to do with it ... the semantics are the semantics even if you put it
in a different place. It might seem odd when it isn't the first, but
that doesn't mean someone else's content can't have what that kind of
markup implies.

Or headers can be omitted.
| If the paragraph in column 3 and the image in column 4 weren't related
| to the stock number in column 1 then it would not be a table.
|
|>| You're rapidly approaching Luigi levels of obliviousness.
|>
|>No meaning to me from that.
|
| Google for Luigi in alt.html. You remind me of him.

In what way?

FYI, I'm not actually going to look. I have no interest in following
some useless thread of conversation somewhere else. And I should not
have followed this one aside from the fact that doing so finally led
me to something that worked. The average person would probably have
given up before a working example was seen.
|>I don't think there is anything in HTML that can truly give me the
|>semantics of the document itself, the way I want.
|
| Which is why HTML gives you the semantically neutral div and span
| elements to as hooks to hang semantics-free presentation on.

But from a practical perspective, when presentation is what is trying to
be achieved, the implications of semantics in HTML don't really matter.
People will use what they want. Elements like TABLE are more about being
shortcuts to common default presentations than they are about semantics,
the exact details of which either are not agreed upon by all, or are not
explained the same way by all.
|>|>| That's how it works - HTML for semantics and CSS for presentation.
|>|>
|>|>There are, however, semantics for the things found in the CSS "language".
|>|>That's not semantics of the document, but rather, semantics of how those
|>|>things will cause the browser to render the document.
|>|
|>| The "semantics" of the CSS display: table-* properties are "make this
|>| look _like_ a typical 2d rendering of a table".
|>
|>Maybe they should have chosen a different term in place of "table".
|
| Would you also suggest that they should have avoided the word list in
| display: list-item and list-style-type?

I don't know. I haven't studied or worked with those, yet.
| Every element in HTML has a presentation that is more or less the same
| across graphical browsers. The writers of CSS 2 decided that thaat
| default presentation had to be expressable in CSS. For most elements
| standard properties like margin and display: block could be used, but
| for lists and even more so for tables a set of new properties had to
| be created to replicate the default presentation.

And even that wasn't 100% complete. A noble effort. A little more
work is needed. You can see that in some tweaks being used in the
default stylesheet for HTML in Firefox.
| Maybe a study of http://www.w3.org/TR/CSS21/sample.html would be
| instructive as to why CSS exists in the form it does?

Same concept as the default one in Firefox, but this one from the
standards people, so no tweaks. I wonder how well it would work in
Firefox if I swap it.
|>But, neveretheless, it is there, and it can be made to work, though it
|>seems a few other people don't have the knack for it (but, you do).
|
| Other people were probably trying to make something that worked in the
| real world where IE dominates.

It could be. That's a big issue. Some stuff I have done and will be
doing is Linux oriented. Yet even there, IE is a big portion of the
user base. Some other stuff I will be doing is for a generic audience,
so not only must IE work, it must work about equally well.
|>|>So why is there "table" in HTML _and_ "table" in CSS? Is "table" a kind
|>|>of presentation? Someone thought so if they put it in CSS.
|>|
|>| The table in HTML is to markup data with table semantics.
|>| The table in CSS is to markup data with table like presentation.
|>
|>You left the door pretty wide for using HTML tables, though.
|
| I'm not opening or closing any doors. I've said all along that as IE
| doesn't support the relevant CSS you have to make a choice between
| using semantically false tables or changing your design (or living in
| a fantasy world where IE doesn't exist).

What I meant about the doors is that you allowed for anything to be
"tabular data" by it merely having the row and column relationships.

Layout _does_ have row and column relationships. Yet layout really is
presentation. But the relationship specifics (e.g. which block of
"stuff" is related in what way to what other block of stuff) can't be
in the presentation; so it has to be in the content markup. So I'm
still force to express at least part of the layout presentation in
the content (at a minimum as classified divisions).
|>| The built in style sheets in browsers give CSS table presentation to
|>| HTML tables, so you don't need to specify the CSS itself in your
|>| author stylesheet.
|>|
|>| But if you want to create something that looks like a table, but
|>| isn't, semantically speaking, a table you use the CSS to give the
|>| table presentation to some other HTML element - one who's semantics
|>| does match the data in question.
|>
|>I think that leaves things pretty well open to the wild to debate
|>whether some contents/document is a table.
|
| Yes, there is room for debate and even disagreement. Your chessboard
| is a good example. It doesn't really match my simplified descript of
| having relationships across the rows and dow the columns, but still
| has many table like qualities to it. A more common example is a form -
| placing all the labels in one column and all the inputs in another.

It ended up being an example of stuff different than what I had intended.
|> Some others would not
|>agree with you about anything being allowed if it had the row and
|>column relationships that you seemed to a few paragraphs above.
|>It might be presented as a table; but _is_ it a table? Who knows.
|
| I think you've missed the point again. The row and column
| relationships must say somthing about the data in cell X,Y so that by
| looking along row X and column Y we learn something more about that
| piece of data.
|
| Using a table to lay out a grid whereby each column contained news
| stories from different regions wouldn't be a table in my mind.

Why not? It has the row and column relationships. Of course, the
data could stand by itself and not _need_ those relationships. But in
the context of how presented, the relationships are a (small) part of
the meaning given. There can be added semantics provided by the editor
merely in _how_ the relationship is set up, without having to actually
change any of the text. So what seems like presentation is also a form
of semantics (that maybe many people just can't see as semantics).
| But if each row specified a time period (and hence each cell could
| contain multiple news stories,) then that would be a table. It
| wouldn't matter in which order a speech browser read out the stories
| so lng

I think the order should matter.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 7 '06 #113
ph**************@ipal.net wrote:
On Sun, 07 May 2006 11:52:37 +0100 Steve Pugh <st***@pugh.net> wrote:
| ph**************@ipal.net wrote:
|>On Sat, 06 May 2006 23:54:28 +0100 Steve Pugh <st***@pugh.net> wrote: |>| Who ever suggested that it can't be a block of text?
|>
|>Other respondents in this newsgroup.
|
| Care to post the messages IDs?

Why would I keep a record of that, for what seemed, at that time, something
with no great controversy? Do you keep a record of every message ID of
everything you discuss when it's about something you are not an expert in
just in case someone later on says "oh, that's not true, give me the message
ID of that"? That's just not a common, or practical practice, any more
than expecting you to police every thread (otherwise I could say "why were
you not there to refute it on the spot").
If you still have the copies of the messages that you downloaded to
read then you can just look them up in your newsreader. I keep threads
so long as I'm participating in them and I keep really interesting
posts for longer. Or you can go to Google Groups and search for the
posts in questions. 'cos at the moment you're saying that "someone
said something" but not offering any cites to back that up.

Maybe someone did say what you think they said, maybe they said
something different and you misunderstood, maybe your making stuff up,
how can I tell?

|>| You're rapidly approaching Luigi levels of obliviousness.
|>
|>No meaning to me from that.
|
| Google for Luigi in alt.html. You remind me of him.

In what way?

FYI, I'm not actually going to look. I have no interest in following
some useless thread of conversation somewhere else. And I should not
have followed this one aside from the fact that doing so finally led
me to something that worked. The average person would probably have
given up before a working example was seen.
Tell me about it. I have no idea why I've put up with this thread for
so long.

| But if each row specified a time period (and hence each cell could
| contain multiple news stories,) then that would be a table. It
| wouldn't matter in which order a speech browser read out the stories
| so lng

Whoops, I missed off the end of that sentence
"It wouldn't matter in which order a speech browser read out the
stories so long as reference was given to the row and column headers
so that the context was known."
I think the order should matter.


Should speech browsers read across rows or down columns? Or should
they give the user the choice? And should they give users the choice
to pick a cell from the middle of the table and listen to that cell in
isolation? Sighted users can choose how they read a table because
their presentation is 2d, blind users have a 1d presentation. Proper
HTML markup give speech readers access to the document semantics so
that that 1d presentation doesn't become a hindrance.

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

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
May 7 '06 #114
On Sun, 07 May 2006 23:43:19 +0100 Steve Pugh <st***@pugh.net> wrote:
| ph**************@ipal.net wrote:
|>On Sun, 07 May 2006 11:52:37 +0100 Steve Pugh <st***@pugh.net> wrote:
|>| ph**************@ipal.net wrote:
|>|>On Sat, 06 May 2006 23:54:28 +0100 Steve Pugh <st***@pugh.net> wrote:
|
|>|>| Who ever suggested that it can't be a block of text?
|>|>
|>|>Other respondents in this newsgroup.
|>|
|>| Care to post the messages IDs?
|>
|>Why would I keep a record of that, for what seemed, at that time, something
|>with no great controversy? Do you keep a record of every message ID of
|>everything you discuss when it's about something you are not an expert in
|>just in case someone later on says "oh, that's not true, give me the message
|>ID of that"? That's just not a common, or practical practice, any more
|>than expecting you to police every thread (otherwise I could say "why were
|>you not there to refute it on the spot").
|
| If you still have the copies of the messages that you downloaded to
| read then you can just look them up in your newsreader. I keep threads
| so long as I'm participating in them and I keep really interesting
| posts for longer. Or you can go to Google Groups and search for the
| posts in questions. 'cos at the moment you're saying that "someone
| said something" but not offering any cites to back that up.

My news reader does not pre-download. And Google Groups' interface
is lousy and hard to use.

And it may not have been in Usenet at all.
| Maybe someone did say what you think they said, maybe they said
| something different and you misunderstood, maybe your making stuff up,
| how can I tell?

You can't tell, and it doesn't matter. The way I deal with such a
conflict is try resolve it in the current context. I'm not using any
of the statements I only remember summaries of to dispute what you
say. I'm only using them to relate to what you say to better clarify
things, or to figure out what I might have misunderstood before, or
see what someone else didn't know.
|>|>| You're rapidly approaching Luigi levels of obliviousness.
|>|>
|>|>No meaning to me from that.
|>|
|>| Google for Luigi in alt.html. You remind me of him.
|>
|>In what way?
|>
|>FYI, I'm not actually going to look. I have no interest in following
|>some useless thread of conversation somewhere else. And I should not
|>have followed this one aside from the fact that doing so finally led
|>me to something that worked. The average person would probably have
|>given up before a working example was seen.
|
| Tell me about it. I have no idea why I've put up with this thread for
| so long.

It's your choice.

If you'd only given a partial explanation (and that's usually what I
see from almost everyone in the first response), and then quite, that
might lead to even more confusion.

I could be working from a lot of misinformation. If your response
corrects some elements of that misinformation, but leaves others not
addressed at all, then I could have a worse mix of information. But
at least if I then recognize that the mix is inconsistent, I will ask
for an explanation. Then I can find out if I misunderstood what you
said, or find out of the other information was just wrong.

Does that make sense, yet?
|>| But if each row specified a time period (and hence each cell could
|>| contain multiple news stories,) then that would be a table. It
|>| wouldn't matter in which order a speech browser read out the stories
|>| so lng
|>
|
| Whoops, I missed off the end of that sentence
| "It wouldn't matter in which order a speech browser read out the
| stories so long as reference was given to the row and column headers
| so that the context was known."

Ah.
|>I think the order should matter.
|
| Should speech browsers read across rows or down columns? Or should
| they give the user the choice? And should they give users the choice
| to pick a cell from the middle of the table and listen to that cell in
| isolation? Sighted users can choose how they read a table because
| their presentation is 2d, blind users have a 1d presentation. Proper
| HTML markup give speech readers access to the document semantics so
| that that 1d presentation doesn't become a hindrance.

Blind users can also use a 2D feedback device to find elements to be
read. But, sure, all these things should be choosable.

It would also be nice to have a choice, as a sighted user, to flip a
table along either axis, or the diagonal.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 8 '06 #115
In <e3*********@news1.newsguy.com>, on 05/06/2006
at 05:47 PM, ph**************@ipal.net said:
One wonders where that finger has been over the past couple of
decades.


Hint: the m$ finger was adjacent to the m$ head. The way of redmond
has always been embrace, extend, extinguish. Maybe if FF gets popular
enough m$ will have to worry about interoperability.

For the limited things that I do, if it works on Firefox and
Konqueror, and passes a W3C validation, then I'm not going to worry
about how it looks on IE. But I expect to be using tables until CSS3
is out, at which point I will evaluate it and take advantage of those
features that I consider prudent.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to sp******@library.lspace.org

May 8 '06 #116
<ph**************@ipal.net> wrote in message
news:e3********@news3.newsguy.com...
On Fri, 05 May 2006 08:10:01 +0100 Steve Pugh <st***@pugh.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.
| 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.


Bit late on this, but I have a suggestion.

How about a definition list?

ie.

<dl>
<dt>Fruit</dt>
<dd>apple</dd>
<dd>orange</dd>
<dd>pear</dd>
<dt>Vegetables</dt>
<dd>potatoe</dd>
<dd>carrot</dd>
<dd>parsnip</dd>
<dd>leek</dd>
<dd>onion</dd>
<dt>Meat</dt>
<dd>Lamb</dd>
<dd>Mutton</dd>
</dl>
May 11 '06 #117
Martin Eyles wrote:
<dl>
<dt>Fruit</dt>
<dd>apple</dd>
<dd>orange</dd>
<dd>pear</dd>
<dt>Vegetables</dt>
<dd>potatoe</dd>
<dd>carrot</dd>
<dd>parsnip</dd>
<dd>leek</dd>
<dd>onion</dd>
<dt>Meat</dt>
<dd>Lamb</dd>
<dd>Mutton</dd>
</dl>


Although HTML permits multiple dd elements for a dt (for different
explanations for the term), I would rather do something like

<dl>
<dt>Fruit</dt>
<dd>
<ul>
<li>apple</li>
<li>orange</li>
<li>pear</li>
</ul>
</dd>
....
</dl>
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
May 11 '06 #118

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.