Spacing between <div> and <table>

[CMAR]

I have the following markup. The problem is that the browser, e.g., IE6,
inserts several lines of blank space between the <div> and the following
table. Is there a way to minimize that vertical spacing?
Thanks, CMA
<div class="vlgray">Condition</div>
<table cellpadding="0" cellspacing="0">

<tr> <td width="696">&nbsp;

<ul>

<li>The focus of this collection is to present

items of superb design in the best possible condition
for

the discerning collector. Please note that even when the

item is marked &quot;mint,&quot; it is still old and,

therefore, is more fragile than a new item.</li>

<li><b><i>Excellent condition does not mean

mint</i></b>. If an item has been used, it will
generally

have at least some subtle signs of wear. It is both

unrealistic and unreasonable to expect a vintage garment
to

have the same durability as a new garment.</li>

<li>Collectors of antique/vintage textiles and

clothing are often willing to live with a few minor
flaws in

order to have qualities not available in modern mass

produced goods, such as exquisite hand work and rich,
hand

loomed fabrics.&nbsp;</li>

<li>The condition of each item is described in

the listing.&nbsp;</li>

<li>All vintage garments need to be treated

with care. <b><i>Wearable condition</i></b> means

&quot;gentle wear&quot; - please don't do the Charleston
in

a beaded dress.</li> </ul> <p></td> </tr>
</table>

Here is the styling of "vlgray".

..vlgray { font-size: larger; font-weight: bold; background: #CCC; width:
100%;

padding-left: 1em; }

[Brian]

CMAR wrote:

I have the following markup. The problem is that the browser, e.g.,
IE6, inserts several lines of blank space between the <div> and the
following table.
That's odd; in most browsers, <div> has no margins by default, and
<table> has modest margins.
Is there a way to minimize that vertical spacing?

<div class="vlgray">Condition</div>
<table cellpadding="0" cellspacing="0">

table {margin-top: 0;}

If that doesn't work, then we need a url to see what is going wrong.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Jukka K. Korpela]

"CMAR" <cm***@yahoo.com> wrote:

I have the following markup. The problem is that the browser, e.g.,
IE6,
inserts several lines of blank space between the <div> and the
following table.
No, it's spacing inside the table. You can see this if you add border="1"
into the <table> tag, for testing.
<tr> <td width="696">&nbsp;

<ul>

Why do you use &nbsp; there? It's a no-break space, creating a line with
that alone, so there you have a blank line, in practice.

There's more. A <ul> element normally has default top margin in most
browsers, but browsers may suppress this margin if the <ul> element is at
the start of a table cell. Now it's not at the start - there's the &nbsp;
stuff before it - so what you get on IE6 is a blank line followed by
a <ul> element's default top margin. Just removing &nbsp; removes the
vertical spacing.

On the other hand, you are using a single-cell table for the sole purpose
of setting the maximal column width to 696 pixels. The markup could thus
be simplified if you do such things in CSS. However, the table trick
actually works better on present-day browsers, especially since IE 6 does
not support the max-width property.

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

[Spartanicus]

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

On the other hand, you are using a single-cell table for the sole purpose
of setting the maximal column width to 696 pixels. The markup could thus
be simplified if you do such things in CSS. However, the table trick
actually works better on present-day browsers, especially since IE 6 does
not support the max-width property.

Hack available though:
http://www.svendtofte.com/code/max_width_in_ie/

--
Spartanicus

[Jukka K. Korpela]

Spartanicus <[e-mail]> wrote:

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

On the other hand, you are using a single-cell table for the sole
purpose of setting the maximal column width to 696 pixels. The markup
could thus be simplified if you do such things in CSS. However, the
table trick actually works better on present-day browsers, especially
since IE 6 does not support the max-width property.

Hack available though:
http://www.svendtofte.com/code/max_width_in_ie/

