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

Re: Multiple Background Images

From: Ben Ward <benmward@gmail.com>
Date: Mon, 22 Nov 2004 20:43:07 +0000
Message-ID: <ef5d0f2f04112212436d3c3225@mail.gmail.com>
To: www-style@w3.org

>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);

The above would be my favoured method of representing multiple
backgrounds too.
I was going to submit such a suggestion myself a few weeks ago but
feared I was too late (and being new to www-style...). Anyway, since
it's come up, this was my theory:

Multiple backgrounds are represented using an indexed attribute
(background(0), background(1) ... background(n)). This indexing applies
to all background attributes (background-xxx and the generic background
attribute as well).
"background(0)" is the lowest rendered background and is equal to the
existing "background", both of which should be valid.

This way, degradation to a CSS1/2 user agent  is catered for with some
elegance (continue using background), can be overridden for a CSS3
design (background, followed by background(0) to override) and (maybe
most important, but also most hypothetical) avoids issues with any
user-agent implementation that could 'act funny' with the comma
separated list (consider what would happen if a UA read the first
background in a comma separated list, rendered it and ignored all
others).

A larger index should be rendered above lower indexes, as with the
z-index attribute.

Using multiple, indexed attributes is advantageous over the proposed
comma-separated list as it permits use of the background-xxx attributes
in a more intuitive manner.
For instance, while you could declare a background-image using the comma
separated list method if you then wanted to set the background-position
of the third background you would be faced with either redeclaring the
default values for backgrounds 1 and 2, or leaving empty entries.
e.g.
        node {
                background-position: ,,top left;
        {

I feel if would be preferable to declare backgrounds with indexes and
make this sort of referencing more intuitive:

e.g.
        node {
                background-image: url("/images/bg0.png");
                background-image(1): url("/images/b01.png");
                background-image(2): url("/images/b02.png");
                background-position(2): top left;
        }

While the comma separated list ordering of highest ... lowest z-index
may be valid for the comparison with font-family, the key difference is
that we are defining an order for layering, not an order for preference.

If anything, comma separated background syntax should be reserved for
some future (hypothetical) 'alternative backgrounds' (in the same
preferential manner
as fonts: maybe you want to specify an SVG image as a background if
supported, fall back to a 24bit PNG if not or fall back to a GIF if you
fail on that). I'm not advocating such an idea right now, but it seems right
to raise it, given the importance of elegant degradation in CSS and 
maintaining the intuitivity of the syntax.
On this basis, I think that using comma separated syntax for multiple
backgrounds would be contrary to the existing behaviour, rather than
consistent.

Immediate downsides to consider: 
1) Using indexes adds character bloat somewhat.

2) If I have an existing set of multiple backgrounds defined
and I wish to add another somewhere in the middle of the indexing
then I would be forced to manually increment each subsequent background
index. This is more effort in code than inserting the new background into the
comma separated list.

I think that the elegance and consistency outweighs those two downsides,
though if this suggestion is considerable then maybe disadvantage #2 
above should be prodding some more.

Regards,

Ben
Received on Tuesday, 23 November 2004 04:04:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:34 GMT