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

Jens Meiert wrote:
>> 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. 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.
>>     
>
> Depending on the use case in question, this does NOT solely rest in the area of HTML, for example when talking about ways to improve CSS efficiency and understandability (which might be supported by proposed selector vars).
>
> I also doubt that focussing on ONLY either HTML or CSS is really helpful – I wonder if there was any way to include style sheets in HTML then. Web development as a process almost implies HTML and CSS changes, and the cost of solution (of HTML/XML problems) might very well be decreased by a CSS solution – and why shouldn't it, especially when the cost of the (implementation) solution can be quite low?
>
> (Again, I do not talk about private pet projects where a single author has full control about all documents. Revising and improving ancient multi-client multi-domain projects is extremely expensive and a major pain […], and I claim that CSS can help here.)
>
>
>   
>> http://css-class.com/test/demos/constant/original.css
>>
>> http://css-class.com/test/demos/constant/propose.css
>>
>> http://css-class.com/test/demos/constant/original-added.css
>>
>> original.css = 4.62 kb
>> propose.css = 4.75 kb
>> original-added.css = 6.70 kb
>>
>> But considering that this can apply to div#navigation, div#menu and
>> nav in one hit. So this is sort of what Jens' was seeking.
>>     
>
> NO, absolutely not.
>
> The minimum I proposed would at least and already allow for about 10 % file size SAVINGS, see
>
> * http://css-class.com/test/demos/constant/original.css (4,740 bytes)
> * http://hell.meiert.org/temp/selector-vars.css (4,177 bytes)
>
>
> However, I didn't discover any concerns about a first draft I should probably create, so I'll try to do exactly that soon.
>
>   
I do not think these constants-selectors is a perfect solution as in 
fact they solve only part of the problem.

Think this way:

Sequence of rules like this:

ul#navigation {...}
ul#navigation, ul#navigation ul {...}
ul#navigation li {...}
ul#navigation>li li {...}
ul#navigation li a {...}
ul#navigation li li a, #navigation li li a:focus {...}
...

is an attempt to establish set of styles local to ul#navigation element.
This task is pretty common so while ago we came up to the idea of style sets. 

Here are the same declarations rewritten using style set named 
"navigation-zone": 

ul#navigation 
{
  style-set: navigation-zone; /* @set navigation-zone below */ 
} 
 
@set navigation-zone
{
  :root {...} /* same as ul#navigation {...} in original css */
  :root, ul {...}
  li {...}
  li li {...}
  li a {...}
  li li a, li li a:focus {...}
  ...
}
  
As you may see this approach allows you to accomplish your task
of using name of local root element (ul#navigation here) only once.

But it gives you more:

1) By defining style set you are making closed style system with local 
root element (the element that has style-set applied) - this set of rules  
can be redefined as a whole - either all rules or no one.
2) Same style set can be assigned to multiple elements.
3) Rules in style set behave as all of them have !important flag set.
4) And probably the most important thing: style sets *significantly* 
   improve speed of style resolving .

I have explained style sets approach that we use here:
http://www.terrainformatica.com/?p=37

--
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 15 February 2008 21:28:17 UTC