[Proposal] Integrate LESS css in XWiki

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Proposal] Integrate LESS css in XWiki

Guillaume "Louis-Marie" Delhumeau
Hello.

In 6.0, we have released a first version of Flamingo. It uses Bootstrap and
the LESS preprocessor during the build to create the final style.css file.

But currently, there is a serious regression compared to Colibri: it does
not support color themes.

So I have started a proposal about the color theme handling in Flamingo,
that you can see there:
http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo

My conclusion is that we need to integrate the LESS preprocesor on the
runtime. This way, we can add velocity variables (corresponding to the
color theme) in our LESS sources BEFORE the LESS preprocessor is launched.
Doing the opposite, (process velocity after LESS) causes some problems that
I have reported on the previous link.

To me, it would be a good step ahead for proposing LESS to our users.

Regarding this, some ideas are coming to me:
- it is quite easy to integrate LESS since we can use Rhino to launch the
LESS preprocessor (which is a javascript program). See:
https://github.com/sandroboehme/lesscss-java
- we need a cache system in order to not always compute the style.css
served to the user (performances issue).
- we need to add this in the "skin" action.
- in the future, we also need to modify the skinx actions, to enable it for
Skin Extensions.

We also need to agree on the use of LESS instead of SASS. I have used LESS
on Flamingo because Bootstrap has originally been written with it (although
an official SASS port exists), so this choice is not based on a strong
analysis. Anyway, it looks quite simple to move from one to the other and
it is probably too soon to predict which of these 2 preprocessors will win
on the long term.

Do you think I am going in the right direction?

Thanks for reading,
Guillaume
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Guillaume "Louis-Marie" Delhumeau
Hi guys.

Since we did not have made a strong analysis on SASS, I have played a bit
with it to compare.

Thomas had the intuition that it should perform faster, because JRuby is a
better implementation for Ruby than Rhino is for JS.

So I have published a little benchmark about them, that you can see there:
https://github.com/xwiki-contrib/less-vs-sass-benchmark

The benchmark is about the time that it takes to compile Bootstrap.

The results are very clear, SASS perform 2 times faster than LESS.

Since it seems easy to switch from LESS to SASS (bootstrap had written a
converter), maybe we should consider this option.

Other thing:
I would like to run Velocity on the sources of my CSS, in order to easily
integrate the color theme variables. But it is risky to run velocity on the
whole tree of bootstrap sources (just imagine that bootstrap has an "#if"
ID...).

So Thomas and I suggest that we can run Velocity on files suffixed by
.scss.vm or .less.vm, to only run velocity on some files (for example:
color-theme.less.vm) that we handle.

WDYT?

Thanks,
Guillaume


2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
[hidden email]>:

> Hello.
>
> In 6.0, we have released a first version of Flamingo. It uses Bootstrap
> and the LESS preprocessor during the build to create the final style.css
> file.
>
> But currently, there is a serious regression compared to Colibri: it does
> not support color themes.
>
> So I have started a proposal about the color theme handling in Flamingo,
> that you can see there:
> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
>
> My conclusion is that we need to integrate the LESS preprocesor on the
> runtime. This way, we can add velocity variables (corresponding to the
> color theme) in our LESS sources BEFORE the LESS preprocessor is launched.
> Doing the opposite, (process velocity after LESS) causes some problems that
> I have reported on the previous link.
>
> To me, it would be a good step ahead for proposing LESS to our users.
>
> Regarding this, some ideas are coming to me:
> - it is quite easy to integrate LESS since we can use Rhino to launch the
> LESS preprocessor (which is a javascript program). See:
> https://github.com/sandroboehme/lesscss-java
> - we need a cache system in order to not always compute the style.css
> served to the user (performances issue).
> - we need to add this in the "skin" action.
> - in the future, we also need to modify the skinx actions, to enable it
> for Skin Extensions.
>
> We also need to agree on the use of LESS instead of SASS. I have used LESS
> on Flamingo because Bootstrap has originally been written with it (although
> an official SASS port exists), so this choice is not based on a strong
> analysis. Anyway, it looks quite simple to move from one to the other and
> it is probably too soon to predict which of these 2 preprocessors will win
> on the long term.
>
> Do you think I am going in the right direction?
>
> Thanks for reading,
> Guillaume
>
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Ecaterina Moraru (Valica)
My major concern about Sass is the syntax very similar to Velocity and the
way we will handle the parsable style sheets.

Thanks,
Caty


On Mon, Apr 28, 2014 at 5:21 PM, Guillaume "Louis-Marie" Delhumeau <
[hidden email]> wrote:

> Hi guys.
>
> Since we did not have made a strong analysis on SASS, I have played a bit
> with it to compare.
>
> Thomas had the intuition that it should perform faster, because JRuby is a
> better implementation for Ruby than Rhino is for JS.
>
> So I have published a little benchmark about them, that you can see there:
> https://github.com/xwiki-contrib/less-vs-sass-benchmark
>
> The benchmark is about the time that it takes to compile Bootstrap.
>
> The results are very clear, SASS perform 2 times faster than LESS.
>
> Since it seems easy to switch from LESS to SASS (bootstrap had written a
> converter), maybe we should consider this option.
>
> Other thing:
> I would like to run Velocity on the sources of my CSS, in order to easily
> integrate the color theme variables. But it is risky to run velocity on the
> whole tree of bootstrap sources (just imagine that bootstrap has an "#if"
> ID...).
>
> So Thomas and I suggest that we can run Velocity on files suffixed by
> .scss.vm or .less.vm, to only run velocity on some files (for example:
> color-theme.less.vm) that we handle.
>
> WDYT?
>
> Thanks,
> Guillaume
>
>
> 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
> [hidden email]>:
>
> > Hello.
> >
> > In 6.0, we have released a first version of Flamingo. It uses Bootstrap
> > and the LESS preprocessor during the build to create the final style.css
> > file.
> >
> > But currently, there is a serious regression compared to Colibri: it does
> > not support color themes.
> >
> > So I have started a proposal about the color theme handling in Flamingo,
> > that you can see there:
> > http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
> >
> > My conclusion is that we need to integrate the LESS preprocesor on the
> > runtime. This way, we can add velocity variables (corresponding to the
> > color theme) in our LESS sources BEFORE the LESS preprocessor is
> launched.
> > Doing the opposite, (process velocity after LESS) causes some problems
> that
> > I have reported on the previous link.
> >
> > To me, it would be a good step ahead for proposing LESS to our users.
> >
> > Regarding this, some ideas are coming to me:
> > - it is quite easy to integrate LESS since we can use Rhino to launch the
> > LESS preprocessor (which is a javascript program). See:
> > https://github.com/sandroboehme/lesscss-java
> > - we need a cache system in order to not always compute the style.css
> > served to the user (performances issue).
> > - we need to add this in the "skin" action.
> > - in the future, we also need to modify the skinx actions, to enable it
> > for Skin Extensions.
> >
> > We also need to agree on the use of LESS instead of SASS. I have used
> LESS
> > on Flamingo because Bootstrap has originally been written with it
> (although
> > an official SASS port exists), so this choice is not based on a strong
> > analysis. Anyway, it looks quite simple to move from one to the other and
> > it is probably too soon to predict which of these 2 preprocessors will
> win
> > on the long term.
> >
> > Do you think I am going in the right direction?
> >
> > Thanks for reading,
> > Guillaume
> >
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

vmassol
Administrator
In reply to this post by Guillaume "Louis-Marie" Delhumeau
On the perfs:

- See also http://brizzled.clapper.org/blog/2012/12/12/play-framework-less-vs-sass-recompilation-performance/
- And about Nashorn (JDK8+):
http://houbie.blogspot.fr/2013/06/javascript-on-jvm-experimenting-with.html Seems it doesn’t help over rhino, but maybe it’s better in Java8 final. Look at Rhino (optimized), it takes about 1 to 1.5s to compile bootstrap after the first 2 passes.
- Now, regarding your figures, are they averages or the whole time for 100 recompilations?

Thanks
-Vincent

On 28 Apr 2014 at 16:22:08, Guillaume Louis-Marie Delhumeau ([hidden email](mailto:[hidden email])) wrote:

> Hi guys.
>  
> Since we did not have made a strong analysis on SASS, I have played a bit
> with it to compare.
>  
> Thomas had the intuition that it should perform faster, because JRuby is a
> better implementation for Ruby than Rhino is for JS.
>  
> So I have published a little benchmark about them, that you can see there:
> https://github.com/xwiki-contrib/less-vs-sass-benchmark
>  
> The benchmark is about the time that it takes to compile Bootstrap.
>  
> The results are very clear, SASS perform 2 times faster than LESS.
>  
> Since it seems easy to switch from LESS to SASS (bootstrap had written a
> converter), maybe we should consider this option.
>  
> Other thing:
> I would like to run Velocity on the sources of my CSS, in order to easily
> integrate the color theme variables. But it is risky to run velocity on the
> whole tree of bootstrap sources (just imagine that bootstrap has an "#if"
> ID...).
>  
> So Thomas and I suggest that we can run Velocity on files suffixed by
> .scss.vm or .less.vm, to only run velocity on some files (for example:
> color-theme.less.vm) that we handle.
>  
> WDYT?
>  
> Thanks,
> Guillaume
>  
>  
> 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
> [hidden email]>:
>  
> > Hello.
> >
> > In 6.0, we have released a first version of Flamingo. It uses Bootstrap
> > and the LESS preprocessor during the build to create the final style.css
> > file.
> >
> > But currently, there is a serious regression compared to Colibri: it does
> > not support color themes.
> >
> > So I have started a proposal about the color theme handling in Flamingo,
> > that you can see there:
> > http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
> >
> > My conclusion is that we need to integrate the LESS preprocesor on the
> > runtime. This way, we can add velocity variables (corresponding to the
> > color theme) in our LESS sources BEFORE the LESS preprocessor is launched.
> > Doing the opposite, (process velocity after LESS) causes some problems that
> > I have reported on the previous link.
> >
> > To me, it would be a good step ahead for proposing LESS to our users.
> >
> > Regarding this, some ideas are coming to me:
> > - it is quite easy to integrate LESS since we can use Rhino to launch the
> > LESS preprocessor (which is a javascript program). See:
> > https://github.com/sandroboehme/lesscss-java
> > - we need a cache system in order to not always compute the style.css
> > served to the user (performances issue).
> > - we need to add this in the "skin" action.
> > - in the future, we also need to modify the skinx actions, to enable it
> > for Skin Extensions.
> >
> > We also need to agree on the use of LESS instead of SASS. I have used LESS
> > on Flamingo because Bootstrap has originally been written with it (although
> > an official SASS port exists), so this choice is not based on a strong
> > analysis. Anyway, it looks quite simple to move from one to the other and
> > it is probably too soon to predict which of these 2 preprocessors will win
> > on the long term.
> >
> > Do you think I am going in the right direction?
> >
> > Thanks for reading,
> > Guillaume
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Guillaume "Louis-Marie" Delhumeau
Thanks,

2014-04-28 16:44 GMT+02:00 [hidden email] <[hidden email]>:

> On the perfs:
>
> - See also
> http://brizzled.clapper.org/blog/2012/12/12/play-framework-less-vs-sass-recompilation-performance/
> - And about Nashorn (JDK8+):
> http://houbie.blogspot.fr/2013/06/javascript-on-jvm-experimenting-with.html Seems
> it doesn’t help over rhino, but maybe it’s better in Java8 final. Look at
> Rhino (optimized), it takes about 1 to 1.5s to compile bootstrap after the
> first 2 passes.
> - Now, regarding your figures, are they averages or the whole time for 100
> recompilations?
>

It's the whole time for 100 recompilations.


>
> Thanks
> -Vincent
>
> On 28 Apr 2014 at 16:22:08, Guillaume Louis-Marie Delhumeau (
> [hidden email](mailto:[hidden email])) wrote:
>
> > Hi guys.
> >
> > Since we did not have made a strong analysis on SASS, I have played a bit
> > with it to compare.
> >
> > Thomas had the intuition that it should perform faster, because JRuby is
> a
> > better implementation for Ruby than Rhino is for JS.
> >
> > So I have published a little benchmark about them, that you can see
> there:
> > https://github.com/xwiki-contrib/less-vs-sass-benchmark
> >
> > The benchmark is about the time that it takes to compile Bootstrap.
> >
> > The results are very clear, SASS perform 2 times faster than LESS.
> >
> > Since it seems easy to switch from LESS to SASS (bootstrap had written a
> > converter), maybe we should consider this option.
> >
> > Other thing:
> > I would like to run Velocity on the sources of my CSS, in order to easily
> > integrate the color theme variables. But it is risky to run velocity on
> the
> > whole tree of bootstrap sources (just imagine that bootstrap has an "#if"
> > ID...).
> >
> > So Thomas and I suggest that we can run Velocity on files suffixed by
> > .scss.vm or .less.vm, to only run velocity on some files (for example:
> > color-theme.less.vm) that we handle.
> >
> > WDYT?
> >
> > Thanks,
> > Guillaume
> >
> >
> > 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
> > [hidden email]>:
> >
> > > Hello.
> > >
> > > In 6.0, we have released a first version of Flamingo. It uses Bootstrap
> > > and the LESS preprocessor during the build to create the final
> style.css
> > > file.
> > >
> > > But currently, there is a serious regression compared to Colibri: it
> does
> > > not support color themes.
> > >
> > > So I have started a proposal about the color theme handling in
> Flamingo,
> > > that you can see there:
> > > http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
> > >
> > > My conclusion is that we need to integrate the LESS preprocesor on the
> > > runtime. This way, we can add velocity variables (corresponding to the
> > > color theme) in our LESS sources BEFORE the LESS preprocessor is
> launched.
> > > Doing the opposite, (process velocity after LESS) causes some problems
> that
> > > I have reported on the previous link.
> > >
> > > To me, it would be a good step ahead for proposing LESS to our users.
> > >
> > > Regarding this, some ideas are coming to me:
> > > - it is quite easy to integrate LESS since we can use Rhino to launch
> the
> > > LESS preprocessor (which is a javascript program). See:
> > > https://github.com/sandroboehme/lesscss-java
> > > - we need a cache system in order to not always compute the style.css
> > > served to the user (performances issue).
> > > - we need to add this in the "skin" action.
> > > - in the future, we also need to modify the skinx actions, to enable it
> > > for Skin Extensions.
> > >
> > > We also need to agree on the use of LESS instead of SASS. I have used
> LESS
> > > on Flamingo because Bootstrap has originally been written with it
> (although
> > > an official SASS port exists), so this choice is not based on a strong
> > > analysis. Anyway, it looks quite simple to move from one to the other
> and
> > > it is probably too soon to predict which of these 2 preprocessors will
> win
> > > on the long term.
> > >
> > > Do you think I am going in the right direction?
> > >
> > > Thanks for reading,
> > > Guillaume
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Guillaume "Louis-Marie" Delhumeau
I have added more informations on:
https://github.com/xwiki-contrib/less-vs-sass-benchmark

Guillaume


2014-04-28 16:48 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
[hidden email]>:

