CSS and definition lists (bug?)...

**Jukka K. Korpela** · Jul 20 '05, 08:54 PM

Re: CSS and definition lists (bug?)...

nzanella@cs.mun .ca (Neil Zanella) wrote:
[color=blue]
> I have posted the following message before but got no replies...[/color]

Maybe it's because you didn't post a URL. It's easier to look at someone's
problem if you can just access a page by URL, instead of constructing a page
first (thinking why, oh why, the poster, who surely had tested his problem,
didn't post a URL).

Or maybe because it didn't get through - I cannot see which previous posting
you are referring to. (A Message-ID would have helped.)
[color=blue]
> I am trying to format an HTML definition list with CSS[/color]

Using definition list markup (<dl> element) in HTML is logical, in
principle, if you actually have a list of definitions. However, the default
rendering is rather poor, and attempts to modify it using CSS often
encounter serious obstacles. But to start with, you should at least use
_valid_ <dl> markup. The snippet you posted lacks the </dl> tag and has a
spurious </p> tag after the table element (presumably </p> is meant to match
a <p> before the table, for some odd reason, but it cannot, due to HTML
syntax).
[color=blue]
> when the
> definition term (<dt>) on the left is too long, as in the HTML
> code posted below, the whole definition list gets messed up.[/color]

The question arises why the term is very long - such a situation often
indicates that a "definition list" doesn't really define anything. Your
example is "A long long long long long long long long long long long long
long long long long long long long long long long long term:", but maybe you
have something real in the real example.

Anyway, if some terms can be long - and that's surely possible - then why do
you make things more difficult by setting widths, even using px units, and
rather small values at that? When the font size is large, problems will
arise with width: 140px even for rather modest length of terms. Assuming
there is a reason - and surely there might be - to set the width (for
example, when floating something), the em unit is to be preferred.
[color=blue]
> I have tested the example with mozilla 1.2.1.[/color]

IE 6 shows it differently. And Opera even more differently.
[color=blue]
> Anyone know
> how I can fix the list so that the top of the offending
> <dd> is aligned with the bottom of the offending <dt>
> as in the "hello world" definition in the example
> given in the ASCII diagram below?[/color]

Given the diagram alone, it seems that you would like to have the definition
data start at the same vertical level as the last line of the definition
term. This sounds a bit odd - and I don't see how you could suggest such a
thing in CSS.

But comparing the browser renderings of your example, it seems that you are
referring to the problem that on Mozilla, the definition data flows on the
right of the definition terms so that it may get misplaced - the definition
of "hello world" (is that really a _term_?) is placed to the left of the the
term "A long long ...".

Basically, <dl> lists have idiosyncratic renderings on browsers, and when
you try to change the rendering, you will encounter problems with browser
defaults (such as default margins that may vary a lot) and with browser
bugs.
[color=blue]
> <table>
> <tr>
> <th>
> Definition Lists...
> </th>
> </tr>[/color]

Is this really adequate markup? You have a table with one <th> cell and one
<td> cell. It sounds you would need a real heading (like <h2>) and just the
list.

Anyway, if you really have a definition list, then structuring _it_ as a
table might be a better practical idea than <dl> markup. After all, it can
adequately be described as a table with two columns, one for terms, another
for the definion of the term. And then you would simply have a table with
rows like

<tr><td><dfn>gn at</dfn></td> <td>Any of various small
usually biting dipteran flies.</td> </tr>

(It's debatable whether the first column should consist of <th> elements
with scope="row". This has a minor impact on the CSS side of the matter,
since <th> vs. <td> affects default rendering.)

That way, you avoid the danger of serious misplacement, and you can easily
make presentational suggestions e.g. using the vertical-align property.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

**Christoph Paeper** · Jul 20 '05, 08:54 PM

Re: CSS and definition lists (bug?)...

*Neil Zanella* <nzanella@cs.mu n.ca>:[color=blue]
>
> I am trying to format an HTML definition list with CSS so that it
> appears as follows,
>
> ----------------------------------+
> | gnat: any of various small |
> | flies |
> | |
> | gnu: either of two large |
> | African antelopes |
> | hello |
> | world: A standard greeting |
> +---------------------------------+
>
> dt { color: red; width: 140px; padding: 4px;
> float: left; clear: left; }
> dd { color: blue; width: 180px; padding: 4px;
> text-align: left; overflow: auto; }[/color]

Why fixed pixel widths?
[color=blue]
> <table>[/color]

What's that one for?

I thought it must be possible with CSS floats, but it's not.

However, e.g.

dl {display: compact; line-height: 1.2em;}
dt, dd {border: 0.1em solid; margin: 0.2em 0; padding: 0.2em 2.25%;}
dt {color: red; width: 20%;}
dd {color: blue; width: 70%; margin-left: 25%;}
dt+dd {margin-top: -2.0em}
dd+dd {margin-top: 0}

should work for browsers that support the adjacent sibling selector '+'. If
it can be assured that there are never two adjacent dds, the last two
ruleset can be replaced by

dd {margin-top: -2.0em}

which also works in IE.

P.S.: This is what I came up with for floats before trying the simple
approach, including a dirty hack (dd.br):
dl {display: compact; clear: both;}
dt, dd {border: thin solid; margin: 0.5% 0; padding: 0.5% 2.25%;}
dt {color: red; width: 20%;}
dd {color: blue; width: 70%;}
/*
* 20% + 2·2.25% + 2·thin + 2·0 +
* + 70% + 2·2.25% + 2·thin + 2·0 * = 99% + 4·thin =< 100% ~>
* ~> thin =< 0.25% !
* (thin == 1px) ? dl@width >= 400px : decrease((dt,dd )@padding)
*/
/* To exclude IE use either this { */
dt+dt, dd+dt {float: left; clear: both;}
dt:first-child {float: left; clear: both;}
dt+dt { clear: left;}
*+dd {float: right; clear: right;}
dd:first-child {float: right; clear: right;}
/* } or this {*/
dt {float: left; clear: both;}
dt+dt {clear: left;}
dd {float: right; clear: right;}
* html dt, * html dd {float: none; clear: none;}
/* } */
dt+dt, dd+dd {margin: 0;}
dd:first-child {margin: 0;}
dd.br {clear: both; margin: 0; padding: 0; border-width: 0;}

<dt>gnu:</dt>
<dd>Either of two large African antelopes (Connochaetes gnou and C.
taurinus) with a head like that of an ox, short mane, long tail, and horns
in both sexes that curve downward and outward</dd>
<dd>Gnu's Not Unix</dd><dd class="br"></dd>
<dt>

--
"The most exciting phrase to hear in science,
the one that heralds new discoveries,
is not 'Eureka!' but 'That's funny...'"
Isaac Asimov

**Neil Zanella** · Jul 20 '05, 08:56 PM

Re: CSS and definition lists (bug?)...

Hello,

Thank you for your replies (and sorry for the accidental multiposts, my news
server was having some problems it seems)...

Christoph Paeper <crissov2003Q4@ gmx.net> wrote in message:
[color=blue]
> *Neil Zanella* <nzanella@cs.mu n.ca>:[color=green]
> >
> > I am trying to format an HTML definition list with CSS so that it
> > appears as follows,
> >
> > ----------------------------------+
> > | gnat: any of various small |
> > | flies |
> > | |
> > | gnu: either of two large |
> > | African antelopes |
> > | hello |
> > | world: A standard greeting |
> > +---------------------------------+
> >[/color]
>
> Why fixed pixel widths?[/color]

You have a good point. Thank you for pointing it out. Percentages should
be used instead whenever possible, isn't this so?
[color=blue]
> I thought it must be possible with CSS floats, but it's not.
>
> However, e.g.
>
> dl {display: compact; line-height: 1.2em;}[/color]

The "display: compact" CSS property is not doing anything for me here
with mozilla 1.2.1. I am not sure about what this property is supposed
to do or why you included it for that matter. Just curious...
[color=blue]
> dt, dd {border: 0.1em solid; margin: 0.2em 0; padding: 0.2em 2.25%;}[/color]

Interesting use of borders. It seems that displaying borders makes debugging
much easier. The borders can be removed once all formatting is tested if not
wanted, but it makes it easier to visualize the browser's relative placement
algorithm for the various elements when the borders are present.

One thing that is not clear to me is why the second parameter to the padding
property (the specified 2.25%) is only working for multiline dd and dl entries.
How come this it has no effect on single line dd and dl elements? Again, this
is with mozilla 1.2.1 so I am not sure about whether this is a browser problem
or a code problem but it looks like it might be a browser problem to me...
Comments on this particular issue?
[color=blue]
> dt {color: red; width: 20%;}
> dd {color: blue; width: 70%; margin-left: 25%;}[/color]

Besides getting rid of fixed withs, interesting use of 25% > 20% so as to
introduce a 5% amount of spacing between the dt and dd elements.
[color=blue]
> dt+dd {margin-top: -2.0em}[/color]

This one is used to align the dd with the dt as in the picture I posted
using CSS2 selectors (+ operator). The CSS properties refer to a dd
element following a dt element (usage of the + operator). The +
operator is valid in CSS2 but not available in CSS1. Nevertheless
mozilla 1.2.1 is rendering the result properly.
[color=blue]
> dd+dd {margin-top: 0}[/color]

Same thing for dd followed by dd, but this line seems to be redundant,
especially since dd is never followed by dd, isn't this so?
[color=blue]
> should work for browsers that support the adjacent sibling selector '+'.
> If it can be assured that there are never two adjacent dds, the last two
> ruleset can be replaced by
>
> dd {margin-top: -2.0em}
>
> which also works in IE.[/color]

I see. Thank you for your explanation. Does the XHTML DTD really allow
adjacent dd elements? Yes it does. Interesting, I did not know that...

P.S. Sorry for not being able to post a functional URL, but posting URLs
has the disadvantage that the content they point to tends to disappear
with time. Secondly, I am simply loading pages into my local Linux
apache web browser, but the provider I am using AFAIK does not
allow/support users to serve web pages/run an HTTP server, so
posting a link was not feasible in my case.

Thanks!

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Definiti ons</title>
<style type="text/css">
dl {line-height: 1.2em;}
dt, dd {border: 0.1em solid; margin: 0.2em 0; padding: 0.2em;}
dt {color: red; width: 20%;}
dd {color: blue; width: 70%; margin-left: 25%;}
dt+dd {margin-top: -2.0em}
</style>
</head>
<body>
<table>
<tr>
<th>
Definition Lists...
</th>
</tr>
<tr>
<td>
<dl>
<dt>
gnat:
</dt>
<dd>
Any of various small
usually biting dipteran
flies
</dd>
<dt>
gnu:
</dt>
<dd>
Either of two large
African antelopes
(Connochaetes gnou and
C. taurinus) with a
head like that of an
ox, short mane, long
tail, and horns in
both sexes that curve
downward and outward
</dd>
<dt>
A long long long long long
long long long long
long long long long
long long long long
long long long long
long long term:
</dt>
<dd>
Definition of the long long... term.
</dd>
<dt>
hello
world:
</dt>
<dd>
A standard greeting
displayed by some of
the smallest computer
programs.
</dd>
</dl>
</td>
</tr>
</table>
</body>
</html>

**Neil Zanella** · Jul 20 '05, 08:56 PM

Re: CSS and definition lists (bug?)...

On Mon, 17 Nov 2003, Christoph Paeper wrote:
[color=blue]
> *Neil Zanella* <nzanella@cs.mu n.ca>:[color=green]
> >
> > I am trying to format an HTML definition list with CSS so that it
> > appears as follows,
> >
> > ----------------------------------+
> > | gnat: any of various small |
> > | flies |
> > | |
> > | gnu: either of two large |
> > | African antelopes |
> > | hello |
> > | world: A standard greeting |
> > +---------------------------------+[/color]
>
> dl {display: compact; line-height: 1.2em;}
> dt, dd {border: 0.1em solid; margin: 0.2em 0; padding: 0.2em 2.25%;}
> dt {color: red; width: 20%;}
> dd {color: blue; width: 70%; margin-left: 25%;}
> dt+dd {margin-top: -2.0em}
> dd+dd {margin-top: 0}[/color]

BTW, there is one more issue concerning this particular problem which I
forgot to address. How did you compute the -2.0em offset. It seems to me
that in general such an offset would depend on font sizes, which, in turn,
last time I checked, are sensitive to browsers, so that the fonts differ
when viewed with different browsers. The problem arises when some of the
dd' have larger relative fonts, as in the following modification of your
example:

dl {line-height: 1.2em;}
dt, dd {border: 0.1em solid; margin: 0.2em 0; padding: 0.2em; }
dt {color: red; width: 20%;}
dd {font-size: xx-large; color: blue; width: 70%; margin-left: 25%;}
dt+dd {margin-top: -2.0em}

How do you deal with this case? Basically, when you speify -2.0em, you
want to specify such a size in the size of the dt, not of the dd. So
how do you refer to the dt's size in CSS?

Furthermore, is -2.0 always right? Where does the 2.0 come from? Is
it just a guess based on the fact it looks good on mozilla or is
there more behind such a choice for an offset?

Thanks,

Neil

**Christoph Paeper** · Jul 20 '05, 08:56 PM

Re: CSS and definition lists (bug?)...

*Neil Zanella* <nzanella@cs.mu n.ca>:[color=blue]
> On Mon, 17 Nov 2003, Christoph Paeper wrote:[color=green]
>>
>> dl {display: compact;[/color][/color]

That's the replacement of the old HTML attribute 'compact' for definition
lists, opposed to which it isn't widely supported, for some reason. I
somehow forgot to remove it. It shouldn't cause harm, though. If it was
supported it would give almost exactly what you wanted without further CSS
needed.
[color=blue][color=green]
>> line-height: 1.2em;}
>> dt, dd {border: 0.1em solid; margin: 0.2em 0; padding: 0.2em 2.25%;}
>> dt+dd {margin-top: -2.0em}[/color]
>
> How did you compute the -2.0em offset.[/color]

Actually it was based on trial and error, but could as well be computed:

line-height(dd) + padding-top(dd) + border-top-width(dd) +
+ margin-bottom(dt) + border-bottom-width(dt) + padding-bottom(dt) = 1.2em + 0.2em + 0.1em + 0.2em + 0.1em + 0.2em = 2.0em

Apparently odd signed vertical margins don't collapse, or I made a wrong
assumption somewhere--when I wrote the last posting I was almost as tired as
I now am.
[color=blue]
> It seems to me that in general such an offset would depend on font sizes,[/color]

All affacted values are in 'em', which depends on the font-size--it *is* the
font-size, actually. However, the computation would become a little more
complex when 'font-size' of 'dt' and 'dd' differed and would only reliably
possible if given in 'em'.

--
"Some people say I am a terrible person,
I'm not, I have the heart of a young boy,
in a jar, on my desk."
Stephen King

**Neil Zanella** · Jul 20 '05, 08:59 PM

Re: CSS and definition lists (bug?)...

Christoph Paeper <crissov2003Q4@ gmx.net> wrote in message:
[color=blue]
> All affacted values are in 'em', which depends on the font-size--it *is* the
> font-size, actually. However, the computation would become a little more
> complex when 'font-size' of 'dt' and 'dd' differed and would only reliably
> possible if given in 'em'.[/color]

This is precisely what I was asking about. How can the problem be solved when
the font sizes of the dt and dd differ? Is an elegant solution possible in CSS?
By elegant I mean that I should be able to change the font size of either an
individual dd or dt in one place and everything else should autoadjust
without further changes to the stylesheet.

Thanks!!!

Neil

**Christoph Paeper** · Jul 20 '05, 08:59 PM

Re: CSS and definition lists (bug?)...

*Neil Zanella* <nzanella@cs.mu n.ca>:[color=blue]
>
> How can the problem be solved when the font sizes of the dt and dd differ?[/color]

With mathematics. You'd have to normalize the dt values to the font-size of
dd, i.e.:

margin-top(dt+dd) = -1 · {
line-height(dd) + padding-top(dd) + border-top-width(dd) +
+ font-size(dt) / font-size(dd) · [margin-bottom(dt) +
+ border-bottom-width(dt) + padding-bottom(dt)] }

Example with resulting calculated pixel sizes:

dl {font-size: inherit/* 16.0px (e.g.) */;}
dt {font-size: 1.25em /* 20.0px = 16px · 1.25 */;}
dd {font-size: 0.75em /* 12.0px = 16px · 0.75 */;}
dt {
margin-bottom: 0.2em /* 4.0px = 20px · 0.2 */;
border-bottom-width: 0.1em /* 2.0px = 20px · 0.1 */;
padding-bottom: 0.2em /* 4.0px = 20px · 0.2 */;
/* sum: 0.5em 10.0px = 20px · 0.5 */;}
dd {
line-height: 1.2em /* 14.4px = 12px · 1.2 */;
padding-top: 0.2em /* 2.4px = 12px · 0.2 */;
border-top-width: 0.1em /* 1.2px = 12px · 0.1 */;
/* sum: 1.5em 18.0px = 12px · 1.5 */;}
dt+dd {
margin-top: -2.33em /* 2_1/3 = 1.5 + 0.5 · 1.25/0.75
28.0px = 12px · 2_1/3*/;}
[color=blue]
> Is an elegant solution possible in CSS?[/color]

AFAICS and IIRC the problem, not more than the above.

--
I'm a signature virus, help me spread!