Vertical space distribution in CSS tables

[ashkoba]

Dear Community:

My company has a debut web site, intended to be fully standards compliant with strict XHTML and CSS validation. We have run into an interesting but disappointing conundrum that appears to affect the dividing line between presentation and content. It's likely to be fixed in CSS3 but I was hoping that someone may have determined a workaround in the short term that we could share, with respect to Table-based layouts in CSS. (No, this is not sinful, ask the experts at SitePoint... tables are a valid HTML data structure.)

Summary: In table formatting, CSS2 doesn't provide a mechanism for allocating the extra space created when a spanning group of table cells has a total height less than that of the larger, spanned element it adjoins. To quote the W3C:

CSS2 does not specify rendering when the specified table height differs from the content height, in particular whether content height should override specified height; if it doesn't, how extra space should be distributed among rows that add up to less than the specified table height...

I know it sounds horrible, since it means that there is browser behaviour that can never be controlled by CSS properties. In this context, it means: if the contents of a vertical group of table cells have some extra space when stacked alongside a larger spanning element, Netscape or IE gets to do whatever it wants to with how it assigns the extra space between the smaller cells, and there is nothing you can do to control the space distribution.

Both major browsers appear to distribute the extra space evenly between all of the cells. If this sounds democratic to you, please visit here. It's a site whose layout is ruined with this extra, unwanted space being added to the navigation bar and sidebar copy when it should be put down in the a decorative background element. But there doesn't seem to be a way of using CSS properties to reallocate this space!

I have created a horrible kludge for this but I am hoping not to have to use it, particularly since one of the goals of my new site is to promote standards compliance on the Internet. The kludge, on the surface, does not invalidate XHTML or CSS rules, though it breaks them in spirit: it adds a bunch of blank lines to this thowaway space so it "gluts up" the extra vertical space that would otherwise be added to the active elements. It shames me to have to add an extra DIV full of lines like this:

<p>&nbsp;</p>

and then claim to achieved a separation of presentation and content, but I have done so in the current "fixed" page. In this version, enough empty <p> elements have been added to the contents of the empty box to make the other vertical elements appear without an extraneous amount of vertical space for "normal" screen widths.

You can follow around the links in both the compliant (unattractive) and the kludged (attractive) site to see how the vertical spacing is achieved. For fun, check out the (Tidy) HTML source of the kludged version to see how many of the above bogus vertical spacing elements were added on each of the pages of the kludged site, and imagine adding or removing an unpredictable number of lines every single time the table elements are modified and consequently change their relative heights. This cannot be practical for any maintainable web site.

I hope this states the problem. Now, the question: is there a kludge, hack, or other method in CSS that allows one to "thin" all the vertical spacing around content cells, such as the navigation and sidebar text in this example, and "fatten" all the rest of the vertical spacing into a single remaining element, like in the coloured background that completes the lefthand column in this example?

I have searched all weekend on the Internet and have found nothing that addresses this problem. I thought its solution would make a nice addition to your FAQ, since there are more and more people that think that tables and CSS should work nicely together.

If there is a solution to come out of this discussion that will benefit everyone, I will do everything I can to make sure it is achieved. Send me a message and/or post if you need any more information... as soon as all the votes are in, I will be happy to prepare a summary that can go into the FAQ.

