Proposal: Convert .css files to .sass

[x2048]

Currently, themes are compiled from .scss. I would suggest to make a transition so that all .css files are replaced by .scss.
This task can be split into two sub-tasks:

• Convert all admin .css to .scss
• Convert all theme .css to .scss

Some of the reasons to convert *all* .css files to .sass:

• Less duplication in the code. Leads to easier development
• Easier to modify code. E.g. we can have global variables for common colors, widths, etc.
• It would be faster to write new styles.
• Possibility to reuse things via mixins.
• Possibility for future optimizations. E.g. there can be a file called main.scss that just includes all other .scss files. That way WordPress can ship with only 1 .css file (e.g. admin.css), which will improve .css loading times, caching, etc.
• Possibility for plugin/theme authors to reuse constants. E.g. if there's a "variables.scss" or a "media-queries-mixins.scss", a plugin author would be able to use the same values as wp-core.
• It's a nice opportunity to perform a code-review and remove legacy styles.

---

Potential Problems

Converting a .css to an *idiomatic* .scss isn't an automatable process - how would we detect a typo in the conversion?

Solution
Suppose we have a farbtastic.scss that is a candidate to replace farbtastic.css
We can check if the two files provide identical functionality with the following script:

#!/bin/sh

node-sass farbtastic.scss farbtastic-scss.css
csstidy fabtastic-scss.css  --silent=true --template=low > farbtastic-clean-scss.css
csstidy farbtastic.css --silent=true --template=low > farbtastic-clean.css

diff farbtastic-clean.css farbtastic-clean-scss.css

The script can of course be modified to work with any .css/.scss file pair.

How would we detect if the .scss produces different, but equivalent .css to the original?

After an .scss file has been shown to replicate the functionality of its .css predecessor, it can then be refactored to produce different, but equivalent output.

Some .css files are 50KB. How would those be converted?

Very big .css files can be split into smaller files before conversion to .scss.
Or, very big .css files can be converted at a later time. It's possible to convert each file individually.

---

I volunteer to create the relevant grunt tasks, to create the tool to check if an .scss is equivalent to the original .css, and to convert the existing .css files.

[x2048]

Sample file converted to .scss

[x2048]

A shell script to check if an SCSS file compiles to an identical CSS file. Usage: While in a directory that contains file.css and file.scss, call "css-check file"

[x2048]

It appears that there already exist tools to produce idiomatic SCSS (that is, the outputted SCSS has nesting and reasonable grouping).

The tool sass-convert (shipped with the Ruby version of sass, but *not* with the node-js version, AFAIK).

It works out-of-the-box for almost all of Wordpress' CSS. The only exception are @keyframes directives, which can be handled separately.

The Admin panel looks indistinguishable from before, which means the conversion was successful.
This means that the task is reduced to "Review the generated SCSS and make sure it's usable.".

I am attaching a trivial script to convert a folder into .SCSS

[x2048]

A script to convert .css files to their .scss equivalents. Run it in e.g. src/wp-admin/css/

[x2048]

Patch to replace the admin CSS with SCSS

[x2048]

The patch isn't final, but is an indication of what the final result will look like.

Consider it a Request For Comments.

[DrewAPicture]

Hi x2048, your patch will need a .patch or .diff extension to be viewable.

[SergeyBiryukov]

Related: #20570, #22862.

[DrewAPicture]

I guess we'll move this to Build Tools.

[nacin]

Hi x2048, this is something we've discussed previously. At the moment, we're not going to be using a preprocessor in core, beyond our use of one for color schemes. See also ​http://make.wordpress.org/core/?s=sass+preprocessor and #22862.

One of the main laws from the book Code Simplicity by Max Kanat-Alexander is: “It is more important to reduce the effort of maintenance than it is to reduce the effort of implementation.” In our case, the efforts of implementation are significantly reduced — we just don't write a whole lot of CSS from scratch; it is often maintaining existing CSS. While preprocessors have plenty of benefits for maintenance too, they also significantly raise the barrier to entry for contributions. At the moment, they also would not add significant value, while they would complicate other ongoing efforts to bring baseline sanity to our CSS.

It's not a matter of the ability to do it, but whether we'd want to. If/when the time comes to discuss this again, it'd likely be proposed by another committer and discussed during a meeting or on ​https://make.wordpress.org/core, so I'm going to close this out.

(See also ​http://adamsilver.github.io/articles/the-boring-front-end-developer/)

[x2048]

@nacin thank you very much for the follow-up explanation.
I accept the reasoning and will read that article.

[ericlewis]

Replying to nacin:

While preprocessors have plenty of benefits for maintenance too, they also significantly raise the barrier to entry for contributions.

We should be pushing developers to use proper modern tooling. I don't think it's too much to ask a developer to figure out preprocessors, and will only help them grow.

Replying to nacin:

they would complicate other ongoing efforts to bring baseline sanity to our CSS.

I agree here. We should consider adopting a CSS methodology, or defining our own. That will go further than converting everything to a CSS preprocessor.