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.
Related
Can I make the img tag use the background-image properties? Like for example, I have these two pages here one has img and the other one has background-image tag. Notice in responsive version the img one squeezes the image, while the background-image one adjusts the image according to the size.
Page with IMG tag
Page with background-image tag
You can find both img and background-image in sub-header div ..
This'll sound a bit pedantic, but there are a few reasons for it.
An <img> element represents content on the page, something intrinsically important to see and understand. Background images are fluffy stuff to make the site look pretty but their removal would not impact the message.
You are mixing your use-cases. You should go with a background-imaged header in this case because the image isn't intrinsic to the message or content of the page.
Use an <img> element when you're displaying a graph, a photo someone took, etc.
Why?
The browser intentionally treats them differently, as you've noticed, placing a higher priority on showing the content of an <img> tag for example. It'll attempt to stretch the image to fit by default, while a background will simply be clipped.
When the user goes to print the page, it's much easier to remove background images via CSS media queries then it is to hide (the correct) IMG tags.
Background images also don't take up space in the DOM and cause fewer conflicts with other elements. IMG tags flow in the document and can easily get dislodged from their intended position (creating a lot of extra work to make them stay put).
Right-clicking a background image doesn't do much. Right-clicking an image gives you image related options, such as downloading or opening the image. This goes along with the theme of the <img> tag as content.
There are other reasons, but this all boils down to semantics. This may not seem like a big deal to you, but that's probably because you don't have a vision impairment (so you don't regularly use a screen reader) and aren't really thinking about web crawlers and the many other systems that attempt to extract meaning from the tags you've used.
You will be far better off for many, many reasons if you stop fighting the system and use it the way it was intended. Or, at least, know why you're bucking convention before doing so.
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.
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.
Assuming there is no og:image or link rel img_source, does anyone have any real-world experience or advice on better-than-random techniques to choose an image that best represents a web page?
Update: All answers are good, so upvoted them all and selected one, although it seems there is no great way of doing this. I will experiment with largest picture and screenshot of what it would like on a low-res client. Thanks all!
PS: I'm finding that quite a few pages seem to have og:image or link rel img_source anyway. More than I expected
Taking a screenshot of the website in its smallest possible form, how it would look on a notebook laptop or even a mobile (but not the mobile site version), would be a non-random approach.
Most good web designers will try to make sure users are able to see what the page is about immediately upon loading and include the most important and relevant information 'above the fold' as they say.
Choose the logo of your page as the og:image. That way your brand becomes associated with all your posts, without having to worry about what image best defines each individual page.
For other pages, you cannot control what image they have.
You could investigate how sharer.php works but other than that there is no silver bullet as to choose which image for a web page that has no definable image.
I don't have any experience with Facebook opengraph, but one trick I've used before is to grab favicons of sites I've linked to and use them as link button icons... They're small and are usually always associated with the company name and/or logo, and they're pretty universal across most professional websites. And the usually univeral filename favicon.ico makes it really easy to pick out of the html (or the link attributes if they change the filename).
Might give that a shot if that could be adapted into what you are trying to do. If you find that doesn't look too good, you can try a more "web 2.0" take and check for iPhone/iPad button apple-touch-icon png images (probably only find them on big name sites though)http://developer.apple.com/library/ios/#DOCUMENTATION/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html
I would normally suggest that you simply scrape the page of img tags. However, these days, CSS background images are frequently applied to h1/header/div/a/etc. tags to display logos in place of text.
One possible solution is to grab all elements with 'logo' in their ID/class name:
var l = $('[id*="logo"],[id*="Logo"],[class*="logo"],[class*="Logo"]');
If this is/contains an img tag, chances are you have the site's logo. Otherwise, if it's a div or other such container, you'll need to dig into the child elements' CSS properties to see if they have a background image.
From this you can build a set of candidate images, which when combined with a heuristic based on (for example) image dimensions, should hopefully spit out a logo every time.
I hope this helps you on your way!
Going for the logo is usually the wrong way. Seeing it from a user of your website's point of view I would rather want no image than a logo all the time. This is the same as in Google+ or Facebook links. Only show images when it really does make sense.
However finding the corresponding image may not always be trivial if there is no og:image or rel="image_source" provided.
An article usually has a title which is presented as <h1> or <h2> tag. The nearest image may be the right one. However the nearest may also be a logo so this can go wrong.
I would do that very pragmatic. I would fetch the most likely image first and read the given EXIF data, if this is a real image there are informations provided. If this is just a logo, spacer or some other kind of layout graphic it does not have EXIF data and therefore is not relevant. If the first picture is not the right tough, I would fetch the next one and so on.
Another clue may be the HTML5 <article> tag which usually has the corresponding image to the post nested.
Nevertheless there are several web designer not using standards and their webpage may not be parable nicely.
When I was first learning HTML a very long time ago, I was told that it was important to always set the dimensions of your images in your HTML, so that browsers could draw an empty box where the image should go, render your page, and then download and render the images where they belong. If you didn't set width and height values for your images, the browser would have to download the images first to discover their dimensions, and it would slow page loading for people with crappy connections.
For the past few years I've been using CSS, I always put a width and height declaration in my img tags in my HTML. My question is, is setting width and height in the style sheet, and no longer adding these HTML attributes, just as good? It certainly makes my spartan HTML look even cleaner without them.
The problem you mention with the image not being downloaded immediately also applies to your CSS.
The difference is that without the rest of the CSS the whole layout may not make sense. In other words, if the rest of the CSS hasn't loaded then the fact that the image dimensions are also missing won't really be that noticeable.
So personally I think it's fine to put the dimensions in the CSS.
This is a good question, but it's a bit subjective and may lead to more discussion than is generally advised on SO.
Back in the 90's, browsers were slow, and so was the internet. 56k took a while to transfer medium sized images. During that time, the layout would resize to fit the image.
Fast-forward a decade, and internet speeds are much faster, rendering times are much faster. People are used to layouts that change a bit in the first half-second of page load. It's not bad to not specify an image size, as long as you understand the layout of the page may shift during loading.
CSS is parsed before the page is loaded, so specifying the height & width in CSS will work just as well as specifying it inline.
One thing to keep in mind is that inline styles (and that includes height and width declarations) always trump CSS in specificity. If you specify heights and widths of images inline, you may have to go back through every page where an image is present if you want to adjust the size of the images.
Personally I'd suggest using CSS, as it keeps all your styles in the same place.
Yes, setting these properties in CSS will work just as well.
I don't know that it affects page rendering speed in any manner, however. The little effect it does have, is that layout that depends on the image will appear to jump around on the page until the image is loaded and allocates all the space it eventually will.
This is not a practice I follow myself.
A similar question has already been discussed and answered here:
Image width/height as an attribute or in CSS?
It should be defined inline. If you
are using the img tag, that image
should have semantic value to the
content, which is why the alt
attribute is required for validation.
If the image is to be part of the
layout or template, you should use a
tag other than the img tag and assign
the image as a CSS background to the
element. In this case, the image has
no semantic meaning and therefore
doesn't require the alt attribute. I'm
fairly certain that most screen
readers would not even know that a CSS
image exists.
This is also helpful:
If it's part of your site template,
I'd place it in the CSS file.
If it's just on one page, it should be
inline (or defined in a block of
page-specific CSS at the top).
I think the only difference is that css can (yeah it's possible!) not to be read, so <img> attributes are used.
But I'm not sure, I'm going to check that.
EDIT: http://www.mezzoblue.com/archives/2005/05/10/image_attrib/
While you can use CSS to clean up the layout, if your layout messes up by inability to load a single image you should fix that first.
Modern layouts should be controlled by divs and CSS, images in the layout should be supplied only in the form of a background-image:
The reason for always putting the dimensions into HTML code back in the day was due to loading times -- on a 14.4K modem, even relatively small image files would load noticably after the main HTML document had loaded.
These days this is much less of an issue. If it is an issue, it's worth noting that a CSS file will load after the main HTML document, so if you only specify your dimensions there you could potentially suffer the same problem, but CSS files are typically fairly small, so the effect should be minimised.
The other point is that old-school HTML design was very focused on layout, and image sizes were often a critical part of that - if the images were the wrong size, the layout of the whole page would often be completely wrong.
Modern page design approaches things very differently, putting minimal of any layout information into the HTML, and abstracting it all to the stylesheet. Therefore on a typical modern site, until the stylesheets have loaded, the site will just be a series of blocks, and be completely lacking in design. In fact, often the graphics themselves - not just their dimensions - are defined in the stylesheet.
So the answer is that to follow modern page design methods, you should put it in the stylesheet.
Obviously it's critical for most sites these days that the stylesheets load quickly, but it isn't just the size of the graphics that it'll affect.