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

Re: [css3] Suggestion: Selector variables or "synonyms"

From: Brad Kemper <brkemper@comcast.net>
Date: Tue, 12 Feb 2008 22:27:58 -0800
Message-Id: <F03936FF-12F9-497A-B207-5DA4156DD21C@comcast.net>
Cc: www-style@w3.org
To: Alan Gresley <alan1@azzurum.com>


On Feb 12, 2008, at 12:13 PM, Alan Gresley wrote:

>
> Brad Kemper wrote:
>
>> This is where I showed a constant to be called "navlink" being
>> created and having a selector sequence assigned to it:
>>
>>> /* for long sequences of selectors that are used in multiple
>>> places: */
>>> @constant navlink( #sidenav ul li a, #topnav ul li a )
>>
>>
>> This is where I showed the just-created "navlink" being used within
>> rules, as a placeholder for typing out that long sequence each time:
>>
>>> navlink:link, navlink:visited { color:black; background-
>>> color:yellow; }
>>> navlink:hover { background-color:black; color:yellow; }
>>> navlink:active { background-color:black; color:red; }
>>>
>>> So, in this syntax, "@constant' means you are defining
>>> the constant. [...] For selectors, after  they are defined,
>>> they are used as though they are just simple  selectors.
>>
>>
>> Note that I am _not_ suggesting that "navlink" in the above example
>> is an ID selector having anything to do with an element with the ID
>> of "navlink" in any HTML document. It does not. I am using it only as
>> a placeholder for the two pieces of selector text, "#sidenav ul li a"
>> and "#topnav ul li a". So that in the three rules I created with
>> "link", "visited", hover", and "active" could be written in a much
>> shorter form, instead of as follows:
>>
>> 	#sidenav ul li a:link,
>> 	#topnav ul li a:link,
>> 	#sidenav ul li a:visited,
>> 	#topnav ul li a:visited { color:black; background-color:yellow; }
>> 	#sidenav ul li a:hover,
>> 	#topnav ul li a:hover { background-color:black; color:yellow; }
>> 	#sidenav ul li a:active,
>> 	#topnav ul li a:active { background-color:black; color:red; }
>
>
> Now I am following, how about a combination. I seeing that navlink  
> as a div and not an anchor.
>
> @constant ???( nav, #sidenav, #topnav ) {
>
>   ul {list-style: none;}
>   li (float: left;} /* specificity 1.0.1 */
>   a {display: block;}
>   a:link, a:visited {color: black; background-color: yellow; }
>   a:hover {background-color: black; color: yellow; }
>   a:active { background-color:black; color:red; }
>
> }

I'm not sure what you are getting at here. If it is defining the  
descendants, that can be done more simply, without the extra  
brackets. I would do it like this:

/* create constant called MYNAVS and assign selectors to it: */
@constant MYNAVS( nav, #sidenav, #topnav )

/* now use MYNAVS as placeholders of those three selectors */
MYNAVS  ul {list-style: none;}
MYNAVS  li (float: left;}
MYNAVS  a {display: block;}
MYNAVS  a:link, MYNAVS a:visited {color: black; background-color:  
yellow; }
MYNAVS  a:hover {background-color: black; color: yellow; }
MYNAVS  a:active { background-color:black; color:red; }

The parser would read that as if you had typed the following:

  	nav  ul.
	#sidenav ul,
	#topnav ul {list-style: none;}

	 nav  li,
	#sidenav li,
	#topnav li (float: left;}

	nav  a,
	#sidenav a,
	#topnav  a {display: block;}

	nav  a:link,
	nav  a:visited,
	#sidenav a:link,
	nav a:visited,
	#topnav a:link,
	#topnav a:visited {color: black; 	background-color: yellow; }

	nav  a:hover,
	#sidenav a:hover,
	#topnav {background-color: black; color: yellow; }

	nav  a:active,
	 #sidenav a:active,
	#topnav { background-color:black; color:red; }

If you wanted it to have a higher specificity than that, you would do  
this:
	html body MYNAVS  ul {list-style: none;}
instead of just this:
	MYNAVS  ul {list-style: none;}

Or, when you were defining the constant, you could have made it more  
specific there:

@constant MYNAVS( html body nav, html body #sidenav, html body #topnav )


> To overrule the list item, I would need a selector like this.
>
> #sidenav ul li {}  /* specificity 1.0.2 */
>
> since everything within the @contant will have a specificity 100  
> plus there own specificity on top.

No, I would not have some sort of magic change to the the specificity  
because of the way the selectors were generated from a variable. That  
just complicates it and makes it more confusing. There is nothing to  
be gained by setting it any higher than its contents. Its really not  
that complicated. The constant or variable is assigned a value  
representing one or more selector patterns. Once so assigned, they  
are what they are. When the parser comes across the variable name (or  
constant name) again, after it has been created and filled with  
selector(s),  its contents are evaluated, and it is parsed be exactly  
the same as if it was reading the selectors it contains. That's how  
variables work (and also how constants work) in any language that  
includes them.

Lets say that I assign a 5 DIV pattern to a constant called fivediv,  
and a 4 div pattern to a constant called fourdiv. Here is what that  
would look like using my syntax:

@constant fivediv( div div div div div )
@constant fivediv( div div div div )

Then when I used them, one would be more specific than the other,  
because it has an extra div. So If I used them like this:

fivediv { background-color:red;  } /* equal to 5 simple selectors */
fourdiv  { background-color:green;  padding:4px; } /* equal to 4  
simple selectors */

and I had this in the HTML:

<div><div><div><div><div>Hello</div></div></div></div></div>

The the inner most DIV would be green (it is more specific than the  
one with only four divs in its rule), and the one outside that would  
be red, and they would both have 4px of padding.

If I wanted fourdiv to overrule the red of fivediv with its green, I  
could make it more specific in conventional ways:

fivediv { background-color:red;  } /* equal to 5 simple selectors */
html body fourdiv  { background-color:green;  padding:4px; } /* equal  
to 6 simple selectors */


>
>
> Alan
>
> http://css-class.com/
>
Received on Wednesday, 13 February 2008 06:29:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:01 GMT