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

Re: Multiple Background Images

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 30 Nov 2004 14:18:47 -0500
Message-ID: <41ACC797.8040708@inkedblade.net>
To: www-style@w3.org

dolphinling wrote:
> fantasai wrote:
>> The working group has already decided to adopt the comma-separated 
>> syntax.
>> A new working draft of Backgrounds and Borders is in the works; we're
>> hoping to have it ready to publish in the next month or so.
> Was there any discussion of this method (background(n):<properties>) at 
> all? I very much favor it over the commas method;
> It's more powerful
>    (you can e.g. specify background(2) in a different place in the css
>    than background(1), or even background-position(2) in a different
>    place than background(2) ),
> It doesn't conflict with any existing methods, and is easily applicable
>    to other situations where you might want multiple things, and
> It is, IMO, easier to understand.
> If there was discussion of this, can we hear what it was (and why it was 
> rejected), and if there wasn't discussion, can there be some?
> Thanks,
> --dolphinling

I can't speak for the rest of the working group, but I find this proposal
(which allows an infinite number of properties to cascade together and
requires multiple property declarations where a single one will do)
significantly more complicated than comma-separated values.
Furthermore, although being able to declare just the second layer image
independent of the other layers can be an advantage, it can also be the
source of a lot of confusion. So it is not a clear advantage.

The WG decided at the last F2F that multiple backgrounds are important
enough that they should be in CSS3, but we also have been trying to simplify
the backgrounds and borders modules from their previous drafts. One advantage
of comma-separated values is that it adds a minimal change to the syntax
of a few background properties' values. It also fits perfectly well with
the current cascading mechanism, requiring no changes to that module --
the interaction of layers is handled in the computation stage, after the
cascade is finished. I cannot say the same of the indexed-property method.

The CSS WG has a very strong preference /against/ modifying the way the
cascade works, and, I believe, also a strong preference against modifying
the core syntax. There would have to be very compelling reasons to change
either of these.

Received on Tuesday, 30 November 2004 18:46:29 UTC

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