grid structures: TABLE/TR/TD vs. DIV

On Sat, 6 May 2006 23:33:10 +0000 (UTC) axlq <axlq (AT) spamcop (DOT) net> wrote:

In article <e3ivqa03183 (AT) news2 (DOT) newsguy.com>, <phil-news-nospam (AT) ipal (DOT) 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/ |
-----------------------------------------------------------------------------

On Sat, 6 May 2006 23:33:10 +0000 (UTC) axlq <axlq (AT) spamcop (DOT) 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/ |
-----------------------------------------------------------------------------

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

On Sat, 06 May 2006 23:54:28 +0100 Steve Pugh <steve (AT) pugh (DOT) net> wrote:
| phil-news-nospam (AT) ipal (DOT) net wrote:
|>On Sat, 06 May 2006 18:48:03 +0100 Steve Pugh <steve (AT) pugh (DOT) net> wrote:
|>| phil-news-nospam (AT) ipal (DOT) 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 <steve (AT) pugh (DOT) net> <http://steve.pugh.net/>

On Sun, 07 May 2006 11:52:37 +0100 Steve Pugh <steve (AT) pugh (DOT) net> wrote:

phil-news-nospam (AT) ipal (DOT) net wrote:
On Sat, 06 May 2006 23:54:28 +0100 Steve Pugh <steve (AT) pugh (DOT) net> wrote:
| phil-news-nospam (AT) ipal (DOT) net wrote:
|>On Sat, 06 May 2006 18:48:03 +0100 Steve Pugh <steve (AT) pugh (DOT) net> wrote:
|>| phil-news-nospam (AT) ipal (DOT) 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/ |
-----------------------------------------------------------------------------

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

On Sun, 07 May 2006 11:52:37 +0100 Steve Pugh <steve (AT) pugh (DOT) net> wrote:
| phil-news-nospam (AT) ipal (DOT) net wrote:
|>On Sat, 06 May 2006 23:54:28 +0100 Steve Pugh <steve (AT) pugh (DOT) 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 <steve (AT) pugh (DOT) net> <http://steve.pugh.net/>

On Sun, 07 May 2006 23:43:19 +0100 Steve Pugh <steve (AT) pugh (DOT) net> wrote:

phil-news-nospam (AT) ipal (DOT) net wrote:
On Sun, 07 May 2006 11:52:37 +0100 Steve Pugh <steve (AT) pugh (DOT) net> wrote:
| phil-news-nospam (AT) ipal (DOT) net wrote:
|>On Sat, 06 May 2006 23:54:28 +0100 Steve Pugh <steve (AT) pugh (DOT) 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/ |
-----------------------------------------------------------------------------

In <e3inem02af9 (AT) news1 (DOT) newsguy.com>, on 05/06/2006
at 05:47 PM, phil-news-nospam (AT) ipal (DOT) 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 spamtrap (AT) library (DOT) lspace.org

<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.


| 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>

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.)