Consider a CSS preprocessor

[chriswallace]

The WordPress admin UI CSS is woefully doomed to a life of inadequacy unless we can amenably agree to use technology already available to build a better future for us and our children.

I propose the introduction of SASS for the WordPress admin styling. SASS is a CSS pre-processor that allows us to write DRY, structured, lightweight CSS. In terms of licensing, SASS is GPL-compatible, licensed under the MIT license.

Why use SASS over LESS?

The answer is simple. SASS is easier to learn and easier to use because it follows the conventions of CSS at its core. In addition, for developers itching to contribute, there are some extremely useful and easy-to-follow reference docs for SASS, making it easy to set up your local development environment and build websites.

What are the advantages?

The biggest advantage is that we can write less CSS and offer advanced features for theming the WordPress Admin UI. Developers can more easily reskin the WordPress admin.

Another major benefit is that SASS offers the use of variables within our stylesheets. For our purposes, these variables can be used to calculate layout widths, generate color schemes, font sizes, etc.

Another simple advantage is the fact that we can combine all our CSS styles into a single stylesheet, saving precious HTTP requests. In addition, we can easily minify generated CSS files in bundled versions of WordPress, saving file size and killing unnecessary white space, thus decreasing load times of the admin even further.

What are the disadvantages?

Developers will need to install Ruby and SASS in order to modify styles for the WordPress Admin. For plugin authors, we should write admin UI CSS in such a way that it is easily overridden with a custom CSS file.

In addition, developers would need to learn SASS if they are going to work directly on the styles for the WordPress admin. For the most part, once you've got the idea of variables, mix-ins, and the structure - you're ready to rock.

Last, but not least, when SASS files are modified, they would need to be compiled and committed to Core every time they change. So instead of pushing a single CSS file, you would be pushing potentially many SCSS files and a generated CSS file.

In Summary

SASS is a great way to reduce code overhead by adhering to DRY principles and will improve performance and modularity in the WordPress admin, which is a top priority.

[helenyhou]

In terms of proposing something, let's back it up and just talk about using a CSS preprocessor as a general concept and not choose one or the other just yet. It will hopefully keep us on the right track rather than spurring an ideological battle :)

The disadvantages listed are where my current feeling lies when it comes to WordPress core development. It would be a great disservice to alienate so many current and potential contributors who are unfamiliar with a given (or any) preprocessor and what it means for workflow. For full disclosure, I don't use them myself, and don't have a detailed view of what it means for what we would then have to do on the core side to accommodate. What I do know is that it adds an extra layer of learning, abstraction, and development work, especially for folks who are less frequent contributors, just learning, or not necessarily development-minded. It's important to remember that anybody can contribute to WordPress, even just once to fix that one thing that's bugging them. Whether or not it's accurate, a perception that higher level knowledge of the admin and its components is expected or required would intimidate many.

Basically, the idea of a higher barrier to entry in an area where we can always use more help makes me squirm, and that there are currently multiple preprocessors that seem equally popular only adds to my discomfort.

I highly encourage you to take the time to really look at our CSS files. I think you'll find there is only one big one for the admin, with a few separated out for colors and specific elements, and then some sheets that are in wp-includes because they can be included on the front, also for specific elements (TinyMCE, buttons, media [which begat buttons on the front]). I'm sure you've taken a look, but not having seen you around core UI before, it's hard to know how close that look has been.

If anybody would like to do a little proof-of-concept, I would suggest the two color sheets as starting points, and think it would be best if both of the really popular preprocessors (SASS and LESS, to be clear) were accounted for. I definitely have viewed color schemes as a favorable starting point in the past when this has come up in UI chats, and would love to see what advantages and disadvantages they bring in practice.

[chriswallace]

Helen,

The reason I propose SASS as the tool of choice is because it eliminates one of the major barriers to getting started with LESS: syntax. Anybody can still propose a CSS patch for admin CSS. A core dev is going to review and implement the patch ultimately anyway. Debugging and troubleshooting would occur the traditional way but a core dev would simply identify the proper SCSS file for the patch and implement it there, rather than inside a generated CSS file.

