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