> Thanks,
>
> 2014-04-28 16:44 GMT+02:00 [hidden email] <[hidden email]>:
>
> On the perfs:
>>
>> - See also
>> http://brizzled.clapper.org/blog/2012/12/12/play-framework-less-vs-sass-recompilation-performance/
>> - And about Nashorn (JDK8+):
>>
>> http://houbie.blogspot.fr/2013/06/javascript-on-jvm-experimenting-with.html Seems
>> it doesn’t help over rhino, but maybe it’s better in Java8 final. Look at
>> Rhino (optimized), it takes about 1 to 1.5s to compile bootstrap after the
>> first 2 passes.
>> - Now, regarding your figures, are they averages or the whole time for
>> 100 recompilations?
>>
>
> It's the whole time for 100 recompilations.
>
>
>>
>> Thanks
>> -Vincent
>>
>> On 28 Apr 2014 at 16:22:08, Guillaume Louis-Marie Delhumeau (
>> [hidden email](mailto:[hidden email])) wrote:
>>
>> > Hi guys.
>> >
>> > Since we did not have made a strong analysis on SASS, I have played a
>> bit
>> > with it to compare.
>> >
>> > Thomas had the intuition that it should perform faster, because JRuby
>> is a
>> > better implementation for Ruby than Rhino is for JS.
>> >
>> > So I have published a little benchmark about them, that you can see
>> there:
>> > https://github.com/xwiki-contrib/less-vs-sass-benchmark
>> >
>> > The benchmark is about the time that it takes to compile Bootstrap.
>> >
>> > The results are very clear, SASS perform 2 times faster than LESS.
>> >
>> > Since it seems easy to switch from LESS to SASS (bootstrap had written a
>> > converter), maybe we should consider this option.
>> >
>> > Other thing:
>> > I would like to run Velocity on the sources of my CSS, in order to
>> easily
>> > integrate the color theme variables. But it is risky to run velocity on
>> the
>> > whole tree of bootstrap sources (just imagine that bootstrap has an
>> "#if"
>> > ID...).
>> >
>> > So Thomas and I suggest that we can run Velocity on files suffixed by
>> > .scss.vm or .less.vm, to only run velocity on some files (for example:
>> > color-theme.less.vm) that we handle.
>> >
>> > WDYT?
>> >
>> > Thanks,
>> > Guillaume
>> >
>> >
>> > 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
>> > [hidden email]>:
>> >
>> > > Hello.
>> > >
>> > > In 6.0, we have released a first version of Flamingo. It uses
>> Bootstrap
>> > > and the LESS preprocessor during the build to create the final
>> style.css
>> > > file.
>> > >
>> > > But currently, there is a serious regression compared to Colibri: it
>> does
>> > > not support color themes.
>> > >
>> > > So I have started a proposal about the color theme handling in
>> Flamingo,
>> > > that you can see there:
>> > > http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
>> > >
>> > > My conclusion is that we need to integrate the LESS preprocesor on the
>> > > runtime. This way, we can add velocity variables (corresponding to the
>> > > color theme) in our LESS sources BEFORE the LESS preprocessor is
>> launched.
>> > > Doing the opposite, (process velocity after LESS) causes some
>> problems that
>> > > I have reported on the previous link.
>> > >
>> > > To me, it would be a good step ahead for proposing LESS to our users.
>> > >
>> > > Regarding this, some ideas are coming to me:
>> > > - it is quite easy to integrate LESS since we can use Rhino to launch
>> the
>> > > LESS preprocessor (which is a javascript program). See:
>> > > https://github.com/sandroboehme/lesscss-java
>> > > - we need a cache system in order to not always compute the style.css
>> > > served to the user (performances issue).
>> > > - we need to add this in the "skin" action.
>> > > - in the future, we also need to modify the skinx actions, to enable
>> it
>> > > for Skin Extensions.
>> > >
>> > > We also need to agree on the use of LESS instead of SASS. I have used
>> LESS
>> > > on Flamingo because Bootstrap has originally been written with it
>> (although
>> > > an official SASS port exists), so this choice is not based on a strong
>> > > analysis. Anyway, it looks quite simple to move from one to the other
>> and
>> > > it is probably too soon to predict which of these 2 preprocessors
>> will win
>> > > on the long term.
>> > >
>> > > Do you think I am going in the right direction?
>> > >
>> > > Thanks for reading,
>> > > Guillaume
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Guillaume "Louis-Marie" Delhumeau
In reply to this post by Ecaterina Moraru (Valica)
2014-04-28 16:33 GMT+02:00 Ecaterina Moraru (Valica) <[hidden email]>:

> My major concern about Sass is the syntax very similar to Velocity and the
> way we will handle the parsable style sheets.
>

I think you talk about the fact that variables are prefixed with $ in SASS.

2 solutions:
- it should be possible to escape the $ when velocity should ignore the
variable
- when the variable does not exist in the velocity context, it displays
$variable and it does not fail.

I personally prefer LESS for the reason for this reason, but regarding the
performances, we might consider the things differently, even with a cache
system (which will be needed anyway).

I need more opinions about this.

Thanks,
Guillaume


>
> Thanks,
> Caty
>
>
> On Mon, Apr 28, 2014 at 5:21 PM, Guillaume "Louis-Marie" Delhumeau <
> [hidden email]> wrote:
>
> > Hi guys.
> >
> > Since we did not have made a strong analysis on SASS, I have played a bit
> > with it to compare.
> >
> > Thomas had the intuition that it should perform faster, because JRuby is
> a
> > better implementation for Ruby than Rhino is for JS.
> >
> > So I have published a little benchmark about them, that you can see
> there:
> > https://github.com/xwiki-contrib/less-vs-sass-benchmark
> >
> > The benchmark is about the time that it takes to compile Bootstrap.
> >
> > The results are very clear, SASS perform 2 times faster than LESS.
> >
> > Since it seems easy to switch from LESS to SASS (bootstrap had written a
> > converter), maybe we should consider this option.
> >
> > Other thing:
> > I would like to run Velocity on the sources of my CSS, in order to easily
> > integrate the color theme variables. But it is risky to run velocity on
> the
> > whole tree of bootstrap sources (just imagine that bootstrap has an "#if"
> > ID...).
> >
> > So Thomas and I suggest that we can run Velocity on files suffixed by
> > .scss.vm or .less.vm, to only run velocity on some files (for example:
> > color-theme.less.vm) that we handle.
> >
> > WDYT?
> >
> > Thanks,
> > Guillaume
> >
> >
> > 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
> > [hidden email]>:
> >
> > > Hello.
> > >
> > > In 6.0, we have released a first version of Flamingo. It uses Bootstrap
> > > and the LESS preprocessor during the build to create the final
> style.css
> > > file.
> > >
> > > But currently, there is a serious regression compared to Colibri: it
> does
> > > not support color themes.
> > >
> > > So I have started a proposal about the color theme handling in
> Flamingo,
> > > that you can see there:
> > > http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
> > >
> > > My conclusion is that we need to integrate the LESS preprocesor on the
> > > runtime. This way, we can add velocity variables (corresponding to the
> > > color theme) in our LESS sources BEFORE the LESS preprocessor is
> > launched.
> > > Doing the opposite, (process velocity after LESS) causes some problems
> > that
> > > I have reported on the previous link.
> > >
> > > To me, it would be a good step ahead for proposing LESS to our users.
> > >
> > > Regarding this, some ideas are coming to me:
> > > - it is quite easy to integrate LESS since we can use Rhino to launch
> the
> > > LESS preprocessor (which is a javascript program). See:
> > > https://github.com/sandroboehme/lesscss-java
> > > - we need a cache system in order to not always compute the style.css
> > > served to the user (performances issue).
> > > - we need to add this in the "skin" action.
> > > - in the future, we also need to modify the skinx actions, to enable it
> > > for Skin Extensions.
> > >
> > > We also need to agree on the use of LESS instead of SASS. I have used
> > LESS
> > > on Flamingo because Bootstrap has originally been written with it
> > (although
> > > an official SASS port exists), so this choice is not based on a strong
> > > analysis. Anyway, it looks quite simple to move from one to the other
> and
> > > it is probably too soon to predict which of these 2 preprocessors will
> > win
> > > on the long term.
> > >
> > > Do you think I am going in the right direction?
> > >
> > > Thanks for reading,
> > > Guillaume
> > >
> > >
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Guillaume "Louis-Marie" Delhumeau
In reply to this post by vmassol
2014-04-28 16:44 GMT+02:00 [hidden email] <[hidden email]>:

> On the perfs:
>
> - See also
> http://brizzled.clapper.org/blog/2012/12/12/play-framework-less-vs-sass-recompilation-performance/
> - And about Nashorn (JDK8+):
> http://houbie.blogspot.fr/2013/06/javascript-on-jvm-experimenting-with.html Seems
> it doesn’t help over rhino, but maybe it’s better in Java8 final. Look at
> Rhino (optimized), it takes about 1 to 1.5s to compile bootstrap after the
> first 2 passes.
>

I have tried optimized Rhino without seeing any change over the default
behaviour.


