 | |
grid structures: TABLE/TR/TD vs. DIV
Cascading Style Sheets Layout/presentation on the WWW (comp.infosystems.www.authoring.stylesheets)
 |
| | Thread Tools | Display Modes |
#41
 
| |||
| |||
|
Re: grid structures: TABLE/TR/TD vs. DIV -
05-02-2006
, 10:25 PM
|
How to keep the columns from floating down to the bottom when the window is narrower? |
something that is not. There are ways to prevent it though, but I'd rather
see stuff to adjust to viewport so...
#42
| |||
| |||
|
|
In the sense that CSS is optional by design, it "works" to specification in IE. It's just that IE chooses not to take the option. |
optional and choose not to take the option. Instead, it chooses to
implement the option incorrectly. That's a totally different thing.
-A
#43
| |||
| |||
|
|
On Tue, 02 May 2006 22:25:17 +0200 Johannes Koch <koch (AT) w3development (DOT) 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? |
presenting table/tr/td etc. That's the default rendering.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
#44
| |||
| |||
|
|
Why have two mechanisms that work the same way? |
bold'? Same answer.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
#45
| |||
| |||
|
|
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. |
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.
#46
| |||
| |||
|
|
And where did I say you said it? I was modifying your information, not contradicting it. |
accusatorily "but pink bananas are no bananas they're grapes!" one might
like EXPECT it has relation to talk about bananas you know.
<snip>
Quote:
|
You're being childishly gratuitous. Of course, that rather fits this whole thread. |
<snip>
#47
| |||
| |||
|
|
phil-news-nospam (AT) ipal (DOT) net wrote: On Tue, 02 May 2006 22:25:17 +0200 Johannes Koch <koch (AT) w3development (DOT) 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. |
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).
--
-----------------------------------------------------------------------------
Quote:
|
Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | ----------------------------------------------------------------------------- |
#48
| |||
| |||
|
|
phil-news-nospam (AT) ipal (DOT) 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. |
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.
--
-----------------------------------------------------------------------------
Quote:
|
Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | ----------------------------------------------------------------------------- |
#49
| |||
| |||
|
|
phil-news-nospam (AT) ipal (DOT) net> kirjoitti viestiss?:e38c3732s8o (AT) news4 (DOT) 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... |
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.
--
-----------------------------------------------------------------------------
Quote:
|
Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | ----------------------------------------------------------------------------- |
#50
| |||
| |||
|
|
To further the education of mankind, "W?rm" nomailstodragon (AT) north (DOT) invalid> vouchsafed: phil-news-nospam (AT) ipal (DOT) net> kirjoitti viestiss?:e35fio11vup (AT) news2 (DOT) 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. |
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.
--
-----------------------------------------------------------------------------
Quote:
|
Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | ----------------------------------------------------------------------------- |
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.