[Paul O'B]

Hi,

I don't know what the answer is to the vertical distribution of space in tables but the answer to your problem is simply to keep the cells even. If you have one cell then you can stack the divs in the cell without any extraneous code or any stretching.

After all tables were designed with exactly that concept in mind where cells would stretch along with adjacent cells.

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>CoTangent Marketing Design - Home - Robert Phair</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<style type="text/css">
/* main.css: CoTangent main style sheet (c) Robert Phair 2004 */
table {
 table-layout: fixed;
 border: 3px black solid;
 border-collapse: collapse;
 border-spacing: 0px;
}
td {
 border: 3px black solid;
 margin: 0px;
 padding: 10px;
}
h1 {
 font-size: 2em;
}
#logo {
 text-align: center;
 vertical-align: middle;
 width: 260px;
 margin: 0;
}
#logo h2, #logo h3 {
 display: none;
}
#headline {
 background-image: url("http://cotangent.com/broken-spacing/...our-cyclic.gif");
 font-size: 0.8em;
 font-family: Verdana, Helvetica, sans-serif;
 color: white;
}
#headline h1 {
 margin: 0px;
}
#navigation {
 height: 1%;
 vertical-align: top;
 background-image: url("http://cotangent.com/broken-spacing/...our-cyclic.gif");
 border-bottom: solid black 3px;
}
td#navigation {padding:0}
#navigation a {
 display: block;
 text-decoration: none;
 font-family: "Palatino Linotype", Palatino, serif;
 font-weight: bold;
 font-size: 1.3em;
 color: white;
 padding-left: 12px;
 padding-right: 12px;
}
#navigation p {
 color: #f99;
 padding:10px 12px;
 margin: 0;
}
#navigation a.sublink {
 padding-left: 1em;
 font-size: 0.9em;
 font-weight: normal;
 color: white;
}
#navigation p.current {
 font-family: "Palatino Linotype", Palatino, serif;
 font-weight: bold;
 font-style: italic;
 font-size: 1.3em;
}
#navigation p.sublink {
 padding-top: 0.1em;
 padding-left: 1em;
 font-size: 0.9em;
 font-weight: bold;
 font-style: italic;
}
#navigation a:hover {
 background-color: #900;
}
#navigation a:active {
 color: #c66;
}
#testimonial {
 vertical-align: top;
 margin-bottom: 10px;
 background:#fff;
 color:#000;
 border-top:4px solid #000;
 border-bottom:4px solid #000;
 width:100%;
}
#testimonial p.quote {
 font-style: italic;
 color:#000;
}
#testimonial p.author {
 font-weight: bold;
 color:#000;
}
#testimonial p.author a {
 text-decoration: none;
 font-weight: bold;
 font-style: italic;
 color: #090;
}
#testimonial p.author a:hover {
 color: #060;
}
#resource {
 height: 1%;
 vertical-align: top;
 background-color: #ccc;
 font-family: "Palatino Linotype", Palatino, serif;
}
#resource strong {
 color: #c00
}
#mini-report {
 height: 1%;
 vertical-align: top;
 font-family: "Palatino Linotype", Palatino, serif;
 font-size: 0.8em;
}
#mini-report .mini-announce {
 color: #00c;
} 
 