> - Now, regarding your figures, are they averages or the whole time for 100
> recompilations?
>
> Thanks
> -Vincent
>
> On 28 Apr 2014 at 16:22:08, Guillaume Louis-Marie Delhumeau (
> [hidden email](mailto:[hidden email])) wrote:
>
> > Hi guys.
> >
> > Since we did not have made a strong analysis on SASS, I have played a bit
> > with it to compare.
> >
> > Thomas had the intuition that it should perform faster, because JRuby is
> a
> > better implementation for Ruby than Rhino is for JS.
> >
> > So I have published a little benchmark about them, that you can see
> there:
> > https://github.com/xwiki-contrib/less-vs-sass-benchmark
> >
> > The benchmark is about the time that it takes to compile Bootstrap.
> >
> > The results are very clear, SASS perform 2 times faster than LESS.
> >
> > Since it seems easy to switch from LESS to SASS (bootstrap had written a
> > converter), maybe we should consider this option.
> >
> > Other thing:
> > I would like to run Velocity on the sources of my CSS, in order to easily
> > integrate the color theme variables. But it is risky to run velocity on
> the
> > whole tree of bootstrap sources (just imagine that bootstrap has an "#if"
> > ID...).
> >
> > So Thomas and I suggest that we can run Velocity on files suffixed by
> > .scss.vm or .less.vm, to only run velocity on some files (for example:
> > color-theme.less.vm) that we handle.
> >
> > WDYT?
> >
> > Thanks,
> > Guillaume
> >
> >
> > 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
> > [hidden email]>:
> >
> > > Hello.
> > >
> > > In 6.0, we have released a first version of Flamingo. It uses Bootstrap
> > > and the LESS preprocessor during the build to create the final
> style.css
> > > file.
> > >
> > > But currently, there is a serious regression compared to Colibri: it
> does
> > > not support color themes.
> > >
> > > So I have started a proposal about the color theme handling in
> Flamingo,
> > > that you can see there:
> > > http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
> > >
> > > My conclusion is that we need to integrate the LESS preprocesor on the
> > > runtime. This way, we can add velocity variables (corresponding to the
> > > color theme) in our LESS sources BEFORE the LESS preprocessor is
> launched.
> > > Doing the opposite, (process velocity after LESS) causes some problems
> that
> > > I have reported on the previous link.
> > >
> > > To me, it would be a good step ahead for proposing LESS to our users.
> > >
> > > Regarding this, some ideas are coming to me:
> > > - it is quite easy to integrate LESS since we can use Rhino to launch
> the
> > > LESS preprocessor (which is a javascript program). See:
> > > https://github.com/sandroboehme/lesscss-java
> > > - we need a cache system in order to not always compute the style.css
> > > served to the user (performances issue).
> > > - we need to add this in the "skin" action.
> > > - in the future, we also need to modify the skinx actions, to enable it
> > > for Skin Extensions.
> > >
> > > We also need to agree on the use of LESS instead of SASS. I have used
> LESS
> > > on Flamingo because Bootstrap has originally been written with it
> (although
> > > an official SASS port exists), so this choice is not based on a strong
> > > analysis. Anyway, it looks quite simple to move from one to the other
> and
> > > it is probably too soon to predict which of these 2 preprocessors will
> win
> > > on the long term.
> > >
> > > Do you think I am going in the right direction?
> > >
> > > Thanks for reading,
> > > Guillaume
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Caleb James DeLisle-3
In reply to this post by Guillaume "Louis-Marie" Delhumeau
My 2 cents worth is all that matters is community.
Between Groovy, Velocity (I think we're now the biggest user of that) and
prototypejs, we're pretty good at backing the wrong horse.

In 3-5 years, one of LESS/SASS (or perhaps something else entirely) will be
the standard for CSS preprocessing and the other will be a historical amusement.
Lets not be the ones left holding the bag.

Thanks,
Caleb


On 04/28/2014 06:01 PM, Guillaume "Louis-Marie" Delhumeau wrote:

> 2014-04-28 16:33 GMT+02:00 Ecaterina Moraru (Valica) <[hidden email]>:
>
>> My major concern about Sass is the syntax very similar to Velocity and the
>> way we will handle the parsable style sheets.
>>
>
> I think you talk about the fact that variables are prefixed with $ in SASS.
>
> 2 solutions:
> - it should be possible to escape the $ when velocity should ignore the
> variable
> - when the variable does not exist in the velocity context, it displays
> $variable and it does not fail.
>
> I personally prefer LESS for the reason for this reason, but regarding the
> performances, we might consider the things differently, even with a cache
> system (which will be needed anyway).
>
> I need more opinions about this.
>
> Thanks,
> Guillaume
>
>
>>
>> Thanks,
>> Caty
>>
>>
>> On Mon, Apr 28, 2014 at 5:21 PM, Guillaume "Louis-Marie" Delhumeau <
>> [hidden email]> wrote:
>>
>>> Hi guys.
>>>
>>> Since we did not have made a strong analysis on SASS, I have played a bit
>>> with it to compare.
>>>
>>> Thomas had the intuition that it should perform faster, because JRuby is
>> a
>>> better implementation for Ruby than Rhino is for JS.
>>>
>>> So I have published a little benchmark about them, that you can see
>> there:
>>> https://github.com/xwiki-contrib/less-vs-sass-benchmark
>>>
>>> The benchmark is about the time that it takes to compile Bootstrap.
>>>
>>> The results are very clear, SASS perform 2 times faster than LESS.
>>>
>>> Since it seems easy to switch from LESS to SASS (bootstrap had written a
>>> converter), maybe we should consider this option.
>>>
>>> Other thing:
>>> I would like to run Velocity on the sources of my CSS, in order to easily
>>> integrate the color theme variables. But it is risky to run velocity on
>> the
>>> whole tree of bootstrap sources (just imagine that bootstrap has an "#if"
>>> ID...).
>>>
>>> So Thomas and I suggest that we can run Velocity on files suffixed by
>>> .scss.vm or .less.vm, to only run velocity on some files (for example:
>>> color-theme.less.vm) that we handle.
>>>
>>> WDYT?
>>>
>>> Thanks,
>>> Guillaume
>>>
>>>
>>> 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
>>> [hidden email]>:
>>>
>>>> Hello.
>>>>
>>>> In 6.0, we have released a first version of Flamingo. It uses Bootstrap
>>>> and the LESS preprocessor during the build to create the final
>> style.css
>>>> file.
>>>>
>>>> But currently, there is a serious regression compared to Colibri: it
>> does
>>>> not support color themes.
>>>>
>>>> So I have started a proposal about the color theme handling in
>> Flamingo,
>>>> that you can see there:
>>>> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
>>>>
>>>> My conclusion is that we need to integrate the LESS preprocesor on the
>>>> runtime. This way, we can add velocity variables (corresponding to the
>>>> color theme) in our LESS sources BEFORE the LESS preprocessor is
>>> launched.
>>>> Doing the opposite, (process velocity after LESS) causes some problems
>>> that
>>>> I have reported on the previous link.
>>>>
>>>> To me, it would be a good step ahead for proposing LESS to our users.
>>>>
>>>> Regarding this, some ideas are coming to me:
>>>> - it is quite easy to integrate LESS since we can use Rhino to launch
>> the
>>>> LESS preprocessor (which is a javascript program). See:
>>>> https://github.com/sandroboehme/lesscss-java
>>>> - we need a cache system in order to not always compute the style.css
>>>> served to the user (performances issue).
>>>> - we need to add this in the "skin" action.
>>>> - in the future, we also need to modify the skinx actions, to enable it
>>>> for Skin Extensions.
>>>>
>>>> We also need to agree on the use of LESS instead of SASS. I have used
>>> LESS
>>>> on Flamingo because Bootstrap has originally been written with it
>>> (although
>>>> an official SASS port exists), so this choice is not based on a strong
>>>> analysis. Anyway, it looks quite simple to move from one to the other
>> and
>>>> it is probably too soon to predict which of these 2 preprocessors will
>>> win
>>>> on the long term.
>>>>
>>>> Do you think I am going in the right direction?
>>>>
>>>> Thanks for reading,
>>>> Guillaume
>>>>
>>>>
>>> _______________________________________________
>>> devs mailing list
>>> [hidden email]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Guillaume "Louis-Marie" Delhumeau
For your informations, I have updated
https://github.com/xwiki-contrib/less-vs-sass-benchmark with a new
implementation of LESS (Asual LESS) which is ever worse!

I have also upgraded LESS to the last version and it is a bit better from
the performances side.

Thanks,
Guillaume


2014-04-29 9:58 GMT+02:00 Caleb James DeLisle <[hidden email]>:

> My 2 cents worth is all that matters is community.
> Between Groovy, Velocity (I think we're now the biggest user of that) and
> prototypejs, we're pretty good at backing the wrong horse.
>
> In 3-5 years, one of LESS/SASS (or perhaps something else entirely) will be
> the standard for CSS preprocessing and the other will be a historical
> amusement.
> Lets not be the ones left holding the bag.
>
> Thanks,
> Caleb
>
>
> On 04/28/2014 06:01 PM, Guillaume "Louis-Marie" Delhumeau wrote:
> > 2014-04-28 16:33 GMT+02:00 Ecaterina Moraru (Valica) <[hidden email]
> >:
> >
> >> My major concern about Sass is the syntax very similar to Velocity and
> the
> >> way we will handle the parsable style sheets.
> >>
> >
> > I think you talk about the fact that variables are prefixed with $ in
> SASS.
> >
> > 2 solutions:
> > - it should be possible to escape the $ when velocity should ignore the
> > variable
> > - when the variable does not exist in the velocity context, it displays
> > $variable and it does not fail.
> >
> > I personally prefer LESS for the reason for this reason, but regarding
> the
> > performances, we might consider the things differently, even with a cache
> > system (which will be needed anyway).
> >
> > I need more opinions about this.
> >
> > Thanks,
> > Guillaume
> >
> >
> >>
> >> Thanks,
> >> Caty
> >>
> >>
> >> On Mon, Apr 28, 2014 at 5:21 PM, Guillaume "Louis-Marie" Delhumeau <
> >> [hidden email]> wrote:
> >>
> >>> Hi guys.
> >>>
> >>> Since we did not have made a strong analysis on SASS, I have played a
> bit
> >>> with it to compare.
> >>>
> >>> Thomas had the intuition that it should perform faster, because JRuby
> is
> >> a
> >>> better implementation for Ruby than Rhino is for JS.
> >>>
> >>> So I have published a little benchmark about them, that you can see
> >> there:
> >>> https://github.com/xwiki-contrib/less-vs-sass-benchmark
> >>>
> >>> The benchmark is about the time that it takes to compile Bootstrap.
> >>>
> >>> The results are very clear, SASS perform 2 times faster than LESS.
> >>>
> >>> Since it seems easy to switch from LESS to SASS (bootstrap had written
> a
> >>> converter), maybe we should consider this option.
> >>>
> >>> Other thing:
> >>> I would like to run Velocity on the sources of my CSS, in order to
> easily
> >>> integrate the color theme variables. But it is risky to run velocity on
> >> the
> >>> whole tree of bootstrap sources (just imagine that bootstrap has an
> "#if"
> >>> ID...).
> >>>
> >>> So Thomas and I suggest that we can run Velocity on files suffixed by
> >>> .scss.vm or .less.vm, to only run velocity on some files (for example:
> >>> color-theme.less.vm) that we handle.
> >>>
> >>> WDYT?
> >>>
> >>> Thanks,
> >>> Guillaume
> >>>
> >>>
> >>> 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
> >>> [hidden email]>:
> >>>
> >>>> Hello.
> >>>>
> >>>> In 6.0, we have released a first version of Flamingo. It uses
> Bootstrap
> >>>> and the LESS preprocessor during the build to create the final
> >> style.css
> >>>> file.
> >>>>
> >>>> But currently, there is a serious regression compared to Colibri: it
> >> does
> >>>> not support color themes.
> >>>>
> >>>> So I have started a proposal about the color theme handling in
> >> Flamingo,
> >>>> that you can see there:
> >>>> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
> >>>>
> >>>> My conclusion is that we need to integrate the LESS preprocesor on the
> >>>> runtime. This way, we can add velocity variables (corresponding to the
> >>>> color theme) in our LESS sources BEFORE the LESS preprocessor is
> >>> launched.
> >>>> Doing the opposite, (process velocity after LESS) causes some problems
> >>> that
> >>>> I have reported on the previous link.
> >>>>
> >>>> To me, it would be a good step ahead for proposing LESS to our users.
> >>>>
> >>>> Regarding this, some ideas are coming to me:
> >>>> - it is quite easy to integrate LESS since we can use Rhino to launch
> >> the
> >>>> LESS preprocessor (which is a javascript program). See:
> >>>> https://github.com/sandroboehme/lesscss-java
> >>>> - we need a cache system in order to not always compute the style.css
> >>>> served to the user (performances issue).
> >>>> - we need to add this in the "skin" action.
> >>>> - in the future, we also need to modify the skinx actions, to enable
> it
> >>>> for Skin Extensions.
> >>>>
> >>>> We also need to agree on the use of LESS instead of SASS. I have used
> >>> LESS
> >>>> on Flamingo because Bootstrap has originally been written with it
> >>> (although
> >>>> an official SASS port exists), so this choice is not based on a strong
> >>>> analysis. Anyway, it looks quite simple to move from one to the other
> >> and
> >>>> it is probably too soon to predict which of these 2 preprocessors will
> >>> win
> >>>> on the long term.
> >>>>
> >>>> Do you think I am going in the right direction?
> >>>>
> >>>> Thanks for reading,
> >>>> Guillaume
> >>>>
> >>>>
> >>> _______________________________________________
> >>> devs mailing list
> >>> [hidden email]
> >>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>
> >> _______________________________________________
> >> devs mailing list
> >> [hidden email]
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Guillaume "Louis-Marie" Delhumeau
To be fair, I have upgraded SASS to the last version too:
https://github.com/xwiki-contrib/less-vs-sass-benchmark

The results are still quite the same.

Thanks,
Guillaume


2014-04-29 11:01 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
[hidden email]>:

> For your informations, I have updated
> https://github.com/xwiki-contrib/less-vs-sass-benchmark with a new
> implementation of LESS (Asual LESS) which is ever worse!
>
> I have also upgraded LESS to the last version and it is a bit better from
> the performances side.
>
> Thanks,
> Guillaume
>
>
> 2014-04-29 9:58 GMT+02:00 Caleb James DeLisle <[hidden email]>:
>
> My 2 cents worth is all that matters is community.
>> Between Groovy, Velocity (I think we're now the biggest user of that) and
>> prototypejs, we're pretty good at backing the wrong horse.
>>
>> In 3-5 years, one of LESS/SASS (or perhaps something else entirely) will
>> be
>> the standard for CSS preprocessing and the other will be a historical
>> amusement.
>> Lets not be the ones left holding the bag.
>>
>> Thanks,
>> Caleb
>>
>>
>> On 04/28/2014 06:01 PM, Guillaume "Louis-Marie" Delhumeau wrote:
>> > 2014-04-28 16:33 GMT+02:00 Ecaterina Moraru (Valica) <[hidden email]
>> >:
>> >
>> >> My major concern about Sass is the syntax very similar to Velocity and
>> the
>> >> way we will handle the parsable style sheets.
>> >>
>> >
>> > I think you talk about the fact that variables are prefixed with $ in
>> SASS.
>> >
>> > 2 solutions:
>> > - it should be possible to escape the $ when velocity should ignore the
>> > variable
>> > - when the variable does not exist in the velocity context, it displays
>> > $variable and it does not fail.
>> >
>> > I personally prefer LESS for the reason for this reason, but regarding
>> the
>> > performances, we might consider the things differently, even with a
>> cache
>> > system (which will be needed anyway).
>> >
>> > I need more opinions about this.
>> >
>> > Thanks,
>> > Guillaume
>> >
>> >
>> >>
>> >> Thanks,
>> >> Caty
>> >>
>> >>
>> >> On Mon, Apr 28, 2014 at 5:21 PM, Guillaume "Louis-Marie" Delhumeau <
>> >> [hidden email]> wrote:
>> >>
>> >>> Hi guys.
>> >>>
>> >>> Since we did not have made a strong analysis on SASS, I have played a
>> bit
>> >>> with it to compare.
>> >>>
>> >>> Thomas had the intuition that it should perform faster, because JRuby
>> is
>> >> a
>> >>> better implementation for Ruby than Rhino is for JS.
>> >>>
>> >>> So I have published a little benchmark about them, that you can see
>> >> there:
>> >>> https://github.com/xwiki-contrib/less-vs-sass-benchmark
>> >>>
>> >>> The benchmark is about the time that it takes to compile Bootstrap.
>> >>>
>> >>> The results are very clear, SASS perform 2 times faster than LESS.
>> >>>
>> >>> Since it seems easy to switch from LESS to SASS (bootstrap had
>> written a
>> >>> converter), maybe we should consider this option.
>> >>>
>> >>> Other thing:
>> >>> I would like to run Velocity on the sources of my CSS, in order to
>> easily
>> >>> integrate the color theme variables. But it is risky to run velocity
>> on
>> >> the
>> >>> whole tree of bootstrap sources (just imagine that bootstrap has an
>> "#if"
>> >>> ID...).
>> >>>
>> >>> So Thomas and I suggest that we can run Velocity on files suffixed by
>> >>> .scss.vm or .less.vm, to only run velocity on some files (for example:
>> >>> color-theme.less.vm) that we handle.
>> >>>
>> >>> WDYT?
>> >>>
>> >>> Thanks,
>> >>> Guillaume
>> >>>
>> >>>
>> >>> 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
>> >>> [hidden email]>:
>> >>>
>> >>>> Hello.
>> >>>>
>> >>>> In 6.0, we have released a first version of Flamingo. It uses
>> Bootstrap
>> >>>> and the LESS preprocessor during the build to create the final
>> >> style.css
>> >>>> file.
>> >>>>
>> >>>> But currently, there is a serious regression compared to Colibri: it
>> >> does
>> >>>> not support color themes.
>> >>>>
>> >>>> So I have started a proposal about the color theme handling in
>> >> Flamingo,
>> >>>> that you can see there:
>> >>>>
>> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
>> >>>>
>> >>>> My conclusion is that we need to integrate the LESS preprocesor on
>> the
>> >>>> runtime. This way, we can add velocity variables (corresponding to
>> the
>> >>>> color theme) in our LESS sources BEFORE the LESS preprocessor is
>> >>> launched.
>> >>>> Doing the opposite, (process velocity after LESS) causes some
>> problems
>> >>> that
>> >>>> I have reported on the previous link.
>> >>>>
>> >>>> To me, it would be a good step ahead for proposing LESS to our users.
>> >>>>
>> >>>> Regarding this, some ideas are coming to me:
>> >>>> - it is quite easy to integrate LESS since we can use Rhino to launch
>> >> the
>> >>>> LESS preprocessor (which is a javascript program). See:
>> >>>> https://github.com/sandroboehme/lesscss-java
>> >>>> - we need a cache system in order to not always compute the style.css
>> >>>> served to the user (performances issue).
>> >>>> - we need to add this in the "skin" action.
>> >>>> - in the future, we also need to modify the skinx actions, to enable
>> it
>> >>>> for Skin Extensions.
>> >>>>
>> >>>> We also need to agree on the use of LESS instead of SASS. I have used
>> >>> LESS
>> >>>> on Flamingo because Bootstrap has originally been written with it
>> >>> (although
>> >>>> an official SASS port exists), so this choice is not based on a
>> strong
>> >>>> analysis. Anyway, it looks quite simple to move from one to the other
>> >> and
>> >>>> it is probably too soon to predict which of these 2 preprocessors
>> will
>> >>> win
>> >>>> on the long term.
>> >>>>
>> >>>> Do you think I am going in the right direction?
>> >>>>
>> >>>> Thanks for reading,
>> >>>> Guillaume
>> >>>>
>> >>>>
>> >>> _______________________________________________
>> >>> devs mailing list
>> >>> [hidden email]
>> >>> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>
>> >> _______________________________________________
>> >> devs mailing list
>> >> [hidden email]
>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>
>> > _______________________________________________
>> > devs mailing list
>> > [hidden email]
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

jerem
In reply to this post by Caleb James DeLisle-3
2014-04-29 9:58 GMT+02:00 Caleb James DeLisle <[hidden email]>:

> My 2 cents worth is all that matters is community.
> Between Groovy, Velocity (I think we're now the biggest user of that) and
> prototypejs, we're pretty good at backing the wrong horse.
>
>
That may be right but as of now at least, groovy/velocity are popular at
least among xwiki current users (dev oriented ones).
I'm really glad personally that you didn't choose PHP or JSPs even if they
were (and are) far more popular than Velocity ... ;)


> In 3-5 years, one of LESS/SASS (or perhaps something else entirely) will be
> the standard for CSS preprocessing and the other will be a historical
> amusement.
>

Maybe CSS preprocessing as we know now, will be a historical amusement.
It's still very very young. To me it mostly looks like hacks added to
workaround things that pure css SHOULD manage ideally, or should not have
to manage at all... Not saying that css preprocessing is bad though of
course :)
The problem is that the "best" and the "most popular" are not always the
same ... (to say the least)

Lets not be the ones left holding the bag.

>
> Thanks,
> Caleb
>
>
> On 04/28/2014 06:01 PM, Guillaume "Louis-Marie" Delhumeau wrote:
> > 2014-04-28 16:33 GMT+02:00 Ecaterina Moraru (Valica) <[hidden email]
> >:
> >
> >> My major concern about Sass is the syntax very similar to Velocity and
> the
> >> way we will handle the parsable style sheets.
> >>
> >
> > I think you talk about the fact that variables are prefixed with $ in
> SASS.
> >
> > 2 solutions:
> > - it should be possible to escape the $ when velocity should ignore the
> > variable
> > - when the variable does not exist in the velocity context, it displays
> > $variable and it does not fail.
> >
> > I personally prefer LESS for the reason for this reason, but regarding
> the
> > performances, we might consider the things differently, even with a cache
> > system (which will be needed anyway).
> >
> > I need more opinions about this.
> >
> > Thanks,
> > Guillaume
> >
> >
> >>
> >> Thanks,
> >> Caty
> >>
> >>
> >> On Mon, Apr 28, 2014 at 5:21 PM, Guillaume "Louis-Marie" Delhumeau <
> >> [hidden email]> wrote:
> >>
> >>> Hi guys.
> >>>
> >>> Since we did not have made a strong analysis on SASS, I have played a
> bit
> >>> with it to compare.
> >>>
> >>> Thomas had the intuition that it should perform faster, because JRuby
> is
> >> a
> >>> better implementation for Ruby than Rhino is for JS.
> >>>
> >>> So I have published a little benchmark about them, that you can see
> >> there:
> >>> https://github.com/xwiki-contrib/less-vs-sass-benchmark
> >>>
> >>> The benchmark is about the time that it takes to compile Bootstrap.
> >>>
> >>> The results are very clear, SASS perform 2 times faster than LESS.
> >>>
> >>> Since it seems easy to switch from LESS to SASS (bootstrap had written
> a
> >>> converter), maybe we should consider this option.
> >>>
> >>> Other thing:
> >>> I would like to run Velocity on the sources of my CSS, in order to
> easily
> >>> integrate the color theme variables. But it is risky to run velocity on
> >> the
> >>> whole tree of bootstrap sources (just imagine that bootstrap has an
> "#if"
> >>> ID...).
> >>>
> >>> So Thomas and I suggest that we can run Velocity on files suffixed by
> >>> .scss.vm or .less.vm, to only run velocity on some files (for example:
> >>> color-theme.less.vm) that we handle.
> >>>
> >>> WDYT?
> >>>
> >>> Thanks,
> >>> Guillaume
> >>>
> >>>
> >>> 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
> >>> [hidden email]>:
> >>>
> >>>> Hello.
> >>>>
> >>>> In 6.0, we have released a first version of Flamingo. It uses
> Bootstrap
> >>>> and the LESS preprocessor during the build to create the final
> >> style.css
> >>>> file.
> >>>>
> >>>> But currently, there is a serious regression compared to Colibri: it
> >> does
> >>>> not support color themes.
> >>>>
> >>>> So I have started a proposal about the color theme handling in
> >> Flamingo,
> >>>> that you can see there:
> >>>> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
> >>>>
> >>>> My conclusion is that we need to integrate the LESS preprocesor on the
> >>>> runtime. This way, we can add velocity variables (corresponding to the
> >>>> color theme) in our LESS sources BEFORE the LESS preprocessor is
> >>> launched.
> >>>> Doing the opposite, (process velocity after LESS) causes some problems
> >>> that
> >>>> I have reported on the previous link.
> >>>>
> >>>> To me, it would be a good step ahead for proposing LESS to our users.
> >>>>
> >>>> Regarding this, some ideas are coming to me:
> >>>> - it is quite easy to integrate LESS since we can use Rhino to launch
> >> the
> >>>> LESS preprocessor (which is a javascript program). See:
> >>>> https://github.com/sandroboehme/lesscss-java
> >>>> - we need a cache system in order to not always compute the style.css
> >>>> served to the user (performances issue).
> >>>> - we need to add this in the "skin" action.
> >>>> - in the future, we also need to modify the skinx actions, to enable
> it
> >>>> for Skin Extensions.
> >>>>
> >>>> We also need to agree on the use of LESS instead of SASS. I have used
> >>> LESS
> >>>> on Flamingo because Bootstrap has originally been written with it
> >>> (although
> >>>> an official SASS port exists), so this choice is not based on a strong
> >>>> analysis. Anyway, it looks quite simple to move from one to the other
> >> and
> >>>> it is probably too soon to predict which of these 2 preprocessors will
> >>> win
> >>>> on the long term.
> >>>>
> >>>> Do you think I am going in the right direction?
> >>>>
> >>>> Thanks for reading,
> >>>> Guillaume
> >>>>
> >>>>
> >>> _______________________________________________
> >>> devs mailing list
> >>> [hidden email]
> >>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>
> >> _______________________________________________
> >> devs mailing list
> >> [hidden email]
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Guillaume "Louis-Marie" Delhumeau
One point in favour of SASS (SCSS): it seems more customizable. For
example, we can define our own SASS functions (like
xwiki-colortheme-get('variable_name')) or our own Importer (for example,
@import will not look in the filesystem but somewhere in our XWiki
instance).

In this case, we can simply avoid using velocity.

See:
http://sass-lang.com/documentation/file.SASS_REFERENCE.html#defining_custom_sass_functions



2014-04-29 15:35 GMT+02:00 Jeremie BOUSQUET <[hidden email]>:

> 2014-04-29 9:58 GMT+02:00 Caleb James DeLisle <[hidden email]>:
>
> > My 2 cents worth is all that matters is community.
> > Between Groovy, Velocity (I think we're now the biggest user of that) and
> > prototypejs, we're pretty good at backing the wrong horse.
> >
> >
> That may be right but as of now at least, groovy/velocity are popular at
> least among xwiki current users (dev oriented ones).
> I'm really glad personally that you didn't choose PHP or JSPs even if they
> were (and are) far more popular than Velocity ... ;)
>
>
> > In 3-5 years, one of LESS/SASS (or perhaps something else entirely) will
> be
> > the standard for CSS preprocessing and the other will be a historical
> > amusement.
> >
>
> Maybe CSS preprocessing as we know now, will be a historical amusement.
> It's still very very young. To me it mostly looks like hacks added to
> workaround things that pure css SHOULD manage ideally, or should not have
> to manage at all... Not saying that css preprocessing is bad though of
> course :)
> The problem is that the "best" and the "most popular" are not always the
> same ... (to say the least)
>
> Lets not be the ones left holding the bag.
> >
> > Thanks,
> > Caleb
> >
> >
> > On 04/28/2014 06:01 PM, Guillaume "Louis-Marie" Delhumeau wrote:
> > > 2014-04-28 16:33 GMT+02:00 Ecaterina Moraru (Valica) <
> [hidden email]
> > >:
> > >
> > >> My major concern about Sass is the syntax very similar to Velocity and
> > the
> > >> way we will handle the parsable style sheets.
> > >>
> > >
> > > I think you talk about the fact that variables are prefixed with $ in
> > SASS.
> > >
> > > 2 solutions:
> > > - it should be possible to escape the $ when velocity should ignore the
> > > variable
> > > - when the variable does not exist in the velocity context, it displays
> > > $variable and it does not fail.
> > >
> > > I personally prefer LESS for the reason for this reason, but regarding
> > the
> > > performances, we might consider the things differently, even with a
> cache
> > > system (which will be needed anyway).
> > >
> > > I need more opinions about this.
> > >
> > > Thanks,
> > > Guillaume
> > >
> > >
> > >>
> > >> Thanks,
> > >> Caty
> > >>
> > >>
> > >> On Mon, Apr 28, 2014 at 5:21 PM, Guillaume "Louis-Marie" Delhumeau <
> > >> [hidden email]> wrote:
> > >>
> > >>> Hi guys.
> > >>>
> > >>> Since we did not have made a strong analysis on SASS, I have played a
> > bit
> > >>> with it to compare.
> > >>>
> > >>> Thomas had the intuition that it should perform faster, because JRuby
> > is
> > >> a
> > >>> better implementation for Ruby than Rhino is for JS.
> > >>>
> > >>> So I have published a little benchmark about them, that you can see
> > >> there:
> > >>> https://github.com/xwiki-contrib/less-vs-sass-benchmark
> > >>>
> > >>> The benchmark is about the time that it takes to compile Bootstrap.
> > >>>
> > >>> The results are very clear, SASS perform 2 times faster than LESS.
> > >>>
> > >>> Since it seems easy to switch from LESS to SASS (bootstrap had
> written
> > a
> > >>> converter), maybe we should consider this option.
> > >>>
> > >>> Other thing:
> > >>> I would like to run Velocity on the sources of my CSS, in order to
> > easily
> > >>> integrate the color theme variables. But it is risky to run velocity
> on
> > >> the
> > >>> whole tree of bootstrap sources (just imagine that bootstrap has an
> > "#if"
> > >>> ID...).
> > >>>
> > >>> So Thomas and I suggest that we can run Velocity on files suffixed by
> > >>> .scss.vm or .less.vm, to only run velocity on some files (for
> example:
> > >>> color-theme.less.vm) that we handle.
> > >>>
> > >>> WDYT?
> > >>>
> > >>> Thanks,
> > >>> Guillaume
> > >>>
> > >>>
> > >>> 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
> > >>> [hidden email]>:
> > >>>
> > >>>> Hello.
> > >>>>
> > >>>> In 6.0, we have released a first version of Flamingo. It uses
> > Bootstrap
> > >>>> and the LESS preprocessor during the build to create the final
> > >> style.css
> > >>>> file.
> > >>>>
> > >>>> But currently, there is a serious regression compared to Colibri: it
> > >> does
> > >>>> not support color themes.
> > >>>>
> > >>>> So I have started a proposal about the color theme handling in
> > >> Flamingo,
> > >>>> that you can see there:
> > >>>>
> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
> > >>>>
> > >>>> My conclusion is that we need to integrate the LESS preprocesor on
> the
> > >>>> runtime. This way, we can add velocity variables (corresponding to
> the
> > >>>> color theme) in our LESS sources BEFORE the LESS preprocessor is
> > >>> launched.
> > >>>> Doing the opposite, (process velocity after LESS) causes some
> problems
> > >>> that
> > >>>> I have reported on the previous link.
> > >>>>
> > >>>> To me, it would be a good step ahead for proposing LESS to our
> users.
> > >>>>
> > >>>> Regarding this, some ideas are coming to me:
> > >>>> - it is quite easy to integrate LESS since we can use Rhino to
> launch
> > >> the
> > >>>> LESS preprocessor (which is a javascript program). See:
> > >>>> https://github.com/sandroboehme/lesscss-java
> > >>>> - we need a cache system in order to not always compute the
> style.css
> > >>>> served to the user (performances issue).
> > >>>> - we need to add this in the "skin" action.
> > >>>> - in the future, we also need to modify the skinx actions, to enable
> > it
> > >>>> for Skin Extensions.
> > >>>>
> > >>>> We also need to agree on the use of LESS instead of SASS. I have
> used
> > >>> LESS
> > >>>> on Flamingo because Bootstrap has originally been written with it
> > >>> (although
> > >>>> an official SASS port exists), so this choice is not based on a
> strong
> > >>>> analysis. Anyway, it looks quite simple to move from one to the
> other
> > >> and
> > >>>> it is probably too soon to predict which of these 2 preprocessors
> will
> > >>> win
> > >>>> on the long term.
> > >>>>
> > >>>> Do you think I am going in the right direction?
> > >>>>
> > >>>> Thanks for reading,
> > >>>> Guillaume
> > >>>>
> > >>>>
> > >>> _______________________________________________
> > >>> devs mailing list
> > >>> [hidden email]
> > >>> http://lists.xwiki.org/mailman/listinfo/devs
> > >>>
> > >> _______________________________________________
> > >> devs mailing list
> > >> [hidden email]
> > >> http://lists.xwiki.org/mailman/listinfo/devs
> > >>
> > > _______________________________________________
> > > devs mailing list
> > > [hidden email]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Caleb James DeLisle-3
https://encrypted.google.com/search?q=less+css -> About 116,000,000 results (less is a common word so this is skewed)
https://encrypted.google.com/search?q=sass+css -> About 2,480,000 results

https://github.com/less/less.js -> 1756 commits, 152 contributors, 2296 forks
https://github.com/nex3/sass -> 5554 commits, 135 contributors, 650 forks

Less feels a bit safer from a community standpoint,
both have java/C/ruby/js implementations (node-sass is a binding to the C version).

These numbers seem to be suggesting that consensus will form around Less if anything.

Thanks,
Caleb


On 04/30/2014 01:22 PM, Guillaume "Louis-Marie" Delhumeau wrote:

> One point in favour of SASS (SCSS): it seems more customizable. For
> example, we can define our own SASS functions (like
> xwiki-colortheme-get('variable_name')) or our own Importer (for example,
> @import will not look in the filesystem but somewhere in our XWiki
> instance).
>
> In this case, we can simply avoid using velocity.
>
> See:
> http://sass-lang.com/documentation/file.SASS_REFERENCE.html#defining_custom_sass_functions
>
>
>
> 2014-04-29 15:35 GMT+02:00 Jeremie BOUSQUET <[hidden email]>:
>
>> 2014-04-29 9:58 GMT+02:00 Caleb James DeLisle <[hidden email]>:
>>
>>> My 2 cents worth is all that matters is community.
>>> Between Groovy, Velocity (I think we're now the biggest user of that) and
>>> prototypejs, we're pretty good at backing the wrong horse.
>>>
>>>
>> That may be right but as of now at least, groovy/velocity are popular at
>> least among xwiki current users (dev oriented ones).
>> I'm really glad personally that you didn't choose PHP or JSPs even if they
>> were (and are) far more popular than Velocity ... ;)
>>
>>
>>> In 3-5 years, one of LESS/SASS (or perhaps something else entirely) will
>> be
>>> the standard for CSS preprocessing and the other will be a historical
>>> amusement.
>>>
>>
>> Maybe CSS preprocessing as we know now, will be a historical amusement.
>> It's still very very young. To me it mostly looks like hacks added to
>> workaround things that pure css SHOULD manage ideally, or should not have
>> to manage at all... Not saying that css preprocessing is bad though of
>> course :)
>> The problem is that the "best" and the "most popular" are not always the
>> same ... (to say the least)
>>
>> Lets not be the ones left holding the bag.
>>>
>>> Thanks,
>>> Caleb
>>>
>>>
>>> On 04/28/2014 06:01 PM, Guillaume "Louis-Marie" Delhumeau wrote:
>>>> 2014-04-28 16:33 GMT+02:00 Ecaterina Moraru (Valica) <
>> [hidden email]
>>>> :
>>>>
>>>>> My major concern about Sass is the syntax very similar to Velocity and
>>> the
>>>>> way we will handle the parsable style sheets.
>>>>>
>>>>
>>>> I think you talk about the fact that variables are prefixed with $ in
>>> SASS.
>>>>
>>>> 2 solutions:
>>>> - it should be possible to escape the $ when velocity should ignore the
>>>> variable
>>>> - when the variable does not exist in the velocity context, it displays
>>>> $variable and it does not fail.
>>>>
>>>> I personally prefer LESS for the reason for this reason, but regarding
>>> the
>>>> performances, we might consider the things differently, even with a
>> cache
>>>> system (which will be needed anyway).
>>>>
>>>> I need more opinions about this.
>>>>
>>>> Thanks,
>>>> Guillaume
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Caty
>>>>>
>>>>>
>>>>> On Mon, Apr 28, 2014 at 5:21 PM, Guillaume "Louis-Marie" Delhumeau <
>>>>> [hidden email]> wrote:
>>>>>
>>>>>> Hi guys.
>>>>>>
>>>>>> Since we did not have made a strong analysis on SASS, I have played a
>>> bit
>>>>>> with it to compare.
>>>>>>
>>>>>> Thomas had the intuition that it should perform faster, because JRuby
>>> is
>>>>> a
>>>>>> better implementation for Ruby than Rhino is for JS.
>>>>>>
>>>>>> So I have published a little benchmark about them, that you can see
>>>>> there:
>>>>>> https://github.com/xwiki-contrib/less-vs-sass-benchmark
>>>>>>
>>>>>> The benchmark is about the time that it takes to compile Bootstrap.
>>>>>>
>>>>>> The results are very clear, SASS perform 2 times faster than LESS.
>>>>>>
>>>>>> Since it seems easy to switch from LESS to SASS (bootstrap had
>> written
>>> a
>>>>>> converter), maybe we should consider this option.
>>>>>>
>>>>>> Other thing:
>>>>>> I would like to run Velocity on the sources of my CSS, in order to
>>> easily
>>>>>> integrate the color theme variables. But it is risky to run velocity
>> on
>>>>> the
>>>>>> whole tree of bootstrap sources (just imagine that bootstrap has an
>>> "#if"
>>>>>> ID...).
>>>>>>
>>>>>> So Thomas and I suggest that we can run Velocity on files suffixed by
>>>>>> .scss.vm or .less.vm, to only run velocity on some files (for
>> example:
>>>>>> color-theme.less.vm) that we handle.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Thanks,
>>>>>> Guillaume
>>>>>>
>>>>>>
>>>>>> 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
>>>>>> [hidden email]>:
>>>>>>
>>>>>>> Hello.
>>>>>>>
>>>>>>> In 6.0, we have released a first version of Flamingo. It uses
>>> Bootstrap
>>>>>>> and the LESS preprocessor during the build to create the final
>>>>> style.css
>>>>>>> file.
>>>>>>>
>>>>>>> But currently, there is a serious regression compared to Colibri: it
>>>>> does
>>>>>>> not support color themes.
>>>>>>>
>>>>>>> So I have started a proposal about the color theme handling in
>>>>> Flamingo,
>>>>>>> that you can see there:
>>>>>>>
>> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
>>>>>>>
>>>>>>> My conclusion is that we need to integrate the LESS preprocesor on
>> the
>>>>>>> runtime. This way, we can add velocity variables (corresponding to
>> the
>>>>>>> color theme) in our LESS sources BEFORE the LESS preprocessor is
>>>>>> launched.
>>>>>>> Doing the opposite, (process velocity after LESS) causes some
>> problems
>>>>>> that
>>>>>>> I have reported on the previous link.
>>>>>>>
>>>>>>> To me, it would be a good step ahead for proposing LESS to our
>> users.
>>>>>>>
>>>>>>> Regarding this, some ideas are coming to me:
>>>>>>> - it is quite easy to integrate LESS since we can use Rhino to
>> launch
>>>>> the
>>>>>>> LESS preprocessor (which is a javascript program). See:
>>>>>>> https://github.com/sandroboehme/lesscss-java
>>>>>>> - we need a cache system in order to not always compute the
>> style.css
>>>>>>> served to the user (performances issue).
>>>>>>> - we need to add this in the "skin" action.
>>>>>>> - in the future, we also need to modify the skinx actions, to enable
>>> it
>>>>>>> for Skin Extensions.
>>>>>>>
>>>>>>> We also need to agree on the use of LESS instead of SASS. I have
>> used
>>>>>> LESS
>>>>>>> on Flamingo because Bootstrap has originally been written with it
>>>>>> (although
>>>>>>> an official SASS port exists), so this choice is not based on a
>> strong
>>>>>>> analysis. Anyway, it looks quite simple to move from one to the
>> other
>>>>> and
>>>>>>> it is probably too soon to predict which of these 2 preprocessors
>> will
>>>>>> win
>>>>>>> on the long term.
>>>>>>>
>>>>>>> Do you think I am going in the right direction?
>>>>>>>
>>>>>>> Thanks for reading,
>>>>>>> Guillaume
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> devs mailing list
>>>>>> [hidden email]
>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>
>>>>> _______________________________________________
>>>>> devs mailing list
>>>>> [hidden email]
>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>
>>>> _______________________________________________
>>>> devs mailing list
>>>> [hidden email]
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>
>>> _______________________________________________
>>> devs mailing list
>>> [hidden email]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Roman Muntyanu
My 2 cents :)
http://www.ohloh.net/p/compare?project_0=Sass&project_1=lesscss

