473,325 Members | 2,608 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,325 software developers and data experts.

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 18379
To further the education of mankind, "W˙rm"
<no*************@north.invalid> vouchsafed:
If it's tabular data, use table. It's that simple.

If table is just there to do layout certain way when data is _NOT
tabular_, don't, there are almost certainly better ways to do that
layout.
A chessboard grid is not tabular data, it's structured data. There
is a difference.


And where did I say it is? Incase it escaped you what I meant above.


And where did I say you said it? I was modifying your information, not
contradicting it.
Translation: (spell it word by word if meaning still happily escapes
from you)

If
it's
tabular
data,
use
table.
It's
that
simple.
You're being childishly gratuitous. Of course, that rather fits this whole
thread.
And data in it meaning _ANY_ data, not just some silly chess stuff.


I'm glad you clarified that in case anyone out there believes they could
use tables only for chess boards...

--
Neredbojias
Infinity has its limits.
May 3 '06 #51

"Neredbojias" <http://www.neredbojias.com/fliam.php?cat=alt.html> kirjoitti
viestissä:Xn*********************************@208. 49.80.251...
And where did I say you said it? I was modifying your information, not
contradicting it.
If one would been talking about bananas and you'd go on telling pretty
accusatorily "but pink bananas are no bananas they're grapes!" one might
like EXPECT it has relation to talk about bananas you know.
<snip>
You're being childishly gratuitous. Of course, that rather fits this
whole
thread.


ofcoz :)

<snip>
May 3 '06 #52
On Wed, 03 May 2006 10:05:44 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|
|> On Tue, 02 May 2006 22:25:17 +0200 Johannes Koch <ko**@w3development.de> wrote:
|> | Because they are two different things: One (HTML tables) is markup for
|> | tabular data. E.g. it includes the "Table rendering by non-visual user
|> | agents" (HTML 4.01, section 11.4). The other (CSS table presentation
|> | model) is just for presenting content in a certain way (a grid).
|>
|> So why not use the CSS table presentation model for the tubular data?
|
| In many browsers the CSS table presentation model _is_ used for
| presenting table/tr/td etc. That's the default rendering.

A new feature that does the same thing as the old feature? Why?

The relationship of data to each other when in a table is fixed. Is CSS
tables trying to change that? I still see no point in having this in CSS
unless there is something different (and hopefully better).

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 3 '06 #53
On Wed, 03 May 2006 10:12:47 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|
|> Why have two mechanisms that work the same way?
|
| Why is there a strong element in HTML, when CSS offers 'font-weight:
| bold'? Same answer.

No.

There still has to be something in HTML for the content to say "this is
strong", whether that is <b>foo</b> or <div class="strong">foo</div>.
CSS cannot just select unmarked text and make it bold or strong. There
has to be content markup to give CSS a handle on it.

In some cases making something bold/strong is content. But in other cases
it is style, such as making headings bold, or not, as a choice of style.

Putting tabular data (or data that might not look tabular to some but
needs to be treated as tabular) into relationships of rows and columns
is content markup, not style. Once in a relationship like that, then
it is a table. Then it's fine for CSS to stylize it in some way (maybe
controlling the borders, for example).

CSS cannot, for example, know how many columns the table might have.
One table might have 4 columns and another table might have 6 columns.
But if the stylemaster wants all tables to have a black border around
the whole table, gray lines separating all cells, a pink background
color, and blue text, then he would use CSS and have _one_ stylesheet
without regard to the number of columns.

So tell me again why CSS needs to define the tabular relationships in
the data, and how it can do that without knowing anything about the
data, in any way _more_ than what can be done with the tags we already
have in HTML? I can see a need perhaps to do this for XML which is
devoid of such tags.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 3 '06 #54
On Wed, 3 May 2006 05:25:23 +0300 "W?rm" <no*************@north.invalid> wrote:
|
| <ph**************@ipal.net> kirjoitti
| viestiss?:e3*********@news4.newsguy.com...
|
| <snip>
|
|> How to keep the columns from floating down to the bottom when the window
|> is narrower?
|
| Let them float down instead of trying to prevent it, don't make issue from
| something that is not. There are ways to prevent it though, but I'd rather
| see stuff to adjust to viewport so...

I'd rather see stuff that maintains its data relationship and does not
alter the semantics of the content by moving data into a different column.
Poor baby, has to use the horizontal scroll bar to see everything on his
puny little screen.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 3 '06 #55
On Wed, 03 May 2006 04:21:36 -0400 Neredbojias <http://www.neredbojias.com/fliam.php?cat=alt.html> wrote:
| To further the education of mankind, "W?rm"
| <no*************@north.invalid> vouchsafed:
|
|>
|> <ph**************@ipal.net> kirjoitti
|> viestiss?:e3*********@news2.newsguy.com...
|>
|> <snip>
|>
|>> It probably comes down to the fact that my intentions in a grid
|>> structure do match the semantics of a table and tabular data.
|>
|> If it's tabular data, use table. It's that simple.
|>
|> If table is just there to do layout certain way when data is _NOT
|> tabular_, don't, there are almost certainly better ways to do that
|> layout.
|
| A chessboard grid is not tabular data, it's structured data. There is a
| difference.
|
| Here's a mock-up I made using someone's visual example from above. Putting
| all the ridiculous artificial restrictions aside, it uses no tables, is
| fluid, and works in IE. It, unfortunately, doesn't work in Opera because
| of Opera's flawed graphic technology.
|
| http://www.neredbojias.com/zyxix/chess/chss2.html
|
| As I intimated, it's just a prototype, but I think it could be a decent
| base for a dynamic chess page.

Now put some content on that cheesboard, such as pieces, or text that
represents pieces, in various positions that present a position of play.
Given that there are not 64 discrete items in the markup where this could
be done, it is not obvious how your design would accomplish that. I do
know I could accomplish it with a table that has 64 TD elements. Or try
putting the letter/number code in each square.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 3 '06 #56
On Wed, 3 May 2006 14:23:28 +0300 "W?rm" <no*************@north.invalid> wrote:
|
| "Neredbojias" <http://www.neredbojias.com/fliam.php?cat=alt.html> kirjoitti
| viestiss?:Xn*********************************@208. 49.80.251...
|
| <snip>
|
|>> If it's tabular data, use table. It's that simple.
|>>
|>> If table is just there to do layout certain way when data is _NOT
|>> tabular_, don't, there are almost certainly better ways to do that
|>> layout.
|>
|> A chessboard grid is not tabular data, it's structured data. There is a
|> difference.
|
| And where did I say it is? Incase it escaped you what I meant above.
|
| Translation: (spell it word by word if meaning still happily escapes from
| you)
|
| If
| it's
| tabular
| data,
| use
| table.
| It's
| that
| simple.
|
| And data in it meaning _ANY_ data, not just some silly chess stuff.

This still leaves open all the arguments about whether some data is, or
is not, tabular data. You're saying if it is tabular data, put it in a
table ... that's fine. You didn't say if it's not tabular data, what to
do or not do. But then you say "_ANY_ data", so I guess that leaves it
open to use a table for anything when the semantics effects of a table
is what is desired.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 3 '06 #57
ph**************@ipal.net wrote:
So tell me again why CSS needs to define the tabular relationships in
the data,


CSS _does not_ define tabluar relationships. It just defines
presentation characteristics. E.g. adjacent blocks with "display:
table-cell" have the same height.

--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
May 3 '06 #58
ph**************@ipal.net wrote:
On Wed, 03 May 2006 10:05:44 +0200 Johannes Koch <ko**@w3development.de> wrote:
| In many browsers the CSS table presentation model _is_ used for
| presenting table/tr/td etc. That's the default rendering.

A new feature that does the same thing as the old feature?
HTML does not the same as CSS. HTML defines structure, CSS suggests
presentation.
The relationship of data to each other when in a table is fixed. Is CSS
tables trying to change that?
No, you can change the appearance with CSS.
I still see no point in having this in CSS
unless there is something different (and hopefully better).


CSS defines the presentation characteristics used in the default
rendering of table/tr/td elements. Just like CSS defines a font-weight
property that is used (value bold) in the default rendering of HTML's
strong element.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
May 3 '06 #59
On Wed, 03 May 2006 17:23:47 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|
|> On Wed, 03 May 2006 10:05:44 +0200 Johannes Koch <ko**@w3development.de> wrote:
|> | In many browsers the CSS table presentation model _is_ used for
|> | presenting table/tr/td etc. That's the default rendering.
|>
|> A new feature that does the same thing as the old feature?
|
| HTML does not the same as CSS. HTML defines structure, CSS suggests
| presentation.

And a table is a structure. Of course its presentation can be styled, too.
|> The relationship of data to each other when in a table is fixed. Is CSS
|> tables trying to change that?
|
| No, you can change the appearance with CSS.

That's what I thought. So for the structure, I should use HTML. Then
for the appearance use CSS. That's what I thought all along.
|> I still see no point in having this in CSS
|> unless there is something different (and hopefully better).
|
| CSS defines the presentation characteristics used in the default
| rendering of table/tr/td elements. Just like CSS defines a font-weight
| property that is used (value bold) in the default rendering of HTML's
| strong element.

And I can change how table/tr/td presented, too.

But I still use table/tr/td to define the structure.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 3 '06 #60
On Wed, 03 May 2006 17:20:04 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|
|> So tell me again why CSS needs to define the tabular relationships in
|> the data,
|
| CSS _does not_ define tabluar relationships. It just defines
| presentation characteristics. E.g. adjacent blocks with "display:
| table-cell" have the same height.

