W3C home > Mailing lists > Public > www-html@w3.org > November 2000

RE: colspan problems

From: Dave J Woolley <david.woolley@bts.co.uk>
Date: Wed, 8 Nov 2000 20:28:39 -0000
Message-ID: <81E4A2BC03CED111845100104B62AFB5824BB4@stagecoach.bts.co.uk>
To: "'www-html@w3.org'" <www-html@w3.org>
> From:	Michael Stevens [SMTP:mike@tokenzone.com]
>     			<td width="26" height="39"><img src="spacer.gif"
> width="26"
> height="39"></td>
	IMG is missing a mandatory alt attribute.  The
	IMG elements appear to be redundant, unless they are
	there for demonstration purpose, in which case a non-blank
	image would be better.

> I have also tried setting the width on the cells I want adjustable to
> relative widths with no luck.  It seems that when the spanned cell in the
	There is no way of setting relative widths on cells in 
	HTML 4, at least not without style sheets.  NB Style sheets
	are outside the scope of this list.  If this is for
	intranet use, you should be using style sheets, not

	You can use COL elements to define the widths; 
	specifying a width of "*" for the variable column will have the
	desired effect, if the browser understands COL elements, 
	although the final table width may be implementation 
	dependent.  COL elements allow percentages and
	proportional widths without style sheets.

	I would assume that omitting the width on TDs would have the
	same effect, but I'd expect that to be even less reliable; the
	widths are only suggested.

	You should seriously consider fully specifying with COL
	elements, or specifying a well defined width for the table
	(style sheets preferred).  This will mean that the table should
	display incrementally in suitable browsers.
	Note that the default styling for IE5 is auto, not fixed 
	table sizing, so you will need a style setting.  NS 4
	does not support this.

	[DJW:]  Without style sheets, table layout is not tightly

> middle get expanded, the extra space seems to get distributed among all
> the
> columns the cell spans.  Is there any way around this problem?
	The HTML table layout algorithm appears not to have any defined
	behaviour for cell widths.  The CSS auto algorithm should
	redistribute excess space across all affected columns, which
	seems to be the behaviour you are getting.  (However, there
	is no guaranteed correlation between TD width and a style
	width on a cell.)
	The only combination that works well with good HTML implementation
	(i.e. not NS 4.7, in this case) is to fully specify the widths
	with COL elements, possibly combined with a table width), and
	to force the table layout style to fixed; this is probably the
	only combination with well defined semantics.

	This works with IE5.01, Mozilla M17, and Amaya 3.1 (it gets the 
	widths wrong, but knows which column to vary).  Amaya also works
	without COL elements (possibly because it is ignoring other
	information) and IE works with one unknown width, but resolves
	that by assuming a table width of 100%.

	I replaced the table tag with the following for the final 
	test - border, spacing and padding changes are to make the 
	table shape more apparent:

	<title>No title</title>
		<table border=1  width="80%" style="table-layout:fixed">
	        <col width=26><col width=177><col width="*"><col
width=26><col width=26>

Note. I interepret this queztion as borderline on the basis that,
it does seem to be asking for clarification of the HTML specification,
not about style sheets or browser behaviour, even though the answer
strays into these off topic areas.  As far as I can see, the only 
possible weakness in the specs is not being completely clear about
what they don't define.  It's not clear to me whether the HTML
table layout algorithm is normative or informative.  The use
of COL elements should have been obvious from the HTML spec.
--------------------------- DISCLAIMER ---------------------------------
Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of BTS.
Received on Wednesday, 8 November 2000 15:30:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:55 UTC