Hi, Some other opinions?
Thanks, Caty On Wed, Jan 29, 2014 at 11:42 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote: > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
