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

On Feb 10, 2008, at 5:13 AM, Mike Wilson wrote:

>> So, in this syntax, "@constant' means you are defining
>> the constant.
>
> Personally, I find the word "constant" awkward (How are
> these property assignments more constant than others?)
> and would suggest something more along the lines of reuse
> or modularity. But again, I am trying not to suggest any
> particular syntax, and personal preferences differ...

I'd be OK with me if it was "var" or "macro" or something instead. I  
used "constant" because that is how I envisioned it being most used,  
i.e. to to define some short placeholders for styles or selectors  
near the beginning of a style sheet, and then use those placeholders  
throughout the style sheet. Later, if you wanted to change a color,  
or if the order of things in the HTML changed (breaking contextual  
selectors), then you could fix it by changing a few (or even a  
single) @ rules in the style sheet.

As I mentioned, we would either have to say that a  new string could  
not be assigned to an existing constant once it was created with a  
valid string (making it truly constant), or not, and just let its  
entire contents be replaced (in which case "var" might be better than  
"constant"). What I was trying to avoid was complex inheritance  
rules, and I think the way I specified it would do so, because it  
basically just substitutes valid strings of text wherever the defined  
key word is used.

> The important thing to settle is whether it is interesting
> to add rule composition or inheritance to CSS at all.

I would say rule composition via variables or constants: "yes", but  
without changing how inheritance or the cascade works once the UA  
"expands" those variables or constants into the text that was  
assigned to them.

For instance, using the syntax I presented, if I had a constant  
called "g" with "color:green" in it, and one called "r" with  
"color:red" in it, then the following would end up with  
"color:green", using the existing rules for resolving differences:

	DIV#mydiv { constant:r; constant:g }

For selectors, if you defined "x" to mean "#navlists ul li a[href]",  
then the following two rules would be equivalent:

	BODY x:hover span { color:blue; }
	BODY #navlists ul li a[href]:hover span { color:blue; }

> If
> the specification group find it enough interesting then I
> am sure a suitable syntax will emerge with the help of all
> bright minds here.
>
> So, to put it as simply as possible; is it interesting to
> let rules set up property assigments both from their own
> bodies and from other referenced "bodies"?
> In ER speak this could be regarded as adding the second
> mapping below:
>
>   rule body <1:N> property assignment
>   rule body <1:N> rule body [-> more property assignments]

Interesting, yes. I'm not sure what "<1:N>" means, but a key point  
about the way I proposed doing it is that I would a rule inherit the  
properties of just any other rule. I think that would lead to really  
complicated situations. To keep things simple, I would have a special  
@ rule would be used for assigning into a key word, and then that key  
word could be used in any other rule.

Also note that my proposal is not just for assigning properties, but  
also for assigning selector patterns into variables/constants that  
could be used in the selectors of other rules (which is what the  
subject line of this thread is about).


> Just to clarify I don't think this corresponds to Daniel
> Glazman's request for macros as these are only about
> a single property value and not composition of multiple
> assignments. On the other hand Daniel's macros can be used
> on different properties, f ex:
>
>   border-color: danielscolor;
>   color: danielscolor;

That's true, and I do like what he was trying to do too.[1] The  
general way in which the syntax I proposed works could be expanded to  
include that too. So, for instance, the definition part might look  
like this:

	@constant {  danielscolor: #123456; }

Which could then be used as you showed, where "danielscolor" is a  
value, just like "red" or "green". Or create several values at once:

	@constant {  danielscolor: #123456;  bradscolor: #0066ff;  
smallmeasure: 6px; }

Then, once defined that way, they could be used in any rule:

	DIV#mydiv {
		border: 1px solid danielscolor;
		font-color: bradscolor;
		font-size: smallmeasure;
	}

> I would say CSS would benefit from both constructions and
> it would be nice not having to resort to cpp or similar to
> solve global assignment problems like these.

I'm assuming "CPP" means "Computer Pre-Processing", as in "server  
side processing". And I couldn't agree more. To recap, here are the  
three ways I would assign into CSS constants:

	/* assigning values to constants: */
	@constant {  danielscolor: #123456;  bradscolor: #0066ff;  
smallmeasure: 6px; }

	/* assigning groups of property/value pairs to constants: */
	@constant mycolorandfont { color: #444;  font-size: 77%;  border- 
color;blue; }

	/* assigning sequences of selectors to constants: */
	@constant navlink( #sidenav ul li a, #topnav ul li a )

And here is how they might be used, once so assigned

	/* use of "value" constants: */
	DIV#mydiv {
		border: 1px solid danielscolor;
		font-color: bradscolor;
		font-size: smallmeasure;
	}

	/* use of "properties/values" constants: */
	DIV#mydiv {
		constant:mycolorandfont;
		line-height:90%;
		/* etc. */
	}

	/* use of "selector" constants: */
	BODY#home navlink span {
		display: block;
		background-color:yellow;
		/* etc. */
	}

And again, if you don't think "constant" describes what I'm trying to  
do, then something like "var", or "variable", or "macro", or similar  
could be used instead.

>
> Best regards
> Mike Wilson
>
>

[1] http://lists.w3.org/Archives/Public/www-style/2008Feb/0048.html