28 Jan
2014
28 Jan
'14
3:06 p.m.
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
28 Jan
28 Jan
3:22 p.m.
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
29 Jan
29 Jan
10:42 a.m.
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>
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
19 Feb
19 Feb
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
3:32 p.m.
Notes:
1/
It is possible to not use theses pre-processors and to still be able to use
bootstrap, as a pre-computed CSS file.
I don't think it is a good idea, because LESS provides a good solution to
customize the bootstrap implementation, by overriding the variables.less
file. This file defines the default colors, fonts, etc...
Also, the Junco skin [1] requires LESS to be built, because it uses the
LESS features to bind the bootstrap classes to the legacy xwiki ones. We
can build it locally and only commit the results file, but I don't think it
is elegant.
And it means that the XWiki instance would not be able to provide such a
skin during the runtime.
2/
Both of these pre-processors have an "include" feature, that would be
difficult to implement with our SSX objects system.
Thanks,
Louis-Marie
[1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin
2014-02-19 11:09 GMT+01:00 Ecaterina Moraru (Valica) <valicac(a)gmail.com>om>:
Hi,
Some other opinions?
Thanks,
Caty
On Wed, Jan 29, 2014 at 11:42 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
complex
functionality.
API
Velocity).
logic
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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>
> 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
prefix
> 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 >> 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 >
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 >
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 > 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 >
> 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 >> 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
23 Feb
23 Feb
12:02 a.m.
Hi Cathy,
While integrating a CSS preprocessor is a very interesting option, in
particular to support dynamic variations of bootstrap based skins (using
variables.less), it is not necessarily a priority, if we target the
development of a new skin that is entirely using the bootstrap markup. Such
a skin could be easily customized by existing bootstrap variant that are
widely available and does not necessarily require the dynamic change of
them (see the bluebird demo).
Postponing a bit here could also help to take a more advisable decision.
However, if during the development of our bootstrap based skin the need to
extends bootstrap cleverly using less preprocessing reveal to be useful, it
would obviously change this requirement.
Thanks,
On Wed, Feb 19, 2014 at 3:32 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
Notes:
1/
It is possible to not use theses pre-processors and to still be able to use
bootstrap, as a pre-computed CSS file.
I don't think it is a good idea, because LESS provides a good solution to
customize the bootstrap implementation, by overriding the variables.less
file. This file defines the default colors, fonts, etc...
Also, the Junco skin [1] requires LESS to be built, because it uses the
LESS features to bind the bootstrap classes to the legacy xwiki ones. We
can build it locally and only commit the results file, but I don't think it
is elegant.
And it means that the XWiki instance would not be able to provide such a
skin during the runtime.
2/
Both of these pre-processors have an "include" feature, that would be
difficult to implement with our SSX objects system.
Thanks,
Louis-Marie
[1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin
2014-02-19 11:09 GMT+01:00 Ecaterina Moraru (Valica) <valicac(a)gmail.com>om>:
http://www.lesscss.org/)
our
make
topic
not
has
can).
(and
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
Hi,
Some other opinions?
Thanks,
Caty
On Wed, Jan 29, 2014 at 11:42 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
written
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 in
DefaultLessCssCompilerFactory().create();
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 > 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>
>
> > 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 ( > >> 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 > >> 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 > 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 > 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 > 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 >>
(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 >>
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 we
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
> 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
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3859
days inactive
3884
days old
5 comments
3 participants
participants (3)
-
Denis Gervalle -
Ecaterina Moraru (Valica) -
Guillaume "Louis-Marie" Delhumeau