Nearly a year ago, Chris Wallace proposed that the WordPress core adopt a CSS Preprocessor to help move admin UI CSS into the future. Including a CSS preprocessor allows developers to speed up tasks with the use of variables in stylesheets. Variables will make tasks like reskinning the WordPress admin a breeze. Wallace argued strongly for Sass in his ticket because of its relatively low barrier for entry, due to the fact that it follows the conventions of CSS at its core.

With the inclusion of MP6 finally a lock for WordPress 3.8, Helen Hou-Sandi reignited the discussion on CSS preprocessors by highlighting Wallace’s original ticket on the make.wordpress.org core development blog. After an epic debate of Sass vs. LESS, it seems that Sass has won out and will be adopted as WordPress’ CSS preprocessor moving forward.

Why Sass?

Proponents of Sass cited many reasons why it would be a better fit for WordPress than other CSS preprocessors. To quickly summarize the discussion, I’ve outlined just a few of the important arguments for a CSS preprocessor in general and for Sass in particular:

Allows for the use of variables to calculate layout widths, generate color schemes, font sizes, etc.

Reduces HTTP requests when stylesheets are combined into one

Easily minify generated CSS files in bundled versions of WordPress to speed up load times

Sass is GPL-compatible, licensed under the MIT license

Sass is backwards compatible with all versions of CSS

Sass supports more advanced logic – ability to include if/then/else and for/while/each statements

The main challenge with Sass is that it is dependent upon Ruby and the Sass Ruby gem. Efforts to sort out the Ruby dependency have landed on the use of grunt-sass, which allows for compiling .scss files without Ruby.

The inclusion of Sass capabilities in WordPress 3.8 will bring a bright new day for front-end developers who contribute to core. Are you excited about Sass use in WordPress? Or were you on the other side of the debate?