I would prefer the HTML table hack to the trickery suggested there - the
page is far from convincing; it even propagates misconceptions like
"em specifies the width of the capital M". If you are going to say just
one thing about the em unit, this is surely the thing that must not say.
And it plays some odd game that ultimately boils down to _assuming_ some
particular relationship between points and pixels.

Note that the single-cell table hack, in addition to not violating HTML
specifications (the CSS trickery violates CSS specifications), is
flexible in the sense that you can set a maximum width in pixels for non-
CSS browsing situations and a maximum width in em units in CSS:

<td width="350" style="width: 22em">

This roughly gives the typographically recommended width of about 55 - 60
characters per line. Contrary to what the cited document claims, the
typical average width of characters is not half of em but considerably
smaller. And 350 pixels is a reasonable guess if you set column width in
pixels; it's better to make it a little too small than too large.

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

[Spartanicus]

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

Hack available though:
http://www.svendtofte.com/code/max_width_in_ie/
I would prefer the HTML table hack to the trickery suggested there - the
page is far from convincing; it even propagates misconceptions like
"em specifies the width of the capital M".

I see no relation between the fact that he's wrong on the em issue and
the essence of the hack (and it's irrelevant with regard to the pixel
variant).
And it plays some odd game that ultimately boils down to _assuming_ some
particular relationship between points and pixels.
Not if you use the pixel example (bottom of page), which I assume you
would do because the OP's table width was also expressed as a pixel
value.
Note that the single-cell table hack, in addition to not violating HTML
specifications (the CSS trickery violates CSS specifications)
Correct HTML is more important than valid HTML, and the table hack is
incorrect HTML. If there is such a thing as valid CSS, it has little
relevance. I consider ignoring unknown CSS code as is required by the
spec as a feature that can be used if needed.
, is
flexible in the sense that you can set a maximum width in pixels for non-
CSS browsing situations and a maximum width in em units in CSS:

<td width="350" style="width: 22em">

There's nothing structural about the width expressed in HTML here, thus
it should be expressed exclusively in CSS.

--
Spartanicus

[Jukka K. Korpela]

Spartanicus <[e-mail]> wrote:

I see no relation between the fact that he's wrong on the em issue
and the essence of the hack
Anyone who writes about the em as the width of M immediately loses
42 credibility points in CSS matters. This means that whatever hack will
be suggested by him after that, I will assume that he has not studied the
pros and cons and risks well, since he is wrong in an elementary matter.

And it plays some odd game that ultimately boils down to _assuming_
some particular relationship between points and pixels.

Not if you use the pixel example (bottom of page), which I assume you
would do because the OP's table width was also expressed as a pixel
value.

Setting widths in pixels means assuming even much more. The OP wanted to
set maximum width in pixels, indeed, but this does not mean that such an
approach is a good one.

Note that the single-cell table hack, in addition to not violating
HTML specifications (the CSS trickery violates CSS specifications)

Correct HTML is more important than valid HTML, and the table hack is
incorrect HTML.

No, it is not by the W3C specifications. You might dislike it, and even
the W3C might express dislike for it, but this does not make it incorrect
HTML.
If there is such a thing as valid CSS, it has little
relevance.
There isn't, but there are conformance definitions in CSS specifications.
I consider ignoring unknown CSS code as is required by the
spec as a feature that can be used if needed.

Then you are very wrong. The error processing rules were not defined for
such reasons. They were set in an attempt to guarantee that browsers
conforming to a particular CSS specification, such as CSS 1 and CSS 2,
can process style sheets conforming to newer, extended specifications
in a useful way - ignoring what they don't understand. But there is no
guarantee that style sheets using extended, nonstandard features will
work on future browsers. The extended syntax you use might in fact become
standard in some future specification - but possibly with a completely
different _meaning_. (There might be practical reasons to think that this
won't happen to Microsoft extensions, but I wouldn't bet on it.)

<td width="350" style="width: 22em">

There's nothing structural about the width expressed in HTML here,
thus it should be expressed exclusively in CSS.

Please feel free to think so. And you can in fact omit the width
attribute if you like; the hack still works on CSS enabled browsers

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

