Image replacement and Opera mobile

Hm, it’s bit of a bummer, but I noticed today that my preferred image replacement technique (illustrated here by @Paul_O_B) fails in Opera mobile with images off. Darned Opera mobile does not show the text underneath, but just a colored box where it expected the image to be.

Damn! As one who likes to use Opera on the handheld with images off, this is kind of a deal breaker. :frowning:

Has anyone, by any chance, found a way around it?

You’re not actually using all the nasty titles, right?

So is it that any abso-po’d element with a background image on a page in Opera mobile is replaced with a solid coloured block when that image doesn’t load?

Not sure what you mean.

So is it that any abso-po’d element with a background image on a page in Opera mobile is replaced with a solid coloured block when that image doesn’t load?

Yes, exactly. Indeed, with images off in Opera mobile, any missing image is replaced by a solid block of color where the image would have been. I’ve only just noticed the consequences of this in terms of image replacement. But it also sucks in general in terms of alt text, too, because that’s also lost. (I don’t care so much about that, but all the same … if I knew what were there, I might turn on images for special occasions.)

I tend to use Opera on the mobile with images turned off if I’m surfing a lot—in an attempt to reduce bandwidth usage.

Paul’s example has text + two redundant redundant titles.

Does it matter to Opera Mobile if the images are blocked on your end or if they 404?

Also wonder if you should send a question to @brucel it’s possibly a bug that needs a bug report. Maybe I twot it.

Does Opera Mini do the same?

Ah, right. No, I don’t use those.

Does it matter to Opera Mobile if the images are blocked on your end or if they 404?

Hah, clever question. I just checked, and it only happens if the image link is OK but images are off. If the image is a 404 (a bad link) and images are off, the text underneath shows. Interesting.

Also wonder if you should send a question to @brucel it’s possibly a bug that needs a bug report. Maybe I twot it.

Not sure where I’d send that … but feel free to tweet!

Does Opera Mini do the same?

You know, I still haven’t figured out what the difference is between Opera Mini and Mobile. I’ve tried to find out online, even on Opera’s site, but no one seems to be able to articulate the difference. I figure it must be a secret or something. :nono:

That is… man I hope that’s outdated; even outdated I’m shocked Paul would put up something that BAD. Of course that it has the hack for IE 5.2 mac illustrates how old it is.

The bizzare font-size declaration (EM under a image? NOT GOOD!), pointless classes, even more pointless TITLE attributes (which near as I can tell there’s no legitimate reason to even have in there), display state on an element already set to that state, the background color that’s the default state…

There’s no reason for that to be more than:

<h1><a href="">This is the header text<span></span></a></h1>

With this for CSS:

