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

On Feb 11, 2008, at 7:20 PM, Alan Gresley wrote:

>
> Brad Kemper wrote:
>
>>
>> Try as I might, I can't fathom how my proposed syntax, which is
>> basically a way of creating and using placeholders for CSS text,
>> could possibly have any compromising effect on user !important rules.
>> Once the UA expanded the placeholders into the text they contained,
>> they would be no different from any other text the author puts into
>> his or her style sheets. Perhaps you could explain more, or perhaps
>> you misunderstood my proposal?
>
>
> This basically illustrate to core problem. CSS should not be  
> changed to allow for the handling of inconsistency's in HTML (or  
> other languages) coding.

I agree, and that is not what I was proposing.

> CSS should be developed in a way that what it is meant to style is  
> properly coded Semantic HTML. Changing CSS to accommodate a problem  
> that solely rest in the arena of HTML is wrong.
>
> In saying this the concept of a placeholder in CSS has lost me  
> completely.
>
> If say two sets of HTML templates are used on the same site.

No, it doesn't. I can see that I lost you, as that is not the  
proposal that the text you quoted refers to.

> One has it main navigation in a div #navigation. The other template  
> has it main navigation in a div #menu. CSS can accommodate this by  
> having a more cumbersome group selectors.
>
> #navigation ul, #main ul {}
>
> or having to sets of CSS for variations in styling of the navigation
>
> #navigation ul {)
>
> #main ul {}
>
> Now to say #navigation equals #main is changing CSS to solve a HTML  
> coding problem.


That is not at all what I proposed. It is what Jens originally  
proposed, and I proposed something quite different that also did  
assignment, but not to existing selectors for existing HTML. What I  
proposed was assignment of selectors to a variable or constant, not  
to something that already selects something else. [1]

Thus, if I created a constant (or variable) and called it  
"myselector", and  then assigned "#navigation ul li a"  to it, then I  
could use it in my stylesheet as a substitute for typing "#navigation  
ul li a" into multiple rules. Wherever you then saw "myselector" as  
part of rule's selector, you would know that it really was just a  
condensed version of "#navigation ul li a", because I had defined it  
as such earlier in the document with an @ rule. This has nothing to  
do with assigning a string of selectors to an existing ID selector,  
but of being able to create new selectors on the fly.

Besides saving space and improving readability, this also allows you  
to make changes later in one place if all your HTML changes. It does  
not address Jen's desire to be able to support old HTML and new HTML  
templates by equating one set of selectors with another, and I  
pointed that out when I first suggested it. From that post:
>


>> This probably wouldn't help with Jens' first use case (selector  
>> changes that catch old versions of HTML pages), but would be an  
>> elegant and fairly simple way to implement his second (shortened  
>> versions of long contextual selectors).



> CSS I think should be designed to style code, not to style and cope  
> with code inconsistency's.

I agree.

> Some of the problems I see.
>
> 1. No interoperability between non supporting UA and supporting UA.
> 2. Circular references with a whole new set of rules that need to  
> be developed for handling of possible circular references.
> 3. Import rules, cascading rules and important rules and rules that  
> need to be developed for handling them.

#2 and #3 were two of the primary reasons why I proposed something  
different. I will repeat the text from my original proposal[1] that  
dealt with selectors (I'm sorry if it was not clear enough, but I did  
try to be even more explicit in explaining it in later posts):

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; }


>


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