-----Original Message-----
From: devs [mailto:[hidden email]] On Behalf Of Caleb James DeLisle
Sent: Wednesday, April 30, 2014 15:33 PM
To: XWiki Developers
Subject: Re: [xwiki-devs] [Proposal] Integrate LESS css in XWiki

https://encrypted.google.com/search?q=less+css -> About 116,000,000 results (less is a common word so this is skewed) https://encrypted.google.com/search?q=sass+css -> About 2,480,000 results

https://github.com/less/less.js -> 1756 commits, 152 contributors, 2296 forks https://github.com/nex3/sass -> 5554 commits, 135 contributors, 650 forks

Less feels a bit safer from a community standpoint, both have java/C/ruby/js implementations (node-sass is a binding to the C version).

These numbers seem to be suggesting that consensus will form around Less if anything.

Thanks,
Caleb


On 04/30/2014 01:22 PM, Guillaume "Louis-Marie" Delhumeau wrote:

> One point in favour of SASS (SCSS): it seems more customizable. For
> example, we can define our own SASS functions (like
> xwiki-colortheme-get('variable_name')) or our own Importer (for
> example, @import will not look in the filesystem but somewhere in our
> XWiki instance).
>
> In this case, we can simply avoid using velocity.
>
> See:
> http://sass-lang.com/documentation/file.SASS_REFERENCE.html#defining_c
> ustom_sass_functions
>
>
>
> 2014-04-29 15:35 GMT+02:00 Jeremie BOUSQUET <[hidden email]>:
>
>> 2014-04-29 9:58 GMT+02:00 Caleb James DeLisle <[hidden email]>:
>>
>>> My 2 cents worth is all that matters is community.
>>> Between Groovy, Velocity (I think we're now the biggest user of
>>> that) and prototypejs, we're pretty good at backing the wrong horse.
>>>
>>>
>> That may be right but as of now at least, groovy/velocity are popular
>> at least among xwiki current users (dev oriented ones).
>> I'm really glad personally that you didn't choose PHP or JSPs even if
>> they were (and are) far more popular than Velocity ... ;)
>>
>>
>>> In 3-5 years, one of LESS/SASS (or perhaps something else entirely)
>>> will
>> be
>>> the standard for CSS preprocessing and the other will be a
>>> historical amusement.
>>>
>>
>> Maybe CSS preprocessing as we know now, will be a historical amusement.
>> It's still very very young. To me it mostly looks like hacks added to
>> workaround things that pure css SHOULD manage ideally, or should not
>> have to manage at all... Not saying that css preprocessing is bad
>> though of course :) The problem is that the "best" and the "most
>> popular" are not always the same ... (to say the least)
>>
>> Lets not be the ones left holding the bag.
>>>
>>> Thanks,
>>> Caleb
>>>
>>>
>>> On 04/28/2014 06:01 PM, Guillaume "Louis-Marie" Delhumeau wrote:
>>>> 2014-04-28 16:33 GMT+02:00 Ecaterina Moraru (Valica) <
>> [hidden email]
>>>> :
>>>>
>>>>> My major concern about Sass is the syntax very similar to Velocity
>>>>> and
>>> the
>>>>> way we will handle the parsable style sheets.
>>>>>
>>>>
>>>> I think you talk about the fact that variables are prefixed with $
>>>> in
>>> SASS.
>>>>
>>>> 2 solutions:
>>>> - it should be possible to escape the $ when velocity should ignore
>>>> the variable
>>>> - when the variable does not exist in the velocity context, it
>>>> displays $variable and it does not fail.
>>>>
>>>> I personally prefer LESS for the reason for this reason, but
>>>> regarding
>>> the
>>>> performances, we might consider the things differently, even with a
>> cache
>>>> system (which will be needed anyway).
>>>>
>>>> I need more opinions about this.
>>>>
>>>> Thanks,
>>>> Guillaume
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Caty
>>>>>
>>>>>
>>>>> On Mon, Apr 28, 2014 at 5:21 PM, Guillaume "Louis-Marie" Delhumeau
>>>>> < [hidden email]> wrote:
>>>>>
>>>>>> Hi guys.
>>>>>>
>>>>>> Since we did not have made a strong analysis on SASS, I have
>>>>>> played a
>>> bit
>>>>>> with it to compare.
>>>>>>
>>>>>> Thomas had the intuition that it should perform faster, because
>>>>>> JRuby
>>> is
>>>>> a
>>>>>> better implementation for Ruby than Rhino is for JS.
>>>>>>
>>>>>> So I have published a little benchmark about them, that you can
>>>>>> see
>>>>> there:
>>>>>> https://github.com/xwiki-contrib/less-vs-sass-benchmark
>>>>>>
>>>>>> The benchmark is about the time that it takes to compile Bootstrap.
>>>>>>
>>>>>> The results are very clear, SASS perform 2 times faster than LESS.
>>>>>>
>>>>>> Since it seems easy to switch from LESS to SASS (bootstrap had
>> written
>>> a
>>>>>> converter), maybe we should consider this option.
>>>>>>
>>>>>> Other thing:
>>>>>> I would like to run Velocity on the sources of my CSS, in order
>>>>>> to
>>> easily
>>>>>> integrate the color theme variables. But it is risky to run
>>>>>> velocity
>> on
>>>>> the
>>>>>> whole tree of bootstrap sources (just imagine that bootstrap has
>>>>>> an
>>> "#if"
>>>>>> ID...).
>>>>>>
>>>>>> So Thomas and I suggest that we can run Velocity on files
>>>>>> suffixed by .scss.vm or .less.vm, to only run velocity on some
>>>>>> files (for
>> example:
>>>>>> color-theme.less.vm) that we handle.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Thanks,
>>>>>> Guillaume
>>>>>>
>>>>>>
>>>>>> 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
>>>>>> [hidden email]>:
>>>>>>
>>>>>>> Hello.
>>>>>>>
>>>>>>> In 6.0, we have released a first version of Flamingo. It uses
>>> Bootstrap
>>>>>>> and the LESS preprocessor during the build to create the final
>>>>> style.css
>>>>>>> file.
>>>>>>>
>>>>>>> But currently, there is a serious regression compared to
>>>>>>> Colibri: it
>>>>> does
>>>>>>> not support color themes.
>>>>>>>
>>>>>>> So I have started a proposal about the color theme handling in
>>>>> Flamingo,
>>>>>>> that you can see there:
>>>>>>>
>> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
>>>>>>>
>>>>>>> My conclusion is that we need to integrate the LESS preprocesor
>>>>>>> on
>> the
>>>>>>> runtime. This way, we can add velocity variables (corresponding
>>>>>>> to
>> the
>>>>>>> color theme) in our LESS sources BEFORE the LESS preprocessor is
>>>>>> launched.
>>>>>>> Doing the opposite, (process velocity after LESS) causes some
>> problems
>>>>>> that
>>>>>>> I have reported on the previous link.
>>>>>>>
>>>>>>> To me, it would be a good step ahead for proposing LESS to our
>> users.
>>>>>>>
>>>>>>> Regarding this, some ideas are coming to me:
>>>>>>> - it is quite easy to integrate LESS since we can use Rhino to
>> launch
>>>>> the
>>>>>>> LESS preprocessor (which is a javascript program). See:
>>>>>>> https://github.com/sandroboehme/lesscss-java
>>>>>>> - we need a cache system in order to not always compute the
>> style.css
>>>>>>> served to the user (performances issue).
>>>>>>> - we need to add this in the "skin" action.
>>>>>>> - in the future, we also need to modify the skinx actions, to
>>>>>>> enable
>>> it
>>>>>>> for Skin Extensions.
>>>>>>>
>>>>>>> We also need to agree on the use of LESS instead of SASS. I have
>> used
>>>>>> LESS
>>>>>>> on Flamingo because Bootstrap has originally been written with
>>>>>>> it
>>>>>> (although
>>>>>>> an official SASS port exists), so this choice is not based on a
>> strong
>>>>>>> analysis. Anyway, it looks quite simple to move from one to the
>> other
>>>>> and
>>>>>>> it is probably too soon to predict which of these 2
>>>>>>> preprocessors
>> will
>>>>>> win
>>>>>>> on the long term.
>>>>>>>
>>>>>>> Do you think I am going in the right direction?
>>>>>>>
>>>>>>> Thanks for reading,
>>>>>>> Guillaume
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> devs mailing list
>>>>>> [hidden email]
>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>
>>>>> _______________________________________________
>>>>> devs mailing list
>>>>> [hidden email]
>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>
>>>> _______________________________________________
>>>> devs mailing list
>>>> [hidden email]
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>
>>> _______________________________________________
>>> devs mailing list
>>> [hidden email]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Thomas Mortagne
Administrator
In reply to this post by Caleb James DeLisle-3
On Wed, Apr 30, 2014 at 2:33 PM, Caleb James DeLisle <[hidden email]> wrote:
> https://encrypted.google.com/search?q=less+css -> About 116,000,000 results (less is a common word so this is skewed)
> https://encrypted.google.com/search?q=sass+css -> About 2,480,000 results
>
> https://github.com/less/less.js -> 1756 commits, 152 contributors, 2296 forks
> https://github.com/nex3/sass -> 5554 commits, 135 contributors, 650 forks
>
> Less feels a bit safer from a community standpoint,