h1 {
	padding:10px 0;
	font:bold 16px/20px arial,helvetica,sans-serif;

h1 span {
	background:url(images/header-replace.gif) 0 0 no-repeat;

The addition of the line-height should prevent the EM’s from cropping the text funny, there’s no reason to target IE 5.2 mac anymore (NOT that gilder-levin image replacement EVER needed to since you’ve got a perfectly good haslayout trigger)… using PX means it won’t break at the default enlargement OR shrinking that different DPI can have (though people using the retarded text-only zoom in FF might have the text peek out, OH WELL. Use a broken zoom, get a broken page)

There shouldn’t be any color if the image isn’t loading – are you sure that the device you’re testing on isn’t butchering the image? Does changing to PNG fix it? – If you are getting a color then there’s something horrifically wrong with your code, like it inheriting a value from someplace strange… or are you doing something silly like declaring an actual background-color on the nested element because you went and used something stupid like alpha transparency? Does Paul’s demo page actually do what you describe? (Unable to recreate that in mobile OR mini) – what version of mobile? (you still see like 4 different versions in circulation)

Wait, I’m getting what you describe in the mini simulator with images disabled… huh, never seen that before.

Why on earth would they even do that?!?

Well, since mini and mobile do support media queries, my advice would be to strip out the image entirely with background:none for mobile – I’ve been doing that anyways just because images burn up battery and usually don’t look great on mobile anyways – which is why on mobile and mini my EWIUSB site doesn’t have those problems.

Very unusual though – I’ve not had anyone point that one out before… though I just tested a new page I’m working on and… did I ever mention how much I HATE how opera mini/mobile handles monospace fonts?

It’s not a secret at all. :slight_smile:

It would be awesome if your first reaction wasn’t “gee what’s the workaround for this bug?” but instead “this is clearly a bug that should be fixed” and report it at :slight_smile:

I did a quick search in our bug database and didn’t find anything relevant; please report it. Thanks!

That’s what I’ve done for now … although even don’t mobiles download the image anyway? In some circumstances they do, anyhow …

Thanks Simon. (“Secret” iss the tongue-in-cheek term I use when I’m struggling to find something. :slight_smile: )

Problem is, I’m not normally so bold as to assume it’s a bug. For all I know, it’s how it was designed to be. Anyhow, I shall reported it indeed. :slight_smile:

Yes most of those things you mentioned were in place for ie5mac as that page is probably 8 or 9 years old now and the page should be updated.

The em was used because IEmac would not allow a span to work in that place due to an erratic bug but strangely enough allowed an em to hold the image. The small font-size was for IEmac because the overflow:hidden broke IE5 mac and was an attempt to keep the text within the confines of the image for ie5 mac. I’m not sure why I didn’t add that rule into the ie5mac hack anyway.

Title attributes were added in an attempt to imitate the tooltip you get when hovering an image - the duplication again probably for some bug that I’ve forgotten about. Although of course these days I don’t use them but hindsight is a wonderful thing and remember back then ie5 was the only browser on the mac as Safari didn’t exist.

I should have dated these demos but I was expecting to rewrite them but never got around to it.

I should add that—thanks to Simon’s link above—I’ve now finally realized that I’m using Opera Mini instead of Mobile, as I’m on an iPhone. (For whatever reason, I couldn’t figure out which was which … O well, I guess I’m an ijit. :slight_smile: )


PS—Sorry, Paul. I didn’t mean to drop you in it! It’s just a handy page to reference. :slight_smile:

Off Topic:

No worries :slight_smile:

Jason was right anyway and it needs updating. [edit]now updated[/edit]

Report anyway! If people err on the side of not reporting things they’re working around, we never know there’s a problem, and we usually don’t fix problems we don’t know about. :slight_smile:


HTML <img> will be downloaded even if set to display none. However if you have a mobile-first CSS stylesheet, where the span shows no background image and only if your larger screen triggers more CSS which does have the background image, then no, the mobile should not be downloading the image.

h1 span {
styles, no background mentioned;

@media some junk blah blah gazillionpx width {
h1 span {
background: url(someimg.png) 0 0 no-repeat;

This should not request a download because supposedly the mobile whether he understands @ media queries or not, should not even be looking at that CSS and therefore not even seeing the external file.
If a CSS file has an image and it’s not visible, so far as I know the request will go out for the image (will be made while the CSS is being parsed? and so images referenced in CSS are considered “blocking”). So if you started with CSS assuming a large screen and then used an @ media query to say “background: none;”, the image should have already been requested by then.

This is where you get people complaining about stuff where it turns out they simply don’t know how their browser works. Would I be spared the embarrassment and not be told I was just being my usual moron self, or would I get a discrete e-mail saying “maybe possibly consider using another browser pls”? :slight_smile:

I know what that’s like…

Thanks, poes.

OK, so images in the HTML get downloaded. In terms of bg images, it sounds like you are saying that an image that is only visible inside @media for a large screen won’t be downloaded on a small device, but that the image will be downloaded on the small device if the main styles show the image in the background but hide it in the @media for the small device. Is that right?

ralph: yes, assuming a mobile only gets the “mobile” css: if this css does not reference the image, it is not a resource to be downloaded. If there’s any way the mobile browser can see the reference to the image, there should be a request for it.

We know setting something to display: none does not prevent the request to fetch.

I’m assuming no browser looks at @ media queries who shouldn’t load because the screen/device does not match the query requirements, but maybe some do? If they did, the image would be requested.

There’s also something out there called a pre-processor: a parser some browsers (Trident? others?) have which looks ahead in the HTML for external files (src=“” and the such). They may start a fetch even before the actual HTML parser gets that far. This is supposed to improve page loading times, but it’s a problem for some of the “responsive images” solutions. I read someone’s post about this recently but I would have to find it again. It was very interesting.
(edit found

Also, stupid thing: Safari seems to always automatically request a favicon whether you have one or not, whether you reference it in your markup or not. I’ve debated whether I should always have one to prevent the 404 or leave it? Or have it go to something inappropriate and display elsewhere for Safari users?

Thanks poes. Have been trying to get a clear picture of this for a while. :slight_smile:

psh. I’m not the one to go to for a clear picture of anything