They are not interchangeable-- an image inserted with <img> (or <object>) is added to the content of the page, just as a piece of text would be, whereas a background image is part of the layout and thus presentational. One should not be used for the other.

Thus, the kinds of things you can do with image elements and with background images differ. You can tile background images but can't tile content images. You can manipulate content images with Javascript in ways you can't with background images, for instance to resize them.

I know your taking the purist HTML CSS usage stance but for arguments/discussions sake.

I agree and I see what your saying, as well as SEO stuff and information of the image is lost when using background. But there are times when the image is nothing more than ..erm fluff or to evoke an emotion or borderline on whether it should be in or out of the content. In these sort of circumstances where we could could argue it is or isn't important. Thinking along the lines of how a magazine would show an advertisement.

I seem to believe the browser renders the page then requests the images when using background so at least you get some layout first. Which to me is a pro.

But there are times when the image is nothing more than ..erm fluff or to evoke an emotion or borderline on whether it should be in or out of the content.

If it evokes enough emotion to evoke meaning then I guess it's content and should be treated as such, otherwise fluff I guess should be in the CSS; it's presentational.

Also, CSS background images do not print by default - they are presentational, it should not matter.

So I take it that if you wanted to put text over a "content" image, then you would both go with z-index. It's something I don't often see, most sites seem to go... we need text over image, make image background.

Also could we not go the background route for the advantage/disadvantage? of having the content render before the images are pulled from the server and then, if we so need, link to the image with details, bit like how longdesc was supsosed to work. Extra page, SEO stuff etc.

Just thinking outside the triangle ;)

So I take it that if you wanted to put text over a "content" image,

why would you want to do that, if it's a content image then you would use the "alt" attribute to add the 'extra' meaning. SE bots would not read the image they would read the 'alt text'

what would go in that alt text that wouldn't go in a links title attribute?

unles of course the alt attribute has extra weighting, if so has there been any split tests as to the value of a text link with title over an image with alt

my advice is to grab a screen reader or a text browser and "listen" to the page.. or does the Fangs FF extension still exist.. use that and listen to what the bots are reading

[edited by: SuzyUK at 6:37 pm (utc) on June 11, 2008]

Picture of red widget, text over image. "Red widgets now available blaa blaa".

Sorry but hiding it in an alt so the user has to mouse over (ie only) to see the text? We now saying don't have text over images?

think this is what they used to lovingly call "mystery meat"

pretend you can't see the image, (a bot or a screen reader can't)

how does the bot or listener know they're (supposed to be) looking at a picture of a red widget?

if the user can see it, they will see an HTML image just as well as a background image, if they can't they'll have to listen to your double barrelled explanation, and what about the print sheet or rss would you prefer an image with duplicate link below it or nice explanatory (non duplicate) link in a list

Don't know about mystery meat but, 'being led down the wrong path, doesn't gather moss', makes more sense so far.

Can I just say (again)

But more what I'm wondering is download/ http requests and the time the browser takes to render the page.

Any differences? Is one better than the other?

If I did not care about the loss of image information, alt, title, resizing, printing, google, screen reader or a text browser or RSS or aunty Mavis. All of which we could try some sort of work around (not sure about aunty Mavis). AND cared more about how the text/elements image appear/render/popup on the page. Is there a difference?

Don't have to answer, as I did some tests and got the answer. But. That was the question.

[Solved!]

but, 'being led down the wrong path, doesn't gather moss', makes more sense so far.

at least explain?

Can I just say (again)

If I did not care about the loss of image information, alt, title, resizing, printing, google, screen reader or a text browser or RSS or aunty Mavis. All of which we could try some sort of work around (not sure about aunty Mavis). AND cared more about how the text/elements image appear/render/popup on the page. Is there a difference?

if I cared, or understood that last phrase I might try to answer, after all you did post a question for discussion?

Don't have to answer, as I did some tests and got the answer. But. That was the question.

so share!

[Solved!]

ackk, now I'm deflated, means there'll likely never be an explanation, for the above :o

But more what I'm wondering is download/ http requests and the time the browser takes to render the page.

Any differences? Is one better than the other?
:
Don't have to answer, as I did some tests and got the answer.

Care to share the answer? :) Hhhhmmm, it would seem this thread did end up leaning heavily on the semantic/accessibility side of the argument. Personally I did not comment on the other as I did not know...

Well the results were dull anyway. No difference (that I could tell).

Created a php script that called the flickr api and requested 50 or so images and wrote the image url into the CSS background tag.

And another that wrote the img tag into the body.

Both pages had the same layout text/content. In both cases the layout was drawn and the images then loaded one after the other.

Didn't try using a separate CSS file, just had the CSS in the head of the page, shall have to try that later.

Well the results were dull anyway. No difference (that I could tell).

Thanks for reporting back..

I think that's what me & others were trying to say, as long as you convey the information one way or the other then it is very likely (from a common sense viewpoint) that there is no benefit one way or the other, unless you can provide split tests (which would take time).

IMHO it's the way it should be - if images are off, a major accessibility concern, then the "alt" attribute does the work, if CSS is off the "title" attribute does the work.. IMHO the title attribute is a silent force in the accessibility stakes, so if you don't need the image, e.g. presentation/branding (i.e. a company logo) but simply need the branding text then I'd go with the background image every time

interestingly enough Danny Sullivan over at SEland decided he would bow to the FUD that accompanied image replacement when taken to task about using "hidden text" behind his image logo, "Search Engine Land" was the text behind the logo image which says surprising enough "Search Engine Land" at the time someone decided to pick on him for using CSS to hide text.. so he removed it.. silly silly silly, I remeber it happening and thinking you know a lot but common sense should have prevailed, as SEO and accessible design are so closely related

he recently admitted that a few months later he was explicitly told by a google rep that it really didn't matter, if the intention was correct (and if the text matched exactly), well duhh, it's OK when it comes from the "participating" horses mouth.. but that's pretty much what any native CSS'er/accessibility person would/should have known by common sense?

Things have been changing. Changing rapidly. Last year, Search Engine Land itself came under fire for hidden text, because our logo rendered as a text link saying "Search Engine Land" for those who didn't have images or CSS on. I hadn't caught this during the design process; our designer had no idea it was a bad thing. We fixed it. And not two months later in a discussion forum, I saw a Google rep saying this exact tactic wasn't bad if the text matched identically.

where he say his designer had no idea it was a bad thing.. this is the crossing point IMHO.. it was and never has been a "bad thing" unless it was abused.. trust the designer and at least respect that views of crafts work both ways

use wisely and all will be well.. no one company can change the course of of a specification, if microsoft couldn't I'm pretty sure google can't at least not in the next "webn" incarnation ;)

As I said earlier I agree totally, but... just can't help flipping rocks over and seeing what crawls out.

If say CSS background had some advantage on download/rendering then I would have started weighing up the pros/cons and how to do a workaround.
Just off the top of my head how about...
Flips another rock ;)

<div style="background: url (monalisa.jpg)">
<img src="1pxTransparent.gif" width:350px height:400px title="That bloke that painted it!" alt="Mona Lisa"></div>

runs away as SuzyUK throws rocks :)