> both have java/C/ruby/js implementations (node-sass is a binding to the C version).

No they don't, the only working implementation of less is in js for example.

>
> These numbers seem to be suggesting that consensus will form around Less if anything.
>
> Thanks,
> Caleb
>
>
> On 04/30/2014 01:22 PM, Guillaume "Louis-Marie" Delhumeau wrote:
>> One point in favour of SASS (SCSS): it seems more customizable. For
>> example, we can define our own SASS functions (like
>> xwiki-colortheme-get('variable_name')) or our own Importer (for example,
>> @import will not look in the filesystem but somewhere in our XWiki
>> instance).
>>
>> In this case, we can simply avoid using velocity.
>>
>> See:
>> http://sass-lang.com/documentation/file.SASS_REFERENCE.html#defining_custom_sass_functions
>>
>>
>>
>> 2014-04-29 15:35 GMT+02:00 Jeremie BOUSQUET <[hidden email]>:
>>
>>> 2014-04-29 9:58 GMT+02:00 Caleb James DeLisle <[hidden email]>:
>>>
>>>> My 2 cents worth is all that matters is community.
>>>> Between Groovy, Velocity (I think we're now the biggest user of that) and
>>>> prototypejs, we're pretty good at backing the wrong horse.
>>>>
>>>>
>>> That may be right but as of now at least, groovy/velocity are popular at
>>> least among xwiki current users (dev oriented ones).
>>> I'm really glad personally that you didn't choose PHP or JSPs even if they
>>> were (and are) far more popular than Velocity ... ;)
>>>
>>>
>>>> In 3-5 years, one of LESS/SASS (or perhaps something else entirely) will
>>> be
>>>> the standard for CSS preprocessing and the other will be a historical
>>>> amusement.
>>>>
>>>
>>> Maybe CSS preprocessing as we know now, will be a historical amusement.
>>> It's still very very young. To me it mostly looks like hacks added to
>>> workaround things that pure css SHOULD manage ideally, or should not have
>>> to manage at all... Not saying that css preprocessing is bad though of
>>> course :)
>>> The problem is that the "best" and the "most popular" are not always the
>>> same ... (to say the least)
>>>
>>> Lets not be the ones left holding the bag.
>>>>
>>>> Thanks,
>>>> Caleb
>>>>
>>>>
>>>> On 04/28/2014 06:01 PM, Guillaume "Louis-Marie" Delhumeau wrote:
>>>>> 2014-04-28 16:33 GMT+02:00 Ecaterina Moraru (Valica) <
>>> [hidden email]
>>>>> :
>>>>>
>>>>>> My major concern about Sass is the syntax very similar to Velocity and
>>>> the
>>>>>> way we will handle the parsable style sheets.
>>>>>>
>>>>>
>>>>> I think you talk about the fact that variables are prefixed with $ in
>>>> SASS.
>>>>>
>>>>> 2 solutions:
>>>>> - it should be possible to escape the $ when velocity should ignore the
>>>>> variable
>>>>> - when the variable does not exist in the velocity context, it displays
>>>>> $variable and it does not fail.
>>>>>
>>>>> I personally prefer LESS for the reason for this reason, but regarding
>>>> the
>>>>> performances, we might consider the things differently, even with a
>>> cache
>>>>> system (which will be needed anyway).
>>>>>
>>>>> I need more opinions about this.
>>>>>
>>>>> Thanks,
>>>>> Guillaume
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Caty
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 28, 2014 at 5:21 PM, Guillaume "Louis-Marie" Delhumeau <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>> Hi guys.
>>>>>>>
>>>>>>> Since we did not have made a strong analysis on SASS, I have played a
>>>> bit
>>>>>>> with it to compare.
>>>>>>>
>>>>>>> Thomas had the intuition that it should perform faster, because JRuby
>>>> is
>>>>>> a
>>>>>>> better implementation for Ruby than Rhino is for JS.
>>>>>>>
>>>>>>> So I have published a little benchmark about them, that you can see
>>>>>> there:
>>>>>>> https://github.com/xwiki-contrib/less-vs-sass-benchmark
>>>>>>>
>>>>>>> The benchmark is about the time that it takes to compile Bootstrap.
>>>>>>>
>>>>>>> The results are very clear, SASS perform 2 times faster than LESS.
>>>>>>>
>>>>>>> Since it seems easy to switch from LESS to SASS (bootstrap had
>>> written
>>>> a
>>>>>>> converter), maybe we should consider this option.
>>>>>>>
>>>>>>> Other thing:
>>>>>>> I would like to run Velocity on the sources of my CSS, in order to
>>>> easily
>>>>>>> integrate the color theme variables. But it is risky to run velocity
>>> on
>>>>>> the
>>>>>>> whole tree of bootstrap sources (just imagine that bootstrap has an
>>>> "#if"
>>>>>>> ID...).
>>>>>>>
>>>>>>> So Thomas and I suggest that we can run Velocity on files suffixed by
>>>>>>> .scss.vm or .less.vm, to only run velocity on some files (for
>>> example:
>>>>>>> color-theme.less.vm) that we handle.
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Guillaume
>>>>>>>
>>>>>>>
>>>>>>> 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
>>>>>>> [hidden email]>:
>>>>>>>
>>>>>>>> Hello.
>>>>>>>>
>>>>>>>> In 6.0, we have released a first version of Flamingo. It uses
>>>> Bootstrap
>>>>>>>> and the LESS preprocessor during the build to create the final
>>>>>> style.css
>>>>>>>> file.
>>>>>>>>
>>>>>>>> But currently, there is a serious regression compared to Colibri: it
>>>>>> does
>>>>>>>> not support color themes.
>>>>>>>>
>>>>>>>> So I have started a proposal about the color theme handling in
>>>>>> Flamingo,
>>>>>>>> that you can see there:
>>>>>>>>
>>> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
>>>>>>>>
>>>>>>>> My conclusion is that we need to integrate the LESS preprocesor on
>>> the
>>>>>>>> runtime. This way, we can add velocity variables (corresponding to
>>> the
>>>>>>>> color theme) in our LESS sources BEFORE the LESS preprocessor is
>>>>>>> launched.
>>>>>>>> Doing the opposite, (process velocity after LESS) causes some
>>> problems
>>>>>>> that
>>>>>>>> I have reported on the previous link.
>>>>>>>>
>>>>>>>> To me, it would be a good step ahead for proposing LESS to our
>>> users.
>>>>>>>>
>>>>>>>> Regarding this, some ideas are coming to me:
>>>>>>>> - it is quite easy to integrate LESS since we can use Rhino to
>>> launch
>>>>>> the
>>>>>>>> LESS preprocessor (which is a javascript program). See:
>>>>>>>> https://github.com/sandroboehme/lesscss-java
>>>>>>>> - we need a cache system in order to not always compute the
>>> style.css
>>>>>>>> served to the user (performances issue).
>>>>>>>> - we need to add this in the "skin" action.
>>>>>>>> - in the future, we also need to modify the skinx actions, to enable
>>>> it
>>>>>>>> for Skin Extensions.
>>>>>>>>
>>>>>>>> We also need to agree on the use of LESS instead of SASS. I have
>>> used
>>>>>>> LESS
>>>>>>>> on Flamingo because Bootstrap has originally been written with it
>>>>>>> (although
>>>>>>>> an official SASS port exists), so this choice is not based on a
>>> strong
>>>>>>>> analysis. Anyway, it looks quite simple to move from one to the
>>> other
>>>>>> and
>>>>>>>> it is probably too soon to predict which of these 2 preprocessors
>>> will
>>>>>>> win
>>>>>>>> on the long term.
>>>>>>>>
>>>>>>>> Do you think I am going in the right direction?
>>>>>>>>
>>>>>>>> Thanks for reading,
>>>>>>>> Guillaume
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> devs mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>>
>>>>>> _______________________________________________
>>>>>> devs mailing list
>>>>>> [hidden email]
>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>
>>>>> _______________________________________________
>>>>> devs mailing list
>>>>> [hidden email]
>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>
>>>> _______________________________________________
>>>> devs mailing list
>>>> [hidden email]
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>
>>> _______________________________________________
>>> devs mailing list
>>> [hidden email]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Caleb James DeLisle-3


