Re: Multiple Background Images

I think that the idea of a "background-z-index: foo;" (and associated
shorthand) property has been suggested in one of the other
Multiple-Background discussions. I'll try and read through them again
before commenting on that. In a sequential array it might make sense
to have this, as it gets around the insertion issues (in both CSS
development and scripting).
I'd suggest finding the past mentions and revising the downsides
though, on the surface it seems to be a good and (importantly) stable
idea, though. (It is touched on briefly here:
<http://lists.w3.org/Archives/Public/www-style/2004Nov/0096.html>, but
there is a larger, more useful mention in an older discussion that I
can't find...).

Ben

On Thu, 25 Nov 2004 18:30:57 -0500, dolphinling
<dolphinling@myrealbox.com> wrote:
> Ben Ward wrote:
> 
> 
> >>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.
> >
> 
> *points up* Everything he said. (Including the part about was going to
> submit it a few weeks ago. I have a half-written-up draft in one of my
> folders).
> 
> > Immediate downsides to consider:
> > 1) Using indexes adds character bloat somewhat.
> 
> Barely. To add a 2nd+ background is 3 or 4 characters more than a normal
> one.
> 
> > 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.
> 
> A new property should be added to fix that, similar to z-index but
> obviously for the background only.
> 
> 
> 
> > 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.
> 
> 


-- 
http://www.ben-ward.co.uk

Received on Friday, 26 November 2004 11:42:53 UTC