Re: Multiple Background Images

I've been closing following the discusion and multiple backgrounds. I
can tell you that I, for one, find everything that has been proposed
so far to be very convoluted both gramatically and in regards to
practical use. I was hoping that this would simply die out, but it
seems as this has a good chance of making it's way into the spec.

I also find it interesting that no one has brought up the point that
this brings out about CSS and is its inability to handle arrays of
properties. This is essentially what we're talking about. We're
talking about an array of similar properties where each individual
property doesn't have a unique name.

Perhaps it's time to think of a generic mechanism for this kind of
behavior because any solution you create now will be a template for
future solutions to this same kind of problem.

I, however, am doubtful. I feel that CSS wasn't designed around this
idea and as it stands, lacks the leeway to handle such an issue.

On a side note: I also believe one of the fundamental problems with
CSS is that is uses a flat design opposed to a structured design. Each
element has properties, but as we've seen many times not all
properties make sense in all contexts. Structure gives you context.

Orion Adrian

On Mon, 29 Nov 2004 21:29:05 +0000, Ben Ward <benmward@gmail.com> wrote:
> 
> OK - having pondered for a few days, how's this for a proposed
> specification (not in 'proper' specification language, I'm afraid. I
> don't know how to do that right, so I'll just try and make it clear.
> If this solution is viable and accepted, then I imagine more competent
> people than myself on the WG can word it as appropriate ;-).).
> 
> >>>
> Multiple backgrounds are represented using an indexed property
> (background(0), background(1) ... background(n)). This indexing
> applies to all background properties (background-xxx and the generic
> background property as well).
> 
> The index should be sequential, but bears no impact on the layering of
> backgrounds. Instead, a User Agent should layer backgrounds in the
> order in which they are declared in the CSS, lowest first, unless
> overridden by the background-z-index property.
> 
> "background-z-index" declares the 'height' from the page that the
> background image is displayed, relative to other background images for
> this element. This value has no relationship with any other
> background-z-index or z-index value of any other element.
> The value can be any integer value in [a sensible range]. If no
> background-z-index property is declared then the value is calculated
> by incrementing the previously declared background's
> background-z-index property by 1. If no background-z-index is
> specified for the first declared background of the element then a
> value of '0' is assigned.
> >>>
> 
> One conflict that would need resolution:
> 
> In 'background' shorthand, the background-z-index may be declared
> alongside all other properties, but conflicts must be averted with
> unitless background-position properties. Otherwise, you end up with
> something like this:
> 
>         background: url("blah.png") 50 50 3;
> 
> 50 50 could be the background-position with a z-index of 3, or it
> could be 50 3 for position while 50 as z-index.
> This is further confused if you specified a single value for position:
> 
>         background: url("foo.jpg") 50 2;
> 
> It is only necessary to specify one background-position value, but
> this could be 1 + z-index or just a normal 2 value.
> 
> I can't find in the spec [1] whether it is mandatory to include units
> with position, so assuming that you are permitted to, then I have two
> suggested solutions:
> 
> 1) It is specified that background-z-index must be declared AFTER
> background-position, and that when background-z-index is declared,
> both background-position values must be provided. This rule should
> allow user agents to differentiate the properties in the shorthand as
> there will always be three values, with background-z-index as the last
> integer value (where background-position values are not given units).
> 
> 2) The spec should strictly declare that lengths for
> background-position must be specified with units always, even 0. This
> way, any integer in the shorthand without a unit specified /must/ be
> background-z-index.
> 
> I'm inclined to go with the second, since that is far clearer cut than #1.
> 
> Regards,
> 
> Ben
> 
> References:
> [1] http://www.w3.org/TR/REC-CSS2/colors.html#propdef-background-position
> 
>

Received on Monday, 29 November 2004 23:22:27 UTC