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.

Add a conditional comment with XSL

This is probably one of those posts that I’ll use a million times and everyone else will say… that’s nice. Here’s how you create a conditional comment for IE6 with xsl. you need to use an xsl:comment and a cdata and don’t add any extra spacing.

IE6 only element, such as an image or css file

Input size in HTML and CSS

I’ve struggled over the past couple years with including size=”xx” in input tags. My right brain says, “it’s presentational, nooooo!” My left brain says “but it makes the forms more predictable.”

Well, lo and behold, there’s a reason behind the madness. Bite Sized Standards has a new post that describes why the size attribute isn’t just a presentational element.

However, unlike the size attribute of the infamous <font> tag, size of <input> specifies a functional property. The length of an input field is a programmatical decision because it provides an important cue as to the type of input expected: a cue that should be preserved even when the page is not styled.

The advantage of using size becomes apparent when working with web applications that make extensive use of forms, often with different layouts. Instead of having a plethora of CSS classes for different input field sizes, we could simply set their widths using size.
Bite Sized Standards

So, let both sides of your brain feel good. Use the size on input elements and have a happy day after all.

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;}


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