On 04/30/2014 02:59 PM, Thomas Mortagne wrote:

> On Wed, Apr 30, 2014 at 2:33 PM, Caleb James DeLisle <[hidden email]> wrote:
>> https://encrypted.google.com/search?q=less+css -> About 116,000,000 results (less is a common word so this is skewed)
>> https://encrypted.google.com/search?q=sass+css -> About 2,480,000 results
>>
>> https://github.com/less/less.js -> 1756 commits, 152 contributors, 2296 forks
>> https://github.com/nex3/sass -> 5554 commits, 135 contributors, 650 forks
>>
>> Less feels a bit safer from a community standpoint,
>
>> both have java/C/ruby/js implementations (node-sass is a binding to the C version).
>
> No they don't, the only working implementation of less is in js for example.


https://github.com/less/less.ruby
https://github.com/marceloverdijk/lesscss-java <-- wrapper around the js impl w/ rhino
https://github.com/BramvdKroef/clessc


>
>>
>> These numbers seem to be suggesting that consensus will form around Less if anything.
>>
>> Thanks,
>> Caleb
>>
>>
>> On 04/30/2014 01:22 PM, Guillaume "Louis-Marie" Delhumeau wrote:
>>> One point in favour of SASS (SCSS): it seems more customizable. For
>>> example, we can define our own SASS functions (like
>>> xwiki-colortheme-get('variable_name')) or our own Importer (for example,
>>> @import will not look in the filesystem but somewhere in our XWiki
>>> instance).
>>>
>>> In this case, we can simply avoid using velocity.
>>>
>>> See:
>>> http://sass-lang.com/documentation/file.SASS_REFERENCE.html#defining_custom_sass_functions
>>>
>>>
>>>
>>> 2014-04-29 15:35 GMT+02:00 Jeremie BOUSQUET <[hidden email]>:
>>>
>>>> 2014-04-29 9:58 GMT+02:00 Caleb James DeLisle <[hidden email]>:
>>>>
>>>>> My 2 cents worth is all that matters is community.
>>>>> Between Groovy, Velocity (I think we're now the biggest user of that) and
>>>>> prototypejs, we're pretty good at backing the wrong horse.
>>>>>
>>>>>
>>>> That may be right but as of now at least, groovy/velocity are popular at
>>>> least among xwiki current users (dev oriented ones).
>>>> I'm really glad personally that you didn't choose PHP or JSPs even if they
>>>> were (and are) far more popular than Velocity ... ;)
>>>>
>>>>
>>>>> In 3-5 years, one of LESS/SASS (or perhaps something else entirely) will
>>>> be
>>>>> the standard for CSS preprocessing and the other will be a historical
>>>>> amusement.
>>>>>
>>>>
>>>> Maybe CSS preprocessing as we know now, will be a historical amusement.
>>>> It's still very very young. To me it mostly looks like hacks added to
>>>> workaround things that pure css SHOULD manage ideally, or should not have
>>>> to manage at all... Not saying that css preprocessing is bad though of
>>>> course :)
>>>> The problem is that the "best" and the "most popular" are not always the
>>>> same ... (to say the least)
>>>>
>>>> Lets not be the ones left holding the bag.
>>>>>
>>>>> Thanks,
>>>>> Caleb
>>>>>
>>>>>
>>>>> On 04/28/2014 06:01 PM, Guillaume "Louis-Marie" Delhumeau wrote:
>>>>>> 2014-04-28 16:33 GMT+02:00 Ecaterina Moraru (Valica) <
>>>> [hidden email]
>>>>>> :
>>>>>>
>>>>>>> My major concern about Sass is the syntax very similar to Velocity and
>>>>> the
>>>>>>> way we will handle the parsable style sheets.
>>>>>>>
>>>>>>
>>>>>> I think you talk about the fact that variables are prefixed with $ in
>>>>> SASS.
>>>>>>
>>>>>> 2 solutions:
>>>>>> - it should be possible to escape the $ when velocity should ignore the
>>>>>> variable
>>>>>> - when the variable does not exist in the velocity context, it displays
>>>>>> $variable and it does not fail.
>>>>>>
>>>>>> I personally prefer LESS for the reason for this reason, but regarding
>>>>> the
>>>>>> performances, we might consider the things differently, even with a
>>>> cache
>>>>>> system (which will be needed anyway).
>>>>>>
>>>>>> I need more opinions about this.
>>>>>>
>>>>>> Thanks,
>>>>>> Guillaume
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Caty
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 28, 2014 at 5:21 PM, Guillaume "Louis-Marie" Delhumeau <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>>> Hi guys.
>>>>>>>>
>>>>>>>> Since we did not have made a strong analysis on SASS, I have played a
>>>>> bit
>>>>>>>> with it to compare.
>>>>>>>>
>>>>>>>> Thomas had the intuition that it should perform faster, because JRuby
>>>>> is
>>>>>>> a
>>>>>>>> better implementation for Ruby than Rhino is for JS.
>>>>>>>>
>>>>>>>> So I have published a little benchmark about them, that you can see
>>>>>>> there:
>>>>>>>> https://github.com/xwiki-contrib/less-vs-sass-benchmark
>>>>>>>>
>>>>>>>> The benchmark is about the time that it takes to compile Bootstrap.
>>>>>>>>
>>>>>>>> The results are very clear, SASS perform 2 times faster than LESS.
>>>>>>>>
>>>>>>>> Since it seems easy to switch from LESS to SASS (bootstrap had
>>>> written
>>>>> a
>>>>>>>> converter), maybe we should consider this option.
>>>>>>>>
>>>>>>>> Other thing:
>>>>>>>> I would like to run Velocity on the sources of my CSS, in order to
>>>>> easily
>>>>>>>> integrate the color theme variables. But it is risky to run velocity
>>>> on
>>>>>>> the
>>>>>>>> whole tree of bootstrap sources (just imagine that bootstrap has an
>>>>> "#if"
>>>>>>>> ID...).
>>>>>>>>
>>>>>>>> So Thomas and I suggest that we can run Velocity on files suffixed by
>>>>>>>> .scss.vm or .less.vm, to only run velocity on some files (for
>>>> example:
>>>>>>>> color-theme.less.vm) that we handle.
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Guillaume
>>>>>>>>
>>>>>>>>
>>>>>>>> 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
>>>>>>>> [hidden email]>:
>>>>>>>>
>>>>>>>>> Hello.
>>>>>>>>>
>>>>>>>>> In 6.0, we have released a first version of Flamingo. It uses
>>>>> Bootstrap
>>>>>>>>> and the LESS preprocessor during the build to create the final
>>>>>>> style.css
>>>>>>>>> file.
>>>>>>>>>
>>>>>>>>> But currently, there is a serious regression compared to Colibri: it
>>>>>>> does
>>>>>>>>> not support color themes.
>>>>>>>>>
>>>>>>>>> So I have started a proposal about the color theme handling in
>>>>>>> Flamingo,
>>>>>>>>> that you can see there:
>>>>>>>>>
>>>> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
>>>>>>>>>
>>>>>>>>> My conclusion is that we need to integrate the LESS preprocesor on
>>>> the
>>>>>>>>> runtime. This way, we can add velocity variables (corresponding to
>>>> the
>>>>>>>>> color theme) in our LESS sources BEFORE the LESS preprocessor is
>>>>>>>> launched.
>>>>>>>>> Doing the opposite, (process velocity after LESS) causes some
>>>> problems
>>>>>>>> that
>>>>>>>>> I have reported on the previous link.
>>>>>>>>>
>>>>>>>>> To me, it would be a good step ahead for proposing LESS to our
>>>> users.
>>>>>>>>>
>>>>>>>>> Regarding this, some ideas are coming to me:
>>>>>>>>> - it is quite easy to integrate LESS since we can use Rhino to
>>>> launch
>>>>>>> the
>>>>>>>>> LESS preprocessor (which is a javascript program). See:
>>>>>>>>> https://github.com/sandroboehme/lesscss-java
>>>>>>>>> - we need a cache system in order to not always compute the
>>>> style.css
>>>>>>>>> served to the user (performances issue).
>>>>>>>>> - we need to add this in the "skin" action.
>>>>>>>>> - in the future, we also need to modify the skinx actions, to enable
>>>>> it
>>>>>>>>> for Skin Extensions.
>>>>>>>>>
>>>>>>>>> We also need to agree on the use of LESS instead of SASS. I have
>>>> used
>>>>>>>> LESS
>>>>>>>>> on Flamingo because Bootstrap has originally been written with it
>>>>>>>> (although
>>>>>>>>> an official SASS port exists), so this choice is not based on a
>>>> strong
>>>>>>>>> analysis. Anyway, it looks quite simple to move from one to the
>>>> other
>>>>>>> and
>>>>>>>>> it is probably too soon to predict which of these 2 preprocessors
>>>> will
>>>>>>>> win
>>>>>>>>> on the long term.
>>>>>>>>>
>>>>>>>>> Do you think I am going in the right direction?
>>>>>>>>>
>>>>>>>>> Thanks for reading,
>>>>>>>>> Guillaume
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> devs mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> devs mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>>
>>>>>> _______________________________________________
>>>>>> devs mailing list
>>>>>> [hidden email]
>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>
>>>>> _______________________________________________
>>>>> devs mailing list
>>>>> [hidden email]
>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>
>>>> _______________________________________________
>>>> devs mailing list
>>>> [hidden email]
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>
>>> _______________________________________________
>>> devs mailing list
>>> [hidden email]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Thomas Mortagne
Administrator
On Wed, Apr 30, 2014 at 3:04 PM, Caleb James DeLisle <[hidden email]> wrote:

>
>
> On 04/30/2014 02:59 PM, Thomas Mortagne wrote:
>> On Wed, Apr 30, 2014 at 2:33 PM, Caleb James DeLisle <[hidden email]> wrote:
>>> https://encrypted.google.com/search?q=less+css -> About 116,000,000 results (less is a common word so this is skewed)
>>> https://encrypted.google.com/search?q=sass+css -> About 2,480,000 results
>>>
>>> https://github.com/less/less.js -> 1756 commits, 152 contributors, 2296 forks
>>> https://github.com/nex3/sass -> 5554 commits, 135 contributors, 650 forks
>>>
>>> Less feels a bit safer from a community standpoint,
>>
>>> both have java/C/ruby/js implementations (node-sass is a binding to the C version).
>>
>> No they don't, the only working implementation of less is in js for example.
>
>
> https://github.com/less/less.ruby
> https://github.com/marceloverdijk/lesscss-java <-- wrapper around the js impl w/ rhino

"working" was an important detail. Guillaume already tried
https://github.com/marceloverdijk/lesscss-java.