#mini-report p.mini-title {
 margin-top: 0;
 font-weight: bold;
} 
#mini-report p.mini-byline:before {
 content: "\2014\00A0";
}
#mini-report p.mini-byline {
 font-style: italic;
}
#empty-box {
 height: 80%;
 background-image: url("http://cotangent.com/broken-spacing/...our-cyclic.gif");
}
#copy {
 background-image: url("http://cotangent.com/broken-spacing/images/whitmarb.gif");
 font-family: "Palatino Linotype", Palatino, serif;
 vertical-align: top;
}
#photo {
 float: left;
 border-right: solid black 3px;
 border-bottom: solid black 3px;
 margin-right: 10px;
 margin-bottom: 5px;
 background-color: white;
}
#photo img {
}
#photo p {
 font-style: italic;
 font-size: 0.7em;
 line-height: 0.7;
 text-align: center;
 margin: 0;
 padding-bottom: 5px;
}
#photo a {
 text-decoration: none;
 color: #00c;
}
#photo a:hover {
 text-decoration: none;
 color: #66f;
}
p.first {
 margin-top: 0;
}
p.last {
 margin-bottom: 0;
}
#copy a, p.resource a {
 text-decoration: none;
 font-weight: bold;
 color: #00c;
}
#copy a:hover, p.resource a:hover {
 color: #66f;
}
#copy a.article, p.resource a.contact-us {
 color: #090;
}
#copy a.article:hover, p.resource a.contact-us:hover {
 color: #060;
}
#copy a.report {
 color: #c00;
}
#copy a.report:hover {
 color: #600;
}
#copy a.product {
 text-decoration: underline;
}
#service-contact {
 margin-top: 10px;
 border-top: solid black 1px;
}
#service-contact a.free {
 color: #c00;
 font-weight: bold;
}
#service-contact a.free:hover {
 color: #600;
}
#info {
 vertical-align: top;
 font-family: "Palatino Linotype", Palatino, serif;
 background-image: url("http://cotangent.com/broken-spacing/images/whitmarb.gif");
 text-align: center;
}
#info p {
 margin: 0;
}
#info p:first-child {
 margin-top: 0;
}
#info #contact a {
 display: block;
 text-decoration: none;
 font-family: Courier, courier, sans-serif;
 font-weight: bold;
 color: black;
 font-size: 1.2em;
 margin: 5px;
 padding: 5px;
}
#info #contact a:hover {
 display: block;
 background-color: #999;
}
#info #contact a:active {
 color: #c66;
}
#info #contact a:visited {
 border: none;
}
.compliance {
 font-size: 0.8em;
 font-family: "Palatino Linotype", Palatino, serif;
}
.compliance img {
 margin: 3px;
 border-color: black;
 border-width: 2px;
 background-color: white;
}
.compliance a img {
 border-color: white;
}
.compliance a:hover img {
 border-color: black;
}
.terms {
 font-size: 0.8em;
 font-family: "Palatino Linotype", Palatino, serif;
}
.terms a {
 text-decoration: none;
 font-weight: bold;
 color: #c00;
}
.terms a:hover {
 color: #666;
}
p.print-ready {
 margin-bottom: 0;
}
.print-ready a {
 font-size: 0.8em;
 font-style: italic;
 font-weight: bold;
 text-decoration: none;
 color: #00c;
}
.print-ready a:hover {
 color: #666;
}

#subscribe {
 font-family: "Palatino Linotype", Palatino, serif;
 background-color: #999;
}
#subscribe p {
 margin: 0;
}
#subscribe em {
 color: #c00;
}
#subscribe a {
 display: inline;
}
#subscribe form {
 text-align: center;
 margin-top: 5px;
 margin-bottom: 0px;
}
#subscribe p:first-child {
 margin-bottom: 5px;
 font-weight: bold;
}
#logo-bottom {
 text-align: center;
}
#logo-bottom img {
 border-width: 2px;
 border-color: #999;
}
#logo-bottom a:hover img {
 border-color: black;
}
.privacy-notice {
 font-weight: bold;
 font-style: italic;
}
.privacy-notice em {
 color: #c00;
 text-decoration: underline;
}
.privacy-notice a {
 text-decoration: none;
 color: #00c;
}
.privacy-notice a:hover {
 color: #66f;
}
.free {
 color: #c00;
 font-weight: bold;
}
#headline .free {
 color: #f00;
}
p.footnotes {
 font-size: 0.8em;
 margin-top: 0;
 border-top: 1px black solid;
 margin-bottom: 0;
}
@media print {
 #copy {
  float: none;
 }
 #copy-text {
  float: none;
 }
 #logo-bottom img {
  border-width: 0;
 }
 #copy a {
  font-weight: normal;
 }
 .compliance img {
  background-color: white;
 }
}

</style>
<script type="text/javascript" src="http://cotangent.com/external.js">
 </script>
