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

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
>

Received on Wednesday, 4 June 2014 19:50:26 UTC