IE CSS Bug - Disappearing borders

[timwhit]

Please take a look at this page in IE6: http://www.abanet.org/environ/home2.html

Notice that when you scroll over the lower modules/buckets (whatever you want to call them) on the page the left and right borders are disappearing. This does not happen in Firefox.

I searched for similar problems on Google for about 1/2 hour and found nothing conclusive.

Has anyone else witnessed this problem? Got any advise on how to fix it?

I can post code if anyone needs it.

 

[Will Rickards]

Weird thing is that if I alt tab between the two sometimes the borders come back. Seems to be if the page is scrolled to the bottom. I have the window restored, not maximized taking up most of the screen. Trying different resolutions it seems to be related to the scrolling. The loss of borders changes where it starts with the window size. I get the problem in the resources section and the publications section. It is really bad at 800x600.

 

[Will Rickards]

Try this

 

[Will Rickards]

Also might be the peekaboo bug

 

[Will Rickards]

Also some interesting in a bad way stuff from the validation results

Most notably using script language= instead of the correct script type="text/javascript"
Using document.write in a xhtml page

 

[timwhit]

Also might be the peekaboo bug

I think this page has the best information and the best fix.

The other fix from the other page is much more hackish, which is not good.

Thanks for finding this, Will!

 

[timwhit]

Also some interesting in a bad way stuff from the validation results

Most notably using script language= instead of the correct script type="text/javascript"
Using document.write in a xhtml page

There really isn't a lot I can do about this. I really only have control over the content on that page. I don't have control over the header, footer, the top part of the left navigation, or the CSS.

I gave the person that is in charge of the main CSS file the information about how to fix this error. He told me that it could be fixed by just removing the line: <div align="left">. That did not work, I explained that this is caused by a real bug in IE and that the "position: relative;" fix would work fine in this case. I have yet to hear back.

This is not the first thing that I have shown them how to fix in these CSS files.

Will, thanks for the help. It makes me look good at my job. Especially when this really isn't my responsibility to be fixing these kinds of errors. (Somebody needs to do it though)

 

[timwhit]

I got the webmaster to integrate the fix into the main css file. No more problems there.

I have a new problem though and I have been trying to fix it for a good while now. I figure if anyone can fix this, it is you guys.

If you open this page in Firefox you should notice that next to the link "brochure" on the upper right there is a little PDF icon.

Well, if you click on the link it will open a PDF file. The problem comes when you come back to this page and the PDF icon is gone. This doesn't happen in IE. The a:visited has a different color, but it is supposed to be inheriting the background that was imposed on it through the class, but it is not working.

This pdf icon is added to the link with a class:

.pdf {padding: 0 18px 0 0;
	background: transparent url(/images/icons/pdfsmall.gif) no-repeat 100% 50%;}

Here is the part of the css that tells anchors and links what to look like:

/** =Link Styles **/

a {text-decoration: none;
	color: #000099;
	background:inherit;}

a:link {}

a:visited {text-decoration: none;
	color: #990099;
	background:inherit;
	}

a:hover {color: #990000;
	text-decoration: underline;}