</head>
<body>
<table summary="CoTangent Marketing Design - Home - Robert Phair">
  <tr> 
	<td id="logo"> <div id="logo-top"> <img src="http://cotangent.com/images/logo-md.gif" alt="CoTangent Marketing Design" /> 
	  </div>
	  <h2>CoTangent</h2>
	  <h3>Marketing Design</h3></td>
	<td id="headline"> <h1>Powerful strategies for rapid business growth</h1></td>
  </tr>
  <tr> 
	<td id="navigation"> <p class="current">Home</p>
	  <a href="services.html">Services</a> <a href="
	newsletter.html">Newsletter</a> <a href="resources.html">Resources</a> <a href="credentials.html">Credentials</a> 
	  <a href="
	contact.html">Contact</a> <div id="testimonial"> 
		<p class="quote">"Robert's unique talents and business acumen based on 
		  creating a synergy between marketing media and the latest Open Source 
		  IT technology will make his firm the vendor of choice for United States, 
		  European, and Asian firms tired of old formulas which are no longer 
		  valid."</p>
		<p class="author">Roger C. Parker <a rel="external" href="
	<A href="http://www.google.com/search?hl=en&amp;q=Roger+C.+Parker">(about)</a></p">http://www.google.com/search?hl=en&amp;q=Roger+C.+Parker">(about)</a></p>
	  </div></td>
	<td id="copy" > <div id="copy-text"> 
		<p class="first">Whether your business is well-established or ready to 
		  experience a growth phase, it needs a focused marketing effort to survive 
		  in today's marketplace. Traditional methods of advertising remain useful 
		  only for businesses based on mass production: small to medium sized 
		  business must use more progressive marketing methods to distinguish 
		  themselves amidst the flood of information brought about by the Internet.</p>
		<h3>Revolution requires evolution</h3>
		<p><strong>CoTangent</strong> has recognized the need to adapt popular 
		  marketing methods to suit the needs of an information-saturated customer 
		  audience. For a business to grow and prosper in today's global economy, 
		  it has to establish and maintain expert status in the eyes of its customers 
		  by regularly offering solutions to their problems and satisfying their 
		  ongoing needs.</p>
		<p>In a world where cheaper solutions drive the market for outsourcing, 
		  businesses that offer high-quality and often higher-priced products 
		  and services must have marketing efforts that match their own standards 
		  of excellence. These efforts must include the best of conventional direct 
		  marketing methods as well as those that take advantage of the most current 
		  and capable Information Technology available for online marketing.</p>
		<p><strong>CoTangent</strong> meets these needs with four basic marketing 
		  design services:</p>
		<ul>
		  <li><a href="pdf-premium-design.html">Newsletters and premiums</a></li>
		  <li><a href="direct-mail-design.html">Dynamic direct mail design</a></li>
		  <li><a href="css-web-design.html">CSS web site creation</a></li>
		  <li><a href="open-systems-server.html">Open systems server provisioning</a></li>
		</ul>
		<p>Each of these is an independent method for businesses to attract customers 
		  and keep them involved as regular clients. <strong>CoTangent</strong> 
		  also offers <a href="
	 consulting.html">consulting services</a> to customize these methods and deploy 
		  any related software technologies that may be appropriate for your business 
		  and your customer base.</p>
		<p>Please take the time to browse the information resources on this web 
		  site and request any of several <a href="resources.html">free reports</a> 
		  that describe how these strategies and technologies can begin to build 
		  your customer base <em>immediately</em>. Also, please accept our offer 
		  of a complimentary subscription to the leading <a href="
	 newsletter.html">newsletter</a> for creative marketing strategies, unique 
		  software solutions, and high-tech tools to promote and sustain the growth 
		  of your business.</p>
		<p>Warm regards,</p>
		<p class="last">Robert Phair, Principal</p>
	  </div></td>
  </tr>
  <tr> 
	<td id="info"> <p>© 2004 Robert Phair</p>
	  <div id="contact"> 
		<script type="text/javascript">
	 //<![CDATA[
	 <!--
	 var foo = "rphair";
	 var bar = "cotangent.com";
	 document.write('<a href=\"mailto:' + foo + '@' + bar + '\">');
	 document.write(foo + '@' + bar + '<' + '/a' + '>');
	 //-->
	 //]]>
	 </script>
	  </div>
	  <p class="compliance">This site meets the most current web design standards:<br />
		<a href="http://validator.w3.org/check/referer" rel="external"><img src="
	images/valid-xhtml.jpg" alt="XHTML compliant" /></a> <a href="
	http://jigsaw.w3.org/css-validator/check/referer" rel="
	external"><img src="http://cotangent.com/images/valid-css.png" alt="CSS compliant" /></a></p>
	  <p class="terms">Please read <a href="terms-of-use.html" rel="
	external">terms of use</a></p>
	  <p class="print-ready"><a href="support/css-printer-friendly.html" rel="
	external">This page is printer-friendly</a></p></td>
	<td id="subscribe"> <p>Subscribe to the <span class="free">free</span> bi-weekly 
		PDF newsletter:</p>
	  <div id="logo-bottom"> <a href="newsletter.html"><img src="http://cotangent.com/images/logo-sub.gif" alt="
	 CoTangent Marketing Design for Intelligent Business" /></a> </div>
	  <div id="subscribe-form"> 
		<form method="post" action="subscribe.php">
		  <p><strong>email:</strong> 
			<input type="text" name="email" size="16"
	  maxlength="254" />
			<input type="submit" value="Subscribe (Letter)"
	  name="submit" />
			<input type="submit" value="Subscribe (A4)" name="
	  submit" />
		  </p>
		  <p class="privacy-notice">Your email address will <em>never</em> be 
			given to anyone: see <a href="privacy.html" rel="external">privacy 
			policy</a></p>
		</form>
	  </div></td>
  </tr>
