|
Author:
There probably isn't anything more frustrating than to get your web pages working in the major browsers and then an upgrade comes out, and boom, your pages no longer work. Things should get better as the browser vendors develop browsers that are W3C standards compliant and designers code to these standards, but until then we web designers will have to deal with it. We will also have to deal with that fact that some browsers are becoming standards compliant but do not totally support the entire standard....
That is exactly what happen to me. I have pages that used "sliced" images put back together with a table. If there is no cellpadding and cellspacing and no spacing between the tags in the table, the sliced images make up one big image. This technique is used on big images that would load slow. This way, the viewer gets to see the image being built instead of just waiting. The sliced images had no problems until NS6 came out. Not only do sliced images have a problem in NS6 but so do pages that use "spacer gifs" in a table. The problem is that a gap appears below each table row. If you have a line that is set to a particular height using a spacer gif, the line will be higher than what you intended when viewed in NS6.
Below are examples of what I am talking about (I have recreated the problem using HTML so that viewers using IE can see what the problem is, if you look at the code there is an extra row in the sliced image table and the spacer gif is set at 5 pixels but pretending that the spacer gif is 1 pixel):
![]() | ![]() |
![]() | ![]() |
Basically, the problem is a result of NS6 supporting the standard which says an image is an in-line element, thus there is a baseline to which the bottom of the image lines up with.....creating the gap. The documentation on Netscape's Browser Central goes on to say if you don't include a DOCTYPE for XHTML (with some other detail that I am leaving out in this article) the problem won't occur. Of course THAT is not a good solution. The documentation on NS has a couple of CSS workarounds but I like this one because it does not mess up tables with text in them.
Add to CSS:
tr.decoration img {display: block;}
The css code says any IMAGE that is a DESCENDANT of a TABLE ROW which has a CLASS of DECORATION will be displayed as a block element instead of an in-line element. Then there is no baseline and the table cell will be only as big as the image within it.
Add to the TR tags:
<tr class="decoration">
Viola!!! Cool huh!?!
(And these examples really are set using the CSS code to fix the problem. They will appear correctly in any browser.)
![]() | ![]() |
![]() | ![]() |