Re: Table-less sites

On 23 Feb, 12:01, Andy Dingley <ding... (AT) codesmiths (DOT) com> wrote:

On 23 Feb, 08:11, Ian Rastall <rastall... (AT) gmail (DOT) com> wrote:

I've been reading a book called "Everything You Know About CSS
Is Wrong."

If you use grid markup, you need some tags to do it with. HTML doesn't
have many options here, apart from <table> and children, so you're
probably pushed into using an anonymous <div> and classes upon it.
Given the choice, <div class="tr"> has little to offer over <tr> for
coding style. Yes, there's some neat concise markup you can do with
dl> that's rendered into tables too, but this isn't earth-shattering.

Is this right? I've just been trying to code up a neat little example
of this table-like <dl> styling, which unfortunately this margin is
too small to contain.

This CSS:
dl dt,
dl dd {
display: table-cell;
}

Generates a single-row table for an arbitrary list of elements,
rendering each as a table cell.

The CSS is (AIUI) correct despite not using display: table; or
display: table-row; because there's an implication behaviour in the
CSS specification that will insert an anonymous one, if needed.


The almost equally simple CSS:

dl dt {
display: table-row;
}
dl dd {
display: table-cell;
}

Generates a multi-row presentation instead, where each <dt> starts a
new row.

However, there doesn't seem to be any way (and I mean "any way", not
just "an easy way") to transform
<dt ... /><dd ... /><dt ... /><dd ... />

into an "obvious" two-dimensional, two-row, two-column layout. Is
there one? Even generated content seems incapable of assisting.

In the general sense, it seems that "CSS tables" are not only
_unnecessary_ for HTML+CSS (for thier justification with XML+CSS see
"XML and Tables" in Lie & Bos), but it's actually impractical to use
them with any valid HTML markup other than <table> etc. or anonymous
<div> labelled by classes. The problem is that adequate markup of the
content language for a table structure requires around four levels of
structure (akin to <table>, <tbody>, <tr> & <td>) and it's only
possible to reduce this to two (<tr> & <td>) by implication. It is
_not_ possible to take HTML's general <dl> elements and use them to
adequately mark up a useful table with multiple rows.

HTML+CSS tables (outside <table>) aren't just unnecessary, they're
unworkable.
Discuss.

Andy Dingley wrote:

On 23 Feb, 12:01, Andy Dingley <ding... (AT) codesmiths (DOT) com> wrote:
On 23 Feb, 08:11, Ian Rastall <rastall... (AT) gmail (DOT) com> wrote:

I've been reading a book called "Everything You Know About CSS
Is Wrong."

If you use grid markup, you need some tags to do it with. HTML doesn't
have many options here, apart from <table> and children, so you're
probably pushed into using an anonymous <div> and classes upon it.
Given the choice, <div class="tr"> has little to offer over <tr> for
coding style. Yes, there's some neat concise markup you can do with
dl> that's rendered into tables too, but this isn't earth-shattering.

Is this right? I've just been trying to code up a neat little example
of this table-like <dl> styling, which unfortunately this margin is
too small to contain.

This CSS:
dl dt,
dl dd {
display: table-cell;
}

Generates a single-row table for an arbitrary list of elements,
rendering each as a table cell.

The CSS is (AIUI) correct despite not using display: table; or
display: table-row; because there's an implication behaviour in the
CSS specification that will insert an anonymous one, if needed.


The almost equally simple CSS:

dl dt {
display: table-row;
}
dl dd {
display: table-cell;
}

Generates a multi-row presentation instead, where each <dt> starts a
new row.

However, there doesn't seem to be any way (and I mean "any way", not
just "an easy way") to transform
dt ... /><dd ... /><dt ... /><dd ... /

into an "obvious" two-dimensional, two-row, two-column layout. Is
there one? Even generated content seems incapable of assisting.

In the general sense, it seems that "CSS tables" are not only
_unnecessary_ for HTML+CSS (for thier justification with XML+CSS see
"XML and Tables" in Lie & Bos), but it's actually impractical to use
them with any valid HTML markup other than <table> etc. or anonymous
div> labelled by classes. The problem is that adequate markup of the
content language for a table structure requires around four levels of
structure (akin to <table>, <tbody>, <tr> & <td>) and it's only
possible to reduce this to two (<tr> & <td>) by implication. It is
_not_ possible to take HTML's general <dl> elements and use them to
adequately mark up a useful table with multiple rows.

HTML+CSS tables (outside <table>) aren't just unnecessary, they're
unworkable.
Discuss.

If you think classes have no value, then you're right. A table by nature

has to consist of three levels of nesting: table, row, cell. Lists have
two levels.

I have no problem with using semantically meaningful classes, so to me
HTML+CSS tables is useful, but it is a shame that in the case of content
for which a DL would be appropriate, the DL isn't amenable to CSS table
treatment. It would have made good sense, even before CSS came into the
picture, for definition lists to have been conceived of as three-level
structures: list, entry, terms/definitions. In the unusual case where
multiple DTs were used for a term there'd be trouble with CSS table
treatment, but otherwise, this would be fine, and in addition one could
treat the DTs as table-header cells.