</table>
</body>
</html>

The above does what your fixed layout does without any non sematic code added. The rollovers on the nav are now full width and not gapped as in both your examples. You should arrange your nav into a list format rather than non semantic anchors stacked on top of each other without any apparent structure to them.

tables are a valid HTML data structure

Tables are a valid data structure, unfortunately your layout doesn't fall into that category and makes no sense when linearised. However you are allowed to use tables for layout until browsers can replicate the behaviour with css and as long as you simplify their structure and try to keep a logical relationship between cell and following content.

If no other mechanism exists to construct the layout you require then of course use tables if they are presently the only solution for certain layouts. However I would avoid spanning cells when not necessary (and avoid nested tables) and use the table as a wrapper to keep the layout together but style as much as possible with css within minimal cells. (I will use a table if I the layout cannot be done any other way so I have nothing against tables.)

Most of the problems in the css forum that never seem to get solved always have a table in them

Sorry I couldn't shed any light on your initial problem but hopefully approaching the problem from a different angle will help

Paul

Paul

[ashkoba]

Dear Paul:

Thank you for richly detailed and helpful reply. It's been a while since someone has given me pause about the right way to do things. You really made me stop and evaluate how I was doing design... those opportunities to learn (or relearn) don't come along often, and not often enough when one is in the early stages of a learning curve. I can't express my appreciation enough, except with these silly things...

You should arrange your nav into a list format rather than non semantic anchors stacked on top of each other without any apparent structure to them.

I redid my navigational code with unordered lists. I hadn't even noticed how much better it looks with the highlight bar for active links going all the way across the box. I think I'd gotten used to the idea of a link's active region being wherever the browser chose to put it. Thanks for making me think of how much of those usable link areas were only padding and therefore dead space. The resulting layout looks much better and functions more intuitively.

I had originally thought it would just be okay to have the links formatted with the property "display: block" since that would make them stack up nicely... when I was designing this site I hadn't been thinking about the crucial distinction between form and structure. Thanks again for waking me up.

I still have one question that hopefully others will benefit from: where the navigational bar isn't clickable, I had to assign a <div> to the static element to set the padding (indentation) explicitly. Setting the padding in the <li> element (which contains each of the <a> elements) removes this padding from its link's active region and breaks up the rollover. Adding it to a <div> instead has the desired effect but seems unclean. Is there a more canonical way of doing this without creating an extra container?

Tables are a valid data structure, unfortunately your layout doesn't fall into that category and makes no sense when linearised.

Can you please explain what you mean by this? I really made an effort to have some kind of flow in the HTML text that is independent of the style sheet. Right now the layout goes (here is a link to the most content-rich page):

• #logo (graphic replacement for company name)
• #headline (of the main body... the only <h1> tag)
• #navigation (serving here as a table of contents in the web site)
• #copy (MAIN BODY)
• #testimonial, #resource, #mini-report (supporting elements, appendices)
• #info, #subscribe (page footer, the same on every page)

