On Thu, Sep 19, 2013 at 2:19 PM, C. Scott Ananian cananian@wikimedia.orgwrote:
@dan: the particular "less isn't very powerful" issues I'm concerned about are the ones solved by compass. As is well-known, there is no equivalent to compass for less, and is not likely every to be, since less can not express the transformations required. Compass uses ruby code to do this w/ sass. For example,
https://github.com/chriseppstein/compass/blob/stable/lib/compass/sass_extens... the code in compass in order to generate clean gradient specifications that work with all major browsers (including synthesizing SVG background images where required).
http://lesshat.com/#gradient implements it, except it adds custom functions in JS to handle SVG generation. We could trivially implement an equivalent in PHP using http://leafo.net/lessphp/docs/#custom_functions. There is already a patch to extend LESS to provide an embed() function that can generate data URIs from image file references. < https://gerrit.wikimedia.org/r/#/c/85143/%3E.
When two tools share a use-case and vie for the same user-base (as is the case with LESS and Sass) there is a natural tendency to exaggerate the importance of esoteric features that set them apart. There are things that LESS handles more gracefully than Sass, too. But I expect us to be appropriately conservative in using these features anyhow. The biggest gains to be had from using a CSS preprocessor tend to come from the most basic features: giving comprehensible names to literal values (e.g. @wikimediaBlue instead of #006699), and having shorthand notations for generating standard interface patterns.
I personally think it'd be unfortunate for this current effort to collapse over such considerations, but I'm obviously biased.