19 Feb
2014
19 Feb
'14
11:09 a.m.
Hi,
Some other opinions?
Thanks,
Caty
On Wed, Jan 29, 2014 at 11:42 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> 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 <gdelhumeau(a)xwiki.com>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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) <valicac(a)gmail.com>
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