Forum Moderators: not2easy

Message Too Old, No Replies

MAC Help pls - Gilder/Levin IR bug in Firefox on Mac?

"ghosting" of hidden test shows on hover

         

luispunchy

10:48 am on Feb 7, 2007 (gmt 0)

10+ Year Member



I am using the Gilder/Levin IR method (using an extra span to layer a background image over text, rather than hiding the text with visibility:hidden or text-indent: -5000px etc), but am being told that there is an odd bug of sorts in Firefox on Mac.

e.g.

HTML:
<li><span></span><a href="#">replace this text</a></h2

and CSS would be:
li a { width: 100px; height: 60px; position: relative;}
li a span { position: absolute; width: 100%; height: 100%; background-image: url(image.gif) no-repeat; }

That would be repeated for several links, for example. And then there's a "li a span:hover" rule that moves the background position by -60px to show the hover state. (using a behavior htc file so :hover pseudo class works in IE)

It is all valid and fairly straight-forward, and works in all Grade A browsers on Win and Mac, with one exception of Firefox on Mac.

I don't have a Mac (damn!) so I can't see this myself, but as it's been described, basically if you hover quickly between image-replaced elements, the replaced text for those respective elements actually appears on top of the last element you hovered over. I am not sure how else to describe it - like ghost text that shouldn't be there. Move to another IR image, and the ghost text appears on the last image you hovered over. It happens intermittently and only in FF on Mac, best as I can tell.

So I believe this is due to some CSS rendering issue in Firefox on the Mac. No basis for that other than the behavior as it's been described to me. Sounds like bad cleanup by the CSS rendering engine. The images are all cached at first page load, and I'm using the "sprite" image method (one image for all states, just moved via background-position), so it is not an image issue. I believe the problem is that fast hovering action on top of these images doesn't give Firefox's CSS rendering engine enough time to do it's thing on that hover event, and triggers the bug.

I checked my anchor styles' specificity, that seems to check out. I even gave the anchors a lower z-index that the spans that hold the background images. Didn't fix the bug.

Right now, my only remaining option appears to be falling back to another IR method, most likely Phark - though that fails on the CSS on / images off criteria I was hoping to achieve

Has anybody encountered a similar problem, and if so, any solutions?

luispunchy

11:06 pm on Feb 7, 2007 (gmt 0)

10+ Year Member



Nobody biting? Ok - here's more code.

Would-be Mac testers: Firefox 1.5 on Mac OS 10.4.8 is all I had access to for a limited time. But I'd like hear results for both Firefox 1.5 and Firefox 2.0. And running on the two most recent versions of OS X would be great.

I'm thinking this may be a Firefox/Mac bug related to CPU usage which could possibly affect the redraw of the anchor.

Anyway, here is a example which hopefully some Mac users can test for me in Firefox1.5 and FF2.0 - do you see the problem as I described in my original post above?

CSS:

<style type="text/css">
/* Zero out browser default margins and paddings */
* {
margin: 0;
padding: 0;
}

body {
font: small/1.2 Helvetica, Verdana, sans-serif;
margin: 20px 0 0 20px;
}

h1,h2,h3,h4,h5,h6,p { margin: .5em 0; }

ul { list-style:none;}

.clear { clear:both;}

.clearfix:after {
content: ".";
height: 0;
visibility: hidden;
display: block;
clear: both;
}

/* Example specific CSS */

#navUtility {
float: left;
width: 616px; /* images added up to 590px - prod = 592px*/
height: 24px;
padding: 0px 8px 0 100px;
background: #ccc;
}

#navUtility li {
float: left;
}

/* Gilder Levin IR */
#navUtility li a {
display: block;
overflow: hidden;
position: relative;
z-index: 1;
}

#navUtility #link1 a {
width: 86px;
height: 24px;
}

#navUtility #link2 a {
width: 114px;
height: 24px;
}

#navUtility #link3 a {
width: 60px;
height: 24px;
}

#navUtility #link4 a {
width: 93px;
height: 24px;
}

#navUtility #link5 a {
width: 105px;
height: 24px;
}

#navUtility #link6 a {
width: 156px;
height: 24px;
}

#link1 a em, #link2 a em, #link3 a em, #link4 a em, #link5 a em, #link6 a em {
position: absolute;
width:100%;
height: 100%;
cursor: pointer;
z-index: 100; /* Firefox/Mac IR fix */
}

