Comments on: 5e speculative background images

By: Stefan W

Stefan W — Wed, 17 Feb 2010 12:43:07 +0000

Another add to that:
When Opera parses a background declaration and encounters -moz- or -webkit-gradients it will still interpret the parts it understands (e.g. color), instead of throwing the declaration away completely and using a previous one like it should. That’s why I had to split my background declaration into its parts:
background-color: #d9d9d9;
background-position: 0px 0px;
background-repeat: no-repeat;
background-image: url(“../img/background.png”);
background-image:-webkit-gradient(radial, 15% 30, 500, 30% 30, 0, from(#d9d9d9), to(#fff));
background-image:-moz-radial-gradient(25% 30px, circle cover, #fff 0%, #d9d9d9 500px);
/* Fail for Webkit: downloads background image even though it doesn’t need it, Firefox 3.6 is more clever
Also fail for Opera: it doesn’t know -moz- or -webkit-gradients but interprets the part of a
background-declaration it understands instead of throwing it away and using the previous declaration */

By: Robert

Robert — Tue, 16 Feb 2010 15:59:44 +0000

I’ve recently been playing with CSS gradients. For old browsers, I would declare a background image that simulated the gradient I wanted, then overwrite it with the gradient:

#el {
background: red url(gradient.png);
background: -webkit-gradient(…);
background: -moz-linear-gradient(…);
background: linear-gradient(…);
}

I noticed Safari was downloading gradient.png, even though it wasn’t using it. To get around this, I had to use Modernizr (with some slight modifications) to target different capabilities:

.nojs #el, .no-cssgradients #el {
background: red url(gradient.png);
}

.cssgradients #el {
background: -webkit-gradient(…);
background: -moz-linear-gradient(…);
background: linear-gradient(…);
}

I don’t like that it has to be done that way, but some of the gradient files were big enough that I ONLY wanted users to get them if they didn’t have another option.

The spam blocker is asking me the answer to “for times 6″. I’m assuming it meant “four”, or the question makes no sense at all.

By: Steven Roussey

Steven Roussey — Mon, 15 Feb 2010 19:55:40 +0000

I consider #3 a bug. In some situations, say using a complex JS UI framework like ExtJS, there will be a premade CSS design that devs will use and then modify. Now, while I agree that a large site with the right resources should not rely on CSS cascading for this purpose, I don’t think those with lesser resources should be punished in this way.

I still think a manifest file, similar to that used for offline, should be provided by a website to optionally give the preferred order of downloading assets (both those that can be found from a static analysis of html, css, etc., as well as those that the site dev knows will be needed dynamically at a later point in time).

By: Jason

Jason — Sun, 14 Feb 2010 23:51:04 +0000

To offer a reasonable use for item #3, I propose the following:

a { backgound: url(hover.gif); }
a:link { background: url(link.gif); }
a:hover { background: url(hover.gif); }

With the above rules, the hover image would be pre-fetched for the hover event and prevent the lag in rendering the new background image on hover. The same prefetch behavior could be used another way:

button { background:url(hover.gif); }
button { background:url(button.gif); }
button:hover { background:url(hover.gif); }

By: Freddy

Freddy — Sun, 14 Feb 2010 22:22:49 +0000

To add a real-world case where this is relevant: A web application styled with a default stylesheet containing default background images, and a per-client customized stylesheet (“skin”) containing branding graphics etc later in the stylesheet chain.

I am currently working on exactly that. Thank you, you make a very good point about wasting bandwidth, especially in conjunction with image preloading scripts. I shall store the default styling, at least as far as it is superseded by client-specific styles, into a separate stylesheet.

By: Boris

Boris — Sun, 14 Feb 2010 18:25:35 +0000

For what it’s worth, on item #3 Gecko had the current Webkit behavior for a bit, and we considered it a bug that we did so (https://bugzilla.mozilla.org/show_bug.cgi?id=517224 to be exact).

On point 2 all that’s going on in Gecko is that we start downloading the image once we know that some element will use it as a background. But for display:none or visibility:hidden elements we never even compute the computed background style (since it’s not needed), so never find out that some element wants the background image. It’s not a purposeful decision to not download those images, just an artifact of when background computation is optimized away altogether.

By: Anthony Ricaud

Anthony Ricaud — Sun, 14 Feb 2010 16:13:13 +0000

I’ve already filed a bug about the third behavior : https://bugs.webkit.org/show_bug.cgi?id=31630

By: Scott

Scott — Sun, 14 Feb 2010 16:13:03 +0000

I routinely overwrite background images, but it’s only for IE6 and only to get around IE6’s inability to render transparent PNGs.

By: Livingston Samuel

Livingston Samuel — Sat, 13 Feb 2010 07:25:06 +0000

Nice job Steve. This is one of the aspects that I wanted to analyse, thanks a lot for sharing.

By: SM

SM — Sat, 13 Feb 2010 07:10:53 +0000

Definitely a favorite! Intresting post. Thanks