I have a couple of questions about the problem of hiding text inside an anchor tag and only displaying a background image.
Note to those about to bombard me with links to other articles and tell me that this is a repeat question: I have scoured this site and the web in general and read the solutions (and by solutions I mean mostly hacks) people came up with. What most people seem to be doing (or have done up until recently) was the -9999px hack. Also popular is/was wrapping the text in a span and doing something like this or visibility: hidden.
Now, I personally think that "hiding" the text would really only make sense in the first place if it was hidden dynamically, i.e. displayed only if the background image wasn't loading (for whatever reason). However, all the "solutions" I found effectively remove the text completely or at least hide it permanently so even if the background image isn't loaded, the text still wouldn't be displayed.
So here are my questions:
Why would one want to have text and then permanently hide it at all? Why not just leave the anchor empty - i.e. just don't put any text in it - and only have the image displayed? Why have text and then go through the headache of figuring out how to hide it? What's the point of that? Am I missing something here?
Now that we have CSS3, are there actual non-hacky, dynamic ways to hide text when the background image is displayed and have the text appear when the image - for whatever reason - fails to load? I couldn't find any resources so I am assuming this is not supported but maybe one of you ninjas knows better?
There are different possibilities why to do that:
Search Engines scan the web and also gather content that is visually hidden. The site gets better in terms of semantics and has a higher page rank.
Many visually impaired people rely on content that's read to them by screenreaders. Sometimes text in the alt-tag is just not enough. Background images don't even have such a tag.
To your second question:
To me there is no known way to check if a background-image is successfully loaded and is also shown (a totally different story!). CSS only styles content according to defined rules. There may be a javascript way to do it, but in my opinion it isn't worth the cost because mostly this text isn't really a fallback. It has a different purpose as stated above.
Related
Why do images defined in CSS (like backgrounds, lists marker, ...etc.) not behave in the same way in the browser as HTML images? For example, they can't be selected by the mouse, and you can't right click on them.
Images are generally used in CSS for one thing, backgrounds. Which means they aren't used for the same things HTML images are being used for (displaying the actual image as part of the content).
When an image is part of the content, it can be saved and copied etc, because it
is likely to be considered interesting by the reader. Backgrounds (or list-markers etc) however, are less likely (unless the reader is a developer) to interest the reader enough to want to copy them. Instead, the focus is on the actual content of the element (which the background was applied to).
I guess it is a question for browser vendors why they allow certain behavior only when dealing with <img> tag.
However, you can use dev tools/Firebug/whatever and you can download the image file.
This works fine on my computer but im wondering if its a good idea in terms of accessibility, etc.
I have a page of product listings, and I want each listing to link to a product page. The listing is made up of an image and a few photographs of text.
I want the entire listing area to be a link, including white space. So rather than make the images and text links individually, ive put the entire div in a link.
As I said, this is working fine on my computer, but is a good idea for a production site?
Thanks
If it's like a grid or something, and you give a visual cue when the user moves the mouse over the row (background color changing etc) along with the cursor becoming a hand, it should be fine if you use the whitespace as part of your link.
If you want me in your website's audience, I would prefer if you wouldn't. When switching between windows, clicking in the window area is the quickest way to switch focus between windows. If like 80% of your window is really a link, I would find that annoying. I think I am not the only one.
The way it sounds there is also plenty of area which you can make behave like a link, such as the image, and the text in the grid. If that would be clickable, that would be big enough a target to hit.
Also imagine your app being used on a touch screen. These sometimes imsinterpret drag (scroll/zoom) and tick gestures. Which is annoying if everything responds to clicks.
Look at the right-side video links on YouTube. These are block-layout spans wrapped in a tags. (Not that just because Google does it means it's a good idea, but...)
If the area has a :hover color (as these do), then it should be clear enough to the user that this is an action item.
Syntactically it's invalid, you cannot put block elements (div, p, table) inside of inline elements (span, a, strong, em).
I ask because my buddy posted a question earlier on How to resolve issue with image path when testing HtmlHelper? and a few of us in the office got talking about how to resolve this.
One of the guys suggested that he wouldn't have this issue (Test crashing because it has a dependency on functionality in IIS) if he was referencing the image from CSS.
His point made perfect sense, but it kind of threw us back because we'd always been referencing images with <img/>. Were we doing it wrong all along? None of us are experts in this area so I thought it was worth putting to the community. What's the best way to reference images?
There are a variety of benefits to using CSS background-image and inline <img /> tags. CSS background images are great for decorative elements (content borders, background patterns, etc.) as they can be repeated with background-repeat. They make a poor choice for content-centric images, though, like product photographs, bio avatars, etc. Here, inline images work best because you can use an ALT attribute, and images are displayed regardless of browser (some older mobile browsers don't support backgrounds in CSS).
The tag is the best way.
It's standards compliant, accessible, and SEO friendly.
Indiscriminately putting all images into CSS background-image properties is a terrible idea in my opinion. Just a few things you deprive yourself of:
You can't stretch and resize images (may sometimes be necessary)
You can't use the ALT attribute (as David already says)
Background images usually won't get printed
they won't get indexed by search engines
they are difficult for the user to store
missing images won't show up with the "broken image" icon in IE
bad browser layout engines may have problems zooming, because the surrounding container could get zoomed apart from the image content (Shouldn't be a problem in FF though)
you always need an additional container to put the background-image in so you can't e.g. do DOM operations with image elements
the <img> tag exists for a reason, and should absolutely be used where appropriate (i.e. where the image is part of the content rather than decoration or background). For the "sort icon" thing I second what David says, it's fine both ways, but if it's a clickable element it should be an img.
When designing my homepage, I feel like the common knowledge is that it is bad to just have one big picture in the center that gives all of the content. The "right" way to do it would be to chop up the large layed out image into several small backgrounds and make the text use standard html with css background images for layout.
Is the only reason one big image is bad SEO reasons?
A search engine can't make sense of it.
A blind or otherwise visually-impaired person can't make sense of it.
Someone blocking images because he's on a mobile phone with expensive internet can't make sense of it.
There are a few reasons :-)
Also important:
Changes are not easily made to whole, pre-composited images, unless you still have access to the original layered variants. And hopefully they contain text as well, not just pixel data. (Mentioned by others before already. Credits go to pierre and Kendrick)
If you're using background images don't forget to set a text and background color too. Otherwise people not seeing any images might have a hard time deciphering your text (black on black isn't nice to read :-))
You can still use one large image as background. How the text is layed out above that is another matter entirely. In fact, chopping up the image and piecing the pieces together is painful using CSS too. In my experience it's best and easiest to leave background images unchopped and instead composite the rest of the layout above them, using other images or backgrounds if needed. This gives you a little more flexibility when changing a layout again, too.
SEO is one. Handicapped accessibility is another big one -- a screen reader can't read text within an image, typically. Page load time is another one; a user with a slow connection won't see anything useful while the image loads. Lastly, many browsers will use multiple connections to request resources such as images, so they can be loaded simultaneously. If there's just one image, only one connection can be used.
Updating will be tedious; you can also no longer rely on many benefits of CSS.
It's also bad for accessibility (screen readers, text-resizing, different monitor sizes)
It also removes your ability to easily edit text content.
I certainly wouldn't do it if you're looking for a web-developer job, but if you really don't care about the above, you won't be the first person to do it...
I see no reason at all in using imagea to represent something what can easily be achieved with HTML and CSS.
You're putting up a web site to enable communication between you and your visitors. Images and Flash prevent that.
Generally, you design a site with HTML/CSS and text. Only when you wish to add some design that cannot be expressed with standard means, then you use images. But have your site degrade gracefully for those who cannot or does not wish to see images. Let images be an addition, like an advanced version, in no case a replacement for text.
The discussion on this answer to the question "How can I use Google's new imageless button?" Has prompted this question.
Google seems to think that going imageless is good for some reason, but from the comments cited, I fail to see the advantage. Is it worth it to send dozens of lines of HTML and who knows how much CSS to render these imageless buttons, rather than simply load another image, especially when techniques like CSS sprites are available?
When would this technique be preferred? The other question asks how it can be done, but I want to know why it should be done.
Localization (it's easier to translate text than images)
Skinning/themeing (it's easier to change the look and feel with single CSS than recreate multiple images)
Accessibility (screen readers can read properly, text scaling works properly)
Performance (the CSS is shared and so is loaded once from the server)
Functionality (it's easier to expand the button with new UX elements like dropdown arrow when you don't have to change the whole picture)
Btw, the "imageless" button might as well contain an image inside the visual template. This approach is quite similar to XAML's approach to templating and styling the visual tree.
I think in this specific case I can only see the advantage that the buttons can be programatically generated. If you don't know what your button will say it's probably easy to make this way than generating it using somekind of image library generator.
Also changing one CSS can make you change the look-and-feel of all buttons at once. Using image buttons you'll need to update everyone and each of images.
Isn't this done because the height of the button may vary (for example the text size)?
The page load is smoother as no images have to be loaded and will appear later than the rest
The button text is also readable in the case somebody cannot read/view images, yet you have the graphical look. (building a graphical button with images in the traditional way around real text is as complicated HTML as this method)
As they mentioned in their blog, these buttons are skinnable without creating and storing custom images.
Basically, you get all the advantages of plain text buttons over custom imaging, while still having a nice, skinnable graphical look.