473,327 Members | 2,065 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,327 software developers and data experts.

CSS and definition lists (bug?)...

Hello,

I have posted the following message before but got no replies...
I am trying to format an HTML definition list with CSS so that it
appears as follows, but am having the following problem: 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.
I have tested the example with mozilla 1.2.1. Complete code
is provided below so you can see what I mean. 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?

----------------------------------+
| gnat: any of various small |
| usually biting dipteran |
| flies |
| |
| gnu: 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 |
| hello |
| world: A standard greeting |
| displayed by some of |
| the smallest computer |
| programs. |
+---------------------------------+

Thank you for your replies,

Neil

(HTML/CSS code follows...)

<html>
<head>
<title>Definitions</title>
<style type="text/css">
/*dt { color: red; width: 140px; float: left; : left; }*/
/*dd { color: blue; width: 180px; text-align: left; }*/
dl { }
dt { color: red; width: 140px; padding: 4px;
float: left; clear: left; }
dd { color: blue; width: 180px; padding: 4px;
text-align: left; overflow: auto; }
</style>
</head>
<body>
<p>
<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>
</td>
</tr>
</table>
</p>
</body>
</html>
Jul 20 '05 #1
7 4205
nz******@cs.mun.ca (Neil Zanella) wrote:
I have posted the following message before but got no replies...
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.)
I am trying to format an HTML definition list with CSS
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).
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.
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.
I have tested the example with mozilla 1.2.1.
IE 6 shows it differently. And Opera even more differently.
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?
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.
<table>
<tr>
<th>
Definition Lists...
</th>
</tr>


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>gnat</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/
Jul 20 '05 #2
*Neil Zanella* <nz******@cs.mun.ca>:

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; }
Why fixed pixel widths?
<table>


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
Jul 20 '05 #3
Hello,

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

Christoph Paeper <cr***********@gmx.net> wrote in message:
*Neil Zanella* <nz******@cs.mun.ca>:

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

Why fixed pixel widths?


You have a good point. Thank you for pointing it out. Percentages should
be used instead whenever possible, isn't this so?
I thought it must be possible with CSS floats, but it's not.

However, e.g.

dl {display: compact; line-height: 1.2em;}
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...
dt, dd {border: 0.1em solid; margin: 0.2em 0; padding: 0.2em 2.25%;}
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?
dt {color: red; width: 20%;}
dd {color: blue; width: 70%; margin-left: 25%;}
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.
dt+dd {margin-top: -2.0em}
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.
dd+dd {margin-top: 0}
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?
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.


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>Definitions</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>
Jul 20 '05 #4

On Mon, 17 Nov 2003, Christoph Paeper wrote:
*Neil Zanella* <nz******@cs.mun.ca>:

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


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}


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

Jul 20 '05 #5
*Neil Zanella* <nz******@cs.mun.ca>:
On Mon, 17 Nov 2003, Christoph Paeper wrote:

dl {display: compact;
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.
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}
How did you compute the -2.0em offset.


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.
It seems to me that in general such an offset would depend on font sizes,


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
Jul 20 '05 #6
Christoph Paeper <cr***********@gmx.net> wrote in message:
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'.


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
Jul 20 '05 #7
*Neil Zanella* <nz******@cs.mun.ca>:

How can the problem be solved when the font sizes of the dt and dd differ?
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*/;}
Is an elegant solution possible in CSS?


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

--
I'm a signature virus, help me spread!
Jul 20 '05 #8

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

Similar topics

4
by: Lorn | last post by:
I'm trying to figure out a way to create dynamic lists or possibly antother solution for the following problem. I have multiple lines in a text file (every line is the same format) that are...
1
by: Neil Zanella | last post by:
Hello, I have posted the following message before but got no replies... I am trying to format an HTML definition list with CSS so that it appears as follows, but am having the following problem:...
9
by: Dave H | last post by:
Hello, I have a query regarding definition lists. Is it good practice semantically to use the dt and dd elements to mark up questions and answers in a frequently asked questions list, or FAQ? ...
0
by: Jimmy Cerra | last post by:
I recently came up with a cool little stylesheet for definition lists. There is a small demostration for the impatient . I hope this helps someone. Here's how I did it. Definition lists are...
4
by: Gianni Mariani | last post by:
I posted a gcc bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13332 here is the text: ----------------------------------------------------------- This code will compile fine but fail on...
26
by: Patient Guy | last post by:
The code below shows the familiar way of restricting a function to be a method of a constructed object: function aConstructor(arg) { if (typeof(arg) == "undefined") return (null);...
4
by: Mike | last post by:
Hi ! I have some strange problem and I would like to know if it is a bug or not : In my projects, in 2 different .cpp files, I use the same name to define a local structure: file1.cpp : ...
4
by: Steve Swift | last post by:
I'm trying to achieve a format of definition lists that matches the definition lists generated by IBM's "BookMaster" (from quite a few years ago). The effect is as if the terms and their...
275
by: Astley Le Jasper | last post by:
Sorry for the numpty question ... How do you find the reference name of an object? So if i have this bob = modulename.objectname() how do i find that the name is 'bob'
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

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.