Re: Nesting declaration blocks

--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Monday, October 18, 2010 3:46 PM
To: "www-style list" <www-style@w3.org>
Subject: Nesting declaration blocks

>
> Nesting thus has several authoring advantages:
>
> 1) It makes it somewhat easier to read the stylesheet, if done well.
> You don't have to constantly reparse each selector to ensure that it's
> just selecting a descendant of the previous one.
>
> 2) It makes the stylesheet as a whole shorter without loss of
> readability.  Less typing is good, shorter content is good.
>
> 3) It makes editting much easier.  If the page structure changes (say
> #header has its id changed), right now you have to change a *lot* of
> selectors.  With nesting, you just change one.
>
>
> Of course, CSS has a big problem with selector nesting like in my
> first example - it breaks the core grammar pretty badly.  (It might
> also require arbitrary lookahead, but I'm not sure of that.)
>
> Discussing this around the team recently, though, we hit on a possible
> solution - @-rules.  I believe that nesting @-rules in a decl block is
> officially against the core grammar right now, but we discussed this
> back in the April ftf and kinda-sorta agreed to change this, with the
> recommendation that @-rules in decl blocks be put at the end, where it
> would break in a controllable way.
>

I am not sure I understand your motivation. If you want to solve items
#1, #2 and #3 then what stops you from using LESS processor now?
And without need of changing core grammar. As far as I remember we
have discussed this many times here already, two/three times per year
for sure.

If you want CSS (selectors) to work faster and add modularity to CSS
while increasing readability then this is another story.

I'd like to remind about my approach with @style-set:
http://www.terrainformatica.com/2010/09/style-sets-in-h-smile-core/
(if needed I can wrap it into some formal proposal form).

To highlight:

A) Style-sets do not require any changes in CSS grammar. At all.
Just one new @-rule and one property.

B) They allow to reduce task of style resolving from current O(n*m) to
something close to O(n*log(m)) (far better in average). Where
  n - number of DOM elements, m - number of style rules.

C) Style-sets are modules by themselves.
E.g. you can say:
  form.some { style-set: jq-ui-dialog; }
  div#my-form { style-set: jq-ui-dialog; }
And these two sub-trees will share the same set of style rules for
their content.

D) It indeed improves readability.

E) It increases maintainability.
E.g. if you will change style-set [CSS] property value of some element
in runtime - you will *completely* remove one style set from sub-tree
and apply another one. Without any side-effects and "style remnants".

In fact B) alone is pretty big thing. Especially for modern WebApps
and UI frameworks that have tons of styles declared.

I am yet silent about libraries like jquery-ui, mocha-ui, yui and friends.
They will benefit a lot from being able to define isolated style systems.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Thursday, 21 October 2010 03:04:58 UTC