Forum Moderators: open
This is easily done in Opera and Firefox with the following code:
<TABLE BORDER="1" WIDTH="100%">
<TR><TD COLSPAN="2"><IMG SRC=logo.gif" WIDTH="750" HEIGHT="50"></TD></TR>
<TR>
<TD WIDTH="100%">CONTENT</TD>
<TD WIDTH="200" NOWRAP>BUTTONS</TD>
</TR>
</TABLE>
but in IE this forces the width to be the width of the image plus the width of the right hand column (so forcing a scroll on smaller screen sizes)
A similar problem seems to be reported here [webmasterworld.com], but with no satisfactory solution. does anyone have a way of acheiving this?
It can be "fixed" you just have to know how IE actually always had better support for the table models since HTML4.. OK, I'm being a little naughty before anyone says this is another IE/CSS issue.. it's not, but a CSS2 property will help fix it.
The default table-layout [w3.org] algorithm is "auto", this is the one that most are used to, and without any alteration to the above code is what the UA uses. In this model the table renders a little more slowly as it has to make as many "passes" as necessary over the table to calculate its columns widths. The UA can't get the column widths sorted out until it has parsed and calculated the whole table. IE is getting confused because the first row it hits includes a rowspan and is supposed to be 100% wide but then in the next row the first cell it hits is also 100% wide. (it appears to start rendering here.. While you could rightly say that is wrong the specs for HTML do say that there should only usually be 2 passes required.
Anyway.. in HTML 4.0 there was an enhancement introduced - <col> and <colgroup> [w3.org] - which gave tables the capability of rendering incrementally instead, which should make them render faster and better as they no longer have to wait for all the content or do the calculations that might slow it even further ~ IE adopted this method wholeheartedly, IE might even be the reason they're there? But IE still didn't quite seem capable of getting it right, that is until you introduce a bit of CSS (the surprise here is that even IE5.0 supports this, which makes me think IE contributed a lot to this part of the specs) Microsoft Table Layout [msdn.microsoft.com] - so although this property wasn't introduced into CSS until CSS2 you were always able to use it for IE!
what this does (and has done so since IE5 ~ and before the advent of the same property in CSS) is:
You can optimize table rendering performance by specifying the tableLayout property. This property causes Microsoft Internet Explorer to render the table one row at a time, providing users with information at a faster pace. The tableLayout property determines column widths for a table in the following order:1. By using information in the width property for the col or colGroup element.
2. By using information in the width property for the td elements in the first row.
3. By dividing the table columns equally, regardless of the size of the content.
You can see from that quote above that the IE table-layout property worked best in conjunction with the the little used, but very useful <col> and <colgroup> [w3.org] elements.
If it didn't get these it relied of the widths in the first rows, which if it involves colspan spanning 100% like your case, is bringing it to it's knees., but at least it told us that..
These <col> and <colgroup> elements get inserted just after the <table> element and before the first <tr> (or <caption> if using it). These enable the table to know what widths you want the COLUMNS to be regardless of any internal colspans.
and now of course the same CSS property is Valid CSS2 so people are not so averse to using it, it was likely a different story when it was a proprietary property :)
I bet you didn't want all that and just want the answer..
<TABLE BORDER="1" WIDTH="100%" style="table-layout: fixed;"><col width="*" />
<col width="200" /><TR><TD COLSPAN="2"><IMG SRC="logo.gif" WIDTH="750" HEIGHT="50"></TD></TR>
<TR>
<TD>CONTENT</TD>
<TD>BUTTONS</TD>
</TR>
</TABLE>
you can use some style properties on the col elements inside your stylesheet and width is one but I've left it in HTML format and you can put that table-layout fixed into an external stylesheet if you have one.
Sorry for the long explain, perhaps it needs a library ref because this is a case where IE always was "right" well maybe they weren't but it is the model that has been adopted by CSS too.
Suzy
first row it hits includes a rowspan ..
that rowspan should read colspan - it's important :)
this problem will always happen anytime there is a colspan that cannot compute its width properly from the following rows cells
(note this is where the 100% method sometimes used to force "auto" is going to fail in compliant browsers)
talk about relevant issues...
I've just finished debugging this same problem in a table that needed to compute a colspan based on a further colspan later in the table, the second colspan was the one that couldn't compute to the correct width so the first one just lost the plot and the whole layout blew up.
It didn't blow up in IE (strict or quirks), as it was being it's usual forgiving self, but then again the table in IE was also not the width it was supposed to be which was important as graphics were involved!
Suzy
While the code works, if the browser window is set to smaller than the width of the image, then IE crops the image rather than adding a scroll bar. This isn't really a problem for a header image, but is a problem where the content in the right hand panel needs its width (eg if it contains wide input boxes) - that content is also cropped. I've tried setting a minimum width, but IE seems to ignore it. Does anyone know a way around that?
