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