Requests for comment/LESS

This document proposes adopting LESS as a stylesheet language in core.

What is LESS?
LESS is a stylesheet language that compiles into CSS. LESS is a superset of CSS: any valid CSS code is also valid LESS. LESS extends CSS with variables, mixins, operations, and functions. These abstractions provide a means for writing concise and well-factored stylesheets that derive the styling of individual interface components from a core set of definitions.

Code samples
As an example, let's use LESS to refactor some actual CSS code in core:

The first thing we'll do is use LESS's ability to concisely express inheritance and cascade by nesting selectors:

If you look closely at the rules for  and , you'll notice that they share a common pattern of setting a background color on an input element and declaring a one-pixel border on that element that is painted a slightly darker shade of that color (12.5% darker, to be exact). LESS allows us to express this pattern as a mixin. At their most basic, mixins are simply a shorthand for a group of CSS rules that go together. More sophisticated mixins can take parameters:

You may also notice that the colors used to style the valid & invalid input boxes form two-thirds of a triadic color scheme. (Triadic color schemes consist of three colors that are equidistant from each other on the color wheel.) LESS allows us to assign these colors human-readable names and gives us functions we can use to derive harmonious color themes from a base color:

Because we'd like to build up a library of generic style components, we defined our mixin and variables in. To use these definitions in, we use the   directive. The final result looks like this:

Why use a CSS preprocessor?
Using any CSS preprocessor makes your code easier to write, reuse and maintain by adding features such as...


 * mixins, which allows you to embed a rule into another rule, and then extend it with further arguments;
 * variables, which let you define and then reuse values throughout a stylesheet, leading to more consistent design;
 * and nesting, which can clarify how rules inherit from each other and helps avoid unnecessary repetition. Having more concise stylesheets and clearer relationships between styles means that refactoring is easier and diffs are cleaner.

In addition to making stylesheets less of a pain for you to create, the above features can make an open source project easier to customize and extend. For a great example of this in action, check out the very popular Bootstrap project's use of LESS.

Why use LESS?
LESS is one the most popular and stable CSS preprocessors. We really don't want to bikeshed.

Why not SCSS / Sass?
Sass is another excellent CSS preprocessor. The E3 team made extensive use of Sass in our work to update the login and account creation interfaces and found it to be an excellent tool. Comparisons of LESS and Sass often give undue emphasis to minor differences in syntax, but it's important not to lose sight of the broad overlap that exists between these two tools. They are very similar. Our preference for LESS stems from a preference for its PHP implementation: we like its documentation and its large suite of unit tests, and we see the change log and the history of activity on its issue tracker as indicators of a healthy open-source project.

If this RFC is implemented, we will convert the existing SCSS code in core to LESS, and remove the special make process for that.

LESS in MediaWiki core
Adding support for LESS to MediaWiki means that generating CSS from LESS files would not require a separate build step, but instead happen on the fly. ResourceLoader makes this easy to implement because it already implements a static asset pipeline. It does not generally serve JS and CSS files as they are written on disk; instead it applies a series of transformations to the raw source code that optimize it and adapt it for the client's environment, and caches the result of its transformations to avoid repeating work. It already performs minification and RTL flipping of CSS. ResourceLoader has worked extremely well for MediaWiki and we think that by extending it judiciously, LESS support could be implemented in a manner that does not degrade performance. contains a draft implementation.

Why not implement this as an extension?
MediaWiki core has over 10,000 lines of CSS code, some of it quite ancient, and we think that a tool like LESS can help us a lot with its upkeep. This will help us define and enforce a set of consistent design guidelines for MediaWiki's interface, and it's fun to write. Concentrating these generic definitions in core and providing a uniform interface for working with LESS will facilitate standardization and code reuse.