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:
.replaceme {
width: 100px; /* image width */
height: 0;
padding-top: 50px; /* image height */
display: inline-block;
overflow: hidden;
background: url(images/image.png);
}
Curious to hear what method you use.
Jason Z. wrote this on Mar 02 2012 There are 29 comments.
Denis 02 Mar 12
Clever. I usually just go to Phark as a default but this looks like it could work. Does it work with @media stuff as well?
Pavel Pravosd 02 Mar 12
Compass helper
+replace-text-with-dimensions(‘path/to/my-image.jpg’)
that actually implements -9999px indent.
Erik Vorhes 02 Mar 12
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.
Jon Preston 02 Mar 12
I usually do one of two methods:
{ display:none; }
Or
{ height:0px; visibility: hidden; overflow:hidden; }
Trevor 02 Mar 12
“The text is gently nudge from view via padding” VS The text being violently rammed way off sceen with text-indent?
Jeff Croft 02 Mar 12
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.
Bill Nordwall 02 Mar 12
Jeff has the right of it. Stuart Langridge (and Seamus Leahy, who came up with it independently) published this technique in 2003:
http://www.kryogenix.org/code/browser/lir/
David 02 Mar 12
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.
Jimmy Rittenborg 02 Mar 12
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 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 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 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 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.
Tsachi 02 Mar 12
Félix 02 Mar 12
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.
Chuck Neely 02 Mar 12
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 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 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.
Matt Radel 02 Mar 12
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.
Tim 02 Mar 12
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 02 Mar 12
With the advent of webfonts, is there a need to do replacements?
Federico Brigante 02 Mar 12
@Grover Edge case: image fails to load, it happens.
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 <img alt='text' /> . 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.
Erik Vorhes 02 Mar 12
I should clarify, I prefer to avoid IR whenever possible, but sometimes it’s unavoidable. In which cases, I try to go with the “least bad” option.
David Zuch 02 Mar 12
I just use -999%;
Jayson 02 Mar 12
The problem with this method is that sometimes, when you use Ctrl+F and search for the text which is being hidden, it appears on the page and is highlighted (in Chrome at least)
tim 03 Mar 12
I agree with Erik.
Gab 03 Mar 12
Yes I agree with Tim.
Jimmy Rittenborg 04 Mar 12
I do agree with Gab.
David 05 Mar 12
Uh, ok, everyone agrees, but what is this “least bad option” that seems to be so popular?
This discussion is closed.