Re: Proposal for CSS3.5

On Fri, Sep 3, 2010 at 3:58 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Fri, Sep 3, 2010 at 7:17 AM, Matthew Ayres
> <solar.granulation@gmail.com> wrote:
>> On Wed, Sep 1, 2010 at 5:22 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>> On Aug 29, 2010, at 12:27 PM, Alexander Shpack wrote:
>>> > Hello!
>>> >
>>> > Sorry for my bad English.
>>> >
>>> > Multiple backgrounds is unusual, because you can't change only one
>>> > preference, in example packground-position, for only one of
>>> > positioning list.
>>> >
>>> > ..oneClass {
>>> > background-image: url(one.png), url(two.png), url(three.png);
>>> > }
>>> >
>>> > I need to create other class .twoClass and I will change only one image
>>> >
>>> > ..twoClass {
>>> > background-image: url(one.png), url(other.png), url(three.png);
>>> > }
>>> >
>>> > I must write all params again. On other side, working with multiple
>>> > params via DOM will need complex code with string parsing.
>>> >
>>> > My proposal is simple: local css defines
>>> >
>>> > Let's write next code
>>> >
>>> > $bgOne { background: url(one.png) no-repeat top left; }
>>> > $bgTwo { background: url(two.png) no-repeat top right; }
>>> > $bgThree { background: url(three.png) no-repeat bottom right; }
>>> >
>>> > And use it via background: $bgOne, $bgTwo, $bgThree;
>>> >
>>> > In this case my proposals seems like no different. But, on other side,
>>> > when
>>> > we use DOM, we can change only one value
>>> > node.style.background.values("bgTwo").backgroundImage = 'other.png';
>>> >
>>> > Let's change declaration of background property
>>> > background-image[$bgTwo]: url(other.png);
>>> >
>>> > What do you think about it?
>>>
>>> It looks a lot like it belongs in one of the various proposals for CSS
>>> constants and/or variables. We've discussed those on this list before, but
>>> so far there is little traction.
>>>
>>> The problem you describe is more general than just backgrounds; it is a
>>> similar situation for any property that takes a comma-separated list
>>> (including box-shadow, for instance).
>>>
>>> A solution I would like to see that does not involve constants or
>>> variables would be to be able to leave blank spots in the list (astride the
>>> commas) to be able to leave those slots unchanged. So for instance, this:
>>>
>>> ..twoClass { background-image: , url(other.png), ; }
>>>
>>> ....would change the second image only, and keep the other two from
>>> whatever they were before in the cascade. Essentially, keeping them as if
>>> you had retyped them in yourself. If there was a fourth item on the list,
>>> the above rule would still override that image, because of the number of
>>> commas.
>>>
>>> This wouldn't be for backgrounds & borders 3, as that is already feature
>>> complete.
>>>
>>>
>>
>> How about if that code sample were changed, for a little more human
>> readability, to
>>
>> .twoClass  { background-image: inherit, url('other.png'), inherit; }
>>
>> so that there is a very clear reference to each inherited value.
>
> Inherit means something substantially different here.  You're not
> trying to inherit (get a value from your parent), but rather reach
> back and get a value from a less-specific rule that has been
> overridden.
>

I'm not entirely sure that I agree, but this probably depends on how
one interprets the use case.  I suppose you're right, in the general
case.  How about if we used the often seen keyword 'auto'?


> .oneClass { background-image: url(one.png), url(two.png), url(three.png); }
> .twoClass { background-image[1]: url(other.png); }

I have to say that I am concerned about using syntax that resembles
array indices within a style declaration.  It would be unfortunate if
this ended up causing confusion, such as the often seen example of
thinking that an array's first element is at [1] instead of [0].

Received on Friday, 3 September 2010 16:17:07 UTC