[Jan Roland Eriksson]

On Sat, 31 Jul 2004 09:04:20 +0100, Spartanicus <[e-mail]> wrote:

[...]

I consider ignoring unknown CSS code as is required by the
spec as a feature that can be used if needed.

The history of the www is filled with individuals who decided that their
own interpretation of a "decision in consensus" is more correct than
what others did agree upon.

I'm seriously surprised to see you, of all people, claim your own
individual space in that muddy stream of history.

--
Rex

[Stephen Poley]

On Sat, 31 Jul 2004 13:58:35 +0200, Jan Roland Eriksson <re*@css.nu>
wrote:

On Sat, 31 Jul 2004 09:04:20 +0100, Spartanicus <[e-mail]> wrote:

[...]

I consider ignoring unknown CSS code as is required by the
spec as a feature that can be used if needed.

The history of the www is filled with individuals who decided that their
own interpretation of a "decision in consensus" is more correct than
what others did agree upon.

I've just hit a case where I'd also like to pursuade IE to implement
some form of maxwidth. I have an extra reason for not using a table, as
I'd like some small floating sidebars to float clear of the text if
window-width permits, or "embed" into the text if it doesn't.

How (un)acceptable would people consider this IE mangled-css if it were
enclosed within an IE conditional comment?

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

[Jukka K. Korpela]

Stephen Poley <sb******************@xs4all.nl> wrote:

I have an extra reason for not using a table, as
I'd like some small floating sidebars to float clear of the text if
window-width permits, or "embed" into the text if it doesn't.
Tables can be floated, too, even in HTML - though this has been greatly
obscured by the attribute name and mixed semantics: <table align="left">
or <table align="right"> effectively mean float: left and float: right
for the table element (whereas <table align="center"> means something
quite different).
How (un)acceptable would people consider this IE mangled-css if it were
enclosed within an IE conditional comment?

You mean you would use a construct that is a comment in HTML terms, yet
recognized by IE as something else? Something like

<!--[if IE]><style>...</style><![endif]-->

Sounds awful. But I can't find an argument against it as regards to
conformance to specifications. :-)

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

[CMAR]

Thanks, Jukka, you solved the problem. I removed the non-breaking space. It
is simple when you know it, which you do and I don't *S*.

Now here is a perhaps tougher question. I have and want extra spaces in my
unordered lists but I did that with 5 uls. Is there a way to do it with just
one list?
Cheers, CMA

<table cellpadding="0" cellspacing="0">
<tr> <td width="699">
<ul>
<li>I do not refund shipping costs or credit card fees.
They will be deducted from the total amount of your refund.</li>
</ul>
<ul> <li>A 10% restocking fee will be charged on any accepted
return over $300.&nbsp; </li> </ul>
<ul> <li>Refunds are issued immediately upon receipt of an
accepted return in good condition.</li> </ul>
<ul> <li>There are no refunds on items purchased by Layaway. </li>
</ul>
<ul> <li>There are no refunds for items damaged in shipping. In
such a case, you must file a claim with the carrier.</li>
</ul>
<p></td> </tr> </table>

[Jukka K. Korpela]

"CMAR" <cm***@yahoo.com> wrote:

Now here is a perhaps tougher question. I have and want extra spaces
in my unordered lists but I did that with 5 uls. Is there a way to do
it with just one list?

Surely. Here's a simple approach:

<style type="text/css">
ul li { margin-bottom: 1em; }
</style>

This sets a bottom margin of 1em for each <li> element that is contained
in a <ul> element. Adjust the value 1em as needed.

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

[Haines Brown]

"Jukka K. Korpela" <jk******@cs.tut.fi> writes:

"CMAR" <cm***@yahoo.com> wrote:

Now here is a perhaps tougher question. I have and want extra spaces
in my unordered lists but I did that with 5 uls. Is there a way to do
it with just one list?

Surely. Here's a simple approach:

