Blank line after a definition list (DL)?

Is there a way I can have the browser automatically insert a blank
line after each definition in a definition list? Right now I have
this:

term-1
definition text ....
term -2
definition text ...

I'd like to have this:

term-1
definition text ....

term -2
definition text ...


But I want to do it without manually putting a blank line after each
"definition text".

..oO(Timur Tabi)

Is there a way I can have the browser automatically insert a blank
line after each definition in a definition list?

Sure. Use CSS to adjust the bottom margin of the 'dd' elements:

dd {margin-bottom: 1em}

Micha

On 2008-03-02, Timur Tabi <timur (AT) tabi (DOT) org> wrote:

Is there a way I can have the browser automatically insert a blank
line after each definition in a definition list? Right now I have
this:

term-1
definition text ....
term -2
definition text ...

I'd like to have this:

term-1
definition text ....

term -2
definition text ...


But I want to do it without manually putting a blank line after each
"definition text".

dl { margin-bottom: 2.24em }

On 2008-03-02, Michael Fesser <netizen (AT) gmx (DOT) de> wrote:

.oO(Timur Tabi)

Is there a way I can have the browser automatically insert a blank
line after each definition in a definition list?

Sure. Use CSS to adjust the bottom margin of the 'dd' elements:

dd {margin-bottom: 1em}

Oops, yes that's what I meant when I just said to put a margin-bottom on
the dl.

You could use margin-bottom: 1.12em since that's normally what's used in
browser default stylesheets to approximate the height of one line. It
doesn't make much difference though.

On 3/2/2008 12:44 PM, Timur Tabi wrote:

Is there a way I can have the browser automatically insert a blank
line after each definition in a definition list? Right now I have
this:

term-1
definition text ....
term -2
definition text ...

I'd like to have this:

term-1
definition text ....

term -2
definition text ...


But I want to do it without manually putting a blank line after each
"definition text".

I prefer to specify margins at the top, not only for Web pages but also
when using Word.

<style TYPE="text/css">
dt { margin-top: 1em }
dd { margin-top: 0.5em }
</style>

This puts a one-em blank line before the defined term (the dt) and only
a half-em line between the defined term and the definition itself (dd).

--
David Ross
<http://www.rossde.com/>

Have you been using Netscape and now feel abandoned by AOL?
Then use SeaMonkey. Go to <http://www.seamonkey-project.org/>.

Scripsit Ben C:

You could use margin-bottom: 1.12em since that's normally what's used
in browser default stylesheets to approximate the height of one line.
It doesn't make much difference though.

And you don't need to make guesses on the line height, because you can
set it (it's healthy anyway; the specific value should depend on the
font characteristics):

* { line-height: 1.12; }
dd { margin-bottom: 1.12em; }

A full blank line might be a little too much, though.

Anyway, this is purely a CSS matter. It would not make sense to try to
force empty vertical spacing using HTML markup, especially since it's so
simple in CSS.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

On 2 Mar, 20:44, Timur Tabi <ti... (AT) tabi (DOT) org> wrote:

Is there a way I can have the browser automatically insert a blank
line after each definition in a definition list?

Others have posted the correct way to do this, using the CSS margin
properties.

It's worth clearing up a terminology point too. You're not inserting a
"blank line" here, you're taking the single linebreak you've already
got and then making it taller. This is different. <dl> is a "block"
elememnt, which means that the default CSS of display:block; embeds a
single linebreak after it anyway. This linebreak causes a "box" to be
displayed when the CSS renders it, and boxes have margins around them
that you can control the size of.

It's important in HTML / CSS (and most other typesetting work) to
understand the difference between a "linebreak" and the size of
whitespace associated with such linebreaks. In HTML you "add a
linebreak" by using the <br> element, but this is _NOT_ the way to do
things for controlling appearance. Use hard linebreaks when you're
setting poetry where the _content_ requires the breaks to be fixed in
position, but typography should just adjust sizes of what you already
have, not add more.

"Jukka K. Korpela" <jkorpela (AT) cs (DOT) tut.fi> writes:

And you don't need to make guesses on the line height, because you can
set it (it's healthy anyway; the specific value should depend on the
font characteristics):

The specific value should depend on several factors, language not the
least of them (erm, I know that you know that, but you don’t say that
above, and normal people never consider that ;-).

A full blank line might be a little too much, though.

I wonder why the idea of a baseline grid is so alien to web
typography. But I don't even know if I disagree. :-)

--
“Rapidiously develop corporate value rather than installed base process
improvements. Collaboratively unleash process-centric synergy with
interoperable best practices.”
<http://www.apple.com/downloads/dashboard/developer/corporateipsum.html>

Scripsit Eric B. Bednarz:

A full blank line might be a little too much, though.

I wonder why the idea of a baseline grid is so alien to web
typography. But I don't even know if I disagree. :-)

Probably because web typography, to the extent that it exists, is not
oriented towards presenting a document on paired sheets of paper, where
the grid is relevant. And how _could_ you make an image or a table, for
example, occupy a vertical space that is a multiple of the copy text
line height? We would need a rather different style sheet language,
wouldn't we?

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

"Jukka K. Korpela" <jkorpela (AT) cs (DOT) tut.fi> writes:

Scripsit Eric B. Bednarz:

I wonder why the idea of a baseline grid is so alien to web
typography. But I don't even know if I disagree. :-)

Probably because web typography, to the extent that it exists, is not
oriented towards presenting a document on paired sheets of paper,
where the grid is relevant.

For any piece of copy with more than one font family and/or size, it’s a
rather silly assumption that the grid would not be relevant (if it is
possible is an entirely different question).

And how _could_ you make an image

I do know how to do that, and it works very well; not on your OS though,
I suppose.

or a table, for example

Well, relative font sizing is rather inconsistent, I can agree there.

--

|| hexadecimal EBB
o-o decimal 3771

--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011