PDA

View Full Version : added padding w/td: doc type issue

Parsed Twice
03-23-2007, 12:45 PM
Wow! I finally figured out why I had some unwanted padding in a row of table cells I was working on ... on a whim I changed doctype and the mystery (and very, very annoying) padding was gone! This was after some time involved with troubleshooting both the html and css!

This was also only in Firefox and Opera which made it even more surprising!
Examples below:

Bottom padding added to the cells containing the weather images - this is with a xhtml strict doctype:
http://www.dreamscraps.com/tdpadstrict.html

Transitional doctype - no bottom padding in cells containing the weather images
http://www.dreamscraps.com/tdpadtrans.html

If you view in IE (only tested with IE6) you will see no difference.

Okay - my questions are:

Why?? This must be a bug considering that the table is unstyled (only border added to illustrate the effect) - there should be no problem rendering a normal table in any doctype or with any browser. True or false? Anyone actually know what the browser is thinking with the strict doctype to add that padding?

How?? I would really hate to ditch the strict doctype in order to simply render a normal table. Is there a way to fix this bug? I tried a few css values but nothing has been effective in eliminating the rogue padding so far.

Thanks for taking a look

PT
coothead
03-23-2007, 12:58 PM
Hi there Parsed Twice,

try it like this...
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<style type="text/css">
td {
border: 1px solid #000000;
}
td img {
display:block;
}
</style>

</head>
<body>

<table cellspacing="3" cellpadding="0" summary="contains 5 day forecast data - images, conditions, highs and lows">
<tr>
<td>M</td>
<td>T</td>
<td>W</td>
<td>Th</td>
<td>F</td>
</tr>

<tr>
<td><img src="http://www.ktbb.com/images/wx/smallthunder.gif" height="24" width="24" alt="Thunder" title="Thunder" /></td>
<td><img src="http://www.ktbb.com/images/wx/smallthunder.gif" height="24" width="24" alt="Thunder" title="Thunder" /></td>
<td><img src="http://www.ktbb.com/images/wx/smallthunder.gif" height="24" width="24" alt="Thunder" title="Thunder" /></td>
<td><img src="http://www.ktbb.com/images/wx/smallpartlycloudy.gif" height="24" width="24" alt="Partly Cloudy" title="Partly Cloudy" /></td>
<td><img src="http://www.ktbb.com/images/wx/smallpartlycloudy.gif" height="24" width="24" alt="Partly Cloudy" title="Partly Cloudy" /></td>
</tr>

<tr>
<td>70</td>
<td>68</td>
<td>72</td>
<td>78</td>
<td>68</td>
</tr>

<tr>
<td>55</td>
<td>62</td>
<td>58</td>
<td>55</td>
<td>48</td>
</tr>

</table>

</body>
</html>
Further reading:-
Eric A. Meyer article (http://devedge-temp.mozilla.org/viewsource/2002/img-table/)
coothead
Parsed Twice
03-23-2007, 02:06 PM
Excellent! So this was a known issue, even back in '02?

Well, thanks so much for the link and fix :)

PT
coothead
03-23-2007, 05:41 PM
No problem, you're welcome. ;)
Arbitrator
03-23-2007, 11:47 PM
Why?? This must be a bug considering that the table is unstyled (only border added to illustrate the effect) - there should be no problem rendering a normal table in any doctype or with any browser. True or false? Anyone actually know what the browser is thinking with the strict doctype to add that padding?Ideally, the DTD should have no effect on rendering in this manner. Modern browsers have quirks mode and standards modes though and render in one or the other according to DTD (or lack thereof). Some browsers, like Firefox, also have a third rendering mode—almost standards mode—that causes it to not quite comply with the standards. In this case, it doesn’t quite comply by removing the rendering “bug” to which you refer; it’s not a bug at all. Historically, people have used tables for layout, like jigsaw puzzles, and don’t understand the CSS inline box model (which coothead’s resource clarifies); Mozilla apparently thought that it was enough of an issue to add a third rendering mode and make the page display like the general, ignorant author expects and not according to the specs (which sounds (disgustingly) close to what Internet Explorer has a habit of doing).