> https://github.com/BramvdKroef/clessc
>
>
>>
>>>
>>> These numbers seem to be suggesting that consensus will form around Less if anything.
>>>
>>> Thanks,
>>> Caleb
>>>
>>>
>>> On 04/30/2014 01:22 PM, Guillaume "Louis-Marie" Delhumeau wrote:
>>>> One point in favour of SASS (SCSS): it seems more customizable. For
>>>> example, we can define our own SASS functions (like
>>>> xwiki-colortheme-get('variable_name')) or our own Importer (for example,
>>>> @import will not look in the filesystem but somewhere in our XWiki
>>>> instance).
>>>>
>>>> In this case, we can simply avoid using velocity.
>>>>
>>>> See:
>>>> http://sass-lang.com/documentation/file.SASS_REFERENCE.html#defining_custom_sass_functions
>>>>
>>>>
>>>>
>>>> 2014-04-29 15:35 GMT+02:00 Jeremie BOUSQUET <[hidden email]>:
>>>>
>>>>> 2014-04-29 9:58 GMT+02:00 Caleb James DeLisle <[hidden email]>:
>>>>>
>>>>>> My 2 cents worth is all that matters is community.
>>>>>> Between Groovy, Velocity (I think we're now the biggest user of that) and
>>>>>> prototypejs, we're pretty good at backing the wrong horse.
>>>>>>
>>>>>>
>>>>> That may be right but as of now at least, groovy/velocity are popular at
>>>>> least among xwiki current users (dev oriented ones).
>>>>> I'm really glad personally that you didn't choose PHP or JSPs even if they
>>>>> were (and are) far more popular than Velocity ... ;)
>>>>>
>>>>>
>>>>>> In 3-5 years, one of LESS/SASS (or perhaps something else entirely) will
>>>>> be
>>>>>> the standard for CSS preprocessing and the other will be a historical
>>>>>> amusement.
>>>>>>
>>>>>
>>>>> Maybe CSS preprocessing as we know now, will be a historical amusement.
>>>>> It's still very very young. To me it mostly looks like hacks added to
>>>>> workaround things that pure css SHOULD manage ideally, or should not have
>>>>> to manage at all... Not saying that css preprocessing is bad though of
>>>>> course :)
>>>>> The problem is that the "best" and the "most popular" are not always the
>>>>> same ... (to say the least)
>>>>>
>>>>> Lets not be the ones left holding the bag.
>>>>>>
>>>>>> Thanks,
>>>>>> Caleb
>>>>>>
>>>>>>
>>>>>> On 04/28/2014 06:01 PM, Guillaume "Louis-Marie" Delhumeau wrote:
>>>>>>> 2014-04-28 16:33 GMT+02:00 Ecaterina Moraru (Valica) <
>>>>> [hidden email]
>>>>>>> :
>>>>>>>
>>>>>>>> My major concern about Sass is the syntax very similar to Velocity and
>>>>>> the
>>>>>>>> way we will handle the parsable style sheets.
>>>>>>>>
>>>>>>>
>>>>>>> I think you talk about the fact that variables are prefixed with $ in
>>>>>> SASS.
>>>>>>>
>>>>>>> 2 solutions:
>>>>>>> - it should be possible to escape the $ when velocity should ignore the
>>>>>>> variable
>>>>>>> - when the variable does not exist in the velocity context, it displays
>>>>>>> $variable and it does not fail.
>>>>>>>
>>>>>>> I personally prefer LESS for the reason for this reason, but regarding
>>>>>> the
>>>>>>> performances, we might consider the things differently, even with a
>>>>> cache
>>>>>>> system (which will be needed anyway).
>>>>>>>
>>>>>>> I need more opinions about this.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Guillaume
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Caty
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Apr 28, 2014 at 5:21 PM, Guillaume "Louis-Marie" Delhumeau <
>>>>>>>> [hidden email]> wrote:
>>>>>>>>
>>>>>>>>> Hi guys.
>>>>>>>>>
>>>>>>>>> Since we did not have made a strong analysis on SASS, I have played a
>>>>>> bit
>>>>>>>>> with it to compare.
>>>>>>>>>
>>>>>>>>> Thomas had the intuition that it should perform faster, because JRuby
>>>>>> is
>>>>>>>> a
>>>>>>>>> better implementation for Ruby than Rhino is for JS.
>>>>>>>>>
>>>>>>>>> So I have published a little benchmark about them, that you can see
>>>>>>>> there:
>>>>>>>>> https://github.com/xwiki-contrib/less-vs-sass-benchmark
>>>>>>>>>
>>>>>>>>> The benchmark is about the time that it takes to compile Bootstrap.
>>>>>>>>>
>>>>>>>>> The results are very clear, SASS perform 2 times faster than LESS.
>>>>>>>>>
>>>>>>>>> Since it seems easy to switch from LESS to SASS (bootstrap had
>>>>> written
>>>>>> a
>>>>>>>>> converter), maybe we should consider this option.
>>>>>>>>>
>>>>>>>>> Other thing:
>>>>>>>>> I would like to run Velocity on the sources of my CSS, in order to
>>>>>> easily
>>>>>>>>> integrate the color theme variables. But it is risky to run velocity
>>>>> on
>>>>>>>> the
>>>>>>>>> whole tree of bootstrap sources (just imagine that bootstrap has an
>>>>>> "#if"
>>>>>>>>> ID...).
>>>>>>>>>
>>>>>>>>> So Thomas and I suggest that we can run Velocity on files suffixed by
>>>>>>>>> .scss.vm or .less.vm, to only run velocity on some files (for
>>>>> example:
>>>>>>>>> color-theme.less.vm) that we handle.
>>>>>>>>>
>>>>>>>>> WDYT?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Guillaume
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
>>>>>>>>> [hidden email]>:
>>>>>>>>>
>>>>>>>>>> Hello.
>>>>>>>>>>
>>>>>>>>>> In 6.0, we have released a first version of Flamingo. It uses
>>>>>> Bootstrap
>>>>>>>>>> and the LESS preprocessor during the build to create the final
>>>>>>>> style.css
>>>>>>>>>> file.
>>>>>>>>>>
>>>>>>>>>> But currently, there is a serious regression compared to Colibri: it
>>>>>>>> does
>>>>>>>>>> not support color themes.
>>>>>>>>>>
>>>>>>>>>> So I have started a proposal about the color theme handling in
>>>>>>>> Flamingo,
>>>>>>>>>> that you can see there:
>>>>>>>>>>
>>>>> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
>>>>>>>>>>
>>>>>>>>>> My conclusion is that we need to integrate the LESS preprocesor on
>>>>> the
>>>>>>>>>> runtime. This way, we can add velocity variables (corresponding to
>>>>> the
>>>>>>>>>> color theme) in our LESS sources BEFORE the LESS preprocessor is
>>>>>>>>> launched.
>>>>>>>>>> Doing the opposite, (process velocity after LESS) causes some
>>>>> problems
>>>>>>>>> that
>>>>>>>>>> I have reported on the previous link.
>>>>>>>>>>
>>>>>>>>>> To me, it would be a good step ahead for proposing LESS to our
>>>>> users.
>>>>>>>>>>
>>>>>>>>>> Regarding this, some ideas are coming to me:
>>>>>>>>>> - it is quite easy to integrate LESS since we can use Rhino to
>>>>> launch
>>>>>>>> the
>>>>>>>>>> LESS preprocessor (which is a javascript program). See:
>>>>>>>>>> https://github.com/sandroboehme/lesscss-java
>>>>>>>>>> - we need a cache system in order to not always compute the
>>>>> style.css
>>>>>>>>>> served to the user (performances issue).
>>>>>>>>>> - we need to add this in the "skin" action.
>>>>>>>>>> - in the future, we also need to modify the skinx actions, to enable
>>>>>> it
>>>>>>>>>> for Skin Extensions.
>>>>>>>>>>
>>>>>>>>>> We also need to agree on the use of LESS instead of SASS. I have
>>>>> used
>>>>>>>>> LESS
>>>>>>>>>> on Flamingo because Bootstrap has originally been written with it
>>>>>>>>> (although
>>>>>>>>>> an official SASS port exists), so this choice is not based on a
>>>>> strong
>>>>>>>>>> analysis. Anyway, it looks quite simple to move from one to the
>>>>> other
>>>>>>>> and
>>>>>>>>>> it is probably too soon to predict which of these 2 preprocessors
>>>>> will
>>>>>>>>> win
>>>>>>>>>> on the long term.
>>>>>>>>>>
>>>>>>>>>> Do you think I am going in the right direction?
>>>>>>>>>>
>>>>>>>>>> Thanks for reading,
>>>>>>>>>> Guillaume
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> devs mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> devs mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> devs mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>>
>>>>>> _______________________________________________
>>>>>> devs mailing list
>>>>>> [hidden email]
>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>
>>>>> _______________________________________________
>>>>> devs mailing list
>>>>> [hidden email]
>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>
>>>> _______________________________________________
>>>> devs mailing list
>>>> [hidden email]
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>
>>> _______________________________________________
>>> devs mailing list
>>> [hidden email]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Thomas Mortagne
Administrator
On Wed, Apr 30, 2014 at 3:16 PM, Thomas Mortagne
<[hidden email]> wrote:

> On Wed, Apr 30, 2014 at 3:04 PM, Caleb James DeLisle <[hidden email]> wrote:
>>
>>
>> On 04/30/2014 02:59 PM, Thomas Mortagne wrote:
>>> On Wed, Apr 30, 2014 at 2:33 PM, Caleb James DeLisle <[hidden email]> wrote:
>>>> https://encrypted.google.com/search?q=less+css -> About 116,000,000 results (less is a common word so this is skewed)
>>>> https://encrypted.google.com/search?q=sass+css -> About 2,480,000 results
>>>>
>>>> https://github.com/less/less.js -> 1756 commits, 152 contributors, 2296 forks
>>>> https://github.com/nex3/sass -> 5554 commits, 135 contributors, 650 forks
>>>>
>>>> Less feels a bit safer from a community standpoint,
>>>
>>>> both have java/C/ruby/js implementations (node-sass is a binding to the C version).
>>>
>>> No they don't, the only working implementation of less is in js for example.
>>
>>
>> https://github.com/less/less.ruby
>> https://github.com/marceloverdijk/lesscss-java <-- wrapper around the js impl w/ rhino
>
> "working" was an important detail. Guillaume already tried
> https://github.com/marceloverdijk/lesscss-java.

Actually I tough you were talking about another one, If you really
look at the detail you will see this one is using rhino so no it's not
a java implementation.

>
>> https://github.com/BramvdKroef/clessc
>>
>>
>>>
>>>>
>>>> These numbers seem to be suggesting that consensus will form around Less if anything.
>>>>
>>>> Thanks,
>>>> Caleb
>>>>
>>>>
>>>> On 04/30/2014 01:22 PM, Guillaume "Louis-Marie" Delhumeau wrote:
>>>>> One point in favour of SASS (SCSS): it seems more customizable. For
>>>>> example, we can define our own SASS functions (like
>>>>> xwiki-colortheme-get('variable_name')) or our own Importer (for example,
>>>>> @import will not look in the filesystem but somewhere in our XWiki
>>>>> instance).
>>>>>
>>>>> In this case, we can simply avoid using velocity.
>>>>>
>>>>> See:
>>>>> http://sass-lang.com/documentation/file.SASS_REFERENCE.html#defining_custom_sass_functions
>>>>>
>>>>>
>>>>>
>>>>> 2014-04-29 15:35 GMT+02:00 Jeremie BOUSQUET <[hidden email]>:
>>>>>
>>>>>> 2014-04-29 9:58 GMT+02:00 Caleb James DeLisle <[hidden email]>:
>>>>>>
>>>>>>> My 2 cents worth is all that matters is community.
>>>>>>> Between Groovy, Velocity (I think we're now the biggest user of that) and
>>>>>>> prototypejs, we're pretty good at backing the wrong horse.
>>>>>>>
>>>>>>>
>>>>>> That may be right but as of now at least, groovy/velocity are popular at
>>>>>> least among xwiki current users (dev oriented ones).
>>>>>> I'm really glad personally that you didn't choose PHP or JSPs even if they
>>>>>> were (and are) far more popular than Velocity ... ;)
>>>>>>
>>>>>>
>>>>>>> In 3-5 years, one of LESS/SASS (or perhaps something else entirely) will
>>>>>> be
>>>>>>> the standard for CSS preprocessing and the other will be a historical
>>>>>>> amusement.
>>>>>>>
>>>>>>
>>>>>> Maybe CSS preprocessing as we know now, will be a historical amusement.
>>>>>> It's still very very young. To me it mostly looks like hacks added to
>>>>>> workaround things that pure css SHOULD manage ideally, or should not have
>>>>>> to manage at all... Not saying that css preprocessing is bad though of
>>>>>> course :)
>>>>>> The problem is that the "best" and the "most popular" are not always the
>>>>>> same ... (to say the least)
>>>>>>
>>>>>> Lets not be the ones left holding the bag.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Caleb
>>>>>>>
>>>>>>>
>>>>>>> On 04/28/2014 06:01 PM, Guillaume "Louis-Marie" Delhumeau wrote:
>>>>>>>> 2014-04-28 16:33 GMT+02:00 Ecaterina Moraru (Valica) <
>>>>>> [hidden email]
>>>>>>>> :
>>>>>>>>
>>>>>>>>> My major concern about Sass is the syntax very similar to Velocity and
>>>>>>> the
>>>>>>>>> way we will handle the parsable style sheets.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I think you talk about the fact that variables are prefixed with $ in
>>>>>>> SASS.
>>>>>>>>
>>>>>>>> 2 solutions:
>>>>>>>> - it should be possible to escape the $ when velocity should ignore the
>>>>>>>> variable
>>>>>>>> - when the variable does not exist in the velocity context, it displays
>>>>>>>> $variable and it does not fail.
>>>>>>>>
>>>>>>>> I personally prefer LESS for the reason for this reason, but regarding
>>>>>>> the
>>>>>>>> performances, we might consider the things differently, even with a
>>>>>> cache
>>>>>>>> system (which will be needed anyway).
>>>>>>>>
>>>>>>>> I need more opinions about this.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Guillaume
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Caty
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Apr 28, 2014 at 5:21 PM, Guillaume "Louis-Marie" Delhumeau <
>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>
>>>>>>>>>> Hi guys.
>>>>>>>>>>
>>>>>>>>>> Since we did not have made a strong analysis on SASS, I have played a
>>>>>>> bit
>>>>>>>>>> with it to compare.
>>>>>>>>>>
>>>>>>>>>> Thomas had the intuition that it should perform faster, because JRuby
>>>>>>> is
>>>>>>>>> a
>>>>>>>>>> better implementation for Ruby than Rhino is for JS.
>>>>>>>>>>
>>>>>>>>>> So I have published a little benchmark about them, that you can see
>>>>>>>>> there:
>>>>>>>>>> https://github.com/xwiki-contrib/less-vs-sass-benchmark
>>>>>>>>>>
>>>>>>>>>> The benchmark is about the time that it takes to compile Bootstrap.
>>>>>>>>>>
>>>>>>>>>> The results are very clear, SASS perform 2 times faster than LESS.
>>>>>>>>>>
>>>>>>>>>> Since it seems easy to switch from LESS to SASS (bootstrap had
>>>>>> written
>>>>>>> a
>>>>>>>>>> converter), maybe we should consider this option.
>>>>>>>>>>
>>>>>>>>>> Other thing:
>>>>>>>>>> I would like to run Velocity on the sources of my CSS, in order to
>>>>>>> easily
>>>>>>>>>> integrate the color theme variables. But it is risky to run velocity
>>>>>> on
>>>>>>>>> the
>>>>>>>>>> whole tree of bootstrap sources (just imagine that bootstrap has an
>>>>>>> "#if"
>>>>>>>>>> ID...).
>>>>>>>>>>
>>>>>>>>>> So Thomas and I suggest that we can run Velocity on files suffixed by
>>>>>>>>>> .scss.vm or .less.vm, to only run velocity on some files (for
>>>>>> example:
>>>>>>>>>> color-theme.less.vm) that we handle.
>>>>>>>>>>
>>>>>>>>>> WDYT?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Guillaume
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
>>>>>>>>>> [hidden email]>:
>>>>>>>>>>
>>>>>>>>>>> Hello.
>>>>>>>>>>>
>>>>>>>>>>> In 6.0, we have released a first version of Flamingo. It uses
>>>>>>> Bootstrap
>>>>>>>>>>> and the LESS preprocessor during the build to create the final
>>>>>>>>> style.css
>>>>>>>>>>> file.
>>>>>>>>>>>
>>>>>>>>>>> But currently, there is a serious regression compared to Colibri: it
>>>>>>>>> does
>>>>>>>>>>> not support color themes.
>>>>>>>>>>>
>>>>>>>>>>> So I have started a proposal about the color theme handling in
>>>>>>>>> Flamingo,
>>>>>>>>>>> that you can see there:
>>>>>>>>>>>
>>>>>> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
>>>>>>>>>>>
>>>>>>>>>>> My conclusion is that we need to integrate the LESS preprocesor on
>>>>>> the
>>>>>>>>>>> runtime. This way, we can add velocity variables (corresponding to
>>>>>> the
>>>>>>>>>>> color theme) in our LESS sources BEFORE the LESS preprocessor is
>>>>>>>>>> launched.
>>>>>>>>>>> Doing the opposite, (process velocity after LESS) causes some
>>>>>> problems
>>>>>>>>>> that
>>>>>>>>>>> I have reported on the previous link.
>>>>>>>>>>>
>>>>>>>>>>> To me, it would be a good step ahead for proposing LESS to our
>>>>>> users.
>>>>>>>>>>>
>>>>>>>>>>> Regarding this, some ideas are coming to me:
>>>>>>>>>>> - it is quite easy to integrate LESS since we can use Rhino to
>>>>>> launch
>>>>>>>>> the
>>>>>>>>>>> LESS preprocessor (which is a javascript program). See:
>>>>>>>>>>> https://github.com/sandroboehme/lesscss-java
>>>>>>>>>>> - we need a cache system in order to not always compute the
>>>>>> style.css
>>>>>>>>>>> served to the user (performances issue).
>>>>>>>>>>> - we need to add this in the "skin" action.
>>>>>>>>>>> - in the future, we also need to modify the skinx actions, to enable
>>>>>>> it
>>>>>>>>>>> for Skin Extensions.
>>>>>>>>>>>
>>>>>>>>>>> We also need to agree on the use of LESS instead of SASS. I have
>>>>>> used
>>>>>>>>>> LESS
>>>>>>>>>>> on Flamingo because Bootstrap has originally been written with it
>>>>>>>>>> (although
>>>>>>>>>>> an official SASS port exists), so this choice is not based on a
>>>>>> strong
>>>>>>>>>>> analysis. Anyway, it looks quite simple to move from one to the
>>>>>> other
>>>>>>>>> and
>>>>>>>>>>> it is probably too soon to predict which of these 2 preprocessors
>>>>>> will
>>>>>>>>>> win
>>>>>>>>>>> on the long term.
>>>>>>>>>>>
>>>>>>>>>>> Do you think I am going in the right direction?
>>>>>>>>>>>
>>>>>>>>>>> Thanks for reading,
>>>>>>>>>>> Guillaume
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> devs mailing list
>>>>>>>>>> [hidden email]
>>>>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> devs mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> devs mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> devs mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>>
>>>>>> _______________________________________________
>>>>>> devs mailing list
>>>>>> [hidden email]
>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>
>>>>> _______________________________________________
>>>>> devs mailing list
>>>>> [hidden email]
>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>
>>>> _______________________________________________
>>>> devs mailing list
>>>> [hidden email]
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>>>
>>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Integrate LESS css in XWiki

