On Thu, Sep 19, 2013 at 2:19 PM, C. Scott Ananian <[email protected]>wrote:
> @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_extensions/functions/gradient_support.rbis > 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/>. 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. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
