IE7 measuring sprites from bottom up?

I’m doing some IE7 hacking and was wondering what was going on with some of my sprites. They look fine in all of the browsers except IE7. For that lovely browser, I say with my teeth clinched, I’m getting really strange results. At first I thought it was a hasLayout issue, that I needed to do some messing around with the position:relative, or that it just didn’t like me.

However, while doing some troubleshooting, it looks like, please tell me I’m wrong, lE7 is measuring the sprite from the bottom up instead of the bottom down.

Here’s an example on Yahoo! Tech. You should see in the top product header 4 out of 5 blue stars for Pro Reviews and 5 out of 5 red stars for User Reviews. In IE7b, there are tiny nubbins from the tips of stars.

Here’s the background image (.png) for the pro stars and the normal CSS for 4/5 stars:

.bigprostars4 span {width:100px; height:20px; top:0; background:url(/images/bg-pro-ratings.png) no-repeat 0 -50px;}

I began looking at the numbers, thinking they were off by a few pixels. After doing some testing of the positions, I realized that it was not measuring 50px down from the top, as other browsers handle sprites, but starting at the bottom of the image and measuring 50px up! Hence, displaying the tips of the small stars.

To fix this I added this style to the IE7.css (currently not live!) file:
.bigprostars4 span {width:100px; height:20px; top:0; background-position: 0 -400px;}

This is not a small issue. If you use sprites as extensively as I do, this involves opening every image and re-calculating the distance from the bottom up and inserting these numbers in an IE7 only style sheet. Please, please tell me that I need to get another cup of coffee and I’m just dreaming this.

Update (05-02): Is this a position:absolute issue in IE7?

I’m still seeing this bizarre activity in the sprites of absolutely positioned elements. The sprites of links and other objects that are not positioned are working fine. sigh…

Update: IE7 passes sprite test (05-07)

I’ve created a test page to see if I could narrow down the issues with IE7 and sprites. I was surprised to find IE7 passed my initial tests. It must be a unique combination of styles causing my problem.

Image replacement and screenreaders

Ok kids, if you use image replacement to create super-cool rollover buttons, raise your hands. Good. Now, keep your hands raised if you put title attributes on the links to give added information. Great! What is the text inside the link? Keep your hands raised if you repeated your title attribute in the link text.

Congratulations, you’ve probably done some usability testing with an actual screen reader.

For those who put your hands down; here’s the deal-eeo. Screenreaders ignore title attributes by default. Sucks… I know. I’ve been adding really juicy title attributes for usability and they’re being ignored!

Go ahead and duplicate your text

I was doing some user-testing today with Victor Tsaran, the Accessibility Project Manager at Yahoo! He came across a button with link text that was the same as the image. He said, “what’s this going to do?” It was a simple thing like “more info”… But the title attribute said “Visit Joe’s Web Site for more information.” That, he suggested, should have been the link text.

The link text is hidden from the visual users and the title attribute is hidden from the screen readers; so duplicating the information isn’t a bad thing. If you find yourself putting good information in a title attribute for a link that is using image replacement, duplicate the content in the link. It’s that simple. Now, put your hands down, it’s starting to smell musky around here.

Control form button width in IE6

I’m working on a project with shiny, happy submit buttons all over the place. To offer more control over the presentation, we are using the form button element and inserting images inside the button tags.

...

Now, you need to over-ride some pretty ugly default presentation styles:


form button {padding:0; margin:0; border:none; background:0;}

This works fine and dandy until you get to IE6. The buttons tend to get really large with IE. So, you need to re-define the width of the buttons and apply overflow:visible. Here’s the entry in your IE6.css file:

form button {width:1%; overflow:visible;}

Resources

Special thanks to Jehiah Czebotar for saving me a bunch of time trying to figure this out.

Get rid of the dotted lines on links with image replacement

Update 2-26-2014

This is obviously an outdated article. Please do not follow the older advice on using outline:none and hiding focus. We need to provide some visual cue that a user has placed their focus on a link or button via the keyboard. The key is not to hide focus, rather to avoid generating the marching ants that went off screen with older methods of image replacement. The key is hide the text while not pushing it off-screen. Thierry Koblentz’s article Clip your hidden content for better accessibility is the gold standard on using hidden text while avoiding the off-screen outlines and making your site global-ready.

If you do decide to use outline:none, you must make sure that you re-define the focus style. This is normally done by duplicating the :hover style

:hover, :focus, :active {
    text-decoration:underline;
}

Original post

I don’t remember where I first found this tip (Hedger Wang?), but it’s a good one. If you are using image replacement, i.e. background images and negative text-indent, you may notice a dotted line appear when the link is clicked and waiting for the page to change (:focus). It’s outlining the text that happens to be wayyyyy off screen. It’s easy as pie to fix this issue.

CSS Fix

This will fix the problem in Firefox. Just drop this into your global.css file.

a:focus {
    -moz-outline-style: none;
}/*this avoids having image replacement sections display a dotted outline*/

JavaScript Fix

This will fix the issue in the other browsers.

var theahrefs = document.getElementsByTagName('a');
//fix dotted line thing when link is OnClicked
for(var x=0;x!=theahrefs.length;x++){
    theahrefs[x].onfocus = function stopLinkFocus(){this.hideFocus=true;};
}

Hacking to fix for IE7

I’ve played around with IE7 for a while, but haven’t really started debugging with it until now. Fortunately, I’ve already set up the site to use conditional comments and deliver an IE6.css file and a separate IE7.css file. This has made it much easier to target the offending areas of the site.

IE7 has had a couple surprising problems for me. I have a topnav section that completely disappeared. The container div only has position:relative and inside are a number of floated elements. This actuall works great in all browsers… but IE7! No hacks for IE6, but hack for IE7! I went with the old adage, I think from Andy Budd, when all else fails float, if it’s already floated, unfloat. I added float:left to the container div and the topnav re-appeared from the IE7 void.

Munged Background Images

I’m using a series of positioning, text-indent, and background images on the site. Here’s a simplified version:


.targetdl dd {position:relative;}
.targetdl dd span {text-indent:-1000em; width:66px; display:block; position:absolute; top:5px; right:20px;}
.happy0 span {background:url(/images/happy0.png) no-repeat 0 -650px;}

IE7 shows the background image ok on some pages and on other pages, it shrinks the background image. I tried adding zoom:1 and font-size:100% to no avail. I’ll try line-height next. This is an odd bug, but not the first time I noticed it on IE7 betas. It certainly seems to be buggy with positioning.

De-bugging Strategy

Since I’ve already got a fairly solid ie6.css file, I’m going to use that as the basis of my IE7 CSS construction. After fixing the topnav, the rest of the ie6.css file is going into the IE7 css and rules will be removed one at a time. This should help me figure out what is still needed.

I’ll keep notes on this site as I find it a convenient place to remember them. Has anyone else come across some positioning bugs in IE7? Sorry, no screen shots or details at this time, we’re still pre-alpha stage.