a:active {color: #ff0000;}

Any help would be greatly appreciated.

 

[Will Rickards]

The problem is your background: inherit on a:visited.
It's specifity is overriding the .pdf class rule.
But I don't think it is needed anyway as the a rule already has it.
So for an anchor (link) with a pdf class that is visited you will have the rules from all three of these applied.
a
a:visited
.pdf

 

[Will Rickards]

Meant to link to the rules for specifity and note that my order is a bit off.
First the rules for a are applied, specifity 1
then the rules for .pdf are applied, specifity 1
then the rules for a:visited are applied, specifity 2
if your rule had a.pdf as that would have a specifity of 2 as well it would take whatever was the last one in the css file and use that.

Confused yet?

 

[timwhit]

Damn you are right. I even tried this, but I just used an inline style to try to change this, but it was still picking up the inherit from the main style sheet. Stupid CSS is going to cause me to have a mental breakdown.

Thanks again Will.

 

[Will Rickards]

Also reading your post, I think your missing the point of inherit.
It is to inherit from the parent element, not another css rule.
In this case the li element.

 

[Will Rickards]

You know these posts make me sound like a css master or something when that really isn't the case. I hardly ever have to deal with this stuff. Most of my css is dead simple stuff, make this bold make that float. I don't even do fancy layout stuff, mostly tabular data and the like. It is just that the times it is screwy, I've had to figure it out by reading specs and sites by people much more experienced then me. This has given me some css troubleshooting skills. My authoring skills are not quite at that level though.

 

[Will Rickards]

then = than
specifity = specificity

 

[timwhit]

I just read up on inheritance a bit and now have a better understanding. I was under the impression before that it was inheriting from a not from whatever element on the page that it was under.

Will, since you are on such a role with fixing my problems maybe you want to try your hand at another one. I will be deeply indebted if you do.

This is somewhat similar to the last question. The icons are now working fine on one line links, but on two line links in IE6 the image become invisible. You can kind of see where it should go, but it is not there. It shows up just fine in FF.

Check out the link near the top of this page.

I am drawing a total blank about where to look for a solution to this problem.

 

[Will Rickards]

This is an interesting one.

Both browsers correctly honor your padding-right: 18px;
The problem is the coordinates of your background image are causing it to be clipped.
IE is putting your background on the first line not the second. Changing the '100% 50%' at the end of the background to 'bottom right' and increasing the padding-right to like 100px on .pdf and you can see what IE is doing. It is having major problems figuring out the coordinates for your background.
A value of 'right 75%' and padding-right of 45px fixes it in IE but the increased padding is bad on the other links.

Honestly I'd remove the BR from the markup and be done with it.
I would probably never nest a br in an inline tag. It might be allowed by the specifications but it is one of those difficult things for browsers to figure out. But just now I tested a line break caused by long text and sure enough same problem. So maybe br isn't so bad.

Actually this whole thing shows the problem with using background images where you want inline content. You probably want something like content:after here but I don't think that works in IE. So a javascript solution would be my suggestion. Something like

window.onload = window_load;

function window_load()
   {

   var arrLinks = document.getElementsByTagName('A');

   for ( var i = 0; i < arrLinks.length; i++ )
      {

      if ( arrLinks[i].className == 'pdf' )
         {

         arrLinks[i].innerHTML = arrLinks[i].innerHTML + '[img]http://www.abanet.org/images/icons/pdfsmall.gif[/img]'

         }

      }

   }

 

[timwhit]

Thanks for looking into it, Will.

I wouldn't normally break a link on purpose. I just did it on this page to serve as an example. On other pages where a link is too long for the line it breaks itself and then the icon image gets broken as IE is not smart enough to know where to place it.

I highly doubt that I would be able to do the javascript solution.

I would really like to get this working with the CSS solution, but maybe that is impossible at this point.

Got any other ideas?

 

[timwhit]

Where are Tannin and Buck? Aren't both of those guys supposed to be experts at this sort of stuff?

 

[Mercutio]

Tannin is sleeping and Buck is enjoying a delicious curry and some kind of German wood-grain beverage.

 

[Will Rickards]

My only other idea was to look for the article I saw on this technique of adding the images to links. I know I saw it somewhere but my google-fu failed at first attempt to locate it again. I know someone must have encountered this problem.

Anyway, this seems to work acceptably.

.pdf {
	display: inline-block; background: transparent url(http://www.abanet.org/images/icons/pdfsmall.gif) bottom right no-repeat; padding: 0px 18px 0px 0px;
}

 

[timwhit]

I'm home from work now, but I will try it first thing tomorrow morning to let you know if it works.

Thanks for the help, Will.

 

[Tannin]

Will seems to be doing fine. It's Friday. I'm stonkered. Not sure if my brain is in shape to code a "hello world" page right now.

(Tannin sees fragment of Javascript, promptly hides head under blankets and turns the light out.)

 

[Will Rickards]

For the record inline-block doesn't work in firefox, but then firefox ignores it. And when firefox supports it, it will still be fine. I know IE supports it. Not sure about the other browsers: opera, safari, etc.

 

[timwhit]

It is kind of working. It is pushing the icon out to the very right. Do you know if there is any way to force IE to put the icon in the same place that firefox does?

I can't make the change go live until later today, but here is a screenshot of what it looks like.

 

[Buck]

It is kind of working. It is pushing the icon out to the very right. Do you know if there is any way to force IE to put the icon in the same place that firefox does?

In my limited experience, the only way I can see it working in IE exactly as it works in FF is if you use a separate image tag instead of the CSS method.

 

[timwhit]

Buck might be right. I am still holding my breath for a hat trick from Will.

 

[Will Rickards]

No hat trick coming, the display inline is probably the best I could do. The problem is you have to support single line links and multiple line links. By treating them as a block but flowing them inline, yes the image does go the far right. I played around with floating the links and that showed promise but that also has to treat the link as a block to float it.

I much prefer the javascript solution. It is a progressive enhancement so people without javascript still have links.

Any other solution would have to muck with the markup perhaps enclosing the link in some containing inline element to which the background image could be applied. You do have a b element there. But this would make the image non-clickable which I think is more unacceptable than the inline-block.

 

[Will Rickards]

An example of messing with markup.
Padding is not that same in each browser and it requires the use of
I don't like it.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en-US" dir="ltr">
<head>
<title>Test</title>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="Content-Script-Type" content="text/javascript">
<style type="text/css">
a
   {
   font-weight: bold;
   padding: 0px 8px 0px 0px;
   }

span.pdf
   {
   background: transparent url(http://www.abanet.org/images/icons/pdfsmall.gif) bottom right no-repeat;
   padding: 0px 18px 0px 0px;
   }  
</style>
</head>
<body>




<a href="http://www.abanet.org/environ/committees/waterresources/newsletter/jun05/waterres0605.pdf">
Vol. 8, No. 3 - WILLWILLWILLWILLWILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL WILLWILLWILLWILL  June 2005
<span class="pdf"><span>
</a>
</p>



News from the Chair


[i]Ramsey L. Kropf[/i]
</p> 




<a href="http://www.abanet.org/environ/committees/waterresources/newsletter/jun05/waterres0605.pdf">
Vol. 8, No. 3 June 2005
<span class="pdf"><span>
</a>
</p>

</body>
</html>

 

[timwhit]

http://mezzoblue.com/presentations/2006/sxsw/css/q1.html

I guess someone else has finally addressed this problem as well.

Their solution is fairly similar to what Will came up with. The one change that I like is instead of placing the icon in the bottom right, this solution places it top right in IE. This works slightly better because most links will have a longer top line than bottom line.

The difference in code is done by changing bottom-right; to 100% 0;

In Firefox the icon still remains in the same place. IE is such is piece of shit it is amazing.