In addition, I think making the move to a CSS preprocessor will actually open WordPress up to an audience of discerning designers and developers who appreciate working smarter, not harder. This is a topic gaining great traction for developers right now and has matured to a point of stability and is a logical path for software development. Bringing it to WordPress will demand attention as a forward-thinking platform for developers - which is what it ultimately should strive to be. The biggest question I ask is this: is this a better way to build software? The answer is most definitely yes.

Regarding color schemes as a starting point, I think that's a mighty fine idea. I will take a close look at the CSS and see what I can whip up in the next week or so.

[bpetty]

From the software architecture perspective, this actually abstracts out even further.

Obviously, implementing admin (or anything in WP) in SASS or LESS would require adding at least one of the preprocessors to WP. At it's very basic level, LESS is definitely the easiest, and is already possible to do from plugins and themes. However, we're really not just talking about admin-only here. Whatever solution is in place, it's going to need to give plugins and themes options as well, and it's likely not going to be adequate unless it gives at least both options of SASS and LESS, not to mention CoffeeScript.

What we're really talking about here is an asset management system much like the Rails ​asset pipeline, or the CakePHP ​Asset Compress plugin, except, WP would probably be best using the ​Assetic PHP library currently used by most Symfony developers. We're already half way there with WP_Scripts and WP_Styles. This would just extend those.

The ideal system here would handle not just preprocessing of a variety of popular formats, but also minification, and combination of both CSS and JS (as a replacement for what we already do using a Subversion asset minification bot). It would leave everyone the option of using any preprocessor they want or not using one at all, so admin could be left in plain CSS (which Helen has some good arguments for) while a theme might choose to use SASS markup, and a plugin might include some LESS styles.

The problem with all of this is that any system implementing asset management (except for a LESS-only system) relies very heavily on either a high performance persistent cache (which WP rarely has available in almost all shared environments) or at least write access to a public temporary directory for serving out generated assets just like most page caching plugins use so the web server can properly manage expiration and caching. There are sites where WP works without filesystem write access though (imagine anyone not using media, or using an S3 media plugin). Without either of those, the best WP can do is serve processed assets directly from transients (in other words, PHP/WP initialization and a database hit for all assets). That would result in terrible performance, and should never be imposed on anyone.

So with that in mind, I don't think this proposal should even be considered right now, leaving this to plugin territory for now.

[dd32]

I think we can ignore filesystem-based restrictions for the purpose of this really. There are 2 reasons for this:

• Releases of WordPress would be using a compiled & minified CSS stylesheet, the same as at present (Remember, in addition to minification, we also combine all stylesheets together into one and serve it gzip'd on the fly)
• Developers who are altering CSS stylesheets would have to use the pre-processor anyway, so in those environments where the minified/compressed/concatinated scripts are not in use, I'd expect the pre-processor to be in use.

It also seems obvious that we'd want to implement a pre-processor which is written in PHP for maximum flexibility and server-side regeneration during development.

This is also another one of these tickets that would be far better off discussed on a P2 among the design group, and a summary brought back to the table on Trac, P2 generally leads to a easier discussion flow for all involved.

[helenyhou]

Replying to chriswallace:

The reason I propose SASS as the tool of choice...

A good thing to keep in mind when proposing something is that we should work to identify the entirety of the underlying problem first before tackling the solution. Starting with presenting a solution first, however much you've reasoned it out yourself, creates that dreaded "when all you have is a hammer, everything looks like a nail" feeling.

In any case, dd32 is right - Trac is not a great place for theoretical discussion. We're re-sorting the UI group, and the core part of what we do will likely get absorbed back into that group so it's not so separate-seeming, but you are welcome to pitch this in #wordpress-ui anytime, including regular chat time if you want to schedule it and we're not otherwise occupied, or better yet in my opinion, write about this on your own blog and really own the discussion there and get into all the details, present examples, etc. I'd hesitate to put it on Make UI solely because there is a tendency for casual observers to take discussions there as promises for the future.

[TJNowell]

Relevant is the WP-LESS plugin by Robert O'Rourke:

​https://github.com/sanchothefat/wp-less

Using just PHP is auto-compiles theme LESS files that are enqueued on the front and backend, allows inserting LESS variables via filter/hook too, seems to be in use by a number of experience people.

A similar plugin also exists called WP-SASS:

​https://github.com/sanchothefat/wp-sass

I can't comment on how stable or its feature set however as I haven't used it, but it's by the same person and follows the same train of thought.

If we were to SASS'ise or LESS'ise the admin css, doing it in a plugin coupled with one of these, and de-queueing the existing stylesheets is one possible route for testing/prototyping ( that removes the need for ruby )

[helen]

Now would be a really good time for somebody who uses preprocessors regularly to tackle a proof-of-concept here. :)

