RE: [Css Variables] Variable Declaration Blocks

Anne van Kesteren wrote:
> Mike Wilson wrote:
> > fantasai wrote:
> > > This was as far as I got Friday afternoon at the F2F:
> > >    http://fantasai.inkedblade.net/style/specs/constants/
> >
> > The discussion in the meeting notes
> > http://lists.w3.org/Archives/Public/www-style/2008Sep/0075.html
> > was kind of brief regarding some of the technical problems with the
> > original CSS Vars suggestion.
> 
> Well, the CSSOM problem is significant.

Could you describe what the main problems are?

I can see that CSSOM is still a work in progress so wouldn't it be 
possible to add more API to handle these things? (Or are there some 
fundamental issues that make it hard to make an API?)
Or is the problem you see not about the actual API, but implementing 
it?

> > I think Dave's implementation with
> > changeable/scriptable variables is far more elegant than a 
> > parse-time solution where the constants are no longer visible 
> > after parsing.
> 
> Could you elaborate on why you consider it to be more elegant? 
> Style sheets on the Web are hardly ever modified through the CSSOM 
> so optimising for that does not seem like such a good idea to me, 
> given the added complexity and changes we need to make to make it 
> work properly.

Well, if we don't want to do things to loaded style sheets then there
are other things in CSSOM that could be removed I guess? :-)

Anyway, why I think the "preserved variables" style is better, or 
more elegant, is because it preserves the information in the CSS
file better. CSS is a declarative language and I think this structure
should be mirrored in the CSSOM, just like the DOM mirrors the
structure of HTML. Imagine if HTML attributes had not been exposed in
the DOM because it was thought that people hardly use them from script.

Mentioning good use cases is hard and I think the killer use cases 
will lie in the future. One area I think will be interesting is theming
on component sets as this today demands lots of classes and repeated
properties. Maybe in-place theme editing is one use-case (by that I
mean modifying variables used in the theme from script) although I may
agree that the world shouldn't stop turning just for this particular
scenario.

What I think is most important is to not close the door on a more 
dynamic approach. If parse-time constants are implemented, and we later
find out that we really wanted more, then it will take a long time (if 
ever) before we get to change it again.

So I think it would be good if variables/constants at least could be
specified in a way that makes it possible to extend it into something
more dynamic in the future.
Say that CSSOM is the main problem, ok, then don't expose it in CSSOM
now, or make it optional. But avoid specifying the whole thing in a 
way that makes parse-time the only way to implement it. Opening up 
(spec-wise) for variables to be changed after parse but not provide
an API for it is one way to do this until implementations keep up.

That said I would really like to hear more about the technical details
making things hard (per my questions above) as to understand what 
kind of compromises could be designed, so it would be really great if
you could take little of your time to tell us about it.
(Maybe this thread should be split into 1:"reasons for having
preserved vars" and "2:problems implementing preserved vars".)

Best regards
Mike Wilson

Received on Friday, 26 September 2008 15:47:35 UTC