html/css query

[helenic]

I'm trying to add an element to an existing webpage - www.lapada.org. On their Fairs and Exhibitions page, I need to add four subsections inbetween the "LAPADA Fairs" heading and the main text. The new sections should look like this.

I've coded these subsections such that they work in IE. In Firefox, I have what looks like a 5 pixel gap underneath each image. According to Firebug, the gap is inside the 'imagecell' td, but it shouldn't be there, and I can't find a way of removing it.

When I insert this code into the existing LAPADA page, this gap underneath each image disappears. Fine. But there's a worse problem: a similar gap to the right hand side of either the title or textbox td, causing these cells to be wider than the image between them, and making the fixed-width background of the textbox td start to repeat on the right hand side. This problem exists in both Firefox and IE. Because this space doesn't exist when the code is taken out of context, I'm assuming it's some existing piece of styling on the LAPADA website interfering with the new sections. But I can't work out what could be causing it.

The existing LAPADA page with my new sections added to it can be seen here.

Can anyone advise me on
a) how to get rid of the horizontal gap in this page? (because I don't know what's causing it, and it's bugging me)
b) how to get rid of the extra space on the right hand side of each column in this page?

Comments

[chaosdeathfish.livejournal.com]

This block:

div.category img {
float:left;
margin-right:5px;
}

in main.css is causing the 5-pixel margin.

[libellum.livejournal.com]

You are awesome! Thankyou so much :)

{inherit: none;} wasn't helping, so I've ended up just deleting the margin-right:5px line, on the grounds that doing so doesn't result in any obvious changes to the page. Here's hoping :/

Gah, I hate working with other people's code...

[hairyears.livejournal.com]

Looks fine in Opera.

[deliberateblank.livejournal.com]

The white gap in the standalone page goes away if you say:

.faf-image {
    vertical-align: top;
}

Therefore I believe it is due to fighting between the text (  in the central divider) and the image. (vertical-align is one of the non-inherited CSS properties, so can do weird things from time to time, as well as being slightly counter-intuitive in itself. Firefox has a lot of built-in rules for it, especially for table elements, which can interfere too.)

[deliberateblank.livejournal.com]

Now that I've applied the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=306340 I can work out a fuller answer :-)

FF's default built-in CSS rules give TBODY vertical-align: middle, and TR and TD get vertical-align: inherit. IMG by default gets nothing, so it doesn't inherit its parent's vertical-align, instead resetting to its non-inherited default of baseline. (The v-a you've placed on TABLE probably does very little for this reason...)

The text of your middle divider (the  ) is the normal content of a TD, not a separate element, therefore the TD rule above applies and it is v-a: middle. The IMGs on either side use v-a: baseline.

vertical-align doesn't mean "make this element go to here relative to its container". Instead it means "pick this point on this element as the vertical-align anchor point. Make sure the anchor points of all elements in this horizontal span are at the same vertical position".

Hence the baseline of the IMG (which is the same as its bounding box bottom) must be at the same position as the middle (which is half way between the x-height and baseline of the font) which requires the text to be pushed down, incresing the vertical extent of the parent table row. The gap you see ought to be the size of the font descender height plus half the baseline to x-height distance - looks a little less to my eye but I think the reasoning is close.

The reason the full page version doesn't do this is because of the rule "div.category img { float: left }". The float forces the IMGs to become block-level elements instead of inline elements, and that takes them out of the vertical-align calculation. So you're not seeing the rendering error because of a fortuitous cascade error ;-)