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 <[email protected]>: > 2014-04-29 9:58 GMT+02:00 Caleb James DeLisle <[email protected]>: > > > 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) < > [email protected] > > >: > > > > > >> 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 < > > >> [email protected]> 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 < > > >>> [email protected]>: > > >>> > > >>>> 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 > > >>> [email protected] > > >>> http://lists.xwiki.org/mailman/listinfo/devs > > >>> > > >> _______________________________________________ > > >> devs mailing list > > >> [email protected] > > >> http://lists.xwiki.org/mailman/listinfo/devs > > >> > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