I would really like to know how that isn't linear, not to be argumentative but to understand your notion of "linearity." I want to make absolutely sure I'm not missing anything!

I don't know what the answer is to the vertical distribution of space in tables but the answer to your problem is simply to keep the cells even. If you have one cell then you can stack the divs in the cell without any extraneous code or any stretching.

Interestingly, that was the way the original layout was set up. I never really liked it, for the reasons you mentioned above... the flow of the HTML is neither logical or linear, but the supporting elements have to precede what they refer to since all the HTML in the left-hand side of the table must precede all of the HTML on the right! But there was another problem...

This layout has a stack of <div>s with borders designed to look like the table borders, so there are no extraneous spaces in those <div>s and the extra space just sits at the bottom of the cell. It looks great in a browser window, but it won't print properly! Something about those extra borders of the <div>s inside the table cells screws up the table borders that surround them. It could never be used professionally or even presentationally. I haven't seen this problem documented anywhere.

Thanks again, Paul... please let me know what you think regarding:

• propriety of using <div>s for indentation???
• linearization of source HTML pages (particularly this example)
• browser printing bug for <div>s in tables... seen before? workaround?

I hope everyone else is benefiting from the information in this discussion, even if the originally posted problem turns out to be unsolvable.

[Paul O'B]

Hi,

I'm in a bit of a rush at the moment so I'll revisit this tomorrow

But here's the fix for your list. The div in the list #current is unnecessary as the padding can be applied to the li item for the current state as its not required to rollover. This will save a div and looks much neater.

To get the whole link clickable in ie (other browsers are already clickable because of the display:block) you need to give ie a height or width. As you have padding on the width you don't want to add a width as you will incur the wrath of the broken box model so its best to give it a height. This Forces IE to make the whole link clickable to the edge of the container.

In other situations where you don't want a real height you could use the height:1% hack which does the same thing but has no ill effects because ie treats height as min-height and will expand accordingly. (Of course this hack has to be hidden from other browsers and mac ie.)

However in this case no hacks are needed as height:100% is what you want anyway and also brings ie into line with other browsers with repsect to the linespacing that was out.
CSS:

#navigation li#current {
 padding-left: 10px;
 padding-right: 10px;
}
#navigation a {
 padding-left: 10px;
 padding-right: 10px;
 display: block;
 font-style: normal;
 color: white;
 text-decoration: none;
 height:100%;
}

html:

 <ul>
		<li id="current">Home</li>
		<li><a href="services.html">Services</a></li>
		<li><a href="newsletter.html">Newsletter</a></li>
		<li><a href="resources.html">Resources</a></li>
		<li><a href="credentials.html">Credentials</a></li>
		<li><a href="contact.html">Contact</a></li>
	  </ul>

It looks great in a browser window, but it won't print properly!

Maybe I'm missing the point here but I didn't see a print stylesheet in the page. You can completely change the look of the page for printed output by defining the appropriate styles in your print stylesheet. You can turn borders on and off, get rid of tables, get rid of images , change backgrounds and colours etc.. It doesn't matter what the screen layout is you can always offer the printer something it likes (within limits of course).

I would really like to know how that isn't linear, not to be argumentative but to understand your notion of "linearity." I want to make absolutely sure I'm not missing anything!

Well, I may have not explained it very well A table by implication establishes a relationship between one cell and the next adajacent cell. Therefore, the expectation is that if one cell says "Number of items" then the next cell is likely to have a value related to the first e.g. "500". The table will have heading etc for the rows and columns that define the data so the whole concept of the table makes sense and can be understood visually and by screen readers and the like also. This is what table were designed to do - hold tabular data.

When you use a table for layout then there is no logical connection between one cell and the next. You may hav a nav element in the left cell but the destination and relationship of the nav element isn't the next cell along. If your left cell is a heading then the expectation would be that the following cell would contain information about that heading. This is what I meant by linearised.

