Re: [css-variables] a more "Classical" approach

-- Just as a slight note, macros can be much smarter than just text 
replacements. See for instance sweet.js which can literally understand the 
JS syntax. Powerful macros could solve the mixin problem, but I agree simple 
textual macros may have a harder time trying to. When I talk about macros, I 
talk about smart macros which understand the CSS syntax, even if I didn't 
tell that before. Okay, let's move to your example now.

> $my-style, h1 {font-weight: bold; margin-left: 1ex; 
> padding:3pt;border-radius:12pt}
> p, $my-style {font-style:italic;border-color:green}
> ul {border: $my-style }
> $my-style {border-left:red}
>
> Its intepretation:
> 1. I would imagine, that $variables procesing should be completted 
> entirely, before CSS engine starts to use it (like in line with "ul" 
> above).
> 2. so at the point when "ul" is styled, $my-style contains: {font-weight: 
> bold; margin-left: 1ex; 
> padding:3pt;border-radius:12pt;font-style:italic;border-color:green;border-left:red}
> 3. in the process of "ul" style calculation, any "border" components of 
> the $my-style is selected and applied to "ul". In this example, it would 
> be equivalent to: "ul {border-color:green;border-left:red}", no other 
> content of $my-style should propagate to "ul" style, since only "border" 
> attributes is selected there.

Ok, got it. What you want is what I call a mixin. Like I said, this problem 
isn't solved by Custom Properties, you're totally right.

That being said, preprocessors like SASS or LESS [1] already solve this 
problem in a similar way. However they can't possibly solve the problems 
solved by Custom Properties because those happen at run-time and therefore 
cannot be emulated by any preprocessor.

Custom Properties have been prioritized higher than static variables and 
mixins because there is no other software than the CSS engine which can 
implement them, to the contrary of the other proposals including mixins. The 
fact custom properties solved the simple "variable" problem was an added 
bonus which made them very attractive to implementors, but the key element 
was that they were not polyfillable by preprocessors. To the contrary, 
macros/mixins/nesting-rules have been deprioritized because preprocessors 
can solve those problems, and already do. That doesn't mean CSS will never 
solve those problems on its own, but that some other things are more 
important right now.

So, stay tuned for more mixins goodness in the future, I'm pretty sure it 
will solve your use cases; in the mean time, find a preprocessor you like 
and start using them rightaway (we agree they are useful).

Best regards,
François


[1] http://lesscss.org/features/#mixins-feature

Received on Wednesday, 4 June 2014 16:50:29 UTC