[Rarst]

I am not sure why OP has such an issue with LESS syntax, since valid CSS is valid LESS. LESS is historically close to common CSS syntax, while SASS moved towards it from more diverged version.

For my taste LESS is preferable because it can be run with less.js in browser, which is not very performant but trivial to set up.

[Bueltge]

Important for me is, that we not only discuss about the preprocessor for administration. The topic is often a requirement of different topics on front and backend and important, if you will, that more and more developrs work with wp and can use his default tools.

[chriswallace]

Replying to Rarst:

I am not sure why OP has such an issue with LESS syntax, since valid CSS is valid LESS. LESS is historically close to common CSS syntax, while SASS moved towards it from more diverged version.

For my taste LESS is preferable because it can be run with less.js in browser, which is not very performant but trivial to set up.

I personally don't care as long as we decide to move forward with at least experimenting and trying to do something to make the styling easier to tap into without completely overriding it with custom CSS. Maybe this could even be added as a feature of MP6, which is probably a good place to look since its already in its own sandbox.

[helen]

Replying to chriswallace:

Maybe this could even be added as a feature of MP6, which is probably a good place to look since its already in its own sandbox.

I would agree that MP6 or even a companion plugin is likely a better route for experimenting, given that CSS patches to core have a nasty habit of going stale quickly.

Also... let's not rabbit hole (yet). One step at a time, and the first step in my eyes is converting some existing file and demonstrating/describing a contributor's workflow to making a patch for the admin. I would also still like to see both SASS and LESS represented :) That is to say: data is nice.

[rmccue]

I'm working on a conversion of MP6 to SCSS at the moment as a proof of concept. :) (I'm also using the ​Compass framework at the moment for utility mixins, but I'm happy to rewrite it without the framework.)

[rmccue]

Decided to not convert the entire codebase, but ​just a few for now. This isn't really using all the strengths of a preprocessor (that is, sharing across files), but I haven't had time to get to that yet.

This generates ​almost the exact same CSS, but with some changes. I've left the line number comments in for now; when importing this into WP, we'd move the actual compilation tasks off to bumpbot with the style set to compressed.

Keep in mind that converting the codebase isn't a small task that I have time to handle, but if you'd like to see a more practical usage, I can open-source a slightly larger codebase of mine that uses SCSS extensively.

[rmccue]

Also, ​comparison of SCSS and Less (via ​Hacker News) that might help with a decision on a specific one. Personally, I prefer SCSS's mixin syntax, which makes clear the distinction between virtual classes (mixins) and real ones, whereas Less only has real classes.

Also, interesting note: "Sass output compression currently beats the google pagespeed css plugin output by a few percent."

[wonderboymusic]

I think the main advantage of using one of these bad boys is the ability to break apart the 10 billion line CSS files into modules / imports. It has been a huge upgrade to every huge project I have worked on. I may do a LESS proof of concept today to show my worldview.

[helen]

Previously: #18314

[Rarst]

I have put together small plugin that shows switching between compiled CSS and browser-compiled LESS mode ​https://bitbucket.org/Rarst/less-colors Doesn't actually use any LESS features on top of compilation, it's too monday to rewrite 2k lines of CSS :) Symlink admin images into plugin folder for them to work.

