Why does Mozilla core display incorrect TR heights?

Question about Mozilla's table handling

[kcartlidge]

As I sometimes update my site at work where IE rules the roost, all my pages are designed initially for that.
However, at home I am using NS7, Opera and Pheonix, and am becoming more frustrated by the strange happenings with these browsers (I know Opera doesn't use any Mozilla code, but the others presumably do).

Rather than use table borders, I like to draw horizontal seperators using the following:

<TR height="1" bgcolor="black"><TD></TD></TR>

It's quite straightforward code. Sometimes there's a colspan, and sometimes I use HTML colour codes rather than names, but it makes no difference.

I can use the IDENTICAL code several times within the same table, and sometimes they render as single-height lines and sometimes they expand to around 5 or 6 pixels high. Nothing I seem to do creates consistency.

I have used copy & paste to guarantee nothing is different between each occurrence.

Is this a known 'feature'?

[Nick_W]

Not certain but, it may have something to do with the way these browsers handle images in tables and the "theoretical baseline" for inline elements.

If you have images in your table try doing this in your CSS and see what effect it has:

td img {
display: block;
}

It eleminates extra 'white space' by telling the browser to display all images in <td> tags as block level elements rather than inline.
It's the culprit for many a tables/images problem with the 'newer' browsers but, it's not a mistake.

Otherwise, (and a good idea anyway) specify a border on the td tags instead using a class like this:

.tdborder {
border-bottom: 2px solid #000000;
}

<td class="tdborder">blah</td>

I'm afraid I probably don't 100% get your problem but maybe the above will give some insight in how you might tackle it...

Good luck!

Nick

[jatar_k]

You can always use the old spacer tag trick. That was the way to get NN4.x to show empty cells.

<spacer type=block width=100 height=1>

moz always seems to like to make the lines bigger than IE but, it still works.

Nick's idea is more elegant and what I would recommend but this is another uglier way.

[tedster]

One of the issues here is that the <tr> element does not actually have a height attribute in the HTML spec. So, if a browser renders it at all, there is no standard it's "supposed to" apply.

Nick's direction is the way to go.

[piskie]

Try inserting a 1x1 pixel transparent spacer and nothing else in each cell in the row.

[g1smd]

Netscape requires that there must be something inside the table data, even if it is just:

<tr height="1" bgcolor="black"><td>&nbsp;</td></tr> or perhaps just a spacer.gif image.

[piskie]

If you use &nbsp; the minimum height will be set to the active font height.

A transparent image in each cell set to the required minimum tr height is the way to go.

[martinibuster]

IE rules at my client's site, too. But I still downloaded NN7 and NN4.7 and preview my work in there.

Of course, I also run it by the w3c validator to spot the coding mistakes that would cause it to render badly in Mozilla in the first place.

[kcartlidge]

Many thanks for all the comments.
I wasn't aware the 'height' attribute of TR wasn't standard. Now I am, I'll drop it and give NICK's suggestion a go. I always use style sheets anyway so it's no extra work.

G1SMD - You're right about the &nbsp; being used to ensure that there is *something* in the cell but as stated by PISKIE it does lead to rows rather deeper than 12 pixel.

I always find it amazing what I can learn even when I think you know what you're doing, so thanks again everyone.

[kcartlidge]

I've tried NICK's suggestion and it works great, thanks.

I must admit to still being unsure as to what the problem was as some occasions where I have used the EXACT SAME code to do a 1 pixel high TR as mentioned previously continue to work without needing changing (I'll do it anyway).

Ah, the vagaries of multi-browser support ...