grid structures: TABLE/TR/TD vs. DIV

<phil-news-nospam (AT) ipal (DOT) net> kirjoitti
viestissä:e3e5sd01b9q (AT) news1 (DOT) 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...

On Fri, 5 May 2006 06:06:21 +0300 "W?rm" <nomailstodragon (AT) north (DOT) invalid> wrote:

phil-news-nospam (AT) ipal (DOT) net> kirjoitti
viestiss?:e3e5sd01b9q (AT) news1 (DOT) 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/ |
-----------------------------------------------------------------------------

On Fri, 5 May 2006 10:35:23 +1000 Mark Parnell <webmaster (AT) clarkecomputers (DOT) com.au> wrote:

Deciding to do something for the good of humanity,
phil-news-nospam (AT) ipal (DOT) 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/ |
-----------------------------------------------------------------------------

Deciding to do something for the good of humanity,
<phil-news-nospam (AT) ipal (DOT) 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

On Fri, 5 May 2006 06:06:21 +0300 "W?rm" <nomailstodragon (AT) north (DOT) 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/ |
-----------------------------------------------------------------------------

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

On Thu, 04 May 2006 12:19:00 +0200 Johannes Koch <koch (AT) w3development (DOT) de> wrote:
| phil-news-nospam (AT) ipal (DOT) net wrote:
|> On Thu, 04 May 2006 10:08:09 +0200 Johannes Koch <koch (AT) w3development (DOT) de> wrote:
|> | phil-news-nospam (AT) ipal (DOT) net wrote:
|> |
|> |> On Wed, 03 May 2006 23:50:16 +0200 Johannes Koch <koch (AT) w3development (DOT) 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: <4459273d$0$11086$892e7fe2 (AT) authen (DOT) yellow.readfreenews.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 <steve (AT) pugh (DOT) net> <http://steve.pugh.net/>

phil-news-nospam (AT) ipal (DOT) 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 <steve (AT) pugh (DOT) net> <http://steve.pugh.net/>

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

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

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

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

In a table it means something. e.g. it means that it's the printer
sales figure for France (row) in May 2005 (column); or that the black
queen is on square C6 (which is why I think the chessboard is a valid
table).

But it just means that this block of text is in the third row and the
second column, then there are no table semantics. And hence HTML
tables should not be used, but CSS display: table-* can be used to
give the appearance a table like grid effect.

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

On Fri, 5 May 2006 15:10:24 +1000 Mark Parnell <webmaster (AT) clarkecomputers (DOT) com.au> wrote:

Deciding to do something for the good of humanity,
phil-news-nospam (AT) ipal (DOT) 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/ |
-----------------------------------------------------------------------------