#link1 a em { background: url(img/navUtility-link1.gif) no-repeat 0 0;}
#link2 a em { background: url(img/navUtility-link2.gif) no-repeat 0 0;}
#link3 a em { background: url(img/navUtility-link3.gif) no-repeat 0 0;}
#link4 a em { background: url(img/navUtility-link4.gif) no-repeat 0 0;}
#link5 a em { background: url(img/navUtility-link5.gif) no-repeat 0 0;}
#link6 a em { background: url(img/navUtility-link6.gif) no-repeat 0 0;}

#navUtility li:hover em { background-position: 0 -24px; }

#navMain {
float: left;
width: 990px;
background: #000 url(img/navMain-bar.gif) no-repeat;
}

#navMain li {
float: left;
position: relative;
overflow: hidden;
}

#navMain li a {
display: block;
}

#navMain li, #navMain li em { height: 33px; }

#navDest em, #navTravel em, #navTV em, #navVideos em, #navShare em, #navNews em, #navLogin em {
position: absolute;
width: 100%;
height: 100%;
top: 0; left: 0;
background: url(img/navMain-bar.gif) no-repeat;
cursor: pointer;
}

#navDest, #navDest em { width: 144px; }
#navDest em { background-position: 0 0; }
#navDest:hover em { background-position: 0 -33px;}

#navTravel, #navTravel em { width: 137px; }
#navTravel em { background-position: -144px 0; }
#navTravel:hover em { background-position: -144px -33px; }

#navTV, #navTV em { width: 122px; }
#navTV em { background-position: -281px 0; }
#navTV:hover em { background-position: -281px -33px; }

#navVideos, #navVideos em { width: 95px; }
#navVideos em { background-position: -403px 0; }
#navVideos:hover em { background-position: -403px -33px; }

#navShare, #navShare em { width: 93px; }
#navShare em { background-position: -498px 0; }
#navShare:hover em { background-position: -498px -33px; }

#navNews, #navNews em { width: 165px; padding-right:0px; margin-right:154px;}
#navNews em { background-position: -591px 0; }
#navNews:hover em { background-position: -591px -33px; }

#navLogin, #navLogin em { width: 80px; }
#navLogin em { background-position: -910px 0; }
#navLogin:hover em { background-position: -910px -33px; }

</style>
<!--[if IE ]>
<style type="text/css">
body { behavior: url(/htc/csshover.htc); }
.clearfix {height: 1%;}</style>
<![endif]-->

HTML:

<div class="clearfix">
<ul id="navUtility">
<li id="link1"><a href="#"><em></em>Link 1</a></li>
<li id="link2"><a href="#"><em></em>Link 2</a></li>
<li id="link3"><a href="#"><em></em>Link 3</a></li>
<li id="link4"><a href="#"><em></em>Link 4</a></li>
<li id="link5"><a href="#"><em></em>Link 5</a></li>
<li id="link6"><a href="#"><em></em>Link 6</a></li>
</ul>
</div>
<div id="navMain">
<ul>
<li id="navDest"><a href="#"><em></em>Destinations</a></li>
<li id="navTravel"><a href="#"><em></em>Travel Ideas</a></li>
<li id="navTV"><a href="#"><em></em>TV Shows</a></li>
<li id="navVideos"><a href="#"><em></em>Videos</a></li>
<li id="navShare"><a href="#"><em></em>Share</a></li>
<li id="navNews"><a href="#"><em></em>News &amp; Weather</a></li>
<li id="navLogin"><a href="#"><em></em>Login</a></li>
</ul>
</div>

Wiggle your mouse quickly between and hovering over the navigational links. Does any "ghost" text appear, i.e. the image-replaced text briefly/sporadically appears on top of the absolute inline element?

[edited by: SuzyUK at 6:10 pm (utc) on Feb. 17, 2007]
[edit reason] snipped URLs [/edit]

SuzyUK

6:12 pm on Feb 17, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



*bump*

Some MAC testers would be appreciated,
and luispunchy has some more code samples to follow

thanks
Suzy

cmarshall

8:37 pm on Feb 17, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I actually have a special XHTML and a PHP file that I use *specifically* for testing WebmasterWorld snippets. I can access these from all 14 different test browsers I use (although I'm usually lazy, and just use Mac FF).

I did test, and I don't see the problem.

Of course, I always encase my tests in the evil XHTML 1.1 DOCTYPE...

encyclo

9:18 pm on Feb 17, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



> I always encase my tests in the evil XHTML 1.1 DOCTYPE...

Good question, though - the XHTML 1.1 doctype triggers standards-compliance mode - so what doctype are you using?

cmarshall

9:28 pm on Feb 17, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



If you want, you can always send me a URI by PM to look at.