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

On Wed, Jun 4, 2014 at 3:49 PM, Rafał Pietrak <rafal@ztk-rp.eu> wrote:

> Hmm. So that's that then. Priorities set in motion. Pity.
>
> My last comment on that would be: as an average web-cook:
> 1. I've seen LESS, and don't use it personally. I don't like the "compiler
> atitude" it offers. I do use other peoples stuff from their use of LESS
> though :) but if the same was available "natively" from CSS engine, tha
> would be another story.
> 2. I avoid JavaScript when there is any possible way to make things
> stright in CSS instead; even if it may look a bit worse. (thus my
> objections to companion scripts) The performence panelty of interpreted
> language versus style interpretation is noticable to the naked eye; I dont
> like. it.
> 3. And I do apreciate set-math, which cascading so nicely leans against.
>
> That said about "my final comment", I'm tempted to ask if anyone did tried
> to take a sample web-page (say the proposal page at:
> http://dev.w3.org/csswg/css-variables/), and improve its style code by
> the use of "--*"/"var()" tools. And check it it actually improves in any
> way. I do think, that its css files could be improved with $var.
>
> But that's just the finall comment, not really a suggestion.
>
> -R
>
> W dniu 04.06.2014 18:50, François REMY pisze:
>
>  -- 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
>>
>>
>
>
Improved by what measure? seems an important distinction.



-- 
Brian Kardell :: @briankardell :: hitchjs.com