WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#29797 closed enhancement (duplicate)

Proposal: Convert .css files to .sass

Reported by: x2048 Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.1
Component: Build/Test Tools Keywords: has-patch needs-testing needs-refresh
Focuses: ui, rtl, administration, template Cc:

Description

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.

Attachments (4)

farbtastic.scss (540 bytes) - added by x2048 5 years ago.
Sample file converted to .scss
css-check (1.0 KB) - added by x2048 5 years ago.
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"
convert-all.sh (273 bytes) - added by x2048 5 years ago.
A script to convert .css files to their .scss equivalents. Run it in e.g. src/wp-admin/css/
patch (729.2 KB) - added by x2048 5 years ago.
Patch to replace the admin CSS with SCSS

Download all attachments as: .zip

Change History (12)

@x2048
5 years ago

Sample file converted to .scss

@x2048
5 years ago

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"

#1 @x2048
5 years ago

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
5 years ago

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

@x2048
5 years ago

Patch to replace the admin CSS with SCSS

#2 @x2048
5 years ago

  • Keywords has-patch needs-testing added

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

Consider it a Request For Comments.

#3 @DrewAPicture
5 years ago

  • Keywords needs-refresh added

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

#5 @DrewAPicture
5 years ago

  • Component changed from General to Build/Test Tools

I guess we'll move this to Build Tools.

#6 follow-up: @nacin
5 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

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/)

#7 @x2048
5 years ago

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

#8 in reply to: ↑ 6 @ericlewis
5 years ago

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.

Note: See TracTickets for help on using tickets.