<style type="text/css">
ul li { margin-bottom: 1em; }
</style>

You gave a simple anwser to that question, but I have a situation that
is a bit more complex. I need to group items in the unordered list. I
do so by assigning an ID to an li item. The "down" class refers to a
style defined externally for all list items. For example:

#spaced {margin-top: 0.6em;}

<ul>
<li class="down">item 1</li>
<li class="down">item 2</li>
<li class="down" id="spaced">item 3</li>
<li class="down">item 4</li>
</ul>

The result is a list consisting of four items that are placed in two
separated groups of two items each.

Now my question. In my example, I have merely two groups. But not
unusually I have three or more groups. What I do is use something like
id="spaced-1", id="spaced-2", ... to separate each group of list
items. I'd like something more elegant, but I can't repeat the same ID
name for more than one item.

I could use a ul li selector and assign the style associated with the
name "down", and that would allow me to have a li.spaced class that I
could use at will, but "down" is defined in an external stylesheet. I
don't know how to reference the "down" style by means of a stylesheet
selector rather than specifying the class in the list itself. I'm sure
there's a simple answer, but it has not occurred to me.

This just illustrates what I'm getting at:

ul.special li {somehow reference the "down" style}
li.spaced {margin-top: 0.6em;}

<ul class="special">
<li>item 1</li>
<li>item 2</li>
<li class="spaced">item 3</li>
<li>item 4</li>
</ul>
--
Haines Brown

[Jukka K. Korpela]

Haines Brown <br****@teufel.hartford-hwp.com> wrote:

I need to group items in the unordered list.
I guess you mean visual grouping in the sense of leaving some extra
vertical space.
I do so by assigning an ID to an li item.
Well, yes, you need to play with the li items (unless you divide the list
into separate ul elements, which might be illogical). HTML syntax does
not permit you to group li elements, since a ul element may not contain
anything but li elements. But it need not be an ID attribute that you
use; CLASS could work just as well, and might be more natural - ID
identifies a single element, whereas CLASS classifies one or more
elements into a class.
<ul>
<li class="down">item 1</li>
<li class="down">item 2</li>
<li class="down" id="spaced">item 3</li>
<li class="down">item 4</li>
</ul>
That's unnecessarily verbose markup, since you can use <ul class="down">
instead of class attributes for each li, and use the selector
ul.down li
In my example, I have merely two groups. But not
unusually I have three or more groups.
If equal spacing between them is desired, you can just use class="spaced"
instead of id="spaced" (and naturally the selector .spaced instead of
#spaced). In principle, "spaced" is not a good name for a class since it
corresponds to intended presentation rather than logical structure like
grouping; class="newgrp" might sound better.
- - I can't repeat the same
ID name for more than one item.
That's why a CLASS is better. Should you wish to make a <li> element
belong to another class as well, like "down" in the original markup, you
can use class="down spaced", though this isn't quite universally
supported. (If I remember correctly, Netscape 4 ignores the entire
attribute then. But should we care?)
I could use a ul li selector and assign the style associated with the
name "down", and that would allow me to have a li.spaced class that I
could use at will, but "down" is defined in an external stylesheet.
So? Can't you change the external stylesheet? Or override some of its
settings as needed?
This just illustrates what I'm getting at:

ul.special li {somehow reference the "down" style}

No, you can't do that.

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

[Stephen Poley]

On Sat, 31 Jul 2004 14:31:43 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:

Stephen Poley <sb******************@xs4all.nl> wrote:

I have an extra reason for not using a table, as
I'd like some small floating sidebars to float clear of the text if
window-width permits, or "embed" into the text if it doesn't.
Tables can be floated, too, even in HTML - though this has been greatly
obscured by the attribute name and mixed semantics: <table align="left">
or <table align="right"> effectively mean float: left and float: right
for the table element (whereas <table align="center"> means something
quite different).

True, but not quite what I was talking about. I've put an example at
http://www.xs4all.nl/~sbpoley/misc/maxwidth.html (Try varying the window
width in any recent browser except IE.) I'm not sure how one could do
that with tables.

