One more thing: = Cient-Side compilation =
LESS is written in javascript. It is possible to "compile" a .less file to .css on the server-side, but it is also possible to do it on the client-side (see: http://www.lesscss.org/#usage ). In my opinion, it should be always done server-side, but except in one case: in the color theme editor. In this case, it is possible to use the JS API of LESS in the browser: less.modifyVars({ '@buttonFace': '#5B83AD', '@buttonText': '#D9EEF2' }); In this example, it changes the color or every buttons on the fly. = Integration with java = Some links: * Official LESS CSS Compiler for Java ** https://github.com/marceloverdijk/lesscss-java ** The compiler uses Rhino, Envjs (simulated browser environment written in JavaScript), and the official LESS JavaScript compiler. Example of use: // Instantiate the LESS compiler LessCompiler lessCompiler = new LessCompiler(); // Compile LESS input string to CSS output string String css = lessCompiler.compile("@color: #4D926F; #header { color: @color; }"); // Or compile LESS input file to CSS output file lessCompiler.compile(new File("main.less"), new File("main.css")); * LessCSS4j ** https://github.com/localmatters/lesscss4j ** the author claims it has better performances that the official compiler. Example of use: StyleSheetResource resource = new FileStyleSheetResource(filename); LessCssCompiler compiler = new DefaultLessCssCompilerFactory().create(); compiler.compile(resource, System.out, null); * Sass-Java: ** https://github.com/darrinholst/sass-java ** "Compiles sass to css on-the-fly with compass <http://compass-style.org/>via a j2ee servlet filter". ** Not sure if we can use it. * Others java compilers for sass look dead. Louis-Marie 2014-01-28 Guillaume "Louis-Marie" Delhumeau <[email protected]> > 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