But how is it that the CSS capability is having certain people tell me
to not use TABLE/TR/TD/etc in HTML?

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 3 '06 #61

<ph**************@ipal.net> kirjoitti
viestissä:e3*********@news2.newsguy.com...
On Wed, 3 May 2006 14:23:28 +0300 "W?rm" <no*************@north.invalid>
wrote:
|
| "Neredbojias" <http://www.neredbojias.com/fliam.php?cat=alt.html>
kirjoitti
| viestiss?:Xn*********************************@208. 49.80.251...
|
| <snip>
|
|>> If it's tabular data, use table. It's that simple.
|>>
|>> If table is just there to do layout certain way when data is _NOT
|>> tabular_, don't, there are almost certainly better ways to do that
|>> layout.
|>
|> A chessboard grid is not tabular data, it's structured data. There is
a
|> difference.
|
| And where did I say it is? Incase it escaped you what I meant above.
|
| Translation: (spell it word by word if meaning still happily escapes
from
| you)
|
| If
| it's
| tabular
| data,
| use
| table.
| It's
| that
| simple.
|
| And data in it meaning _ANY_ data, not just some silly chess stuff.

This still leaves open all the arguments about whether some data is, or
is not, tabular data. You're saying if it is tabular data, put it in a
table ... that's fine. You didn't say if it's not tabular data, what to
do or not do. But then you say "_ANY_ data", so I guess that leaves it
open to use a table for anything when the semantics effects of a table
is what is desired.


And I bet you also use hammer to drive in screws, instead of using
screwdriver. After all, IT can be done.

You are making issues from anything just because you wanna argue and not use
elements that have proper semantical meaning. Like in your linux page, those
links, they are LISTS of links so use <ul><li><a href="">..</a></li>...</ul>
structure for those. Those lists had image in top if I recall right, like a
heading, so maybe use heading for those, etc. Just because you try to twist
something to be tabular data when it obviously is not, it don't make it
"proper use of tables".

Use elements that have proper _SEMANTICAL_ meaning. If you got tabular data
it's table, for a LIST it is a list etc. When you do not have any element
that has proper semantical meaning for something, go for DIV or SPAN. Just
keep it simple.

Do not make issues just because you wanna argue.
May 3 '06 #62
ph**************@ipal.net wrote:
On Wed, 03 May 2006 17:23:47 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|
|> On Wed, 03 May 2006 10:05:44 +0200 Johannes Koch <ko**@w3development.de> wrote:
|> | In many browsers the CSS table presentation model _is_ used for
|> | presenting table/tr/td etc. That's the default rendering.
|>
|> A new feature that does the same thing as the old feature?
|
| HTML does not the same as CSS. HTML defines structure, CSS suggests
| presentation.

And a table is a structure. Of course its presentation can be styled, too.
Yes.
|> The relationship of data to each other when in a table is fixed. Is CSS
|> tables trying to change that?
|
| No, you can change the appearance with CSS.

That's what I thought. So for the structure, I should use HTML. Then
for the appearance use CSS. That's what I thought all along.
Yes.
|> I still see no point in having this in CSS
|> unless there is something different (and hopefully better).
|
| CSS defines the presentation characteristics used in the default
| rendering of table/tr/td elements. Just like CSS defines a font-weight
| property that is used (value bold) in the default rendering of HTML's
| strong element.

And I can change how table/tr/td presented, too.

But I still use table/tr/td to define the structure.


Yes.
--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)
May 3 '06 #63
ph**************@ipal.net wrote:
But how is it that the CSS capability is having certain people tell me
to not use TABLE/TR/TD/etc in HTML?


If you have tabular data, use table, caption, col, colgroup, thead,
tfoot, tbody, tr, th, td. If you don't have tabular data, use
appropriate markup. Additionally, if you want the non-tabular data to be
styled like a grid (equal height etc.), then use the CSS table model.

E.g. DocBook defines an element called 'simplelist'
(<http://www.docbook.org/tdg/en/html/simplelist.html>), which may be
presented as a grid:

apple banana bread cherry
hazelnut mango orange pear
potato tomato

This is not really tabular. What is it that mango has in common with
banana and tomato that differs from hazelnut, orange and pear? What OTOH
does mango have in common with hazelnut, orange and pear that differs
from banana and tomato? There are no row and column relations. It's just
a 2-dimensional presentation of a 1-dimensional list.
--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)
May 3 '06 #64
To further the education of mankind, "W˙rm"
<no*************@north.invalid> vouchsafed:

"Neredbojias" <http://www.neredbojias.com/fliam.php?cat=alt.html>
kirjoitti
viestissä:Xn*********************************@208. 49.80.251...
And where did I say you said it? I was modifying your information,
not contradicting it.


If one would been talking about bananas and you'd go on telling pretty
accusatorily "but pink bananas are no bananas they're grapes!" one
might like EXPECT it has relation to talk about bananas you know.


Perhaps, but are we all just a troupe of gibbering monkeys? (-Okay,
present scope excluded.)
You're being childishly gratuitous. Of course, that rather fits this
whole
thread.


ofcoz :)


The whole point of my original post was to gleen feedback about what you
(et al) thought of my version of the grid. Instead I get nonsense. It
certainly seems as if ciwas has become much more like alt.2600 and its ilk
than it used to be.

--
Neredbojias
Infinity has its limits.
May 3 '06 #65

"Neredbojias" <http://www.neredbojias.com/fliam.php?cat=alt.html> kirjoitti
viestissä:Xn**********************************@208 .49.80.251...

<snip>
The whole point of my original post was to gleen feedback about what you
(et al) thought of my version of the grid. Instead I get nonsense.


Whoa!! Now hold on your horses and do some rechecking about WHO might have
said something. I haven't said __ANYTHING__ about your version of grid.
<snip>
May 3 '06 #66
On Wed, 03 May 2006 23:50:16 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|> But how is it that the CSS capability is having certain people tell me
|> to not use TABLE/TR/TD/etc in HTML?
|
| If you have tabular data, use table, caption, col, colgroup, thead,
| tfoot, tbody, tr, th, td. If you don't have tabular data, use
| appropriate markup. Additionally, if you want the non-tabular data to be
| styled like a grid (equal height etc.), then use the CSS table model.

In another followup you weren't saying this. Now you are. I don't get
what this flip flop is.

What do you think the "appropriate markup" is for non-tabular data that
needs to have the same rigid structure as a table?
| E.g. DocBook defines an element called 'simplelist'
| (<http://www.docbook.org/tdg/en/html/simplelist.html>), which may be
| presented as a grid:
|
| apple banana bread cherry
| hazelnut mango orange pear
| potato tomato
|
| This is not really tabular. What is it that mango has in common with
| banana and tomato that differs from hazelnut, orange and pear? What OTOH
| does mango have in common with hazelnut, orange and pear that differs
| from banana and tomato? There are no row and column relations. It's just
| a 2-dimensional presentation of a 1-dimensional list.

That data could just as easily come out as:

apple banana bread cherry hazelnut
mango orange pear potato tomato

or as:

apple banana bread
cherry hazelnut mango
orange pear potato
tomato

This example is not what I have been talking about.

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

apple bread hazelnut orange potato
banana cherry mango pear tomato

or in a narrower window like:

apple cherry orange tomato
banana hazelnut pear
bread mango potato

or even:

apple hazelnut potato
banana mango tomato
bread orange
cherry pear

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

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

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 4 '06 #67
Deciding to do something for the good of humanity,
<ph**************@ipal.net> declared in
comp.infosystems.www.authoring.stylesheets:
But I'll talking about it briefly, anyway. I'd like to have a COLUMN
orientation version of that, which would come out like this: <snip> There are some things where this would work better, such as a list of
files in a folder/directory. But it would be style ... something to
decide how to present. Does CSS have a way to say to list stuff this
way?


CSS3 does/will.
http://www.w3.org/TR/2005/WD-css3-multicol-20051215/

--
Mark Parnell
My Usenet is improved; yours could be too:
http://blinkynet.net/comp/uip5.html
May 4 '06 #68
On Thu, 4 May 2006 00:20:49 +0300 "W?rm" <no*************@north.invalid> wrote:

| And I bet you also use hammer to drive in screws, instead of using
| screwdriver. After all, IT can be done.

I make my decisions based on what is practical. YES! I do use a hammer
on a screw ... to pound in just enough of a dent in the wood to keep the
screw stable as the screwdriver turns it into the wood. In extreme cases
I'll even use a drill to drill a hole a bit smaller than the screw core
to avoid causing the wood to split.

But it is NOT practical to use a hammer to drive the screw in all the way
unless you're objective it to just gouge a hole in the wood (someone might
want to do that). On a smaller scale, your dentist may well be doing
something akin to that with the tiny tools used for root canals.

I use TABLE/TR/TD for what those are the most practical solution I can
see at the time.
| You are making issues from anything just because you wanna argue and not use
| elements that have proper semantical meaning.

No.

I use what works most practical. I simply have not seen anything that
is any more practical than using TABLE/TR/TD for 2-D data. If you want
to every show how it is done some other way, maybe I can show you where
your solution doesn't match my problem.

| Like in your linux page, those
| links, they are LISTS of links so use <ul><li><a href="">..</a></li>...</ul>
| structure for those. Those lists had image in top if I recall right, like a
| heading, so maybe use heading for those, etc. Just because you try to twist
| something to be tabular data when it obviously is not, it don't make it
| "proper use of tables".

If you look more closely at the source you'll see that the list of links
is NOT structured in a table. The entire list for a given site, inside
a box for that site, is in ONE cell. There are BR elements to force each
link to a new line ... not TR elements.