How (un)acceptable would people consider this IE mangled-css if it were
enclosed within an IE conditional comment?

You mean you would use a construct that is a comment in HTML terms, yet
recognized by IE as something else? Something like

<!--[if IE]><style>...</style><![endif]-->

Yes.
Sounds awful. But I can't find an argument against it as regards to
conformance to specifications. :-)

I think it may sometimes be the least of the available evils.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

[Haines Brown]

Jukka,

Not sure if you quite followed my question, but you kindly provided an
answer anyway. Let me offer the solution here in case there are
lurkers who may be a slow as I am.

Problem: How to group list items by adding space between groups, while
the ul and the li already have a style defined for them.

ul.listStyle {
... list style definiton ...
}
ul.listStyle li {
... item style definition ...
}
.group {margin-top: 0.6em;}
<ul class="listStyle">
<li>item 1a</li>
<li>item 1b</li>
<li class="group">item 2a</li>
<li>item 2b</li>
<li class="group">item 3a</li>
<li>item 3b</li>
</ul>

The resulting list will look like this:

item 1a
item 1b

item 2a
item 2b

item 3a
item 3b

--
Haines Brown

[Claire Tucker]

On Sun, 01 Aug 2004 17:58:27 GMT, Haines Brown
<br****@teufel.hartford-hwp.com> wrote:

Jukka,

Not sure if you quite followed my question, but you kindly provided an
answer anyway. Let me offer the solution here in case there are
lurkers who may be a slow as I am.

Problem: How to group list items by adding space between groups, while
the ul and the li already have a style defined for them. [snip!]
item 1a
item 1b

item 2a
item 2b

item 3a
item 3b

You've not said what these items are in a structural sense, but if
here's some kind of structural reason for these "spaces" perhaps you
should consider some actual markup rather than CSS alone. Remember
that CSS should be considered *optional* ... your page should at least
be readable without it.

One idea would be a list of lists:

<ul>
<li>
<ul>
<li>item 1a</li>
<li>item 1b</li>
</ul>
</li>
<li>
<ul>
<li>item 2a</li>
<li>item 2b</li>
</ul>
</li>
<li>
<ul>
<li>item 3a</li>
<li>item 3b</li>
</ul>
</li>
</ul>

.... and then some CSS to make it render how you described. When CSS
isn't available, most current browsers will render it like this by
default:

*
* item 1a
* item 1b
*
* item 2a
* item 2b
*
* item 3a
* item 3b

....which *does* look a little weird, but at least your "spaces" are
still there and the extra bullets will provide a clue to the grouping
in browsers which don't create that extra space above each sub-list.
The three separate sub-lists make the CSS easy - just apply a
top-margin to the selector "ul ul", maybe with some class on the main
containing list. You can try to use a :first-child selector to remove
the margin from the first sublist, remembering that it isn't supported
in Opera and maybe Internet Exporer for Windows.

Of course, you should only do this if a list of lists makes sense for
the information your're representing. Other possibilities would be
just three separate lists (if the items don't really belong together
at all) or perhaps even ordered lists.

As a final note, remember that strictly speaking an "unordered list"
is a list where the order isn't important. Technically, then, you
should write them with the expectation that browsers could allow users
to sort them alphabetically, or otherwise mix them up. No current
browsers do, but if you consider your semantics important you might
like to consider if an ordered list is more applicable, possibly with
some CSs to suggest bullets instead of numbering.

All the best,
-Claire

[Haines Brown]

Claire Tucker <fa**@invalid.invalid> writes:

Problem: How to group list items by adding space between groups, while
the ul and the li already have a style defined for them. [snip!]

item 1a
item 1b

item 2a
item 2b

item 3a
item 3b

You've not said what these items are in a structural sense, but if
here's some kind of structural reason for these "spaces" perhaps you
should consider some actual markup rather than CSS alone. Remember
that CSS should be considered *optional* ... your page should at least
be readable without it.

