30 Apr
2014
30 Apr
'14
2:59 p.m.
On Wed, Apr 30, 2014 at 2:33 PM, Caleb James DeLisle <cjd(a)cjdns.fr> 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.
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:
--
Thomas Mortagne
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 <jeremie.bousquet(a)gmail.com>om>:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 2014-04-29 9:58 GMT+02:00 Caleb James DeLisle
<cjd(a)cjdns.fr>fr>:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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> 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;:
>>>
>>>> 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