W3C home > Mailing lists > Public > www-style@w3.org > February 2008

Re: [css3] Suggestion: Selector variables or “synonyms”

From: David Woolley <forums@david-woolley.me.uk>
Date: Sat, 09 Feb 2008 21:16:50 +0000
Message-ID: <47AE1842.6060100@david-woolley.me.uk>
To: www-style CSS <www-style@w3.org>

Brad Kemper wrote:
> On Feb 9, 2008, at 3:13 AM, David Woolley wrote:
>> Jens Meiert wrote:
>>> Apparently, Carmelo Capinpin already suggested the concept in 2006 
>>> [1] (with few success, unfortunately [2]), but I may propose to 
>>> consider something like “selector variables” in CSS 3 again in order 
>>> to help both maintainability and style sheet efficiency.
>>> The basic idea is to syntactically allow definitions like
>>>   E = F;
>>> … so that rules matching E would match F as well (and the other way 
>>> around), while variable (or synonym) declarations could probably be 
>>> located at the beginning of a style sheet or within a certain @-rule.
>> Could you explain how this would interact with the cascade, in 
>> particular:
>> - how does it interact with !important rules;
>> - what is the scope of the effect.
> I know you weren't asking me, but I would like to answer based on the 
> way I suggested handling this sort of thing (see quoted text below), in 
> which constants are merely placeholders for other text. Thus, the 
> definition of the constants would not be involved in the cascade, and 

That would only be true if the mechanism only had file scope (in which 
case it is a candidate for server side processing).  Is that what you meant?

> The last value in the constant assignment will have an implied semicolon 
> if it is missing. Adding "!important" to a rule as part of the value of 
> the "constant" parameter would thus be ignored, in the following example:

The point about important was that, if the scope is not limited to the 
file, user !important rules must not be compromised by author selector 

David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.
Received on Saturday, 9 February 2008 21:17:02 UTC

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