PS remembered that less.js is Apache License 2.0 so including it in core is toast :(

[wonderboymusic]

So I took a big bite out of this....

22862.diff​ is wp-admin.css and wp-admin.min.css compiled by LESS. I broke up the admin styles from one 10,000 line file into 32 modules. The structure is like so:

/wp-admin/css/wp-admin.css
/wp-admin/css/wp-admin.min.css
/wp-admin/css/less/wp-admin.less // manifest file
/wp-admin/css/less/variables.less
/wp-admin/css/less/mixins.less
/wp-admin/css/less/modules/* <--- the 32 modules

I rewrote the entire wp-admin.css in LESS syntax. There are still probably a billion things that could be done, but you'll get the gist. I only made one variable, but I made a bunch of mixins.

To compile the code from LESS to CSS, cd to the /wp-admin/css/less directory and then:

lessc wp-admin.less > ../wp-admin.css
lessc wp-admin.less --yui-compress > ../wp-admin.min.css

I am sure I broke stuff, but I did a bunch of testing to make sure everything appears like it wasn't broken by my test.

My immediate reactions after doing this:

1. There is an ungodly amount of CSS
2. Splitting it up into modules is the easiest to optimize by feature
3. LESS shows us when our nesting levels are way too deep. Google PageSpeed generally recommends only 2 levels deep max
4. I would prefer if we found a way to move forward with LESS or an equivalent, but ultimately that's up to UI team players
5. If you want to mess around and make your own version in LESS, SASS, or SCSS, might I suggest that you fork my patch. It takes 300 forevers to do this from scatch.

[bpetty]

Since there's more activity on this again lately, I figure it's a good time to update everyone on recent developments on SASS since they might be relevant here.

Since this ticket was first opened, there is now a sponsored effort working towards the ​libsass project, opening up non-ruby implementations, and eventually replacing the ruby version altogether way down the road (with a ruby binding on libsass). In fact, there's also already at least two PHP ​libsass ​bindings I've found in the works, and while they are still incredibly young, unstable, and mostly unusable, this is the direction we're headed with eventually including a SASS compiler as a built-in PHP extension without any other external dependencies.

Of course, this is all still a *long* way away (I'd say about 8 to 10 years) from being something WP could take advantage of for core development, but it's not like core devs wouldn't already have to install additional tools to compile LESS anyway. However, when we break it down there, installing lessc frequently gets new devs caught up with installing npm/node/etc, but with SASS we will have a command line tool written in C, built on libsass much sooner that doesn't have any other dependencies. We would be looking at native platform binaries with super simple installers and distro packages, no extra npm package management and environment configuration.

If you follow development on these projects much, you might find one of the latest podcast interviews with the inventor of SASS and founder of libsass interesting that covers much of this work: ​http://5by5.tv/changelog/94

There isn't any effort along these lines for LESS (at least JS is already much more portable than Ruby anyway).

As for my opinion...

When I compare the two precompilers, I generally agree the most with ​this comparison of the language features. So when I take the above developments into consideration along with the comparisons on language features (which I find SASS is much stronger in due mostly to limitations of the browser-side LESS compiler holding LESS back), it's still easy to consider LESS for tiny, quick projects, but not for large-scale projects like this with many collaborators. There's a huge benefit to making use of the Compass library for SASS for WordPress core too, assuming it's not too much to ask for newbie devs and designers to learn and really make good use of anyway.

@dd32 may have also nailed it too:

Replying to dd32:

It also seems obvious that we'd want to implement a pre-processor which is written in PHP for maximum flexibility and server-side regeneration during development.

Although, I guess that's still possible with ​lessphp, it would just be a pity to have to bundle that somewhere unless we also got around to ​adopting composer.

[wonderboymusic]

Point of order: I only used LESS because I don't know SASS or SaaaaassyCSS. It would probably be easy for someone to just search and replace my vars and mixins and change them to the alt syntax

[Rarst]

Although, I guess that's still possible with ​lessphp

I would be cautious about lessphp. It's a fine port, but it lags behind in updates. Also original LESS implementation allows to embed generic JavaScript transparently and that doesn't play well with ports to different languages.

I've used to compile LESS in PHP (via wp-less plugin mentioned above in the thread), but moved away from it in favor of compilation by IDE in development.

[toscho]

Will it still be possible to see the actual result of a patch with a pre-processor? This is a must, because the real CSS is the code we have to review.

[wonderboymusic]

Currently converting my patch to SCSS - I don't like it. Syntax sucks, and you can't overload mixins - meaning, you can't have multiple versions of a mixin that take a different number of arguments. I don't think the libsass argument means we should pick one or the other just because of the code it compiles on top of. I fully thought SASS was going to better, it was just something I hadn't looked at yet - I think the latest version of LESS is cleaner with better docs.

As it stands right now, SASS by default compiles via Ruby gem - a lateral move from NodeJS. No matter what the method of development, at the end, someone's going to have to push a button that compiles the code so they can run it in the browser.

[wonderboymusic]

22862-sass.diff​ is the SaaaaaassyCSS version, which I downvote.

sass wp-admin.scss > ../wp-admin.css
sass wp-admin.scss --style compressed > ../wp-admin.min.css

[rmccue]

Worth mentioning that there's also ​scssphp by the same author as the previously mentioned lessphp. Jetpack actually bundles both of these for the Custom CSS feature.

Replying to wonderboymusic:

Currently converting my patch to SCSS - I don't like it. Syntax sucks, and you can't overload mixins - meaning, you can't have multiple versions of a mixin that take a different number of arguments.

Also true of PHP. I'm not sure you really need it to be honest.

As it stands right now, SASS by default compiles via Ruby gem - a lateral move from NodeJS.

Anecdotally, I've found it much, much easier to install and use Sass (via Compass) on Windows.

No matter what the method of development, at the end, someone's going to have to push a button that compiles the code so they can run it in the browser.

That's true, and I think both the tools are at parity there.

I'll take a look at your SCSS version this afternoon and see if there's anything we can do better in that. There's a few things in there I can see that I'd improve, so I'll see if I can clean it up a little (unless someone else gets to it first).

[TJNowell]

One should bear in mind that using lessphp allowed WP-LESS to add filters and hooks for Less variables. One can use a variable in LESS whose value was defined in the theme customiser in PHP, and it re-generates the stylesheet as those values change.

The benefit of this being that you could have instead of a blue and a green and a red admin style, you could have a single style with a colour picker and let the user choose what they like best, and have the stylesheet procedurally generate the colours via math.

[jorbin]

Replying to rmccue:

Replying to wonderboymusic:

No matter what the method of development, at the end, someone's going to have to push a button that compiles the code so they can run it in the browser.

That's true, and I think both the tools are at parity there.

With the new setup that @koop just announed on the make blog (​http://make.wordpress.org/core/2013/08/06/a-new-frontier-for-core-development/) , we won't need to push any buttons. We'll be able to use grunt tasks that can watch andauto run our preprocessor. Both SASS (standalone and with Compass) and LESS have grunt tasks ready for us to use.

[helen]

And now you know why I said that now would be a really good time. :)

[rmccue]

Replying to jorbin:

With the new setup that @koop just announed on the make blog (​http://make.wordpress.org/core/2013/08/06/a-new-frontier-for-core-development/) , we won't need to push any buttons. We'll be able to use grunt tasks that can watch andauto run our preprocessor. Both SASS (standalone and with Compass) and LESS have grunt tasks ready for us to use.

Yep, it fits in perfectly with this ticket. (I actually noticed that ​on GitHub a few days ago, hence the updates here. ;) )

Based on discussions with nacin, the Apache license of LESS may be a bit prohibitive here, whereas both Sass and Compass are MIT licensed. I personally don't think it matters, since this is tooling rather than part of the source, but it may matter in that it's generating code distributed with WP. I suspect a similar argument to ​using GCC applies, but don't quote me on that.

[bpetty]

@wonderboymusic - The Grunt system announced can use ​node-sass through ​grunt-sass to compile SCSS, which is the new javascript binding to the new libsass library I mentioned earlier, although it is much more mature and usable than the PHP bindings. The reason I mention what language the library is written in is because the difference between the libsass C library, and the Ruby library means the difference between WordPress developers being required to install a full Ruby stack to work on WordPress, or just libsass + whatever preferred binding needed (node-sass, or eventually a even a PHP extension). The former is significantly more difficult across various platforms, and raises the bar for new developers interested in contributing.

Grunt didn't even have the ability to compile SCSS without requiring you to install Ruby until that work was done on libsass. It's not hard to find other projects ​making the switch to grunt-sass instead of grunt-contrib-sass (Ruby).

So yes, I did consider this a factor worth considering in this decision.

[ocean90]

Have ​found ​Autoprefixer yesterday.
What about a CSS file without ANY prefixes and let the prefixes, if neccessary (uses the Can I Use database), be added by Autoprefixer? There is also a ​module for grunt.

[rmccue]

(Heads up: bronsonquick is taking a look at converting MP6 to SCSS properly as a proof of concept here.)

[sennza]

Yeah I've been working on Sassing MP6. It's taking longer than I thought due to post-WCSF jetlag and the crazy amount of email I have to catch up on. #damnclients

I was hoping to have 4 variations of colours done tonight based on the awesomeness that is MP6 but I think that'll be more achievable by tomorrow arvo. I'm planning on doing a classic WP colour scheme, standard MP6 colour scheme, bbPress colour scheme and a custom colour scheme for proof of concept. All of which will be based on tri-colour base palette so anyone should be able to enter 3 variable colours and everything should just flow through.

I'm not happy with the structure and Sass nesting I've been doing based on MP6 but I'm gonna have to get over that and just do a proof of concept to get some feedback.

I'll be honest and will admit that I haven't actually applied any of the other LESS and Sass patches in this ticket so I could be wasting my time. I'm working on the 'plugin' angle though :)

[helen]

Replying to ocean90:

What about a CSS file without ANY prefixes and let the prefixes, if neccessary (uses the Can I Use database), be added by Autoprefixer?

That actually occurred to me yesterday. I think that could be really nice. I guess it might make sense to undo the big CSS merge in a way, although still have the separate files all compiled/minified into one file like it is now so we don't have the duplication problem.

---

Beyond making the files LESS/SCSS, what does the patching process look like for somebody? Like from figuring out where the problem CSS is to fixing it to making a patch and submitting it.

[rmccue]

Replying to helen:

Beyond making the files LESS/SCSS, what does the patching process look like for somebody? Like from figuring out where the problem CSS is to fixing it to making a patch and submitting it.

We can generate source maps with Sass that will ​give a reasonably good output (and I think Less has similar). (​This post may be more accurate on the maps themselves) For production, we may want to minify the stylesheets, but otherwise, we can also output ​comments into the CSS that point back to the source.

To contribute a patch, they track down the source in SCSS/Less and fix the issue there, while running grunt watch or similar, which will automatically rebuild their CSS on the fly. Once it's fixed, patch as normal.

[helen]

Replying to rmccue:

I've seen some stuff about source maps; sounds new-ish but pretty cool. :)

To contribute a patch, they track down the source in SCSS/Less and fix the issue there, while running grunt watch or similar, which will automatically rebuild their CSS on the fly. Once it's fixed, patch as normal.

I imagine that for develop we'd have compiled but uncompressed CSS files; not sure whether it would be compiled into one or not, but that's probably not important. Patch would need to be without the CSS files, yeah? I guess that's a slight extra step, to not include that in your diff. Not a big deal, just want to know all the details. Thanks for that.

[aaroncampbell]

Replying to rmccue:

To contribute a patch, they track down the source in SCSS/Less and fix the issue there, while running grunt watch or similar, which will automatically rebuild their CSS on the fly. Once it's fixed, patch as normal.

This is the part that worries me a little. Currently the process is something like this (assuming you're using uncompressed CSS):

1. See a problem
2. Right-click, inspect element
3. See that it's on line XXX of some.css
4. Edit line XXX of some.css
5. Test
6. Create patch and upload to ticket

It seems like we'd be turning it into:

1. See a problem
2. Right-click, inspect element
3. See that it's on line XXX of some.css
4. Track down what scss file creates that line (correct me if I'm wrong, but most built-in dev tools don't support tracking back to scss yet, right?)
5. Edit line XXX of some.css
6. Re-build some.css based on it's scss files
7. Test
8. Create patch and upload to ticket

I'm afraid that steps 4 & 6 (the newly added steps in the process) are going to be the hardest ones. Currently someone can learn almost everything they need to know to contribute a CSS patch just by tweaking on their personal site for a while (the one exception being generating a patch). The new method would involve more tools that they can't learn in that way, causing a steeper learning curve.

I'm not saying this isn't doable, but there's going to be more training needed and I think we need to seriously consider how this will affect our volunteer contributors.

[wonderboymusic]

You are correct, but I would rather have modular / professional code. I say we still build un-min'd versions, someone can patch that, and the committer can do the LESSASCSS part for the noob. Or, people can rise to our level of expectations

[taupecat]

There are tools that ease Sass debugging. [FireSass](​https://addons.mozilla.org/en-US/firefox/addon/firesass-for-firebug/), in particular, will identify the precise file and line of Sass where a declaration is made, provided one has the proper debugging turned on (requires line comments and Sass debug_info to be true). One could turn on the requisite debugging info, make the changes, then revert back to compressed and no debugging to generate the *.min.css file. This would all happen on the developer's personal development environment.

If we're going to go the Sass (or LESS) route, which I am all for (since I'm CSS preprocessor woman lately), we should put this kind of process information in the core developer's handbook.

[WraithKenny]

I'd like to cast my vote for LESS!

From ​http://lesscss.org/#usage LESS has the same line-number commenting as SCSS.

Firebug has a FireLESS plugin much like FireSASS.

Firefox has sourcemaps enabled already (Initial support landed in Firefox 23), and Less.js 1.5.0 will generate the maps. At that point you won't need the plugin or the line-number comments.

It'd be fairly easy to make a plugin that reads the directory of less files and lets contributors edit, compile, save, and refresh the css live from the Admin screen itself.

[WraithKenny]

A Plugin to contribute to WP's LESS.

[WraithKenny]

After activating the development plugin, there will be a button on the right side of the Toolbar.

To change the configuration of the plugin, see wp-admin-less.json (which is
based loosely on grunt watch files). Valid values for the package's base are admin_url, plugins_url, and themes_url.

This plugin keeps track of dependent LESS files, so if you save a file imported into a main file, this plugin loads the main file and compiles it with the new changes.

To edit WP's admin LESS, you will need to have applied the LESS patch from this ticket.

This plugin comes configured to edit the LESS branch of MP6 if you have that installed.

If you don't have either of the above, you can edit "This Plugin's CSS."

[helen]

Thanks to everybody who's commented so thoughtfully here thus far - might finally be getting toward an actual decision time :) ​http://make.wordpress.org/core/2013/11/05/22862-consider-a-css-preprocessor/

[jorbin]

The above patch is a prototype for splitting up into individual files and building to a single file based on Helen's suggestion in ​http://make.wordpress.org/core/2013/11/05/22862-consider-a-css-preprocessor/#comment-11209

[helen]

Per my comment on Make/Core:

• Sass (SCSS) for color schemes. Consider this a first run at using a preprocessor. Yes, it requires Ruby right now. Yes, you may have to update Sass on your machine because sourcemaps. Yes, Grunt. Yes, I know LESS can do it, too.
• Concat + Autoprefixer (+ min, as it already does) for the rest. We can re-evaluate the helpfulness of a preprocessor on a per-file basis later, once we see how the contribution process plays out. Impossible to even think about given the selectors and the sheer size of wp-admin.css in its current state, anyway. We need to split it up first.

First part landing shortly.

[helen]

In 26137:

Merge the color schemes component from MP6. Introduces Light, Blue, and Midnight.

Color scheme selection on your own profile page gives you a preview and autosaves the selection.

Also introduces the usage of a preprocessor for core files, namely Sass. For 3.8, we will not expand its implementation past the color schemes. This does require Ruby as well as Sass 3.3.0+ due to the usage of the sourcemap option.

Note that only the default color scheme is available when running out of src. Use build to test the rest as well as the color picker.

props ryelle, melchoyce, tillkruess, drw158, littlethingsstudio, helen. see #25858, #22862.

[nacin]

In 26143:

Temporarily remove CSS preprocessing until we can get our Ruby dependency sorted out.

see #25858, #22862.

[nacin]

In 26145:

Move to grunt-sass, which which has less bells and whistles than grunt-contrib-sass but also no Ruby dependency.

see #25858, #22862, [26143].

[samuelsidler]

Pretty sure this is committed and in. Any reason not to close this ticket?

[helen]

Nah, let's address autoprefixing and concat separately and in between cycles / the very start of a new one - too much churn to do it right now without killing everybody's patches.

[nacin]

In 26773:

Add four more color schemes to round out our collection at eight.

The new schemes are Ectoplasm, Coffee, Ocean, Sunrise. For those following along, the first three were at one point named Ghostbusters, Pixel, and Cape Cod.

See [26137] for the original color schemes.

props ryelle, melchoyce, drw158, littlethingsstudio.
fixes #26468. see #25858, #22862.

[nacin]

In 26793:

Nonces are already per-user. see #22862.

[nacin]

[26793] was noticed because $user_id wasn't defined on about.php. The proper global is $user_ID, but get_current_user_id() should *always* be used regardless. Including the user ID in the nonce like this was my fault, I must have been sleep-walk-committing.

[nacin]

#29797 was marked as a duplicate.