Of course thats all semantics anyway and if a table is the only way to accomplish something then of course it should be used. And of course that doesn't mean that css layouts are any more logical if they are constructed badly.

Talking about semantics and as a bit of light relief you may be interested in ths thread that I ran some time ago :

http://www.sitepoint.com/forums/show...est+css+skills

Hope thats been of some interest

Paul

[ashkoba]

Dear Paul:

Thanks again for another successive refinement. When all is said and done, I hope to point others to this thread as an example of how one grows into proper design navigation and page structure in CSS.

The div in the list #current is unnecessary as the padding can be applied to the li item for the current state as its not required to rollover. This will save a div and looks much neater.

It did, and I was so happy. There was very little change to the CSS file and the HTML looked so neat. Then I clicked on this link and my heart sank. I meant to save a copy of my site out to another directory as an illustration of the problem but accidentally overwrote it, yet it's probably not difficult to visualise what the problem was: setting the padding on the li#current selector eliminates that padded space from the links in the sublist that the parent <li> contains. So rollover bars were again broken up. If you have a way around this one I'll be really impressed... it would seem to involve having the links break out of their containing box.

However in this case no hacks are needed as height:100% is what you want anyway and also brings ie into line with other browsers with repsect to the linespacing that was out.

Ugh, I didn't even notice until this morning that all that extra space was there. Thank you for pointing out the problem and providing such an elegant solution. Very impressive that you knew setting the height explicitly will make the link text active to the end of the container. I hope the O'Reilly CSS book comes out soon since I wouldn't know where to go to find information like that. (My mentor is trying to get me a review copy.)

The behaviour sounds frustratingly stupid at first, but makes sense when you think about it... it forces the browser to treat the link as a box, which must have dimensions, rather than a line of text which may not.

I think now the navigational issues are taken care of, unless there's a snappy fix to eliminiate the extra <div>. Your help is most appreciated and now I have a mini-tutorial I can refer people to on your site.

Maybe I'm missing the point here but I didn't see a print stylesheet in the page. You can completely change the look of the page for printed output by defining the appropriate styles in your print stylesheet. You can turn borders on and off, get rid of tables, get rid of images , change backgrounds and colours etc.. It doesn't matter what the screen layout is you can always offer the printer something it likes (within limits of course).

Now I feel like we are getting to the heart of the matter. It's awesome when a discussion naturally comes around to its original topic after having covered so much ground.

My print style sheet has actually been contained in my main style sheet. It's pretty rudimentary, with only code to change to soften the print density of text that looks good in bold on the screen, or remove links that don't make sense in a printout, or remove image link borders that show up as ugly boxes:

@media print {
        #copy, #popup, #popup-copy, #popup-copy-serious {
                float: none;
        }
        #logo-bottom img {
                border-width: 0;
        }
        #copy a {
                font-weight: normal;
        }
        #testimonial p.author a {
                display: none;
        }
        #popup-copy p.close, #popup-copy-serious p.close {
                display: none;
        }
        #popup-copy-serious {
                font-weight: normal;
        }
}

That's all. I wasn't being lazy, I just thought it would be more of an elegant design if I got a good-looking printout of a web page using the browser defaults, not micromanaging the spacing and letting browsers use their own defaults. It just so happened that the relatively unadorned table design printed very well, even though the borders, margins, and padding are all specified in pixels. After my initial surprise I came to the conclusion that the browser was a assuming a "screen" width in pixels and using it to scale pixel feature sizes in the style sheet to proportional feature sizes in the printout.

That worked well until I tried to simulate adding extra boxes to the table by putting some <div>s into one of the cells with single borders matching the border of the rest of the table. As I said a couple of postings ago, it (see page here) looks fine on the web, but when you print it in Netscape the borders don't show up right for the parts of the table that adjoin these <div>s, beginning with the second page. The problem shows up on the page above in a "Print Preview" from Netscape so hopefully you can see what I'm talking about it without wasting paper.

This is not a problem in Internet explorer (though when it picks the page width it picks one that doesn't allow enough room for all the GIF's on the page to print, and truncates these graphics while Netscape scales them).

