W3C home > Mailing lists > Public > www-style@w3.org > November 2004

Re: Multiple Background Images

From: Andrew Stevens <andrew.r.stevens@gmail.com>
Date: Sat, 20 Nov 2004 00:17:19 -0500
Message-ID: <75ffca4c04111921178c99f72@mail.gmail.com>
To: "www-style@w3.org" <www-style@w3.org>

> Considering usual stacking order I would rather interpret it the other way
> round, foo at lowest level, followed by bar and any other image in order
> of appearance, much like layers are added on top of each other in image
> editing software.

Having the ability to define multiple backgrounds for <body> (and
<div>, for that matter) would be a great addition. I've often been
frustrated by needing to create nested <div>s in order to have
multiple background images.

I would intuitively tend to agree that this seems to be the
interpretation consistent with the rest of CSS.

Much like defining:
body { background: url(image1.jpg); background: url(image2.jpg);}
will produce a page with a background of image2.jpg

However, Eric raises a good point by noting that font family
preferences are listed with the primary choice coming first.

In the end, I find that using either of these examples as an argument
is invalid, since neither is really supposed to be setting multiple
values for a property (the first is overwriting one value with
another, the second is setting an order of preferred values).

Another possible method for determining stacking order that I can
think of off the top of my head would be to use something like
background(1): url(image1.jpg); background(2): url(image2.jpg);

As far as the delimiter is concerned,  background: url(foo) |
url(bar); looks better to my eyes.

Also, regardless of which image stacking order is chosen, it should
also apply to positioned backgrounds.  That is, if any overlap occurs
between two positioned backgrounds, the one that is defined as being
on top should be stacked on top of the one defined as being on the

 Andrew Stevens
Received on Saturday, 20 November 2004 17:18:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:16 UTC