Re: WebKit now supports CSS Variables

Also sprach David Hyatt:

 > > Still, it may be simpler and better not to allow any such crossing.
 > > Take for instance this example:
 > >
 > >  style sheet 1: @variable { X: 10px }
 > >  style sheet 2: @variable { X: none }
 > >  style sheet 3: div { width: var(X) }
 > >
 > > Style sheet numbering is in document order. If the
 > > fininshed-loading-order is: 3, 1, 2, the width declaration would first
 > > be invalid ("The declaration becomes invalid if the variable does not
 > > exist") then valid with 10px, and then invalid again when X is none.
 > In WebKit at least, the parsing of the declaration with the variable  
 > call is delayed until all stylesheets have been loaded (we don't show  
 > any content in WebKit while stylesheets are still loading).

Ok, so you don't see the problem outlined above. Opera supports
progressive rendering of content as style sheets are loaded so for us
the problem is real. 

Progessive rendering of content is a long-established concept in CSS
and I don't think the benefit of variables outweight the cost of
breaking progressive rendering.

Style sheet reuse is another area that will suffer as a result of
allowing cross-stylesheet variables; style sheets will become more
interdependent and therefore harder to reuse. On a more practical
level, style sheet debugging will be harder as one has to search for
where global variables are set and changed.

Here's some reading on global variables:

  They are usually considered bad practice precisely because of their
  nonlocality: a global variable can potentially be modified from
  anywhere, and any part of the program may depend on it. A global
  variable therefore has an unlimited potential for creating mutual
  dependencies, and adding mutual dependencies increases complexity.

              Håkon Wium Lie                          CTO °þe®ª        

Received on Tuesday, 24 June 2008 18:30:03 UTC