In article <70g907F525t7U1 (AT) mid (DOT) individual.net>,
Harlan Messinger <hmessinger.removethis (AT) comcast (DOT) net> wrote:

It would have made good sense, even before CSS came into the
picture, for definition lists to have been conceived of as three-level
structures: list, entry, terms/definitions.

Things make sense if you can afford them. If you have a lot of money, it
makes sense to pay for a view to go with a house purchase. If you can
afford a complication in system, it makes sense to have lots of html
elements with specialised functions. But simplicity has its own rewards.

HTML lists generally are an indulgence, tables always being available to
do a perfectly capable job.

--
dorayme

On 2009-02-23, Andy Dingley <dingbat (AT) codesmiths (DOT) com> wrote:

On 23 Feb, 12:01, Andy Dingley <ding... (AT) codesmiths (DOT) com> wrote:
On 23 Feb, 08:11, Ian Rastall <rastall... (AT) gmail (DOT) com> wrote:

I've been reading a book called "Everything You Know About CSS
Is Wrong."

If you use grid markup, you need some tags to do it with. HTML doesn't
have many options here, apart from <table> and children, so you're
probably pushed into using an anonymous <div> and classes upon it.
Given the choice, <div class="tr"> has little to offer over <tr> for
coding style. Yes, there's some neat concise markup you can do with
dl> that's rendered into tables too, but this isn't earth-shattering.

Is this right? I've just been trying to code up a neat little example
of this table-like <dl> styling, which unfortunately this margin is
too small to contain.

This CSS:
dl dt,
dl dd {
display: table-cell;
}

Generates a single-row table for an arbitrary list of elements,
rendering each as a table cell.

The CSS is (AIUI) correct despite not using display: table; or
display: table-row; because there's an implication behaviour in the
CSS specification that will insert an anonymous one, if needed.

Correct.

The almost equally simple CSS:

dl dt {
display: table-row;
}
dl dd {
display: table-cell;
}

Generates a multi-row presentation instead, where each <dt> starts a
new row.

However, there doesn't seem to be any way (and I mean "any way", not
just "an easy way") to transform
dt ... /><dd ... /><dt ... /><dd ... /

into an "obvious" two-dimensional, two-row, two-column layout. Is
there one?

I don't think there is.

Even generated content seems incapable of assisting.

Yes, because that can only put things inside the dts and dds. You would
need generated elements outside them.

Firefox (the last time I checked) only supported certain styles on
generated nodes anyway. But I still don't think it's possible.

dorayme wrote:

In article <70g907F525t7U1 (AT) mid (DOT) individual.net>,
Harlan Messinger <hmessinger.removethis (AT) comcast (DOT) net> wrote:

It would have made good sense, even before CSS came into the
picture, for definition lists to have been conceived of as three-level
structures: list, entry, terms/definitions.

Things make sense if you can afford them. If you have a lot of money, it
makes sense to pay for a view to go with a house purchase. If you can
afford a complication in system, it makes sense to have lots of html
elements with specialised functions. But simplicity has its own rewards.

HTML lists generally are an indulgence, tables always being available to
do a perfectly capable job.

Lists make a lot of sense for navigation. Easy to style and set
background images. Easy to change from vertical to horizontal layout.

To me that is simpler than customizing html to get a specific look.

But as far as definition lists, I agree. Since I don't write content,
they are just one more thing that my clients would have to understand.
Simple is better and definition lists are unfamiliar and hard to
understand for most. I've never had a request for them.

Jeff

In article <AuOdnWqVpv0IqjnUnZ2dnUVZ_vCdnZ2d (AT) earthlink (DOT) com>,
Jeff <dont_bug_me (AT) all (DOT) uk> wrote:

dorayme wrote:
....
HTML lists generally are an indulgence, tables always being available to
do a perfectly capable job.

Lists make a lot of sense for navigation. Easy to style and set
background images. Easy to change from vertical to horizontal layout.

....

Tables are easy to style too and horizontal is nothing at all odd or
special about them - unlike the default tendencies of html lists. It is
just a matter of the use of the row as against the column.

One thing tables do not do that a horiz list will do, is wrap the list
items/cells. This is truly an advantage. But curiously enough, it is a
mere accident that the Good God himself did not allow authors to wrap
cells in a situation where there was only one row to a table. It is
nothing conceptually fundamental. It is either a trivial oversight of an
extremely busy god or else a deliberate decision for good reason.

You see, his thoughts were that since he is providing for lists in other
ways, he need not bother to put any special bells or whistles on one row
tables. So, his sense of economy, as his fans know, is to be admired. He
complicated HTML in order to simplify things for earthlings, in the way
decking out the tool system in a garage calls for more than a nice big
hammer and a shifter and a few screwdrivers (notwithstanding that small
subsets are amazingly versatile).

--
dorayme