By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,868 Members | 1,974 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,868 IT Pros & Developers. It's quick & easy.

how to increase vertical spacing between UL or OL items

P: n/a
Hi,

what Property and Values are used to space out further from one
another the items in a list (assuming it's possible)? The default
presentation is a bit "bunched up" for me.

Thanks,
Dave
Jul 20 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
Dave wrote:
what Property and Values are used to space out further from one
another the items in a list (assuming it's possible)? The default
presentation is a bit "bunched up" for me.


I use:

li {
margin-left: 0;
margin-right: 10%;
margin-top: .5em;
margin-bottom: .5em;
}

(The margin-right makes the LIs shorter than the paragraphs
around them which suits my purposes).

You could also try line-height:150% (I think anything over 120%
is larger than most browser defaults).
--
jc

Remove the -not from email
Jul 20 '05 #2

P: n/a
> I use:

li {
margin-left: 0;
margin-right: 10%;
margin-top: .5em;
margin-bottom: .5em;
}


Or...

li {margin:.5em 10% .5em 0}

the margin or padding properties (on either the top, bottom or both) should
work just fine.
Jul 20 '05 #3

P: n/a
Jeremy Collins <jd********@ntlworld-not.com> wrote:
You could also try line-height:150%
Well, yes, but it has a quite different meaning. Using margin-top and
margin-bottom for li elements is fine. One just needs to remember that
vertical margins don't add up. If you specify
li { margin-top: 0.5em; margin-bottom: 0.8em; }
then the distance between list items is not 0.5em + 0.8em but larger of
0.5em and 0.8em.

The line-height property sets the line height within an element. While
this may create the impression of separation of list items, it's
deceptive. When the display area is narrowed, so that list item
contents wrap, the effect is probably rather disturbing.
(I think anything over 120%
is larger than most browser defaults).


Probably so, despite the fact that CSS specifications recommend that
the default be between 1.0 and 1.2 and even uses the following settings
in the sample style sheet (which is presented as non-normative, yet as
recommended browser default style, and also presented as summary of
actual study of browser behavior, despite the fact many features there
have just been made up):
CSS 1: line-height: 1.1
CSS 2: line-height: 1.33 (above the range recommended in the spec!)
CSS 2.1 CR: line-height: 1.12

What browsers actually use seems to be near 1.2.

The conclusion is that due to this confusion, and due to the fact that
1.2 is too small for many fonts (especially for sans-serif fonts when
line length is large, as it may well be on the Web), authors should
probably set the body element's line-height to a reasonable value
like 1.25 or 1.3. I would use plain numbers due to problems of
inheritance. (If you set e.g. line-height: 150% for a li element, then
the line height inside the element will be 150% of the element's font
size, even in subelements which may have different font sizes - since
the computed value is inherited, not the percentage, but for plain
numbers, it's the number that gets inherited, and gets interpreted in
relation to each element's own font size.)

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Jul 20 '05 #4

P: n/a
Jukka K. Korpela wrote:

[snip]

There were a few issues there I wasn't aware of; thanks
for taking the time to reply.
--
jc

Remove the -not from email
Jul 20 '05 #5

P: n/a
e n | c k m a wrote:
I use:

li {
margin-left: 0;
margin-right: 10%;
margin-top: .5em;
margin-bottom: .5em;
}

Or...

li {margin:.5em 10% .5em 0}


I can *never* remember the correct order for those one-line
shortcuts! My background is programming, and I'm used to
working with RECT structures where the convention is left,
top, right, bottom. The CSS order of top, right, bottom, left
is counter-intuitive to me (although remembering that they're
both "clockwise" might help).

--
jc

Remove the -not from email
Jul 20 '05 #6

P: n/a
On Sat, 06 Mar 2004 09:00:24 +0000, Jeremy Collins
<jd********@ntlworld-not.com> wrote:
I can *never* remember the correct order for those one-line
shortcuts!


I remember CSS starts at noon. Or midnight, and if you're the time cube
guy it's like 4 days ago.
Jul 20 '05 #7

P: n/a
Jeremy Collins <jd********@ntlworld-not.com> wrote in
news:Hpg2c.2241$54.2210@newsfe1-win:
e n | c k m a wrote:
li {margin:.5em 10% .5em 0}


I can *never* remember the correct order for those one-line
shortcuts! My background is programming, and I'm used to


You mean you have TRouBLe remembering the order?
Jul 20 '05 #8

P: n/a
Eric Bohlman wrote:
Jeremy Collins <jd********@ntlworld-not.com> wrote in
news:Hpg2c.2241$54.2210@newsfe1-win:

e n | c k m a wrote:
li {margin:.5em 10% .5em 0}


I can *never* remember the correct order for those one-line
shortcuts! My background is programming, and I'm used to

You mean you have TRouBLe remembering the order?


Cute - I'm sure it'll stick now!

--
jc

Remove the -not from email
Jul 20 '05 #9

P: n/a
On Sat, 06 Mar 2004 09:00:24 +0000, Jeremy Collins
<jd********@ntlworld-not.com> wrote:
e n | c k m a wrote:
I use:

li {
margin-left: 0;
margin-right: 10%;
margin-top: .5em;
margin-bottom: .5em;
}
Or...

li {margin:.5em 10% .5em 0}
I can *never* remember the correct order for those one-line
shortcuts! My background is programming, and I'm used to
working with RECT structures where the convention is left,
top, right, bottom. The CSS order of top, right, bottom, left
is counter-intuitive to me (although remembering that they're
both "clockwise" might help).


In other words - you have TRouBLe remembering them.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/
Jul 20 '05 #10

P: n/a
Thank you everyone for your comments. As a bit of a novice, would this
be the best way for me to go:
li {margin:.5em 10% .5em 0}
rather than using line height in li attributes.
And that it is best to set line height in the body element, and to set
it there as 1.3 rather than as a percentage?
Would line height specified in the body element be inherited into
table cells?

Thanks
Dave

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message news:<Xn*****************************@193.229.0.31 >...
Jeremy Collins <jd********@ntlworld-not.com> wrote:
You could also try line-height:150%


Well, yes, but it has a quite different meaning. Using margin-top and
margin-bottom for li elements is fine. One just needs to remember that
vertical margins don't add up. If you specify
li { margin-top: 0.5em; margin-bottom: 0.8em; }
then the distance between list items is not 0.5em + 0.8em but larger of
0.5em and 0.8em.

The line-height property sets the line height within an element. While
this may create the impression of separation of list items, it's
deceptive. When the display area is narrowed, so that list item
contents wrap, the effect is probably rather disturbing.
(I think anything over 120%
is larger than most browser defaults).


Probably so, despite the fact that CSS specifications recommend that
the default be between 1.0 and 1.2 and even uses the following settings
in the sample style sheet (which is presented as non-normative, yet as
recommended browser default style, and also presented as summary of
actual study of browser behavior, despite the fact many features there
have just been made up):
CSS 1: line-height: 1.1
CSS 2: line-height: 1.33 (above the range recommended in the spec!)
CSS 2.1 CR: line-height: 1.12

What browsers actually use seems to be near 1.2.

The conclusion is that due to this confusion, and due to the fact that
1.2 is too small for many fonts (especially for sans-serif fonts when
line length is large, as it may well be on the Web), authors should
probably set the body element's line-height to a reasonable value
like 1.25 or 1.3. I would use plain numbers due to problems of
inheritance. (If you set e.g. line-height: 150% for a li element, then
the line height inside the element will be 150% of the element's font
size, even in subelements which may have different font sizes - since
the computed value is inherited, not the percentage, but for plain
numbers, it's the number that gets inherited, and gets interpreted in
relation to each element's own font size.)

Jul 20 '05 #11

P: n/a
ze********@yahoo.com.au (Dave) wrote:
As a bit of a novice, would this
be the best way for me to go:
li {margin:.5em 10% .5em 0}
rather than using line height in li attributes.
Looks OK
And that it is best to set line height in the body element, and to
set it there as 1.3 rather than as a percentage?
Yes, something like that.
Would line height specified in the body element be inherited into
table cells?


In correctly behaving browsers, yes, when no style sheet sets the line
height for the cells (and normally there is no such style sheet unless
you write one). There are problems in inheritance to table cells in
general, though. You could set
body, th, td { line-height: 1.3; }
if needed.

P.S. Please quote just the most relevant part in future in your
postings, and before your own comments.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Jul 20 '05 #12

P: n/a
ze********@yahoo.com.au (Dave) wrote:
... would this be the best way for me to go:
li {margin: .5em 10% .5em 0}
rather than using line height in li attributes.
Using margin, yes. The specific values are a matter of taste. That
right indent idea might be an unnecessary affectation, but you will
know if it's appropriate.

And that it is best to set line height in the body element, and to set
it there as 1.3 rather than as a percentage?
*IF* there is a reason to set line height at all, then yes, on the
body - usually. Or, wherever the rest of the font specification
occurs.

If the phrase, "1.3 rather than as a percentage," uses 1.3 only as an
example of a non-percentage number, then yes. It would take a lot of
doublethink to justify messing about with percentages, ems or even
worse physical units like px or pt when you can just specify the
actual number the browser will use in its calculation. If it means
"1.3" as the actual value to specify, then no. Yuck. (Unless you like
that sort of thing.)

Line height is part of the font specification and as such is one of
the things that should not be messed with arbitrarily. Are you
specifying a font with larger or smaller than average ascenders and
descenders, so that it looks odd without an adjustment of line height?
Do you have regions of differently sized text, so the area with
smaller font size has higher line height to avoid appearing cluttered
(and vice versa)? Since line height is intimately bound to font size,
it's usually best to forget you ever heard of it.

Would line height specified in the body element be inherited into
table cells?


Yes.

--
Karl Smith.
Jul 20 '05 #13

P: n/a
Karl Smith wrote:
[snip]
Line height is part of the font specification and as such is one of
the things that should not be messed with arbitrarily. Are you
specifying a font with larger or smaller than average ascenders and
descenders, so that it looks odd without an adjustment of line height?
Do you have regions of differently sized text, so the area with
smaller font size has higher line height to avoid appearing cluttered
(and vice versa)? Since line height is intimately bound to font size,
it's usually best to forget you ever heard of it.

[snip]

Unless you are using Matthew Somerville's workaround for the IE 6 peekaboo
bug!

(The Holly Hack isn't always appropriate).

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.