Spacing between <div> and <table>

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; }

"CMAR" <cma6j (AT) yahoo (DOT) 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/

"Jukka K. Korpela" <jkorpela (AT) cs (DOT) 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

Spartanicus <me (AT) privacy (DOT) net> wrote:

"Jukka K. Korpela" <jkorpela (AT) cs (DOT) 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/

"Jukka K. Korpela" <jkorpela (AT) cs (DOT) 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

Spartanicus <me (AT) privacy (DOT) net> 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/

On Sat, 31 Jul 2004 09:04:20 +0100, Spartanicus <me (AT) privacy (DOT) net> 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

On Sat, 31 Jul 2004 13:58:35 +0200, Jan Roland Eriksson <rex (AT) css (DOT) nu>
wrote:

On Sat, 31 Jul 2004 09:04:20 +0100, Spartanicus <me (AT) privacy (DOT) net> 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/

Stephen Poley <sbpoleySpicedHamTrap (AT) xs4all (DOT) 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/

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>