An early version DID use UL/LI, but that never came out right. That MAY
be tweakable today, but some things like the bullet size don't seem to
be adjustable. So for now, they are just a list formed in lines with BR.

The page does have two basic levels of tables (with additional levels used
to wedge things into place). The outer level is to organize things into
3 columns ... in a way that stays as 3 columns. The inner level is the big
mess used to create the drop shadow effect. This inner layer is what will
go away soon. I already have it's general replacement done in CSS, and am
working on reorganizing the PHP code before it all goes online.
| Use elements that have proper _SEMANTICAL_ meaning. If you got tabular data
| it's table, for a LIST it is a list etc. When you do not have any element
| that has proper semantical meaning for something, go for DIV or SPAN. Just
| keep it simple.

Show me where a list (there are many separate lists on linuxhomepage.com)
is being formatted using a table.
| Do not make issues just because you wanna argue.

Why not show what you think is the solution, so you can either prove
someone wrong ... or perhaps have your solution knocked down because
maybe you didn't understand the original problem. There are LAYERS
going on in LHP. The list of links is the 3rd layer. The shadows are
the 2nd layer (though in a correct markup, this shouldn't be a layer).
And the columnization is the 1st layer.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 4 '06 #69
Deciding to do something for the good of humanity,
<ph**************@ipal.net> declared in
comp.infosystems.www.authoring.stylesheets:
If you look more closely at the source you'll see that the list of links
is NOT structured in a table.
He never said it was. He was simply using it as another example of you
using non-semantic markup, similar to your use of tables.
An early version DID use UL/LI, but that never came out right. That MAY
be tweakable today, but some things like the bullet size don't seem to
be adjustable.
Not AFAIK (they tend to adjust with the font size but can't be resized
independently), but you can certainly remove the bullets altogether and
e.g. use an image instead.
So for now, they are just a list formed in lines with BR.


Which isn't really a list at all.

--
Mark Parnell
My Usenet is improved; yours could be too:
http://blinkynet.net/comp/uip5.html
May 4 '06 #70
ph**************@ipal.net wrote:
On Wed, 03 May 2006 23:50:16 +0200 Johannes Koch <ko**@w3development.de> wrote:
| If you have tabular data, use table, caption, col, colgroup, thead,
| tfoot, tbody, tr, th, td. If you don't have tabular data, use
| appropriate markup. Additionally, if you want the non-tabular data to be
| styled like a grid (equal height etc.), then use the CSS table model.

In another followup you weren't saying this. Now you are. I don't get
what this flip flop is.
Where can you quote me?
What do you think the "appropriate markup" is for non-tabular data that
needs to have the same rigid structure as a table?
I'm not talking about "rigid structure as a table". I try to explain to
you what the CSS table presentation model is about in contrast to the
HTML table model. CSS is not about structure. It's about presentation.
| E.g. DocBook defines an element called 'simplelist'
| (<http://www.docbook.org/tdg/en/html/simplelist.html>), which may be
| presented as a grid:
|
| apple banana bread cherry
| hazelnut mango orange pear
| potato tomato
|
| This is not really tabular. What is it that mango has in common with
| banana and tomato that differs from hazelnut, orange and pear? What OTOH
| does mango have in common with hazelnut, orange and pear that differs
| from banana and tomato? There are no row and column relations. It's just
| a 2-dimensional presentation of a 1-dimensional list.

That data could just as easily come out as:

apple banana bread cherry hazelnut
mango orange pear potato tomato

or as:

apple banana bread
cherry hazelnut mango
orange pear potato
tomato
Of course, it can.
This example is not what I have been talking about.
I chose this example to explain to you the difference between tabular
data and non-tabular data that someone wants to present in a grid way.
But I'll talking about it briefly, anyway. I'd like to have a COLUMN
orientation version of that, which would come out like this: [...] apple hazelnut potato
banana mango tomato
bread orange
cherry pear

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


I don't think, CSS currently has a way to do this. Neither has HTML. The
HTML table model is row-oriented. So the table's serialization would not
represent the alphabetical order.

--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
May 4 '06 #71
On Thu, 4 May 2006 15:24:10 +1000 Mark Parnell <we*******@clarkecomputers.com.au> wrote:
| Deciding to do something for the good of humanity,
| <ph**************@ipal.net> declared in
| comp.infosystems.www.authoring.stylesheets:
|
|> But I'll talking about it briefly, anyway. I'd like to have a COLUMN
|> orientation version of that, which would come out like this:
| <snip>
|> There are some things where this would work better, such as a list of
|> files in a folder/directory. But it would be style ... something to
|> decide how to present. Does CSS have a way to say to list stuff this
|> way?
|
| CSS3 does/will.
| http://www.w3.org/TR/2005/WD-css3-multicol-20051215/

Sounds good. I look forward to it. Any chance Firefox has advance
support to try it out?

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 4 '06 #72
On Thu, 4 May 2006 15:53:29 +1000 Mark Parnell <we*******@clarkecomputers.com.au> wrote:
| Deciding to do something for the good of humanity,
| <ph**************@ipal.net> declared in
| comp.infosystems.www.authoring.stylesheets:
|
|> If you look more closely at the source you'll see that the list of links
|> is NOT structured in a table.
|
| He never said it was. He was simply using it as another example of you
| using non-semantic markup, similar to your use of tables.

So he's shifting off topic and trying to address the person instead of
the issue. That's not the first time he's done so. Well, at least he
isn't doing so in an insulting/attack manner (as some people I've seen
are want to do). But I think he needs to stay _on_ topic for 2 reasons.
One is that it can get confusing when the deviation is made. And two,
he hasn't really addressed the TABLE/TR/TD issue adequately. Merely
saying that I'm not using the semantics means he expects me to use some
other means, but only makes vague references to what those are, without
being specific. I think he needs to be specific because that's the only
way I can pin point _his_ misunderstanding of what _I_ am trying to do.
|> An early version DID use UL/LI, but that never came out right. That MAY
|> be tweakable today, but some things like the bullet size don't seem to
|> be adjustable.
|
| Not AFAIK (they tend to adjust with the font size but can't be resized
| independently), but you can certainly remove the bullets altogether and
| e.g. use an image instead.

I don't want to use an image there. I want something very tiny. The dash
did the job just fine.
|> So for now, they are just a list formed in lines with BR.
|
| Which isn't really a list at all.

My "semantics of a list" does not require a bullet. I would call such a
thing a "bulleted list". That's not so much of a departure from an ordered
list that gets numbered. I see the choice of bullet, or numbers, or nothing
at all, a presentation issue, anyway. But I can't see where CSS gives me
those choices just yet. Maybe in CSS3?

OK, for semantics purposes, I'll call the list of links "not a list".
Then I won't use UL/LI. Or would it be better to just accept that the
semantics really is a list, but that available stylings are inadequate
for now?

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 4 '06 #73
On Thu, 04 May 2006 10:08:09 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|
|> On Wed, 03 May 2006 23:50:16 +0200 Johannes Koch <ko**@w3development.de> wrote:
|> | If you have tabular data, use table, caption, col, colgroup, thead,
|> | tfoot, tbody, tr, th, td. If you don't have tabular data, use
|> | appropriate markup. Additionally, if you want the non-tabular data to be
|> | styled like a grid (equal height etc.), then use the CSS table model.
|>
|> In another followup you weren't saying this. Now you are. I don't get
|> what this flip flop is.
|
| Where can you quote me?

In Message-ID: <44***********************@authen.yellow.readfreen ews.net>
All those short answers.
|> What do you think the "appropriate markup" is for non-tabular data that
|> needs to have the same rigid structure as a table?
|
| I'm not talking about "rigid structure as a table". I try to explain to
| you what the CSS table presentation model is about in contrast to the
| HTML table model. CSS is not about structure. It's about presentation.

But I want the rigid structure. If CSS is not about structure, then that
goal should not attempt to use CSS.
|> | E.g. DocBook defines an element called 'simplelist'
|> | (<http://www.docbook.org/tdg/en/html/simplelist.html>), which may be
|> | presented as a grid:
|> |
|> | apple banana bread cherry
|> | hazelnut mango orange pear
|> | potato tomato
|> |
|> | This is not really tabular. What is it that mango has in common with
|> | banana and tomato that differs from hazelnut, orange and pear? What OTOH
|> | does mango have in common with hazelnut, orange and pear that differs
|> | from banana and tomato? There are no row and column relations. It's just
|> | a 2-dimensional presentation of a 1-dimensional list.
|>
|> That data could just as easily come out as:
|>
|> apple banana bread cherry hazelnut
|> mango orange pear potato tomato
|>
|> or as:
|>
|> apple banana bread
|> cherry hazelnut mango
|> orange pear potato
|> tomato
|
| Of course, it can.

Though that is not what I want in my 2-D structures.
|> This example is not what I have been talking about.
|
| I chose this example to explain to you the difference between tabular
| data and non-tabular data that someone wants to present in a grid way.
|
|> But I'll talking about it briefly, anyway. I'd like to have a COLUMN
|> orientation version of that, which would come out like this:
| [...]
|> apple hazelnut potato
|> banana mango tomato
|> bread orange
|> cherry pear
|>
|> There are some things where this would work better, such as a list of
|> files in a folder/directory. But it would be style ... something to
|> decide how to present. Does CSS have a way to say to list stuff this
|> way? In case someone doesn't see what I'm showing, just look at the
|> alphabetical sequence of these "food items".
|
| I don't think, CSS currently has a way to do this. Neither has HTML. The
| HTML table model is row-oriented. So the table's serialization would not
| represent the alphabetical order.

So for 1-D lists I want presented in that form, I'll have to wait for CSS3.
In the mean time, there is no way to really get it.

But for 2-D structures, I can put it together with TABLE/TR/TD since the
position of everything would be known by the content producer/generator.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 4 '06 #74
ph**************@ipal.net wrote:
On Thu, 04 May 2006 10:08:09 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|
|> On Wed, 03 May 2006 23:50:16 +0200 Johannes Koch <ko**@w3development.de> wrote:
|> | If you have tabular data, use table, caption, col, colgroup, thead,
|> | tfoot, tbody, tr, th, td. If you don't have tabular data, use
|> | appropriate markup. Additionally, if you want the non-tabular data to be
|> | styled like a grid (equal height etc.), then use the CSS table model.
|>
|> In another followup you weren't saying this. Now you are. I don't get
|> what this flip flop is.
|
| Where can you quote me?

In Message-ID: <44***********************@authen.yellow.readfreen ews.net>
All those short answers.


You said:
And a table is a structure. Of course its presentation can be styled,
too.

I responded:
Yes.

You said:
So for the structure, I should use HTML. Then for the appearance use
CSS. That's what I thought all along.

I responded:
Yes

You said:
And I can change how table/tr/td presented, too.
But I still use table/tr/td to define the structure.

I responded:
Yes
Now, why is that flip flop?
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
May 4 '06 #75

<ph**************@ipal.net> kirjoitti
viestissä:e3*********@news3.newsguy.com...

<snip>
So he's shifting off topic and trying to address the person instead of
the issue. That's not the first time he's done so.
Not true. My point is that most of the time in _your examples_ you are NOT
using semantically meaningful elements for the things you do. That's all. I
don't see point of you trying to stick using table to define LAYOUT. Because
that's what you keep doing. It might be hard to unlearn thinking in table
way, but it's worth it.

Even in latest drop shadow thing you keep using table to create layout
structure.

<snip>
But I think he needs to stay _on_ topic for 2 reasons.
One is that it can get confusing when the deviation is made. And two,
he hasn't really addressed the TABLE/TR/TD issue adequately.
I am saying you use table to position things, like your columns.

http://www.kolumbus.fi/ace/ng/boxes.html is quick mock up without tables. I
have no idea where it works because I didn't really test it that much
though...

Merely
saying that I'm not using the semantics means he expects me to use some
other means, but only makes vague references to what those are, without
being specific. I think he needs to be specific because that's the only
way I can pin point _his_ misunderstanding of what _I_ am trying to do.
How does your ROWS and colums relate in tables, what relation that data in
there has?

For example first thing in your page, you are using TABLE to position
elements. Meaning you use TABLE to position a heading of your page and
google ads (that I have turned off, only saw those when looked in IE).

On main part of page you use again TABLE to create three columns. Again to
make a LAYOUT. And when you look inside those three tables cells, well,
what you know. More tables.. etc. You are not using elements that have
semantical purpose for things. Like lists (of those links) are inside tables
and just text you use <BR> to split in lines. Etc.

And yes, I know you have said this page is not new, so, as I look things,
now is yout chance to "fix" things like not anymore using tables for
position things or create layout structures.

|> An early version DID use UL/LI, but that never came out right. That
MAY
|> be tweakable today, but some things like the bullet size don't seem to
|> be adjustable.
|
| Not AFAIK (they tend to adjust with the font size but can't be resized
| independently), but you can certainly remove the bullets altogether and
| e.g. use an image instead.

I don't want to use an image there. I want something very tiny. The dash
did the job just fine.
then use that in either text or

li:before
{
content: "-";
}

That don't work IE6 or earlier though. Though if you'd use TINY image on LI
background positioned left, it would suit too.

|> So for now, they are just a list formed in lines with BR.
|
| Which isn't really a list at all.

My "semantics of a list" does not require a bullet.
then use list-style-type: none;

I would call such a
thing a "bulleted list". That's not so much of a departure from an
ordered
list that gets numbered. I see the choice of bullet, or numbers, or
nothing
at all, a presentation issue, anyway. But I can't see where CSS gives me
those choices just yet. Maybe in CSS3?


li
{
list-style-type: none;
}

etc?

<snip>
May 4 '06 #76
On Thu, 04 May 2006 12:19:00 +0200 Johannes Koch <ko**@w3development.de> wrote:

| ph**************@ipal.net wrote:
|
|> On Thu, 04 May 2006 10:08:09 +0200 Johannes Koch <ko**@w3development.de> wrote:
|> | ph**************@ipal.net wrote:
|> |
|> |> On Wed, 03 May 2006 23:50:16 +0200 Johannes Koch <ko**@w3development.de> wrote:
|> |> | If you have tabular data, use table, caption, col, colgroup, thead,
|> |> | tfoot, tbody, tr, th, td. If you don't have tabular data, use
|> |> | appropriate markup. Additionally, if you want the non-tabular data to be
|> |> | styled like a grid (equal height etc.), then use the CSS table model.
|> |>
|> |> In another followup you weren't saying this. Now you are. I don't get
|> |> what this flip flop is.
|> |
|> | Where can you quote me?
|>
|> In Message-ID: <44***********************@authen.yellow.readfreen ews.net>
|> All those short answers.
|
| You said:
| And a table is a structure. Of course its presentation can be styled,
| too.
|
| I responded:
| Yes.
|
| You said:
| So for the structure, I should use HTML. Then for the appearance use
| CSS. That's what I thought all along.
|
| I responded:
| Yes
|
| You said:
| And I can change how table/tr/td presented, too.
| But I still use table/tr/td to define the structure.
|
| I responded:
| Yes
|
|
| Now, why is that flip flop?

You said in a previous post:

If you have tabular data, use table, caption, col, colgroup, thead,
tfoot, tbody, tr, th, td. If you don't have tabular data, use
appropriate markup. Additionally, if you want the non-tabular data to be
styled like a grid (equal height etc.), then use the CSS table model.

I don't know about equal height bit, though that would be expected in a
grid structure. The "data" I have is blocks of text. It's not what people
refer to as "tabular data" (like you might find in a spreadsheat as one
person described it). Instead, it is a grid organization of sections of
data, pretty forcing a specific set of columns. But all the semantics are
still the same as what TABLE/TR/TD and friends provide, and not what any
other method provides (certainly not float:left). So unless your definition
of "tabular data" doesn't follow the norm, this does come across as a
flip-flop. But looking over all your postings, it certain does seem you
may have a different definition of things like "tabular data".

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 5 '06 #77
Deciding to do something for the good of humanity,
<ph**************@ipal.net> declared in
comp.infosystems.www.authoring.stylesheets:
I don't want to use an image there. I want something very tiny.
So use a tiny image. ;-)
The dash
did the job just fine.
As Wyrm said, just put the dash in the text as you are now, or add it
with CSS (with the caveat that IE doesn't support it).
My "semantics of a list" does not require a bullet.
Well, really you want a bullet that looks like a dash instead of a disc.
That's not so much of a departure from an ordered
list that gets numbered. I see the choice of bullet, or numbers, or nothing
at all, a presentation issue, anyway.
The actual style of the bullet or number is certainly a presentation
issue, yes.

However there is a semantic difference between bullets and numbers, i.e.
an unordered list and an ordered list - in the former, the order of the
list items is irrelevant, in the latter, the order does matter. A recipe
is a prime example - the list of ingredients can be in any order, but
the steps in the method need to be in the correct order.

Though you could style an unordered list with numbers (or an ordered
list with glyphs) if you really wanted to.
But I can't see where CSS gives me
those choices just yet.
The bullet style can be set with list-style-type, though a dash is not
one of the options.
Maybe in CSS3?


Looks like it - according to the current draft, list-style-type will
include "hyphen".
http://www.w3.org/TR/2002/WD-css3-li...021107/#glyphs

--
Mark Parnell
My Usenet is improved; yours could be too:
http://blinkynet.net/comp/uip5.html
May 5 '06 #78
On Thu, 4 May 2006 22:30:09 +0300 "W?rm" <no*************@north.invalid> wrote:
|
| <ph**************@ipal.net> kirjoitti
| viestiss?:e3*********@news3.newsguy.com...
|
| <snip>
|
|> So he's shifting off topic and trying to address the person instead of
|> the issue. That's not the first time he's done so.
|
| Not true. My point is that most of the time in _your examples_ you are NOT
| using semantically meaningful elements for the things you do. That's all. I
| don't see point of you trying to stick using table to define LAYOUT. Because
| that's what you keep doing. It might be hard to unlearn thinking in table
| way, but it's worth it.

I don't see _anyone_ doing any layout that gets what I want to have
who uses anything but tables. People have suggested things before and
it did not work (not same semantics ... stuff like rightmost column
falls down to left side, which is unacceptable).
| Even in latest drop shadow thing you keep using table to create layout
| structure.

And so far, it takes that to ensure it works.
|> But I think he needs to stay _on_ topic for 2 reasons.
|> One is that it can get confusing when the deviation is made. And two,
|> he hasn't really addressed the TABLE/TR/TD issue adequately.
|
| I am saying you use table to position things, like your columns.
|
| http://www.kolumbus.fi/ace/ng/boxes.html is quick mock up without tables. I
| have no idea where it works because I didn't really test it that much
| though...

Some issues exist:

1. Text falls outside of these boxes, but does not with tables.
Maybe that's another property that table/tr/td defaults to
that you could add.

2. The content producer (that does not produce the CSS) decides how
many columns of data there are (it's the content the user selects).

3. There's no savings here. That's been touted as _one_ reason to
use CSS. But I don't see it. You have as many elements as I would
just named different, and with classes.

I've been doing styles now with selectors like:

..foo
..foo>*
..foo>*>*
..foo>*>*>*

to handle each level of element to select. I suppose that could work
whether the elements involved are TABLE/TR/TD or DIV/DIV/DIV and only
need a class on the outmost one. Seems to work.
|> Merely
|> saying that I'm not using the semantics means he expects me to use some
|> other means, but only makes vague references to what those are, without
|> being specific. I think he needs to be specific because that's the only
|> way I can pin point _his_ misunderstanding of what _I_ am trying to do.
|
| How does your ROWS and colums relate in tables, what relation that data in
| there has?

That depends one which things I'm doing. Where there are multiple rows,
each item (cell) needs to be under the others of the same column. Where
there are not, it's basically just one row of N columns to stop flow of
blocks onto the row below.
| For example first thing in your page, you are using TABLE to position
| elements. Meaning you use TABLE to position a heading of your page and
| google ads (that I have turned off, only saw those when looked in IE).
|
| On main part of page you use again TABLE to create three columns. Again to
| make a LAYOUT. And when you look inside those three tables cells, well,
| what you know. More tables.. etc. You are not using elements that have
| semantical purpose for things. Like lists (of those links) are inside tables
| and just text you use <BR> to split in lines. Etc.

Don't count the tables used to structure the drop shadow. That I know is
not what tables is for. Semantically, the drop shadows are not content,
just style, so ideally I should be able to do that in CSS. Unfortunately,
even this can't be done just in CSS. CSS needs more element laters to be
in the content to accomplish it.
| And yes, I know you have said this page is not new, so, as I look things,
| now is yout chance to "fix" things like not anymore using tables for
| position things or create layout structures.

Which is what I am working on. The drop shadows I'm going to do in CSS as
much as I can (but I still have to put 2 extra layers of DIVs in to do
stationary drop shadows, and 4 extra layers to do saluting drop shadoows
where the page rises up ... one of those layers to prevent a situation
where the salute can oscillate when the point is positioned where the
movement pulls the object out from under the pointer, then it no longer
is hovering and it comes back, then it is hovering again, over and over.

But As I said earlier, I don't see the gain in using 3 different elements
for 3 elements I already use. But the real point here is, if you can do
exactly what TABLE/TR/TD does with DIV/DIV/DIV then you've also shown that
having TABLE/TR/TD in HTML is unnecessary (and I would expect to see you
urge that they be depricated from the standard).
|> |> An early version DID use UL/LI, but that never came out right. That
|> MAY
|> |> be tweakable today, but some things like the bullet size don't seem to
|> |> be adjustable.
|> |
|> | Not AFAIK (they tend to adjust with the font size but can't be resized
|> | independently), but you can certainly remove the bullets altogether and
|> | e.g. use an image instead.
|>
|> I don't want to use an image there. I want something very tiny. The dash
|> did the job just fine.
|
| then use that in either text or
|
| li:before
| {
| content: "-";
| }
|
| That don't work IE6 or earlier though. Though if you'd use TINY image on LI
| background positioned left, it would suit too.
|
|
|> |> So for now, they are just a list formed in lines with BR.
|> |
|> | Which isn't really a list at all.
|>
|> My "semantics of a list" does not require a bullet.
|
| then use list-style-type: none;

OK.
|> I would call such a
|> thing a "bulleted list". That's not so much of a departure from an
|> ordered
|> list that gets numbered. I see the choice of bullet, or numbers, or
|> nothing
|> at all, a presentation issue, anyway. But I can't see where CSS gives me
|> those choices just yet. Maybe in CSS3?
|
| li
| {
| list-style-type: none;
| }

I missed that one. But I'm still focusing my work on other aspect of the
design right now. This is generated HTML, so I've got to get all aspects
of the coding just right on the context of the coming variations in content.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 5 '06 #79

<ph**************@ipal.net> kirjoitti
viestissä:e3*********@news1.newsguy.com...

<snip>
I don't see _anyone_ doing any layout that gets what I want to have
who uses anything but tables. People have suggested things before and
it did not work (not same semantics ... stuff like rightmost column
falls down to left side, which is unacceptable).
And you can prevent it if you actually wan't, because I prefer layout to be
fluid wien it comes to colums which only "relation" is that you want them
presented (no relation in data of the columns itself) side by side instead
being fluid so that's why I don't do that in example. I don't see it to be
unacceptable in this case because there is not any relation for the data you
have in columns, atleast not currently.

Too bad internet explorer do not support min-width: but there are other
ways to prevent it too. Use width for the body, or h1, or add maybe one more
container with width set so wide things dont mess up, or use one line gif
(with "minumum" acceptable width for all columns combined (for IE to get by
the missing min-width:) etc. there are different ways. Now what is best,
that is not something I will say a thing, because I like content to be fluid
unless design itself is "fixed width" and I try avoid such designs when ever
I can.
<snip>
Some issues exist:

1. Text falls outside of these boxes, but does not with tables.
Maybe that's another property that table/tr/td defaults to
that you could add.
one way is min-width: to sent minimum acceptable width for those things. But
don't work for IE. Again there are work arounds for that, but what's good or
proper, that's entirely different matter...

2. The content producer (that does not produce the CSS) decides how
many columns of data there are (it's the content the user selects).

3. There's no savings here. That's been touted as _one_ reason to
use CSS. But I don't see it. You have as many elements as I would
just named different, and with classes.
Yes there are actually less when you remove tables, depends how complex use
of tables there is, your tables are simple so there's not that much
difference. But that is not the point.

Point is to use structures that have semantical meaning.

Like those unordered lists, headings etc. Then use CSS to tweak their
presentation in way you want to show em.

It's like when you write Document, you should use elements that have
semantical meaning, like Headings for Headings (in html H1 as whole document
heading, H2 as headings under it, H3 for headings that are under H3 etc.),
not just use paragraph for heading and style it to look like heading.

See, idea is to use elements that have certain semantical meaning for the
content. Headings are headings, lists are, well lists, paragraphs of text
are paragraphs etc. And when there's no proper thing to use, then there's
DIV and SPAN...
<snip> | How does your ROWS and colums relate in tables, what relation that data
in
| there has?

That depends one which things I'm doing. Where there are multiple rows,
each item (cell) needs to be under the others of the same column. Where
there are not, it's basically just one row of N columns to stop flow of
blocks onto the row below.
So data itself has no relation, you only use table for layout.
<snip>
But As I said earlier, I don't see the gain in using 3 different elements
for 3 elements I already use. But the real point here is, if you can do
exactly what TABLE/TR/TD does with DIV/DIV/DIV then you've also shown that
having TABLE/TR/TD in HTML is unnecessary (and I would expect to see you
urge that they be depricated from the standard).
No, I say that you should use _elements_ that are _semantical_ for the
purpose. Like those mentioned headings for headings, lists for lists etc.
Table will not be unnecessary, it has it's semantical meaning too, not to
use it for layout, but for tabular data. Table represent relationships
between data.
<snip>
I missed that one.
Easy to miss things sometimes, been doing whole night C# coding and was
refactoring some earlier code. Plenty of lines that I had done some point
earlier, happily reinventing some wheels when there were already stuff on
..NET for that purpose. I was feeling like kicking my self plenty of times
just because I had originally missed those things, heh. Just gotta try
remember next time and keep on trying to learn more. Sad part is that more
one learn, more one feel like knowing nothing. Always find more new things
to learn than manage to learn.

But I'm still focusing my work on other aspect of the
design right now. This is generated HTML, so I've got to get all aspects
of the coding just right on the context of the coming variations in
content.


Well, you'll get there some point :) Maybe kicking and screaming about
HTML/CSS and them having no "use" ;)

Anyway, I hope you get what I am trying to say, about using semantically
meaningful stuff. It's 6am and haven't yet got any sleep (but plan to have
some now) so might be rather rambling state...
May 5 '06 #80
On Fri, 5 May 2006 10:35:23 +1000 Mark Parnell <we*******@clarkecomputers.com.au> wrote:
| Deciding to do something for the good of humanity,
| <ph**************@ipal.net> declared in
| comp.infosystems.www.authoring.stylesheets:
|
|> I don't want to use an image there. I want something very tiny.
|
| So use a tiny image. ;-)

I'm wanting to avoid the extra server hit.
|> The dash
|> did the job just fine.
|
| As Wyrm said, just put the dash in the text as you are now, or add it
| with CSS (with the caveat that IE doesn't support it).
|
|> My "semantics of a list" does not require a bullet.
|
| Well, really you want a bullet that looks like a dash instead of a disc.

I guess you could say it that way.
|> That's not so much of a departure from an ordered
|> list that gets numbered. I see the choice of bullet, or numbers, or nothing
|> at all, a presentation issue, anyway.
|
| The actual style of the bullet or number is certainly a presentation
| issue, yes.
|
| However there is a semantic difference between bullets and numbers, i.e.
| an unordered list and an ordered list - in the former, the order of the
| list items is irrelevant, in the latter, the order does matter. A recipe
| is a prime example - the list of ingredients can be in any order, but
| the steps in the method need to be in the correct order.

So if an implementation were to re-arrange the order of items given in
a list with UL/LI, that would be OK?

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 5 '06 #81
On Fri, 5 May 2006 06:06:21 +0300 "W?rm" <no*************@north.invalid> wrote:
|
| <ph**************@ipal.net> kirjoitti
| viestiss?:e3*********@news1.newsguy.com...
|
| <snip>
|
|> I don't see _anyone_ doing any layout that gets what I want to have
|> who uses anything but tables. People have suggested things before and
|> it did not work (not same semantics ... stuff like rightmost column
|> falls down to left side, which is unacceptable).
|
| And you can prevent it if you actually wan't, because I prefer layout to be
| fluid wien it comes to colums which only "relation" is that you want them
| presented (no relation in data of the columns itself) side by side instead
| being fluid so that's why I don't do that in example. I don't see it to be
| unacceptable in this case because there is not any relation for the data you
| have in columns, atleast not currently.

We each have our own different desires of ways to do things, and/or different
projects with different requirements.
| Too bad internet explorer do not support min-width: but there are other
| ways to prevent it too. Use width for the body, or h1, or add maybe one more
| container with width set so wide things dont mess up, or use one line gif
| (with "minumum" acceptable width for all columns combined (for IE to get by
| the missing min-width:) etc. there are different ways. Now what is best,
| that is not something I will say a thing, because I like content to be fluid
| unless design itself is "fixed width" and I try avoid such designs when ever
| I can.

On the TABLE element I can specify width=100% and get the whole table to go
to at least the width of the viewing area. Then however many columns I have
can be made to fit with width= some percentage that the content generator
will have knowledge of. I suppose I could do style= on DIV elements their
place instead of the separate CSS file.
|> Some issues exist:
|>
|> 1. Text falls outside of these boxes, but does not with tables.
|> Maybe that's another property that table/tr/td defaults to
|> that you could add.
|
| one way is min-width: to sent minimum acceptable width for those things. But
| don't work for IE. Again there are work arounds for that, but what's good or
| proper, that's entirely different matter...

Apparently width= works on TH/TD in IE.
|> 2. The content producer (that does not produce the CSS) decides how
|> many columns of data there are (it's the content the user selects).
|>
|> 3. There's no savings here. That's been touted as _one_ reason to
|> use CSS. But I don't see it. You have as many elements as I would
|> just named different, and with classes.
|
| Yes there are actually less when you remove tables, depends how complex use
| of tables there is, your tables are simple so there's not that much
| difference. But that is not the point.
|
| Point is to use structures that have semantical meaning.

I'd like to. But details of the layout come with the content, not with the
style, based one what the content generator produces (e.g. data selections
the user may supply on a form).
| Like those unordered lists, headings etc. Then use CSS to tweak their
| presentation in way you want to show em.

I guess I need to get used to using things that by default have some kind
of presentation style already which I have to then turn off, as opposed to
the previous method (basically just using <BR> to force a new line) which
was simple and did exactly what I wanted.
| It's like when you write Document, you should use elements that have
| semantical meaning, like Headings for Headings (in html H1 as whole document
| heading, H2 as headings under it, H3 for headings that are under H3 etc.),
| not just use paragraph for heading and style it to look like heading.
|
| See, idea is to use elements that have certain semantical meaning for the
| content. Headings are headings, lists are, well lists, paragraphs of text
| are paragraphs etc. And when there's no proper thing to use, then there's
| DIV and SPAN...

Now to find the CSS properties that make DIV behave like each of the elements
of a table.
|> That depends one which things I'm doing. Where there are multiple rows,
|> each item (cell) needs to be under the others of the same column. Where
|> there are not, it's basically just one row of N columns to stop flow of
|> blocks onto the row below.
|
| So data itself has no relation, you only use table for layout.

There is relation, though relatively simple. It just has to all be in the
same row. You did accomplish that, but there were other issues which I
don't yet know the answers to.
|> But As I said earlier, I don't see the gain in using 3 different elements
|> for 3 elements I already use. But the real point here is, if you can do
|> exactly what TABLE/TR/TD does with DIV/DIV/DIV then you've also shown that
|> having TABLE/TR/TD in HTML is unnecessary (and I would expect to see you
|> urge that they be depricated from the standard).
|
| No, I say that you should use _elements_ that are _semantical_ for the
| purpose. Like those mentioned headings for headings, lists for lists etc.
| Table will not be unnecessary, it has it's semantical meaning too, not to
| use it for layout, but for tabular data. Table represent relationships
| between data.

And I often see (where others often don't) a relationship that is like what
a table creates. So it's just natural to use a table there for that.
|> I missed that one.
|
| Easy to miss things sometimes, been doing whole night C# coding and was
| refactoring some earlier code. Plenty of lines that I had done some point
| earlier, happily reinventing some wheels when there were already stuff on
| .NET for that purpose. I was feeling like kicking my self plenty of times
| just because I had originally missed those things, heh. Just gotta try
| remember next time and keep on trying to learn more. Sad part is that more
| one learn, more one feel like knowing nothing. Always find more new things
| to learn than manage to learn.

Sometimes one reinvents things that would have worked. And sometimes one
one tries to use things that exist that end up not working or being a big
pain to use. In my programming I started collecting all my tools and even
made them available online as a library. Some people see some of the things
I've done as duplication of what others have done. But looking closer one
could see there's more to it, or it's simpler, etc. Not everything that
appears to be a re-invention really is.
|> But I'm still focusing my work on other aspect of the
|> design right now. This is generated HTML, so I've got to get all aspects
|> of the coding just right on the context of the coming variations in
|> content.
|
| Well, you'll get there some point :) Maybe kicking and screaming about
| HTML/CSS and them having no "use" ;)
|
| Anyway, I hope you get what I am trying to say, about using semantically
| meaningful stuff. It's 6am and haven't yet got any sleep (but plan to have
| some now) so might be rather rambling state...

My understanding is the content should have markup to say what it is, and
the stylesheet should say how to present it. But there's a gap of layout
that straddles the two. Maybe a third language for that is needed. But
in some cases, the relationships of data are known with the content and
can be different such that a single style can't be used to do a layout.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 5 '06 #82
Deciding to do something for the good of humanity,
<ph**************@ipal.net> declared in
comp.infosystems.www.authoring.stylesheets:
So if an implementation were to re-arrange the order of items given in
a list with UL/LI, that would be OK?


It shouldn't matter, no. For example a UA could (theoretically) provide
the ability to automatically sort list items in alphabetical order. For
an unordered list that would be fine. For an ordered list it wouldn't.

--
Mark Parnell
My Usenet is improved; yours could be too:
http://blinkynet.net/comp/uip5.html
May 5 '06 #83
On Fri, 5 May 2006 06:06:21 +0300 "W?rm" <no*************@north.invalid> wrote:

| Anyway, I hope you get what I am trying to say, about using semantically
| meaningful stuff. It's 6am and haven't yet got any sleep (but plan to have
| some now) so might be rather rambling state...

So how would you do the following? You have a list of stuff, maybe a lot.
The list is to be presented where each row alternates between white and
light green. But the list is being produced by some database program you
cannot change. So whatever HTML element it uses, it's identical for every
row generated. I saw the + used on selectors to accomplish that effect
for a chessboard (I had replied to that with "gross"). But you could not
really use that here because this list might have thousands of rows. Of
course, it would be nicer to have the rows generated with some kind of
even/odd class names so it can be done with 2 selectors.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 5 '06 #84
ph**************@ipal.net wrote:
On Thu, 04 May 2006 12:19:00 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|> On Thu, 04 May 2006 10:08:09 +0200 Johannes Koch <ko**@w3development.de> wrote:
|> | ph**************@ipal.net wrote:
|> |
|> |> On Wed, 03 May 2006 23:50:16 +0200 Johannes Koch <ko**@w3development.de> wrote:
|> |> | If you have tabular data, use table, caption, col, colgroup, thead,
|> |> | tfoot, tbody, tr, th, td. If you don't have tabular data, use
|> |> | appropriate markup. Additionally, if you want the non-tabular data to be
|> |> | styled like a grid (equal height etc.), then use the CSS table model.
|> |>
|> |> In another followup you weren't saying this. Now you are. I don't get
|> |> what this flip flop is.
|> |
|> | Where can you quote me?
|>
|> In Message-ID: <44***********************@authen.yellow.readfreen ews.net>
|> All those short answers.
|
| You said:
| And a table is a structure. Of course its presentation can be styled,
| too.
|
| I responded:
| Yes.
|
| You said:
| So for the structure, I should use HTML. Then for the appearance use
| CSS. That's what I thought all along.
|
| I responded:
| Yes
|
| You said:
| And I can change how table/tr/td presented, too.
| But I still use table/tr/td to define the structure.
|
| I responded:
| Yes
|
|
| Now, why is that flip flop?

You said in a previous post:

If you have tabular data, use table, caption, col, colgroup, thead,
tfoot, tbody, tr, th, td. If you don't have tabular data, use
appropriate markup. Additionally, if you want the non-tabular data to be
styled like a grid (equal height etc.), then use the CSS table model.

I don't know about equal height bit, though that would be expected in a
grid structure. The "data" I have is blocks of text. It's not what people
refer to as "tabular data" (like you might find in a spreadsheat as one
person described it). Instead, it is a grid organization of sections of
data, pretty forcing a specific set of columns. But all the semantics are
still the same as what TABLE/TR/TD and friends provide, and not what any
other method provides (certainly not float:left). So unless your definition
of "tabular data" doesn't follow the norm, this does come across as a
flip-flop. But looking over all your postings, it certain does seem you
may have a different definition of things like "tabular data".


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

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.

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.

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

One that will be meaningful, so that if an aural browser read out
[heading for row 3, heading for column 2, content of cell at
intersection of row 3 and column 2] it would make sense.

It's not always necessary to then go and put these headings in the
page (though it's usually a very good idea to do so) but if you don't
have any headings for your rows or columns then there's a good chance
that semantically you don't have a data table and hence you should be
looking at CSS tables not HTML tables.

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

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 5 '06 #85
ph**************@ipal.net wrote:
So how would you do the following? You have a list of stuff, maybe a lot.
The list is to be presented where each row alternates between white and
light green. But the list is being produced by some database program you
cannot change. So whatever HTML element it uses, it's identical for every
row generated. I saw the + used on selectors to accomplish that effect
for a chessboard (I had replied to that with "gross"). But you could not
really use that here because this list might have thousands of rows. Of
course, it would be nicer to have the rows generated with some kind of
even/odd class names so it can be done with 2 selectors.


Either wait for support for CSS3.

Or use some JavaScript to apply the styling dynamically (see the
thread 'Style based on tag content' for examples using both plain
JavaScript and bindings/behaviours).

Or take the ouput HTML and feed it through another level or processing
on the server to add the classes for odd/even.

I guess I'm lucky that on my current job that the back end programs
grabbing stuff out of the database spit everything out as XML and so
the production of the HTML via XSLT is entirely in my hands. I can
write the XSLT and CSS at the same time and never need to bother the
back end programmers or database guys to get an extra class attribute
included.

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 5 '06 #86
Steve Pugh 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_?

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.

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.

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

One that will be meaningful, so that if an aural browser read out
[heading for row 3, heading for column 2, content of cell at
intersection of row 3 and column 2] it would make sense.

It's not always necessary to then go and put these headings in the
page (though it's usually a very good idea to do so) but if you don't
have any headings for your rows or columns then there's a good chance
that semantically you don't have a data table and hence you should be
looking at CSS tables not HTML tables.
Well summarized.
Of course this is somewhat academic as IE6 doesn't support CSS tables,
so if your design really demands a grid then you must either abuse
HTML tables or change the design.


Or ignore IE :-)
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
May 5 '06 #87
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.

I saw a demonstration of display: table-* that did not do the job.
Maybe that demonstration was defective and you can provide a better
one?
| 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. One demo page
I was showed an invisible grid with thumbnail pictures. When the size
of the displayable area was shrunk, the object on the right moved to
the next lower row and on the left. For some kinds of semantics this
would be fine (and I've done stuff like that, too). But for others it
is not.
| One way to decide whether your data belongs in a table or not is to
| consider whether every row and column could be given a heading, i.e.
| could you include a <th> for each row and column?

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

However, what I ahve in mind right now needs to have the layout semantics
of TABLE/TR/TD. I've seen some examples that correct the flow problem
(e.g. they made the right column stay at the right) but they had other
issues which I don't know can be corrected (in part because I have seen
that problem in a _lot_ of web pages, so I worry that it could be an issue
of CSS).
| Of course this is somewhat academic as IE6 doesn't support CSS tables,
| so if your design really demands a grid then you must either abuse
| HTML tables or change the design.

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

The site design of http://linuxhomepage.com/ was made for Netscape 3 because
Netscape 4 that was already out at the time I created that design (which was
before that site itself) was horrendously bloated and terribly slow when
compared to Netscape 3. So I could not recommend Netscape 4 to anyone. The
design (based entirely on tables) was tweaked to work in NS 3, NS 4, IE 3,
IE 4, and Opera (forgot the version). It is the emergence of Firefox 1.5
that has changed the landscape for me because it is universally recommendable
and apparently is very compliant. That is why I am doing CSS now.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 5 '06 #88
On Fri, 5 May 2006 15:10:24 +1000 Mark Parnell <we*******@clarkecomputers.com.au> wrote:
| Deciding to do something for the good of humanity,
| <ph**************@ipal.net> declared in
| comp.infosystems.www.authoring.stylesheets:
|
|> So if an implementation were to re-arrange the order of items given in
|> a list with UL/LI, that would be OK?
|
| It shouldn't matter, no. For example a UA could (theoretically) provide
| the ability to automatically sort list items in alphabetical order. For
| an unordered list that would be fine. For an ordered list it wouldn't.

I usually want my lists to be in order, but generally do not want the
numbers. So I'll have to see if CSS can do that.

Keep in mind that I only raised the TABLE/TR/TD issue, and I did that since
that is the level of what I am working on right now. I was not concerned
with the list issue at this time because I could fall back to doing it the
way I have been doing it all along, and I would eventually get to that part
of CSS. I'm doing one thing at a time, and someone else raised the list
issue and I simply addressed it the best I can.

Here's a little unordered list:

It would help if:

* Answers given would include actual exact CSS code and not just say
"you need to understand ..."

* Online example pages would be the utmost minimum to illustrate just one
feature so people don't have to figure out what parts of the HTML and
CSS are really needed.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 5 '06 #89
ph**************@ipal.net wrote:
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.
So you can swap the items in the third row, second column and fifth
rowm second column, without changing the meaning of the page?

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

I saw a demonstration of display: table-* that did not do the job.
Maybe that demonstration was defective and you can provide a better
one?
I'd need to know in which way it "did not do the job".
| It's all about the semantics. A table has semantics whereby any piece
| of content belongs to a row and column and that belonging has a set
| meaning. A 'grid' just has the same appearance but none of the
| semantics.

I've found more than one kind of semantics for a grid.
A grid has no semantics.
One demo page
I was showed an invisible grid with thumbnail pictures. When the size
of the displayable area was shrunk, the object on the right moved to
the next lower row and on the left. For some kinds of semantics this
would be fine (and I've done stuff like that, too). But for others it
is not.
If it's just an image gallery then in terms of semantics that's not a
problem. In terms of layout it might not match the designer's vision
and then it becomes an issue of usability v. design fidelity in the
edge case or users with narrow browser windows.
| One way to decide whether your data belongs in a table or not is to
| consider whether every row and column could be given a heading, i.e.
| could you include a <th> for each row and column?

In some cases they could be. Or it could be implied and not actually
shown (which I think you intended to include by your choice of the word
"could").
Or by the bit a little later where I say "It's not always necessary to
then go and put these headings in the page (though it's usually a very
good idea to do so)"

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

However, what I ahve in mind right now needs to have the layout semantics
of TABLE/TR/TD.
"Layout semantics". That doesn't really make sense. Some semantics
demand a particular layout (though for most data tables you can rotate
by 90 degrees - i.e. swap rows and columns - and maintain the
semantics) and in general the layout may give visual hints towards the
underlying semantics (unless the author has done something stupid like
make all of H1 - H6 appear the same) but the semantics and the
presentation are different things.
I've seen some examples that correct the flow problem
(e.g. they made the right column stay at the right)
For a table, where the data in a row must stay in a row otherwise the
meaning is distorted, that is essential. For a layout where the
meaning is the same but the presntation is different that is totally
optional.
but they had other
issues which I don't know can be corrected (in part because I have seen
that problem in a _lot_ of web pages, so I worry that it could be an issue
of CSS).
What is this other problem?
| Of course this is somewhat academic as IE6 doesn't support CSS tables,
| so if your design really demands a grid then you must either abuse
| HTML tables or change the design.

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


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

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

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
May 5 '06 #90
> Show me CSS2 coding that will produce tables with the same semantics that
TABLE/TR/TD has, and maybe I could believe it's an implementatuon issue.

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

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


I think you underestimate what's possible with CSS:

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

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

Ciao
Niels

May 5 '06 #91
> That data could just as easily come out as:

apple banana bread cherry hazelnut
mango orange pear potato tomato

or as:

apple banana bread
cherry hazelnut mango
orange pear potato
tomato

This example is not what I have been talking about.

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

apple bread hazelnut orange potato
banana cherry mango pear tomato

or in a narrower window like:

apple cherry orange tomato
banana hazelnut pear
bread mango potato

or even:

apple hazelnut potato
banana mango tomato
bread orange
cherry pear

There are some things where this would work better, such as a list of
files in a folder/directory. But it would be style ... something to
decide how to present. Does CSS have a way to say to list stuff this
way? In case someone doesn't see what I'm showing, just look at the
alphabetical sequence of these "food items".
You're changing language-semantics here, this is
direction: ltb (gravity left, order top-to-bottom)
float: top
whereas western style is 'tlr'.

Also it goes into the direction of:

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

Both have the same 'problem', the restrictor is _height_
not _width_, but that's only natural behaviour (consistent
with the definition of direction in both cases).
But if I have 2-dimentional data, then this is not the thing to be doing.
So I'm still back to using TABLE/TR/TD, etc., for the 2-D stuff.


Ciao
Niels

May 5 '06 #92
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:
|>
|>| Consider your blocks of text that you want to arrange in a grid. Now
|>| take the block of text that's at the intersection of the third row and
|>| the second column. What does that fact that it's at that intersection
|>| _mean_?
|>
|>That can depend. It might be more important that it is in the second
|>column.
|
| So you can swap the items in the third row, second column and fifth
| rowm second column, without changing the meaning of the page?

In some such cases, sure. Maybe not in others. It depends on which site
and the nature of that content.
| That's almost certaibly not a data table and hence should not be
| marked up with HTML table elements.

But until I see a way to make it work correctly in CSS, I fall back to
what does work, and will still use TABLE elements, regardless of any
debate over whether the meaning is appropriate.
|>| In a table it means something. e.g. it means that it's the printer
|>| sales figure for France (row) in May 2005 (column); or that the black
|>| queen is on square C6 (which is why I think the chessboard is a valid
|>| table).
|>|
|>| But it just means that this block of text is in the third row and the
|>| second column, then there are no table semantics. And hence HTML
|>| tables should not be used, but CSS display: table-* can be used to
|>| give the appearance a table like grid effect.
|>
|>I saw a demonstration of display: table-* that did not do the job.
|>Maybe that demonstration was defective and you can provide a better
|>one?
|
| I'd need to know in which way it "did not do the job".

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

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

But here are some of the issues I have seen:

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

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

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

There may be other issues. In all, the way TABLE/TR/TD elements work in
HTML must be retained.
|>| It's all about the semantics. A table has semantics whereby any piece
|>| of content belongs to a row and column and that belonging has a set
|>| meaning. A 'grid' just has the same appearance but none of the
|>| semantics.
|>
|>I've found more than one kind of semantics for a grid.
|
| A grid has no semantics.

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

To me, it's a grid if it meets certain criteria. I call those criteria
the semantics of a grid. But maybe it might be clearer to shift the
usage over to something like "rigid grid".
|> One demo page
|>I was showed an invisible grid with thumbnail pictures. When the size
|>of the displayable area was shrunk, the object on the right moved to
|>the next lower row and on the left. For some kinds of semantics this
|>would be fine (and I've done stuff like that, too). But for others it
|>is not.
|
| If it's just an image gallery then in terms of semantics that's not a
| problem. In terms of layout it might not match the designer's vision
| and then it becomes an issue of usability v. design fidelity in the
| edge case or users with narrow browser windows.

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

But I wasn't talking about an image gallery when I was bringing up the
overall table issue.
|>| One way to decide whether your data belongs in a table or not is to
|>| consider whether every row and column could be given a heading, i.e.
|>| could you include a <th> for each row and column?
|>
|>In some cases they could be. Or it could be implied and not actually
|>shown (which I think you intended to include by your choice of the word
|>"could").
|
| Or by the bit a little later where I say "It's not always necessary to
| then go and put these headings in the page (though it's usually a very
| good idea to do so)"
|
| The important thing is that if it's a table then at least one, and
| often both, of rows or columns must have some sort of easily labelled
| relationship.

One thing I have found is that there is some variation among people who
have written in this and other threads about what is a table. Most will
agree that the kind of data found in a spreadsheet is appropriate. But
I can tell you that I've seen some really bizarre spreadsheet files in
some places. Some other people seem to be more accepting of just about
anything in each of the cells, and still call it a table as long as there
simply is the row/column relationship (with the implication that the table
elements in HTML would be OK).
|>| One that will be meaningful, so that if an aural browser read out
|>| [heading for row 3, heading for column 2, content of cell at
|>| intersection of row 3 and column 2] it would make sense.
|>|
|>| It's not always necessary to then go and put these headings in the
|>| page (though it's usually a very good idea to do so) but if you don't
|>| have any headings for your rows or columns then there's a good chance
|>| that semantically you don't have a data table and hence you should be
|>| looking at CSS tables not HTML tables.
|>
|>However, what I ahve in mind right now needs to have the layout semantics
|>of TABLE/TR/TD.
|
| "Layout semantics". That doesn't really make sense. Some semantics
| demand a particular layout (though for most data tables you can rotate
| by 90 degrees - i.e. swap rows and columns - and maintain the
| semantics) and in general the layout may give visual hints towards the
| underlying semantics (unless the author has done something stupid like
| make all of H1 - H6 appear the same) but the semantics and the
| presentation are different things.

Actually, the rotation would retain the relationship; it would just be
in a less convenient form.
|>I've seen some examples that correct the flow problem
|>(e.g. they made the right column stay at the right)
|
| For a table, where the data in a row must stay in a row otherwise the
| meaning is distorted, that is essential. For a layout where the
| meaning is the same but the presntation is different that is totally
| optional.

In a table, the data must also stay in the column. In some cases swapping
whole columns across all rows is OK. In some cases (not necessarily the
same set of cases just mentioned) swapping whole rows across all columns
is OK. In other cases, any swapping is not OK.
|>but they had other
|>issues which I don't know can be corrected (in part because I have seen
|>that problem in a _lot_ of web pages, so I worry that it could be an issue
|>of CSS).
|
| What is this other problem?

See the list I gave above. The biggest one I was thinking about while
writing that was the bleeding of text out of the cell.
|>| Of course this is somewhat academic as IE6 doesn't support CSS tables,
|>| so if your design really demands a grid then you must either abuse
|>| HTML tables or change the design.
|>
|>For a long time I avoided CSS altogether because of the browser upgrade
|>barrier. Firefox has managed to break that barrier because:
|>1. It seems to be a very compliant implementation
|>2. It's portable (Linux, BSD, Unix, Mac, and Windows)
|>3. It didn't bloat too much in relation to machine capability of the day
|>Basically, it means I feel good about recommending to everyone that they
|>use Firefox. Had IE also met all these requirements for just Windows, and
|>Firefox not been ported to Windows, I could have accepted recommending IE
|>for Windows users and Firefox for everyone else. But at least there is a
|>browser I can recommend (and it happens to be the same one for all).
|
| I would largely agree (I use Opera myself and the same points can be
| said about that browser). However, IE is still at least 80% of the
| population, so it can not be ignored. Otherwise CSS tables would be a
| semantics neutral layout grid solution.

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

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 5 '06 #93
On 5 May 2006 12:28:38 -0700 ni*************@seies.de wrote:
|> That data could just as easily come out as:
|>
|> apple banana bread cherry hazelnut
|> mango orange pear potato tomato
|>
|> or as:
|>
|> apple banana bread
|> cherry hazelnut mango
|> orange pear potato
|> tomato
|>
|> This example is not what I have been talking about.
|>
|> But I'll talking about it briefly, anyway. I'd like to have a COLUMN
|> orientation version of that, which would come out like this:
|>
|> apple bread hazelnut orange potato
|> banana cherry mango pear tomato
|>
|> or in a narrower window like:
|>
|> apple cherry orange tomato
|> banana hazelnut pear
|> bread mango potato
|>
|> or even:
|>
|> apple hazelnut potato
|> banana mango tomato
|> bread orange
|> cherry pear
|>
|> There are some things where this would work better, such as a list of
|> files in a folder/directory. But it would be style ... something to
|> decide how to present. Does CSS have a way to say to list stuff this
|> way? In case someone doesn't see what I'm showing, just look at the
|> alphabetical sequence of these "food items".
|
| You're changing language-semantics here, this is
| direction: ltb (gravity left, order top-to-bottom)
| float: top
| whereas western style is 'tlr'.

That's not something I've ever heard of.
| Also it goes into the direction of:
|
| http://www.quirksmode.org/css/multicolumn.html
|
| Both have the same 'problem', the restrictor is _height_
| not _width_, but that's only natural behaviour (consistent
| with the definition of direction in both cases).

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

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 5 '06 #94
On 5 May 2006 11:50:43 -0700 ni*************@seies.de wrote:
|> Show me CSS2 coding that will produce tables with the same semantics that
|> TABLE/TR/TD has, and maybe I could believe it's an implementatuon issue.
|>
|> For another issue with CSS, take a block of text in a _single_ DIV element
|> and using CSS only, style that block so it appears with a drop shadow effect
|> without changing the HTML at all. I had to add extra DIV elements to get it
|> to work, and found that a couple other people doing the same thing did it
|> the same way (though I went a step further and added yet another DIV to make
|> an effect that raised and lowered the shadow effect based on hover). Better
|> CSS would allow doing anything like that wihtout changing HTML at all. If
|> the style needs more container context, then CSS should be able to logically
|> include that.
|>
|> Here's one of the pages I was experimenting with:
|> http://phil.ipal.org/usenet/ciwas/20...in-tables.html
|> Be careful with the top right and bottom left corners as they can result in
|> the raising/lowering effect oscillating if you position the pointer on the
|> pixels that move away.
|
| I think you underestimate what's possible with CSS:
|
| http://www.paradice-insight.us/tests/drop-shadow.html

That middle one oscillates when you move the pointer just into the bottom
of it. I fixed the effect in my drop shadow boxes by enclosing everything
in an invisible outer box (DIV) that had the :hover on it's selector.
| It has it's problems, but shows that you _can_ adress complex (HTML)
| tasks 'successfull' in CSS, also it shows that CSS develops into the
| right direction anyway.
| Regarding your 'table-problem' there is the grid-supporting
| 'display'-attribute in CSS3 which is better suited for grid than tables
| are (try to make floating L- or U-forms with tables).

When will CSS3 be widely usable?

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 5 '06 #95
| You're changing language-semantics here, this is
| direction: ltb (gravity left, order top-to-bottom)
| float: top
| whereas western style is 'tlr'.

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


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

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

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

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

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

Ciao
Niels

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

When will CSS3 be widely usable?


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

Ciao
Niels

May 5 '06 #97
On 5 May 2006 16:07:16 -0700 ni*************@seies.de wrote:

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

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

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
May 6 '06 #98
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 grid does not have those semantics. A grid just has presentation, it
says nothing about what the dat _is_ but everything about how the data
_looks_.

I strongly suspect that you are not using the word semantics in the
same way as the rest of us. Which lets me make a terrible
meta-something joke and ask you "what do you mean by semantics?" ;-)
To me, it's a grid if it meets certain criteria. I call those criteria
the semantics of a grid. But maybe it might be clearer to shift the
usage over to something like "rigid grid".


Probably for the best.

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

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
May 6 '06 #99
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.

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

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

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.

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.

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.

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

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

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.