I just want to check on folks to see if there's any more comments or issues with this RfC: https://www.mediawiki.org/wiki/Requests_for_comment/LESS
Basically, this adds a stylesheet preprocessor for ResourceLoader styles specified as '.less' files; currently no on-wiki or gadget handling is included, so there are not security issues with LESS @import rules.
LESS http://lesscss.org/ is pretty handy and is used by a number of our extensions to make styles more maintainable (set constants, do math, make combined rules for things like -webkit-blah). Direct LESS support in core will do away with the precompilation step during development.
There's a patch implementing it in core: https://gerrit.wikimedia.org/r/#/c/78669/
and a sample patch updating MobileFrontend to use it: https://gerrit.wikimedia.org/r/#/c/84139/
Open questions: * Are there any remaining problems with the caching and dependency checks? * What's the best way to handle image embedding? (/* @embed */ rules get messed up but we can use an alternate function...) -- see notes on gerrit * ...any other concerns with performance, security, or basic functionality?
-- brion
Some more questions for discussion:
- I'm concerned that some of the useful things people do with sass (ie, robust cross-browser support with compass) are impossible with less.
- Has http://learnboost.github.io/stylus/ been considered? I've heard that it's a good compromise between sass and less (but I haven't played with it myself to see if it really lets you do more compass-like things). - The interaction between ResourceLoader and @import seems a bit under-defined. Although less has not really documented it yet, less added a slew of new @import options in 1.4.1/1.5.0 (see https://github.com/less/less.js/blob/master/CHANGELOG.md ; https://github.com/less/less.js/issues/1185 ; https://github.com/less/less.js/issues/1209 ; https://github.com/less/less.js/issues/1210 ). It would be nice to have a concrete written guideline for how MW authors are expected to use @import and/or better integrate @import with ResourceLoader.
- @import processes referenced URLs asynchronously, IIRC, which might cause issues w/ integration. I haven't done a code review to see how the existing patches handle this (or not). --scott
- Has http://learnboost.github.io/stylus/ been considered? I've heard that
it's a good compromise between sass and less (but I haven't played with it myself to see if it really lets you do more compass-like things).
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 4:04 PM, Dan Andreescu dandreescu@wikimedia.org wrote:
- Has http://learnboost.github.io/stylus/ been considered? I've heard that
it's a good compromise between sass and less (but I haven't played with it myself to see if it really lets you do more compass-like things).
*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.
I'm for any compiled-to-css language because I feel they fill a big gaping hole in css's ability to share code. That is really compelling to me. I haven't been convinced the compiled-to-js languages offer quite as compelling a value proposition so the analogy to Limn and Coco is less relevant to me. I admit I could be wrong about the value proposition thing but that is how I feel. I really don't want to start a language war though.
I'm a Sass fan but I'll take whatever I can get.
I will point out that CSS is valid LESS which could assuage some fears.
Nik Everett
On Thu, Sep 19, 2013 at 12:24 PM, C. Scott Ananian cananian@wikimedia.orgwrote:
- The interaction between ResourceLoader and @import seems a bit
under-defined. [...] It would be nice to have a concrete written guideline for how MW authors are expected to use @import and/or better integrate @import with ResourceLoader.
- @import processes referenced URLs asynchronously, IIRC, which might cause
issues w/ integration. I haven't done a code review to see how the existing patches handle this (or not).
@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.
@ori: You might want to look into the different @import options before being so dogmatic. In particular, the media-query restrictions are probably very useful to MW. The (less) option also allows overriding CSS files, which can help prevent the "everything must be less!" problem. And the (reference) option would let you use ResourceLoader to bundle files as usual while *also* allowing less overrides. This could be important when we're trying to override styles defined in a different resource loader bundle.
@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). (Spec in http://compass-style.org/reference/compass/css3/images/ ). Now, maybe we don't actually need all that power. But the automatic cross-browser compatibility it allows sure is nice... --scott
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.
On Fri, Sep 20, 2013 at 2:35 PM, Ori Livneh ori@wikimedia.org wrote:
I personally think it'd be unfortunate for this current effort to collapse over such considerations, but I'm obviously biased.
Oh, I certainly agree. For my part, I'm satisfied that the LESS/Sass/stylus issues have been adequately thought through (maybe some of this can make it back into the RfC). The http://leafo.net/lessphp/docs/#custom_functions stuff looks very promising, it probably should be explicitly mentioned in any "LESS for MW" docs we write. I look forward to seeing the @import guidelines as well. --scott
On Fri, Sep 20, 2013 at 12:53 PM, C. Scott Ananian cananian@wikimedia.orgwrote:
On Fri, Sep 20, 2013 at 2:35 PM, Ori Livneh ori@wikimedia.org wrote:
I personally think it'd be unfortunate for this current effort to
collapse
over such considerations, but I'm obviously biased.
Oh, I certainly agree. For my part, I'm satisfied that the LESS/Sass/stylus issues have been adequately thought through (maybe some of this can make it back into the RfC). The http://leafo.net/lessphp/docs/#custom_functions stuff looks very promising, it probably should be explicitly mentioned in any "LESS for MW" docs we write. I look forward to seeing the @import guidelines as well. --scott
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.
The biggest gains to be had from using a CSS preprocessor tend to come from the most basic features
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.
Ok, we've had another round of review and updates, and it sounds like people are pretty content with the functionality and the conventions we're coming up with around LESS usage; and I don't hear many strong objections.
If there's no last-minute surprises from anybody, I'll drop the +2 hammer on the core support https://gerrit.wikimedia.org/r/#/c/78669/ later today, and folks can start using it.
-- brion
On Fri, Sep 20, 2013 at 1:32 PM, Dan Andreescu dandreescu@wikimedia.orgwrote:
On Fri, Sep 20, 2013 at 12:53 PM, C. Scott Ananian cananian@wikimedia.orgwrote:
On Fri, Sep 20, 2013 at 2:35 PM, Ori Livneh ori@wikimedia.org wrote:
I personally think it'd be unfortunate for this current effort to
collapse
over such considerations, but I'm obviously biased.
Oh, I certainly agree. For my part, I'm satisfied that the LESS/Sass/stylus issues have been adequately thought through (maybe some
of
this can make it back into the RfC). The http://leafo.net/lessphp/docs/#custom_functions stuff looks very promising, it probably should be explicitly mentioned in any "LESS for MW" docs we write. I look forward to seeing the @import guidelines as well. --scott
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.
The biggest gains to be had from using a CSS preprocessor tend to come from the most basic features
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. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Le 21/09/13 19:50, Brion Vibber a écrit :
Ok, we've had another round of review and updates, and it sounds like people are pretty content with the functionality and the conventions we're coming up with around LESS usage; and I don't hear many strong objections.
If there's no last-minute surprises from anybody, I'll drop the +2 hammer on the core support https://gerrit.wikimedia.org/r/#/c/78669/ later today, and folks can start using it.
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,
On Sat, Sep 21, 2013 at 10:50 AM, Brion Vibber bvibber@wikimedia.orgwrote:
Ok, we've had another round of review and updates, and it sounds like people are pretty content with the functionality and the conventions we're coming up with around LESS usage; and I don't hear many strong objections.
If there's no last-minute surprises from anybody, I'll drop the +2 hammer on the core support https://gerrit.wikimedia.org/r/#/c/78669/ later today, and folks can start using it.
There were a couple of suggestions to expand the inline documentation for the configuration vars, which I did. Unless there are objections, I recommend merging it in tandem with < https://gerrit.wikimedia.org/r/#/c/85143/%3E.
My sincere thanks to all reviewers.
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 ori@wikimedia.org wrote:
On Sat, Sep 21, 2013 at 10:50 AM, Brion Vibber <bvibber@wikimedia.org
wrote:
Ok, we've had another round of review and updates, and it sounds like people are pretty content with the functionality and the conventions
we're
coming up with around LESS usage; and I don't hear many strong
objections.
If there's no last-minute surprises from anybody, I'll drop the +2 hammer on the core support https://gerrit.wikimedia.org/r/#/c/78669/ later today, and folks can start using it.
There were a couple of suggestions to expand the inline documentation for the configuration vars, which I did. Unless there are objections, I recommend merging it in tandem with < https://gerrit.wikimedia.org/r/#/c/85143/%3E.
My sincere thanks to all reviewers. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Sep 23, 2013 at 1:08 PM, Brion Vibber bvibber@wikimedia.org wrote:
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
Thank you very very much to all those who co-wrote or reviewed the patch & RFC -- especially & specifically: Timo, Brion, Roan, Bartosz, Steven, Matt, & Jon!
Woot!
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" bvibber@wikimedia.org wrote:
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 ori@wikimedia.org wrote:
On Sat, Sep 21, 2013 at 10:50 AM, Brion Vibber <bvibber@wikimedia.org
wrote:
Ok, we've had another round of review and updates, and it sounds like people are pretty content with the functionality and the conventions
we're
coming up with around LESS usage; and I don't hear many strong
objections.
If there's no last-minute surprises from anybody, I'll drop the +2
hammer
on the core support https://gerrit.wikimedia.org/r/#/c/78669/ later today, and folks can start using it.
There were a couple of suggestions to expand the inline documentation for the configuration vars, which I did. Unless there are objections, I recommend merging it in tandem with < https://gerrit.wikimedia.org/r/#/c/85143/%3E.
My sincere thanks to all reviewers. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Le 23/09/13 22:08, Brion Vibber a écrit :
- https://gerrit.wikimedia.org/r/#/c/84139/ - update for MobileFrontend
Whenever that change is merged, it will be deloyed automatically on the beta cluster after a few minutes at:
http://en.m.wikipedia.beta.wmflabs.org/
;)
On Sep 19, 2013, at 11:19 PM, C. Scott Ananian cananian@wikimedia.org 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_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). (Spec in http://compass-style.org/reference/compass/css3/images/ ). Now, maybe we don't actually need all that power. But the automatic cross-browser compatibility it allows sure is nice... --scott
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.
On 09/19/2013 04:53 PM, Ori Livneh wrote:
I can commit to documenting this on mw.org if / when the proposal is accepted and the patch is merged.
This is a good example. I recommend adding it to https://www.mediawiki.org/wiki/Requests_for_comments/LESS/Conventions.
Matt Flaschen
wikitech-l@lists.wikimedia.org