|IE stretches cell height despite height="" attributes|
IE is being crazy (firefox is alright)
| 1:33 pm on Jan 6, 2006 (gmt 0)|
I'm currently adapting an old website. Unfortunately, the design is mostly in tables, but I'm not going to change that now. The table looks like this:
<td class="main-menu-1" width="133" height="107">
(first part of the main menu)
<td class="sub-menu" width="133" rowspan="3">
(a submenu, has plenty of space)
<td id="content" class="content" rowspan="4" width="355">
(the content, can be short or very, very long)
<td width="109" bgcolor="#181249">
(empty box in the top-right corner)
<td class="main-menu-2" width="133" height="107">
(second part of the main menu)
<td rowspan="2" width="109">
(double-row picture in the right-most column)
<td class="main-menu-3" width="133" height="77">
(third part of the main menu)
(the box that should vary in height so the left column's height matches that of the content)
(the box that should vary in height so the right-most column's height matches that of the content)
In reality it's a lot bigger and more awful that this (I cut quite a lot for readability). However, the varying height of the bottom-left and bottom-right cells works perfectly in Firefox. however, it doesn't work in IE; it stretches all the menu cells that are supposed to have a fixed height.
So why doesn't IE respect those fixed heights? Why does it stretch everything? And most importantly, how can I get it to do what I want?
| 9:08 pm on Jan 6, 2006 (gmt 0)|
There's a lot to say on this topic -- most of all that height and width are deprecated as attributes for <td>. And even before they were deprecated, they were classed as "recommendations" to the browser, and not absolute rules.
If I were trying to adapt that layout, I would not use separate <td> sections for the parts you need to see next to each other vertically -- I would have them all flow within one <td> that uses style="vertical-align:top;".
| 4:43 pm on Jan 21, 2006 (gmt 0)|
ok, but why IE doesn't respect CSS declaration of td height. this attribute is deprecated in CSS too?
| 5:17 pm on Jan 21, 2006 (gmt 0)|
No, CSS is the way to state a height rule for a td. However, IE renders the table according to its own internal "logic" anyway.
I think you'll need to rethink the page layout. Instead of using separate table cells for each menu item, you might just flow the menu areas vertically within one cell. This would not open you up to this IE behavior. The cell heights get averaged out and IE ignores your height rules, even in standards mode.
Unfortunately, your "submenu" cell throws a spanner into the works for this on-big-cell approach, too. If you really need the bottom right content to span the width of both cells (as in the current layout) then I'm at a loss. If you don't, I'd just go with four long cells that are each vertical-align:top
| 5:00 am on Jan 22, 2006 (gmt 0)|
Tables are very tricky (especially if using an editor, like DreamWeaver or FrontPage). You'd think they would make it easier, but you'd be wrong.
With IE, try to work out a plan for the table from the beginning. For instance, know the width and height of the ENTIRE table. Then, break your cells down accordingly. Don't forget about cell spacing and padding. If every value is accounted for, you'll notice much better results. BUT, the key is to NEVER have a cell or table without width and height defined (even if you have to enter '0').
If all your math adds up, IE will see this as "logical" and use what you've set forward. Of course, you have to make sure the content of the table will fit within the slots you've assigned.
| 9:25 pm on Jan 22, 2006 (gmt 0)|
The problem was that there was no way to know or calculate the height of the content in advance, and therefore no way to know the height of the bottom-left cell either. And splitting the bottom-left cell in two (one for the menus column and one for the submenu column) doesn't work either, because sometimes there needs to be a cell with a picture in it above it, and below the menu+submenu column. The picture spans both columns.
But the html code, and the xslt that generates it, is really ugly. But it was ugly before I started working on it, so I'm happy that my next project is a much more thorough redesign, and a real webdesigner wrote some really nice and clean html+css for me. Even less time to do it, but after this last project, I'm getting the impression that sometimes starting over completely can actually save time.