To correct the problem I put these <div>s into their own table cells, which then introduced the cell stretching that inspired this thread.

I have a hypothesis that I'd like to test: that setting relative sizes for the borders may fix the Netscape printing problem, so I can return to the original layout without the vertically stretchy table cells. My question is... relative to what? If, since the current style sheet has

table {... border: 3px black solid; ... }
td {border: 3px black solid; ...}

I should be saying something like

table {... border: 0.375% black solid; ... }
td {border: 0.375% black solid; ...}

assuming the borders are being scaled relative to a 800px-wide table, and then creating the extra cells with <div> like so:

#resource {border-bottom: 0.375% black solid; ...}

These percentages should refer to the width of the containing element, but which containing element? I would think that it would be the <table>, but what if it's the <td>? If I'm about to make a wrong assumption here I hope you'll tell me so. Also, if printing tables in Netscape is broken and there is no way to fix it, to restate it here as a warning may serve as a warning to others.

(There is also a strange tendency for Netscape to want to float things that are longer than one page to the beginning of the next page... another thing that has me stumped but perhaps outside the scope of this thread. If there's a pointer to an FAQ about it I'd be happy to do the research offline.)

Thanks again for everything and I hope to hear from you when you've the time.

[Paul O'B]

Hi,

I thought I'd replied to this but must have pressed the wrong button

So rollover bars were again broken up. If you have a way around this one I'll be really impressed... it would seem to involve having the links break out of their containing box.

Not tested thoroughly yet but this should do the trick

[/code]
#navigation li#current {
padding-left: 10px;
padding-right: 10px;
}
li#current ul li{margin-left:-10px;margin-right:-10px}

[/code]

		<li id="current"> Services 
		 <ul>
			<li><a href="pdf-newsletter.html">Newsletters and PDF premiums</a></li>
			<li><a href="direct-mail-design.html">Dynamic direct mail design</a></li>
			<li><a href="css-design.html">CSS web site development</a></li>
			<li><a href="open-systems-server.html">Open systems server provisioning</a></li>
			<li><a href="consulting.html">Consulting services</a></li>
		 </ul>
		</li>

I should be saying something like
Code:

table {... border: 0.375% black solid; ... }td {border: 0.375% black solid; ...}

Borders can't be specified in precentages I'm afraid. Only pixels , ems etc not percentages.

I will re-visit later to look at the other issues but I must do some work for a change

Paul

[ashkoba]

Paul:

Yes, again I am impressed. Rather than trying to "break" the container hierarchy, the solution was to define elements with an area exceeding that of their container. I hadn't realized this was possible... perhaps I needed to think "outside of the box." You've filled in a valuable piece of the CSS schema in my understanding.

The result is at http://cotangent.com. I have returned to my original layout, with a 2x3 table with the left-hand sidebar stacked full of <div>s with borders to make them look like layout boxes. I feel better about this layout now, knowing that some alternatives have been considered... I don't mind that these extra <div>s aren't "true" table cells, nor that the CSS specification wouldn't provide a mechanism for making them vertically "thin" or "fat" even if they were in their own <td>s.

Also, Your improvements to the CSS navbar were an unexpected benefit.

If a web page looks good in all browser windows, but displays arbitrary border widths under certain conditions when printing in Netscape (like in this document), I know it's a matter of opinion as to whether a real problem exists. I'll give it my best shot to find set of @media print characteristics that fix the problem, and will post it here when I do.

That there would be inconstencies between a layout as generated in a browser window and a print layout is something that should always be considered... I've learned that lesson now. The fact that Internet Explorer and Netscape should both have slightly different problems printing out a CSS table-based layout is something that I hope won't discourage people from attempting this.

If you've got a better way of generating a layout with five independently fillable columns of combined text and graphics, with two pairs of these columns having their heights matched in the middle of a page, please let me know and I'll scrap tables as a layout feature once and for all.

I hope you'll stay in touch, Paul. You're a credit to your organization and to your own gifts as a mentor and as a designer.