Just my 2 cents: = About variables = - in LESS, variables are prefixed by @: @defaultColor: #004400;
- in SASS, variables are prefixed $, just like velocity: $defaultColor: #004400; So, if we use velocity and SASS, what $defaultColor is? A velocity variable? A sass variable? We can escape the $ to make the distinction between sass and velocity variables, but it is not very friendly. = About mixins = Mixins are kind of macros, that we have in velocity. I prefer the implementation of SASS than LESS. The logical operations seem better in SASS too. See: http://css-tricks.com/sass-vs-less/ Louis-Marie 2014-01-28 Ecaterina Moraru (Valica) <[email protected]> > Hi, > > As part of the 6.0 Roadmap we have as entry the creation/integration of a > new Skin inside XWiki. > > Currently there are 2 proposals for the new skin: > Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x > Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin > > Both proposals are done using Twitter's Bootstrap framework ( > http://getbootstrap.com). > Bootstrap officially is written using Less ( http://www.lesscss.org/ ) and > is the default pre-processor they support. There is also a Sass ( > http://sass-lang.com/ ) version for Bootstrap ( > https://github.com/twbs/bootstrap-sass ) so the idea is that the > preprocessor variant is not limiting us in integrating Bootstrap. > > The question we discuss in this thread is what preprocessor we should > integrate in platform when we integrate Bootstrap (that in the case we > integrate either of these tools). > > Currently Junco's extension is done with Bootstrap + Less. My decision to > use this combination was done after a light research and mostly based on a > personal preference of the Less language. > > We are having this preprocessors discussion so late (they appeared in > 2007-2009) because we didn't really need a preprocessor until now. The base > functionality they add we solved by using Velocity (we have CSS3 prefix > macros defined in macro.vm that are similar to the compatibility mixins > provided by Bootstrap, we have also a ColorThemes variables solution for > reusing color values and because we can have Velocity code inside our > stylesheets we cover most of the functions&operations need). > > The only downside for us using Velocity to do these kind of things is that > the functionality we cover is very basic and was done only if we had a > certain need. This is not necessarily a bad thing but it's kind of a > limitation for external developers that might want to make more complex > things. Less and Sass community members are very active and they make sure > their functionality is tested and covers most of the cases. Also there are > some features (like extends, etc.) that would be hard for us to duplicate > in Velocity. > > Just as a note, adding Less doesn't mean we are replacing Velocity. We are > just replacing the CSS things done in Velocity with Less functionality. > Replacing Velocity with another templating engine should be the topic for > another thread (in case we are considering this). > > If we integrate Less, what is currently done with CSS+Velocity will be done > using Less(CSS)+Velocity(less code). > If we integrate Sass (because Sass also has control directives) we > transform CSS+Velocity in Sass(CSS)+Velocity(even less code) but the API > calls will still need to be added with Velocity (so still we will not have > just Sass). > > One of the problems with the preprocessors is that they depend on > Javascript or Ruby (there are some versions also on Java in case of Sass, > but not officially maintained). So first we need to find a solution to > compile Less/Scss files into CSS, inside our platform. > > If you make a Google search you'll see that there are much more > 'recommendations' to pick Sass over Less. One remark regarding this is that > we need to understand that right now Sass is used on a different > technologies stack (mostly for Ruby applications). Sass is very attractive > because of its power. But what we need to ask ourselves is if we need the > full power of Sass (because some of it is already covered by Velocity). > > Personally I prefer Less, but that's because of the separation of concerns > (structure, presentation, behavior). I prefer the limitations Less has > (regarding control structure) in order to not be tempted to write logic > with a language that is not supposed to do that (even though it can). > Preprocessors should be used exclusively to write CSS and especially to > write it more rapid (nesting, mixins). > Also Less syntax is more close to default CSS syntax, which IMO is a big > plus. > > But because of its power, Sass could be in the future the new 'JQuery', > since right now it has a bigger community. One of the advantages of picking > a technology later is that at least you see some clear candidates (and we > don't need to consider other preprocessors like Stylus, etc.). > > Let me know what you think. > Thanks, > Caty > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
