tags:

views:

97

answers:

4

I have a table with an image inside:

<table style="border: 3px solid rgb(0, 0, 0); width: 800px; background-color: rgb(255, 255, 255); margin-left: auto; margin-right: auto; border-collapse: collapse;">
 <tbody>
  <tr>
   <td style="text-align: center; padding: 0px; margin: 0px;"><img style="width: 800px; height: 200px; border: 0px;" alt="Logo" src="logo.png">
   </td>
  </tr>
 </tbody>
</table>

No matter what I do, there is still a little sliver of white at the bottom of the image. A quick check with Chrome's Inspector reveals that the td has a height of 204px!

How can I force the td to be the same height as the image?

As you can see above, I've tried all sorts of things...

A: 

You'll live a far happier life if you give up the idea that you can create pixel-perfect layouts with HTML.

If you really need pixel precision, you might try tossing the table and using absolute positioning via CSS instead.

Hank Gay
Isn't there some way to do this? This is Chrome, not even IE!
George Edison
Of course there is. It's no problem to create pixel-perfect layouts in HTML, you just have to know how.
Pekka
Not really, no. Differences between browsers make it all but impossible, and HTML (especially `table`, which is intended for tabular data, not layout) was never intended to provide that level of control. Instead, it's supposed to allow the user agent to display pages in a way that makes sense in a particular context (mobile vs. desktop, for instance).You can *usually* beat a given page into submission, but it is never as easy as people coming from a desktop app background would expect.
Hank Gay
So go with a `div` then?
George Edison
@Hank the beating into submission part I agree with - it's often bizarrely hard work, and a process of trial and error.
Pekka
+3  A: 

Solution: Add "vertical-align:bottom;" to the image style.
Another solution, not always suitable, is to change the image display type to block, instead of it's original inline display type.
Explanation: The problem occurs due to the automatic behavior of browsers that add a space under the text for characters that are longer than usual. The image is an inline object like text, thus it has a space underneath too.
A great explanation is written in quirksmode.org:

Complication: almost strict mode

In the early days, experiments with strict mode invariably raised the comment that images suddenly got an odd bottom margin that couldn’t be removed. The cause was that in strict mode is an inline element, which means that some space should be reserved for possible descender characters like g, j, or q. Of course an image doesn’t have descender characters, so the space was never used, but it still had to be reserved.

The solution was to explicitly declare images block level elements: img {display: block}.

Nonetheless browser vendors, Mozilla especially, thought this was such a confusing situation that they introduced "almost strict mode". This was defined as strict mode, but with images continuing to be blocks, and not inline elements.

Most common doctypes, including the one I use, trigger almost strict mode. The treatment of images is by far the most important difference between almost strict mode and really strict mode.

Generally you should use a CSS reset document that avoids problems such as this one.

Dor
You're a genius! That worked perfectly.
George Edison
A: 

table { table-layout:fixed; }

luca
That didn't work.
George Edison
have you also added <td style="width:200px" ?
luca
A: 

It's 200px tall for me. Can you post an online example?

If it's 4 pixels difference, I'm pretty sure the culprit is what used to be the cellspacing and cellpadding HTML attributes. Can you try setting those to 0 just to see whether it works? The CSS equivalent to that might be border-spacing but I can't try out because it works for me.

Pekka
No, unfortunately neither the CSS `border-spacing` nor the `cellspacing` and `cellpadding` attributes work.
George Edison
What browser are you using? I'm testing this on Chrome.
George Edison
@George yup, @Dor got it solved. Nice!
Pekka
@George I tested it on Chrome as well but with an image that wouldn't load - which seems to behave differently than one that does.
Pekka