Guillaume "Louis-Marie" Delhumeau
Update:

SASS have good performances because it does not always compute all the
sources. All imported files (using @import) are cached and not recompiled
when there is not change on these files.

It is good if we often recompute flamingo (that does a lot of @import), but
it means that the SASS' performances are not that better than LESS' when it
comes to compile new files, which can happen every-time we will compile a
SSX object in the future (if we decide to).

So I have done a benchmark without the cache, and then the performances of
SASS are quite the same than LESS, but a bit slower (see:
https://github.com/xwiki-contrib/less-vs-sass-benchmark ).

Other thing to consider:
In both LESS and SASS, it is possible to set a directory where the imported
files are searched. So we can add bootstrap sources in every SSX objects so
that users can use Bootstrap mixins (good thing IMO).

In this case, it will be good to have the cache system that SASS has.

Thanks,
Guillaume


2014-04-30 15:17 GMT+02:00 Thomas Mortagne <[hidden email]>:

> On Wed, Apr 30, 2014 at 3:16 PM, Thomas Mortagne
> <[hidden email]> wrote:
> > On Wed, Apr 30, 2014 at 3:04 PM, Caleb James DeLisle <[hidden email]>
> wrote:
> >>
> >>
> >> On 04/30/2014 02:59 PM, Thomas Mortagne wrote:
> >>> On Wed, Apr 30, 2014 at 2:33 PM, Caleb James DeLisle <[hidden email]>
> wrote:
> >>>> https://encrypted.google.com/search?q=less+css -> About 116,000,000
> results (less is a common word so this is skewed)
> >>>> https://encrypted.google.com/search?q=sass+css -> About 2,480,000
> results
> >>>>
> >>>> https://github.com/less/less.js -> 1756 commits, 152 contributors,
> 2296 forks
> >>>> https://github.com/nex3/sass -> 5554 commits, 135 contributors, 650
> forks
> >>>>
> >>>> Less feels a bit safer from a community standpoint,
> >>>
> >>>> both have java/C/ruby/js implementations (node-sass is a binding to
> the C version).
> >>>
> >>> No they don't, the only working implementation of less is in js for
> example.
> >>
> >>
> >> https://github.com/less/less.ruby
> >> https://github.com/marceloverdijk/lesscss-java <-- wrapper around the
> js impl w/ rhino
> >
> > "working" was an important detail. Guillaume already tried
> > https://github.com/marceloverdijk/lesscss-java.
>
> Actually I tough you were talking about another one, If you really
> look at the detail you will see this one is using rhino so no it's not
> a java implementation.
>
> >
> >> https://github.com/BramvdKroef/clessc
> >>
> >>
> >>>
> >>>>
> >>>> These numbers seem to be suggesting that consensus will form around
> Less if anything.
> >>>>
> >>>> Thanks,
> >>>> Caleb
> >>>>
> >>>>
> >>>> On 04/30/2014 01:22 PM, Guillaume "Louis-Marie" Delhumeau wrote:
> >>>>> One point in favour of SASS (SCSS): it seems more customizable. For
> >>>>> example, we can define our own SASS functions (like
> >>>>> xwiki-colortheme-get('variable_name')) or our own Importer (for
> example,
> >>>>> @import will not look in the filesystem but somewhere in our XWiki
> >>>>> instance).
> >>>>>
> >>>>> In this case, we can simply avoid using velocity.
> >>>>>
> >>>>> See:
> >>>>>
> http://sass-lang.com/documentation/file.SASS_REFERENCE.html#defining_custom_sass_functions
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2014-04-29 15:35 GMT+02:00 Jeremie BOUSQUET <
> [hidden email]>:
> >>>>>
> >>>>>> 2014-04-29 9:58 GMT+02:00 Caleb James DeLisle <[hidden email]>:
> >>>>>>
> >>>>>>> My 2 cents worth is all that matters is community.
> >>>>>>> Between Groovy, Velocity (I think we're now the biggest user of
> that) and
> >>>>>>> prototypejs, we're pretty good at backing the wrong horse.
> >>>>>>>
> >>>>>>>
> >>>>>> That may be right but as of now at least, groovy/velocity are
> popular at
> >>>>>> least among xwiki current users (dev oriented ones).
> >>>>>> I'm really glad personally that you didn't choose PHP or JSPs even
> if they
> >>>>>> were (and are) far more popular than Velocity ... ;)
> >>>>>>
> >>>>>>
> >>>>>>> In 3-5 years, one of LESS/SASS (or perhaps something else
> entirely) will
> >>>>>> be
> >>>>>>> the standard for CSS preprocessing and the other will be a
> historical
> >>>>>>> amusement.
> >>>>>>>
> >>>>>>
> >>>>>> Maybe CSS preprocessing as we know now, will be a historical
> amusement.
> >>>>>> It's still very very young. To me it mostly looks like hacks added
> to
> >>>>>> workaround things that pure css SHOULD manage ideally, or should
> not have
> >>>>>> to manage at all... Not saying that css preprocessing is bad though
> of
> >>>>>> course :)
> >>>>>> The problem is that the "best" and the "most popular" are not
> always the
> >>>>>> same ... (to say the least)
> >>>>>>
> >>>>>> Lets not be the ones left holding the bag.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Caleb
> >>>>>>>
> >>>>>>>
> >>>>>>> On 04/28/2014 06:01 PM, Guillaume "Louis-Marie" Delhumeau wrote:
> >>>>>>>> 2014-04-28 16:33 GMT+02:00 Ecaterina Moraru (Valica) <
> >>>>>> [hidden email]
> >>>>>>>> :
> >>>>>>>>
> >>>>>>>>> My major concern about Sass is the syntax very similar to
> Velocity and
> >>>>>>> the
> >>>>>>>>> way we will handle the parsable style sheets.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I think you talk about the fact that variables are prefixed with
> $ in
> >>>>>>> SASS.
> >>>>>>>>
> >>>>>>>> 2 solutions:
> >>>>>>>> - it should be possible to escape the $ when velocity should
> ignore the
> >>>>>>>> variable
> >>>>>>>> - when the variable does not exist in the velocity context, it
> displays
> >>>>>>>> $variable and it does not fail.
> >>>>>>>>
> >>>>>>>> I personally prefer LESS for the reason for this reason, but
> regarding
> >>>>>>> the
> >>>>>>>> performances, we might consider the things differently, even with
> a
> >>>>>> cache
> >>>>>>>> system (which will be needed anyway).
> >>>>>>>>
> >>>>>>>> I need more opinions about this.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Guillaume
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Caty
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Mon, Apr 28, 2014 at 5:21 PM, Guillaume "Louis-Marie"
> Delhumeau <
> >>>>>>>>> [hidden email]> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi guys.
> >>>>>>>>>>
> >>>>>>>>>> Since we did not have made a strong analysis on SASS, I have
> played a
> >>>>>>> bit
> >>>>>>>>>> with it to compare.
> >>>>>>>>>>
> >>>>>>>>>> Thomas had the intuition that it should perform faster, because
> JRuby
> >>>>>>> is
> >>>>>>>>> a
> >>>>>>>>>> better implementation for Ruby than Rhino is for JS.
> >>>>>>>>>>
> >>>>>>>>>> So I have published a little benchmark about them, that you can
> see
> >>>>>>>>> there:
> >>>>>>>>>> https://github.com/xwiki-contrib/less-vs-sass-benchmark
> >>>>>>>>>>
> >>>>>>>>>> The benchmark is about the time that it takes to compile
> Bootstrap.
> >>>>>>>>>>
> >>>>>>>>>> The results are very clear, SASS perform 2 times faster than
> LESS.
> >>>>>>>>>>
> >>>>>>>>>> Since it seems easy to switch from LESS to SASS (bootstrap had
> >>>>>> written
> >>>>>>> a
> >>>>>>>>>> converter), maybe we should consider this option.
> >>>>>>>>>>
> >>>>>>>>>> Other thing:
> >>>>>>>>>> I would like to run Velocity on the sources of my CSS, in order
> to
> >>>>>>> easily
> >>>>>>>>>> integrate the color theme variables. But it is risky to run
> velocity
> >>>>>> on
> >>>>>>>>> the
> >>>>>>>>>> whole tree of bootstrap sources (just imagine that bootstrap
> has an
> >>>>>>> "#if"
> >>>>>>>>>> ID...).
> >>>>>>>>>>
> >>>>>>>>>> So Thomas and I suggest that we can run Velocity on files
> suffixed by
> >>>>>>>>>> .scss.vm or .less.vm, to only run velocity on some files (for
> >>>>>> example:
> >>>>>>>>>> color-theme.less.vm) that we handle.
> >>>>>>>>>>
> >>>>>>>>>> WDYT?
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Guillaume
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau <
> >>>>>>>>>> [hidden email]>:
> >>>>>>>>>>
> >>>>>>>>>>> Hello.
> >>>>>>>>>>>
> >>>>>>>>>>> In 6.0, we have released a first version of Flamingo. It uses
> >>>>>>> Bootstrap
> >>>>>>>>>>> and the LESS preprocessor during the build to create the final
> >>>>>>>>> style.css
> >>>>>>>>>>> file.
> >>>>>>>>>>>
> >>>>>>>>>>> But currently, there is a serious regression compared to
> Colibri: it
> >>>>>>>>> does
> >>>>>>>>>>> not support color themes.
> >>>>>>>>>>>
> >>>>>>>>>>> So I have started a proposal about the color theme handling in
> >>>>>>>>> Flamingo,
> >>>>>>>>>>> that you can see there:
> >>>>>>>>>>>
> >>>>>>
> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
> >>>>>>>>>>>
> >>>>>>>>>>> My conclusion is that we need to integrate the LESS
> preprocesor on
> >>>>>> the
> >>>>>>>>>>> runtime. This way, we can add velocity variables
> (corresponding to
> >>>>>> the
> >>>>>>>>>>> color theme) in our LESS sources BEFORE the LESS preprocessor
> is
> >>>>>>>>>> launched.
> >>>>>>>>>>> Doing the opposite, (process velocity after LESS) causes some
> >>>>>> problems
> >>>>>>>>>> that
> >>>>>>>>>>> I have reported on the previous link.
> >>>>>>>>>>>
> >>>>>>>>>>> To me, it would be a good step ahead for proposing LESS to our
> >>>>>> users.
> >>>>>>>>>>>
> >>>>>>>>>>> Regarding this, some ideas are coming to me:
> >>>>>>>>>>> - it is quite easy to integrate LESS since we can use Rhino to
> >>>>>> launch
> >>>>>>>>> the
> >>>>>>>>>>> LESS preprocessor (which is a javascript program). See:
> >>>>>>>>>>> https://github.com/sandroboehme/lesscss-java
> >>>>>>>>>>> - we need a cache system in order to not always compute the
> >>>>>> style.css
> >>>>>>>>>>> served to the user (performances issue).
> >>>>>>>>>>> - we need to add this in the "skin" action.
> >>>>>>>>>>> - in the future, we also need to modify the skinx actions, to
> enable
> >>>>>>> it
> >>>>>>>>>>> for Skin Extensions.
> >>>>>>>>>>>
> >>>>>>>>>>> We also need to agree on the use of LESS instead of SASS. I
> have
> >>>>>> used
> >>>>>>>>>> LESS
> >>>>>>>>>>> on Flamingo because Bootstrap has originally been written with
> it
> >>>>>>>>>> (although
> >>>>>>>>>>> an official SASS port exists), so this choice is not based on a
> >>>>>> strong
> >>>>>>>>>>> analysis. Anyway, it looks quite simple to move from one to the
> >>>>>> other
> >>>>>>>>> and
> >>>>>>>>>>> it is probably too soon to predict which of these 2
> preprocessors
> >>>>>> will
> >>>>>>>>>> win
> >>>>>>>>>>> on the long term.
> >>>>>>>>>>>
> >>>>>>>>>>> Do you think I am going in the right direction?
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks for reading,
> >>>>>>>>>>> Guillaume
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> devs mailing list
> >>>>>>>>>> [hidden email]
> >>>>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> devs mailing list
> >>>>>>>>> [hidden email]
> >>>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> devs mailing list
> >>>>>>>> [hidden email]
> >>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> devs mailing list
> >>>>>>> [hidden email]
> >>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> devs mailing list
> >>>>>> [hidden email]
> >>>>>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>>>>
> >>>>> _______________________________________________
> >>>>> devs mailing list
> >>>>> [hidden email]
> >>>>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>>>
> >>>> _______________________________________________
> >>>> devs mailing list
> >>>> [hidden email]
> >>>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> devs mailing list
> >> [hidden email]
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >
> >
> >
> > --
> > Thomas Mortagne
>
>
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
12