Interesting observation. As is often the case, I'm sure, there's a
grey area between structure and content. Let me be more specific about
the list content to explore this.

Each "item" refers to one topic within a general category. The items
are "parallel", such as different kinds of fruit. If they were
sorted, the list remains intellible, for what difference does it
make if apples come before or after oranges?

However, there is occasionally an implicit minor distinction among the
items what I want to bring out simply to alert the user to the
distinction, but it remains all various kinds of fruit. For example,
if they were days of the week, I might want to distinguish workdays
and weekend days, such as some calendars do, but there is clearly just
one list of the seven days of the week.

While I could create separate or sublists, for purely practical
reasons I avoid it. First, the separation often involves just one
item. To create a separate list for one item seems pointless. Second,
I have to pound out several of these lists daily. What I'm doing using
a single list is much easier to mark up, even with the ul ul selector,
than trying to keep track of nestings, where I'm more accident prone.

I've elaborated a bit because this touches upon a much-discussed issue
regarding form and content. An unordered list is just a collection of
related items. If there were a basic difference among them, then I
suppose each distinction would call for its own list; if they are
really just a list of options without distinction, then it seems a
single list would be best. My list seems to fall between these chairs.
*
* item 1a
* item 1b
*
* item 2a
* item 2b
*
* item 3a
* item 3b

...which *does* look a little weird, but at least your "spaces" are
still there and the extra bullets will provide a clue to the grouping
in browsers which don't create that extra space above each sub-list.

One complication is that I replace the bullets with a graphic, which
is necessarily the same for each item. Your mention of the problem
that browsers won't handle the extra space consistently seems another
reason I'd best stick with a simple list.

--
Haines Brown

[Christopher]

Haines Brown wrote:

Problem: How to group list items by adding space between groups, while
the ul and the li already have a style defined for them.

ul.listStyle {
... list style definiton ...
}
ul.listStyle li {
... item style definition ...
}
.group {margin-top: 0.6em;}
<ul class="listStyle">
<li>item 1a</li>
<li>item 1b</li>
<li class="group">item 2a</li>
<li>item 2b</li>
<li class="group">item 3a</li>
<li>item 3b</li>
</ul>

The resulting list will look like this:

item 1a
item 1b

item 2a
item 2b

item 3a
item 3b

If there really is a meaningful division between those groups of
items, wouldn't it make more sense to make nested lists?

<ul>
<li><ul>
<li>item 1a</li>
<li>item 1b</li>
</ul></li>
<li><ul>
<li>item 2a</li>
<li>item 2b</li>
</ul></li>
<li><ul>
<li>item 3a</li>
<li>item 3b</li>
</ul></li>
</ul>

Or at least separate lists?

<ul>
<li>item 1a</li>
<li>item 1b</li>
</ul>
<ul>
<li>item 2a</li>
<li>item 2b</li>
</ul>
<ul>
<li>item 3a</li>
<li>item 3b</li>
</ul>

Just an idea. I guess it depends on exactly what you want the spacing
for.

[Stephen Poley]

On Sat, 31 Jul 2004 00:13:22 +0100, Spartanicus <[e-mail]> wrote:

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

On the other hand, you are using a single-cell table for the sole purpose
of setting the maximal column width to 696 pixels. The markup could thus
be simplified if you do such things in CSS. However, the table trick
actually works better on present-day browsers, especially since IE 6 does
not support the max-width property.

Hack available though:
http://www.svendtofte.com/code/max_width_in_ie/

For the benefit of anyone trying this hack: this page doesn't address
printing, and the hack appears to cause problems then (perhaps not
surprisingly). To cut a very long story short, I found that adding:

@media print { p { width: auto ! important; } }

sorted the problem out. (Sounds simple, but (a) some other possible
approaches weren't handled corectly by IE, and (b) IE was playing silly
b*****s with another of my style rules, and one bug hid another ...)

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/