W3C home > Mailing lists > Public > www-style@w3.org > September 2010

Re: Proposal for CSS3.5

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 3 Sep 2010 07:58:24 -0700
Message-ID: <AANLkTi=GBkg1fivkxSE9o89JHjpD6N4sgjH_2sLP0cca@mail.gmail.com>
To: Matthew Ayres <solar.granulation@gmail.com>
Cc: Brad Kemper <brad.kemper@gmail.com>, Alexander Shpack <shadowkin@gmail.com>, www-style@w3.org
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.

~TJ
Received on Friday, 3 September 2010 14:59:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:31 GMT