CSS adding extra padding to bottom of images with hot links!?!

[suess0r]

Hello,

I am having issues with my CSS as far as when I have sliced images that are converted into tables they are tending to add extra padding around the bottom of the image (only when it's a hot link)..

For instance, if I slice the images and put the table on the page and don't have any links to anything on the images it looks fine how it should. BUT, when I make one of the images a link to another page it adds an additional padding to the bottom. I've been all through my CSS to find out why?! and i just can't figure it out, can anyone see anythign blatent that I'm missing? I am aware that tables have a default of padding of 2px, but like I said when the image is not a link it looks perfect. Thanks for the help!?

Here is my CSS file...

[quote]/* standard elements */
* {
margin: 0;
padding: 0;
}
a {
color: #0a52db;
text-decoration: none;
border-bottom:1px dotted 0a52db;
}
a:hover {color: #9A6;}
body {
background: #655A46 url(images/bluebg.jpg) repeat-y center top;
color: #333;
font: normal 62.5% "Lucida Sans Unicode",sans-serif;
}

input {
color: #555;
font: normal 1.1em "Lucida Sans Unicode",sans-serif;
}
p,cite,code,ul {
font-size: 1.2em;
}
ul {margin-left: 1.2em;}
h1 {font-size: 1.4em;}
blockquote {
background: #FFF;
color: #333;
display: block;
font-size: 0.9em;

}
blockquote p {padding: 3px 0;}
h1,h2,h3 {color: #654;}

/* misc */
.clearer {clear: both;}

/* structure */
.container {
background: url(images/bgcontainer.gif) repeat-y;
margin: 0 auto;
width: 702px;
}

/* top */
.top {
background: #0a52db;
font: normal 2.4em Verdana,sans-serif;
height: 60px;
margin: 0 auto;
width: 630px;
}
.top a {
color: #FFF;
display: block;
line-height: 60px;
text-decoration: none;
width: 100%;
}
.top span {padding-left: 24px;}
.top a:hover {
background: #688B00;
color: #FFF;
}

/* header */
.header {
background: url(images/headersmaller.gif) no-repeat;
height: 107px;
margin: 0 auto;
width: 630px;
}

/* item */
.item {clear: both;}
.item .date {
background: url(images/bluebgdate.gif) no-repeat;
color: #ffffff;
float: left;
height: 40px;
text-align: center;
width: 36px;
}
.item .date div {padding-top: 4px;}
.item .date span {font: normal 1.6em serif;}
.item .content {
float: left;
width: 420px;
}
.item h1 {
background: #0a52db;
color: #FFF;
line-height: 40px;
padding-left: 16px;
}
.item .body {padding: 12px 18px;}

/* main */
.main {float: left;}

/* navigation */
.navigation {
float: left;
margin-left: 1px;
width: 208px;
}
.navigation h1 {
background: #0a52db;
color: #FFF;
font-size: 1.3em;
line-height: 40px;
padding-left: 12px;
}
.navigation ul {margin: 0; padding: 0;}
.navigation li {
border-bottom: 1px dotted #D5E8AD;
list-style: none;
}
.navigation li a {
background: #E8F6BF url(images/bluebgnavigation.jpg) repeat-x;
color: #553;
display: block;
padding: 8px 4px 8px 12px;
text-decoration: none;
}
.navigation li a:hover {
background: #F0FFC6;
color: #553;
}

/* footer */
.footer {
background: url(images/bluebgfooter.jpg) repeat-x;
color: #FFF;
font-size: 1.1em;
line-height: 40px;
margin: 0 auto;
text-align: center;
width: 626px;
}
.footer a {color: #FFF;}
.footer a:hover {color: #FAFCB0;}
[/quote]

[obsidian]

Do you have a link where we could play a bit with it?

Right off, I'd say to check that you don't have any unnatural spaces in your markup. IE tends to interpret white space in markup a bit unusually. Also, make sure that your border-bottom on your anchors aren't causing you a problem when applied to your img tags. One extra precaution: I would recommend you make sure you have the border="0" attribute on your images within your markup and let you CSS take control over any borders you want added.

Could you report on what browsers you've tested in, etc?

[suess0r]

Thanks obsidian,

I have added border="0" on the markup, I will give you links so you can see exactly what i mean...

the actual table of images can be found here:
http://www.myclub411.com/customside.php
(here you can see what it looks like with no CSS and the table looks fine)

I use an include and pull it in to my custom page and this is where it gets chopped up..
http://www.myclub411.com/custom.php

I have tested it in 3 browsers: ie7 = it doesn't chop it up, but safari & firefox are what im' having main issues with. (and being a Mac based company, this is becoming a problem) ;x

let me know if i can provide any more information!

[obsidian]

OK, the first big problem I ran into is that your top navigation table and your other table that's having problems are [b]both[/b] sharing the same ID ("Table_01")... This will throw you off big time with CSS. An unique ID should only be used once per page.

[suess0r]

OK good point, I changed the table id on the side bar to Table_side and again, i'm still having those issues ;x any other suggestions?

[obsidian]

The only other thing I can really think to try right off (after playing with your CSS through the FF web developer toolbar) is to get rid of the unnecessary space within your td tags. For instance:
[code]
<!-- Change this -->
<td>
  <a href="#"><img src="" /></a></td>

<!-- To this -->
<td><a href="#"><img src="" /></a></td>
[/code]

Anywhere you see that there may be interpreted space, get rid of it. Otherwise, I'm really not sure what would be giving you this much grief.

[jcombs_31]

I've had the bottom padding issue in firefox before.  From what I remember, add display:block to the image.

[dbrimlow]

[quote author=jcombs_31 link=topic=123524.msg511270#msg511270 date=1169556051]
I've had the bottom padding issue in firefox before.  From what I remember, add display:block to the image.
[/quote]

Arbitrarily using a block level item for layout correction is a VERY bad idea. jcombs_31 was very lucky that the layout most likely needed the block level item. Stay away from display:block unless you know how and where to use it.

obsidian is 100% correct ... NEVER use a blank source tag <img src="" /> . This will totally mess with your layout - and will do it randomly without logical rhyme or reason; and will be virtually impossible to troubleshoot in your css. (I actually had this dynamically creating blank rows in an interactive database table insert!)

Remember the rule of CORRECT css coding:

1. if it works in FF, Opera and/or Safari, but not in IE 6 or below ... the css and mark-up is 100% correct ... you need to add proper hacs to your css.

2. if it works in any, every and all IEs but NOT in FF, Opera and/or Safari ... there's a bug in your code or markup. Period.

3. if it works in every browser in the world, but not IE 7 ... the css and markup is perfect, the hacks work like a charm and you are a master ... you NOW need to make a seperate ie 7 only css AND put a conditional comment link to it in your head tag (welcome to what it was like during the browser wars ... gee, thanks again MS!).

[jcombs_31]

[quote]
Arbitrarily using a block level item for layout correction is a VERY bad idea. jcombs_31 was very lucky that the layout most likely needed the block level item. Stay away from display:block unless you know how and where to use it.
[/quote]

I'd like to know where you pulled that from.  I didn't arbitrarily use anything.  I used it because it solved the exact problem I had.  Changing something to block or inline is bad in what way, because it acheives a different effect?

[quote]

Remember the rule of CORRECT css coding:

1. if it works in FF, Opera and/or Safari, but not in IE 6 or below ... the css and mark-up is 100% correct ... you need to add proper hacs to your css.

2. if it works in any, every and all IEs but NOT in FF, Opera and/or Safari ... there's a bug in your code or markup. Period.

3. if it works in every browser in the world, but not IE 7 ... the css and markup is perfect, the hacks work like a charm and you are a master ... you NOW need to make a seperate ie 7 only css AND put a conditional comment link to it in your head tag (welcome to what it was like during the browser wars ... gee, thanks again MS!).


[/quote]

[obsidian]

I agree with jcombs on this one in this respect: when it comes down to it, sometimes you just have to go with what works in CSS. Yes, you do need to have an underlying knowledge of what all the different attributes do, or else you wouldn't know to try some variants in the first place, but if it works as a display: block, why oppose it?

Block vs. inline displays are about the least of things to worry about for a user to pull out of the air because their effects are so incredibly obvious in most cases. Also, I challenge your #3 "rule of CORRECT CSS coding" above: even with the differences posed in IE7, you shouldn't have to use conditional comments to get your layout to look right. If you've built your site well and your CSS is solidly working in IE6, FF, Opera, etc., it really doesn't take that much reworking to get it to display well in IE7, either. Sure, there are a couple little issues, but nothing that can't be worked out in the markup and CSS side of things without overburdening someone with the need to learn conditional comments on top of everything else.

[ToonMariner]

[quote author=dbrimlow link=topic=123524.msg512528#msg512528 date=1169664959]

Remember the rule of CORRECT css coding:

1. if it works in FF, Opera and/or Safari, but not in IE 6 or below ... the css and mark-up is 100% correct ... you need to add proper hacs to your css.

2. if it works in any, every and all IEs but NOT in FF, Opera and/or Safari ... there's a bug in your code or markup. Period.

3. if it works in every browser in the world, but not IE 7 ... the css and markup is perfect, the hacks work like a charm and you are a master ... you NOW need to make a seperate ie 7 only css AND put a conditional comment link to it in your head tag (welcome to what it was like during the browser wars ... gee, thanks again MS!).


[/quote]

Designing a site that has the same fell cross-browser is not neccessarily dependant on writing css and then adding hacks/additional css for IE.

All the factors come into play - one most commonly overlooked is the use of strict doctype declarations.  If you design your html with the problems of teh box model in mind you can erradicate the need for css hacks or even separate style sheets.  I have not had to do so on any site I  have worked on in a long time.

[dbrimlow]

[quote]I'd like to know where you pulled that from.  I didn't arbitrarily use anything.  I used it because it solved the exact problem I had.  Changing something to block or inline is bad in what way, because it acheives a different effect?[/quote]

I never said changing something to block or inline is bad. I said arbitariliy using display:block is a "bad idea". And, yes, I apologize if I assumed you did your fix arbitrarily. But telling him to use display:block without knowing how it was in relation to its parent block/box appeared to me to be arbitrary.

A "block" positioning in use for layout of non-block elements will cause its position to be controlled by its container block. And its position inheritence is different if you have it within a float, absolute or relative parent and any relative margins, paddings, height, width, borders and even within other block items like list items block quotes, etc. ... and they can all of have a different effect, in different browsers.

Just saying use "display:block" without knowing the parent container block, margins, paddings, borders IS A BAD IDEA.

"The margin box of a table, a block-level replaced element, or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space."

SO. Again my point was, by all means use display:block ... but KNOW why, when and how it should be used.


[quote]Also, I challenge your #3 "rule of CORRECT CSS coding" above: even with the differences posed in IE7, you shouldn't have to use conditional comments to get your layout to look right. If you've built your site well and your CSS is solidly working in IE6, FF, Opera, etc., it really doesn't take that much reworking to get it to display well in IE7, either.[/quote]

True ... if you don't include IE 5.x for PC and Mac and 5.5. These REQUIRE proper hacks to make them behave.

So, consider that I said if your layout looks perfect in every browser in the world except IE7. That would include IE 5.x and 5.5 and 5.x for mac - therefore, that also assumes there are hacks in place to make the old IEs work (and if some of you don't think you need hacks for css layouts in IE 5.x, 5.5 and 5.x for mac ... then you never saw your layout in those browsers without hacks ... it's frightening!)

But, in IE 7 a number of CSS hacks that rely on IEwin's failure to support certain advanced selectors will be failing, because IE7 supports those selectors. And while this IS a good thing overall in the quest for IE standards, it will play havok with those css that already have the hacks there for IE 5.x, 5.5 and 5.x for mac.  So the simple solution is to write a seperate IE 7 css to replace those elements that the hacks tell IE to use and put an <!-- if IE 7 ...> cond-com link to it; because you cannot remove the hacks and expect it to work in 5.x and/or 5.5.

When you have either a few or a few hundred pre-existing pages that work with hacks, you want to tell it to work with IE 7.

I know it sounds more complicated than it should be, but many of us still get plenty of old IE versions showing up in our stats. And until they drop off to infrequent, many business webmasters still allow for them.