Re: [xwiki-devs] [Discussion][Skin] Less vs. Sass vs. Velocity

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 devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs