Another -9999px

Today, Jeffrey Zeldman shared a new alternative to the venerable Phark CSS image replacement method better known by its surely-that’s-far-enough negative 9999 pixel indent. I’ve long since found my own way so it is with a touch of nostalgia and a humble bow to Messrs Fahrner and Phark that I share my favorite alternative.

The idea is still based on a fixed size element (that matches the dimensions of the image to be displayed instead of it’s text equivalent. Overflow:hidden reliably ensures that whatever we push outside the box is invisible. The difference is in how it’s pushed. Instead of a negative index, I prefer to set the height of the element to zero and instead set the top padding to the desired height. The element still ends up the right size and the text is gently nudged from view via padding. Here’s an example:

Pavel Pravosd

I used to use the zero-height + padding technique. Its major shortcoming is that most screenreaders ignore any content in a container styled that way. The one Zeldman shared and the -999em/-9999px technique do not suffer from this problem.

My recollection of the early 2000’s is a bit schetcky, but I’m pretty sure this is the mood we used to call LIR, and that it actually predates the Phark (-9999px) method. I’ve been using it for probably a decade.

Ya know, I don’t think I give myself enough credit. I discovered this method on my own (not to discredit those who discovered before me) and I like the idea of hiding stuff underneath the block instead of beyond the bounds of the viewport.

Like a hearing impaired, Google tends to read webpages like a screenreader -that’s why you in some situations, don’t want to use display:none;
Also, check out Chris Coyier’s tricks he posted last week.
http://css-tricks.com/places-its-tempting-to-use-display-none-but-dont/

George

on 02 Mar 12

Unfortunately you sometimes have to use the -9999px/em method anyways. If you’re doing this on an input button, then Opera won’t know to get rid of the text unless you text-indent it out of the viewport.

Internet Explorer doesn’t always play nice with this type of method on all types of elements, either.

Marcus Tucker

on 02 Mar 12

I think it’s unacceptable & irresponsible to use techniques/hacks which are not accessible, so Erik Vorhes’ comment is a showstopper – i.e. this is not a technique that should be used, the old -9999px way is perfectly fine the way it is.

Mike

on 02 Mar 12

I never use image replacement anymore. It’s benefit for SEO is questionable (alt text should just be indexed) and this new technique, just like the old one, is not accessible (images turned off, you don’t see any text).

It will take you some time to understand this, but once you do (and you see the added value of accessibility) you will probably stop using it too.

Mike

on 02 Mar 12

Also, please don’t confuse accessibility with “a screen reader”. -9999px offset is NOT accessible in the scenario where images are turned off but no screen reader is used. It should be common sense, but not many web developers even try their work without images.

I actually always take the time to make sure my designs work in lynx. It really sobers you up, to see how your pretty navigation just fails horribly, and how parts of your content are missing because you hacked your way around stuff. It’s fun, too.

Personally I use the phark method due to the accessibility benefits, however it will be interesting to see the time when browser resolutions become so high that all these “hidden” words start randomly appearing on people’s screens – as i’m sure there are many occurrences where no ‘overflow:hidden’ parent element has been set.

RDO

on 02 Mar 12

It’s an elegant solution; however, I would say this: judging by all the articles on CSS work-arounds, hacks, tricks, etc. not only here, but smashingmag, and many other solid sources it just sets off all sorts alarm bells in my head that CSS (or the implementation an interpretation thereof by browsers) is hopelessly broken. I wish CSS/web UIs didn’t rely on so many battle-worn and battle-learned “wisdom’ and instead it relied on a more structured and predictable way.

Grover

on 02 Mar 12

@RDO
I too am baffled that image replacement is not built in to CSS 3 since damn near EVERYONE does it.

@Trevor
Yeah, the “rough” characterization of the old technique made me laugh too.

@Mike
So just out of curiosity, what are the situations where images are turned off but no screen reader is in use? Seems like the edgiest of edge cases to me. I’m genuinely asking to be educated.

I think what’s missing here (unless I overlooked someone saying it) is the motivation for the new technique, which is performance. According to Zeldman, when using the -9999px method, the browser still has to draw a box of that size which makes a “noticeable” diference in things like animations on devices like the first iPad.

I can’t say I’m a huge fan of replacement in general, but sometimes it’s unavoidable. It’s always interesting to see alternative solutions.

Has anyone messed with any techniques of adding a span around the text they would like to hide and then manipulating that element which would give some separation from the image replacement element? Just curious what issues might arise from this method.

Eduardo

I’ve used this technic on a website for other reasons but the problem outlined by Erik bothers me… I guess I’ll stick to Phark =/

If it weren’t for the benefits offered by sprites one could just use a plain &lt;img alt='text' /&gt;. The clip could be used on img tags to replicate sprites but I’m afraid we’d lose the benefit of using this method altogether: I assume the alt<code> text will still be cut out of the view… but I haven't tried this.