I was just writing a message about Stylus [0] so I'm glad you brought it up. Limn [1] uses Stylus and we've been pretty happy with it. I read the RFC carefully and it seems the two big reasons to pick LESS over Stylus/SASS are popularity and support in PHP. The reason to pick Stylus/SASS over LESS is a more elegant syntax and a slight edge in features. *PHP support* - Stylus does have PHP support [2] but it's not even close to as mature as the LESS support. *Popularity* - does matter; one of the long comment threads on the RFC is from a potential contributor who is concerned that LESS makes it harder to contribute. I mostly agree with Jon's and Steven's arguments that LESS is pretty easy to learn. However, I have also heard about a year's worth of complaints about Limn being written in Coco instead of pure Javascript. I personally think CSS -> LESS is just as mentally taxing as Javascript -> Coco, but I'm objectively in the minority based on the feedback I've received. I'd be cautious here. You can upcompile CSS into LESS, sure, but if a contributor has to understand a complex LESS codebase full of mixins and abstractions while debugging the generated CSS in the browser, they're right to point out that this requires effort. And this is effort is only increased for more elegant languages like Stylus. *Syntax* - Stylus and SASS definitely have cleaner, simpler syntax. Stylus aims to be the cleanest of the three but it definitely smells like that SNL skit about the number of razor blades. They have 4 blades?! Fine, we'll make one with *5* BLADES!!! What I'm referring to here is that Stylus has optional colons and tries to be as much like python as possible. *Features* - The interesting thing about the features comparisons out there is that all of them seem to be outdated. For example this write-up [3] highlights that @media queries can be nested in SASS (same is true for Stylus). But the LESS people implemented that as well (Feb 2013). This said, it does seem that Stylus and SASS are leading the pack in terms of new features. Introspection [4] is a very cool one in Stylus that I'm not sure you can do in LESS. I think the decision's pretty much been made to go with LESS, and I agree with it. I think it strikes the better balance between making it easy for people to contribute and DRY-ing up our codebase. But in the future, if we loved the migration to LESS and we just wish it had more features and more DRY-ness, we should revisit Stylus. [0] - http://learnboost.github.io/stylus/ [1] - https://github.com/wikimedia/limn/tree/develop/css [2] - https://github.com/AustP/Stylus.php [3] - http://css-tricks.com/sass-vs-less/ [4] - http://learnboost.github.io/stylus/docs/introspection.html

On Thu, Sep 19, 2013 at 12:24 PM, C. Scott Ananian <cananian(a)wikimedia.org>wrote;wrote: @import directives in LESS files pointing at other LESS files are processed synchronously by phpless and are not present in the generated CSS output, and that's the only use of '@import' we encourage / allow. @import is reserved for loading mix-ins and variables so that they may be used by the current LESS stylesheet. It is not intended to be used for concatenating / bundling stylesheets that are related to one another only conceptually; that's what the ResourceLoader module definition is for. /* ------------- Valid use of @import: ------------- */ # myExtension.less @import "extensionColors.less"; body { background-color: @bgColor; } # extensionColors.less @bgColor: #ccc; /* ------------- Invalid use of @import: ------------- */ # myExtension.less @import "headerStyles.less"; body { background-color: #ccc; } # headerStyles.less h1 { font-family: serif; } The relatedness of myExtension.less / headerStyles.less in the second example should be expressed by referencing these files in the 'styles' array of the same ResourceLoader module. I can commit to documenting this on mw.org if / when the proposal is accepted and the patch is merged.

On Thu, Sep 19, 2013 at 2:19 PM, C. Scott Ananian &lt;cananian(a)wikimedia.org&gt;wrote;wrote: <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/>gt;. 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.

On Fri, Sep 20, 2013 at 12:53 PM, C. Scott Ananian &lt;cananian(a)wikimedia.org&gt;wrote;wrote: Heartily agree as well. I alluded to this in my longer answer. Basically Stylus/SASS do seem to be slightly ahead of LESS but it's a vanishing difference and meaningLESS over the long term. This I think is a most astute point from Ori. It's why I made the analogy to Coco. I don't and never will use any of the complicated crazy Coco constructs. But writing class LineNode extends TimeseriesNode instead of all the JS boilerplate for classes and inheritance is good.

Le 21/09/13 19:50, Brion Vibber a écrit : Hello Brion, Thank you for the last minute mail notification on wikitech-l regarding less implementation. I have cast a few minor concerns on patchset 31, mostly related to the way the cache key is forged :-/ Hopefully I have been missing something and that is not going to delay the patch any further. cheers, -- Antoine "hashar" Musso

Ok, I have landed: * https://gerrit.wikimedia.org/r/#/c/78669 (core LESS support) * https://gerrit.wikimedia.org/r/#/c/85143/ (.background-image embedding helper function) Any further tweaks needed on the core support should be done as separate patches rather than additional patchsets on those, as they are merged. :) Next steps -- review and merge when ready on usages of less: * https://gerrit.wikimedia.org/r/#/c/84139/ - update for MobileFrontend * https://gerrit.wikimedia.org/r/#/c/85161/ - draft core tweak -- brion On Sun, Sep 22, 2013 at 10:57 AM, Ori Livneh &lt;ori(a)wikimedia.org&gt; wrote:

I cannot describe how significant this change is in the history of MediaWiki. I truly believe this is the dawn of a new age of design in MediaWiki. Big kudos to Ori for getting this kicked off and finally merged and to all the people involved in code review and the RFC process. *takes off his hat On 23 Sep 2013 13:08, "Brion Vibber" &lt;bvibber(a)wikimedia.org&gt; wrote:

On Sep 19, 2013, at 11:19 PM, C. Scott Ananian &lt;cananian(a)wikimedia.org&gt; wrote: As Ori pointed out, these could be implemented as Less functions in PHP land. However note that (for me) one the reasons I prefer Less over Sass with Compass is that it allows more fine-grained control over browser support and doesn't take the insane approach of trying to support everything and leaving you with very minimal options to switch things off. For example, in the of older browsers supporting SVG background-image but not CSS3 gradients, I'd say just drop that and only provide CSS3 gradient + vendor prefixed versions thereof and have it fallback for the rest. You're gonna have to provide that fallback anyway for browsers that support neither CSS3 or SVG. Optimise for the future, not for the past (those browsers are getting smaller in usage). It's not worth it to generate and serve that SVG to all clients.