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.
Denis
on 02 Mar 12Clever. 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
on 02 Mar 12Compass helper
+replace-text-with-dimensions(‘path/to/my-image.jpg’)
that actually implements -9999px indent.
Erik Vorhes
on 02 Mar 12I 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
on 02 Mar 12I usually do one of two methods:
{ display:none; }
Or
{ height:0px; visibility: hidden; overflow:hidden; }
Trevor
on 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
on 02 Mar 12My 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
on 02 Mar 12Jeff 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
on 02 Mar 12Ya 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
on 02 Mar 12Like 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 12Unfortunately 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 12I 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 12I 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 12Also, 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
on 02 Mar 12Félix
on 02 Mar 12I 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
on 02 Mar 12Personally 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 12It’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.
Matt Radel
on 02 Mar 12I 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
on 02 Mar 12Has 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
on 02 Mar 12With the advent of webfonts, is there a need to do replacements?
Federico Brigante
on 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
on 02 Mar 12I 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
on 02 Mar 12I just use -999%;
Jayson
on 02 Mar 12The 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
on 03 Mar 12I agree with Erik.
Gab
on 03 Mar 12Yes I agree with Tim.
Jimmy Rittenborg
on 04 Mar 12I do agree with Gab.
David
on 05 Mar 12Uh, ok, everyone agrees, but what is this “least bad option” that seems to be so popular?
This discussion is closed.