Re: [xwiki-devs] [Proposal] Integrate LESS css in XWiki

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… 2014-04-29 15:35 GMT+02:00 Jeremie BOUSQUET &lt;jeremie.bousquet(a)gmail.com&gt;om>: > 2014-04-29 9:58 GMT+02:00 Caleb James DeLisle &lt;cjd(a)cjdns.fr&gt;fr>: > >> 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) < > valicac(a)gmail.com >>> : >>> >>>> 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 < >>>> gdelhumeau(a)xwiki.com&gt; 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 < >>>>> gdelhumeau(a)xwiki.com&gt;gt;: >>>>> >>>>>> 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 >>>>> devs(a)xwiki.org >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>> _______________________________________________ >>>> devs mailing list >>>> devs(a)xwiki.org >>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >>> _______________________________________________ >>> devs mailing list >>> devs(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs