On 04/30/2014 02:59 PM, Thomas Mortagne wrote: > On Wed, Apr 30, 2014 at 2:33 PM, Caleb James DeLisle <[email protected]> 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 <[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 >>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
