Add a CSS preprocessor library to core

Are there any plans to support less as well?

Personally, I think this would be fantastic. It would be a real boost for the front end Drupal community. The only thing that concerns me overall is that it adds yet another layer of complexity for newbies. However, I'm sure whatever setup we ended up going with would mitigate that as much as possible, so looking forward to the details and discussion here.

It's also worth noting that there are proposals to include similar functionality in CSS, so it would be great to deal with this proactively in Drupal. Here's a blog post by Tab Atkins Jr. about some of this: CSSOM, Vars, Mixins, Nesting, and Modules. If anyone is interested, the www-style mailing list discussions are available here:

• CSS Variables
• CSS Mixins Proposal
• CSS Hierarchies / Selector Nesting Proposal

None. The Sass source files would be compiled into CSS and Drupal's standard .info syntax and drupal_add_css() would use the compiled CSS as per normal.

It's worth mentioning that there is a new module called Sassy that may helpful/be relevant to this discussion. It's fairly new, and I haven't tried it yet, but @fuhby explained what it does, and might be useful.

Are there any plans to support less as well?

Sass is a clear winner here (see the www-style discussions above). See also http://compass-style.org. Trying to support more than one preprocessor here would be a waste of time and resources that we don't have. The discussions above also mentions that Sass is going to follow whatever spec is decided, and that alone makes it a better choice for us IMO.

Add SASS to Drupal core and convert all the stylesheets to take advantage of it? As attiks mentions, there's also:

• LESS
• xCSS
• CSS Dry
• SASSy

If we add #474684: Allow themes to declare dependencies on modules, we could have contrib themes depend on contrib modules. That way your theme could state that it needs SASS to be installed in order to run correctly...

I think this will be great, but it might be tough to get the community to rally around one tool. I personally support the use of SASS, but we should certainly consider LESS and SCSS (SASSy).

My concern is that installing Ruby (or the RVM), Rubygems, and the SASS (or Less) gem will add yet another layer of complication to developing a Drupal site. This is a particularly acute issue for Windows users, since Ruby support on Windows is essentially moot.

Someone that I think as my teacher from #css, said he would prefer stylus over sass over less. Um, not really trying to say anything, just trying to add some perspective to the issue.

Another css preprocessor is stylus, no contributed module on drupal yet it seems.

With stylus you need a css compiler written in javascript (and some node.js modules).

Regarding supporting more than one preprocessor, who is going to support/maintain that? Are core developers going to be expected to provide and maintain 2+ versions of all CSS code? That would be like providing 2 implementations of code for JavaScript libraries side-by-side in core just because someone might want to use MooTools or Prototype, or providing Smarty templates alongside all our PHPTemplates. Uh, hell no... Can anyone say bloat? Obviously it would need to be easily swappable, but that's what contrib is for IMO.

My concern is that installing Ruby (or the RVM), Rubygems, and the SASS (or Less) gem will add yet another layer of complication to developing a Drupal site. This is a particularly acute issue for Windows users, since Ruby support on Windows is essentially moot.

Same here. Hoping there is a way around this.

LESS, xCSS and CSS Dry have a small dependency tree (just PHP). I'm against depending on Node.js or Ruby in Drupal core (although, I am a Node.js fan).

@Rob Loach - I completely agree. http://code.google.com/p/phamlp/ is a step in the right direction, but a system that has a PHP compiler is certainly ideal.

The next question is whether we want to write an pluggable abstraction layer, therefore allowing use of different CSS systems via contrib modules. My initial response is that while it might be an interesting concept, it would take a lot of work to maintain, most of which would be superfluous.

@skottler: The next question is whether we want to write an pluggable abstraction layer, therefore allowing use of different CSS systems via contrib modules. My initial response is that while it might be an interesting concept, it would take a lot of work to maintain, most of which would be superfluous.

hook_css_alter()? That's how xCSS does it. It just acts on all .xcss files and converts them to .css files. Means you could have multiple CSS preprocessors as you want and they wouldn't conflict.

Hi, I co-wrote Sassy with Fubhy (for Livelink New Media / pk.vaish).

I'll try summarise the issues we came across with the SASS module that caused us to start from scratch:

The SASS module does nothing aside from "Pass any incoming .scss/.sass files through the PhamlP parser". This works great until you need to separate your variables (logic) from the rest of your styling, or if you are working on a subtheme which has a base theme that aims to provide a large library of mixins (or default variables).

When you want to include a file (eg variables.scss) you normally do "@include('variables.scss');" and this path is resolved relative to the path of the file including it (not sure if SASS does even this?). However, the source of the variables.scss file is relative to the file including it, so if you have the base them providing a set of grid styles and you want to alter the size of the grid you need to copy over both the variables.scss file *and* the grid.scss file to make it customisable. This leads eventually to your base theme providing no stylesheets at all, so if you want to fix a bug in the base theme styling then you have to propagate that fix manually throughout all subthemes. This isn't a problem if you are designing a single theme, but if you are a regular themer then having that standard base theme (such as Omega) and making it configurable from the subtheme is a huge boon.

With regards to variables and mixins, it really is handy to have them available to every file without effort, and so we added an "include" section to the .info stylesheets array - adding a .scss/.sass file to the include array means it is added to the head of every .scss/.sass file that is compiled, so mixins and variables are available without having to manually include them. They work the same way as any other stylesheet in that they are taken out of the subtheme if the file exists, or else from further down the theme trail.

Through the course of making the module we added a few drupal_alter calls which allows us to modify the SCSS before and after it is compiled. With that we have added the "Sassy substitutions" module (and another one which isn't named/finished yet) which allows modules or themes to specify tokens or patterns to replace in the SCSS. A few examples:

• background: url(@token(site-logo-path, 'nologo.jpg'));
• li { width: @token(menu-count, 1, 'main-menu'); (1 is default, main-menu is name of menu to count)
• /background: ([^:;g\(]+)gradient\([^\)]+);/ - can be used to capture CSS gradients and replace them with an gradient generator script (which returns an image)

So what does that mean? Simply, you can pass stuff from inside Drupal to your CSS files with almost no effort, in a standardised format, so if you want your #site-title to just show your logo (lovely for SEO) you can do that just by placing the token in the right place, along with tokens for the width/height of the logo. If you want to change your logo just upload a new one and clear your cache.

We'll be releasing an RC version, docs and maybe a screencast on it next week.

I definitely feel that the way we are handling base/subthemes and variables/mixins is a good start on how to handle these things in a core integration.

Hope that helps!

Hi all,

First of all, just want to say I totally agree with the whole concept and practice of CSS preprocessors. Editing plain old CSS, it's just so 1999. That said, I don't agree it's right for drupal core. Some reasons are already mentioned above and I just wanted to pose some (maybe contrived) scenarios -

A) Ok, great suppose Drupal 8 core's Garland 8.x theme includes both CSS and SASS files - and developers X, Y, Z like developing respectively in LESS, SASS, and plain CSS. Z, who is a newbie, spots an improvement for Garland 8.x and submits her first patch to the CSS (yay!). Now it's in the issue queue ... who is going to make sure sass and css files are in sync? now X doesn't have the time, Y has the overhead of setting up his environment, and Z doesn't have the know-how. but it's a different story if everyone's on the same lowest common denominator: plain old CSS can simply move more smoothly through the community.

B) suppose some SASS code introduces a bug present in some, but not all, version of Ruby - who's going to find that out? and when? who's going to maintain that? and when? who benefits? fancy pants developer with all bleeding-edge dev/stage/prod environments? or end user who is trying to get her community website out of a $2/month shared hosting service (which of course has some old unmaintained ruby version)?

I say make Drupal core as CSS preprocessors friendly as possible, but keep the actual preprocessing in contrib-land. And definitely keep any Ruby totally out of core...

For SASS/SCSS at least the PhamlP compiler runs without any issue (pure PHP I believe) on most servers (I can't say all because I haven't tested a Windows server) so the second issue is hopefully not an issue. However PhamlP has a few issues, the biggest oen is that it doesn't handle @extend very well.

With regards to A, if Drupal were to support LESS and SASS/SCSS then keeping them in sync might be a problem. However, as they both implement the same features (mixins, variables, nesting, loop structures) I'm going to say that firstly it's not too difficult to translate between the two (and if this is a requirement for contrib then it's not a huge one) and that they're so similar that a transpiler can be created for converting between the two (with the compiled result being used for verification). I'll see what I can come up with for that as proof.

I agree with you though - making it more difficult to contrib and adding a Ruby requirement to a server are both *bad things*.

Still dont think we should have both SASS and CSS files. Why duplicate the effort in supporting both? We could make http://drupal.org/project/garland use one of the modules as a dependency. Might be a good use case and argument for moving it into core. The benefits of a CSS preprocessot are clear, but is it a valid case for Drupal core? Maybe Drupal 8's Garland is the place to prove that.

We are not adding Ruby or Node.js to core, but a CSS preprocessor that doesnt have a large depency chain is a possibility.

The right approach for whatever parser we might be using is #pre_render via hook_element_info_alter.

I think we need to be clear about what we plan on doing.

I would love to be able to use sass (and compass) when we are building the next core theme or the next version of seven. This sort of support for sass would be great. I would be worried about raising the barrier to entry like some have said above (though if you are going to work on core css issues you are probably in a position where sass is not going to put you off overly much).

I would be very hesitant, however, to add some sort of native processor for sass. Trying to shoe-horn sass processing into some php implementation is just asking for trouble. If you are not severing ruby on the server I think you are always better off simply doing to processing locally (a good read in relation to this is - http://compass-style.org/blog/2011/05/09/compass-django/). It would undoubtably be cool but I think it is a lot more trouble then its worth.

So I would +1 making it acceptable/preferable to use sass (preferable scss syntax) when working with core and contributed projects. Anything else not so sure about.

All the above being said if we were to try and do it we should be thinking about something like https://github.com/kriswallsmith/assetic which does look really cool rather than rolling our own.

I try to avoid CSS in favor of Sass in my work, and I'm 100% in favor of using Sass to author all stylesheets in Drupal. I'm starting to drool at the prospect of simply changing a variable to change system.css. @JohnAlbin's original suggestion is certainly the simplest one put forth, but I worry about confusion about whether the css or sass file is the canonical file. At Zivtech we've established that the sass is always canonical and the css disposable, but that's probably trickier to argue across the drupal codebase and community.

So if we include Sass (and it should be sass, not another preprocessor) in D8 it needs to be established that all contributed CSS should be authored and in Sass (scss) and be accompanied by the compiled CSS.* Anyone who's simply using drupal can do so as they see fit. They should be able to ignore the Sass or use it.

That suggests that anyone contributing css to drupal will need to become familiar with sass. I would argue that css is heading this way anyway. At work I got everyone to adopt Sass with only some minor groaning, and most of that was because we prefer the strange and scary sass syntax. We've had some issues keeping our dependencies up to date, but that's mostly due to some bleeding edge grid frameworks that wouldn't be an issue here.

And as for compilers, I don't know. I'm extremely skeptical of phamlp, or any other sass compiler that's not supported by the Sass project. The Sass team would probably be open to a port, but it would need to support all of Sass's features and be released on the same schedule as the main Sass project I'd think.

I'd also want to avoid locking Drupal in to a specific version of Sass, since it moves so much faster than we do.

(can we have Compass, too?)

* I also think that all compiled CSS should come with a comment at the top of the file explaining that it's generated from a preprocessor, and a link to view the source sass file. It concerns me that we're losing a bit of the 'view source' culture by compiling css.

Note that this issue summary could use a whole lot more detail for people who don't know wtf SASS is and why it's useful, like, for example, certain core maintainers like me who eat PHP for breakfast. :D

It'd also be useful to have a breakdown there of all of the various competing thingies and why we should pick one vs. another so we don't end up re-hashing that conversation 80 times through the lifetime of this issue. :)

well if were talking SASS im pretty sure you can get compass to
...actually it would be pretty sad not to use compass - not to say dumb ;)

IMHO there can be no doubt about using SASS in comparison to other css preprocessors, it got the largest amount of contributers & a big user base - which makes it so much easier to get into the whole sassy thing

So no reason to bikeshed around and trying to make it more complicated than it is (and yes i know that less is much easier the first 6 times)
Lets be honest here we are requiring people to understand GIT to right and if you dont wanna play with the sass files - theres always the original css files to look at, which we still should keep, even that its double work.

adding sass to our workflow would really benefit the frontend developers, no reason to make it harder for ourself right ?

here are some cheap google results, for easy reference:
less: http://lesscss.org/
sass: http://sass-lang.com/

the sass vs less debate:
http://drupal.org/node/758798
https://gist.github.com/674726
http://wrangl.com/sass-v-less

compass:
http://compass-style.org/

Um, nobody tries to compare with stylus?

I can't find any, so I'll just throw these:

• syntax comparison.
• error reporting comparison.
• stylus issue queue.

Notes:

• they are pretty much documents from the stylus side. XD
• I learn to use stylus in one day.

and i learned sass i in 15 minuts - seriously should we bikeshed the crap outta this issue?
This issie is about figuring out if we could use sass for drupal -> "Add Sass versions of all CSS files" so could we stick to the subject, how sass & compass could make life easier or frontend ppl - and what the problems could be.

[rant]
If somebody has an oppinion about why less, stylus, nodejs whatever would & could be better for drupal & consider the fallbacks of not going with the biggest and most widespread preprocessor there is (documentation, further development etc) and then please show show some code examples / implementations in drupal with the pro cons of this or that preprocessor system, right now this whole issue is turning into bikeshedding, and that wont bring us any further than namedropping every css preprocessor there is in the universe.
[/rant]

/king

This would be an epic win for all the front-end people.

In my experience, I don't compile on the server but locally, so I put my less/sass file + css file in version control,
and in production I just use the plain css.
For me this seems like the most logical solution. That way you do not need to add a dependency for a compiler to core.

whichever preprocessor we would choose, if we choose one, we still need to consider how to deal with it
for instance, do we only keep source files in the repository and have the package script compile it?
that way, we don't really create a dependency for users who hit just the download link and only people who check it out from the repository have to compile themselves...
I guess it does however make it harder to submit patches for core and puts more strain on the package script

Note that Sass is written in Ruby, so you’ll need Ruby installed as well.
http://sass-lang.com/download.html

Does including scss files in drupal core mean front-end/design folk need to start managing ruby & ruby gems to contribute?

Do any contrib themes already include scss files? If so, maybe their theme maintainers can shed some light on the advantages/disadvantages of managing source & compiled files within the drupal community?

Also, does it make sense to divide this issue into two?

1. Add preprocessed versions of all CSS files
2. Determine what preprocessor to use for drupal core

I guess it does however make it harder to submit patches for core and puts more strain on the package script

Yes... One way to deal with this is to have a Sass triage team. When CSS patches are posted (and being considered for inclusion), people on this task force could re-roll with Sass versions. People would have to step up and make a commitment to take this on for a few years. I would definitely be on that team.

@jacine if it came to that, a Sass team, I'd be all over it. One benefit to that approach would be that there would be a small team who knew Sass well who could find efficiencies and create refactoring patches. Probably a variable and mixin system as well. It would give us a chance to framework-ize our css and make it really svelt.

@technicalknockout We *could* create an issue for determining which preprocessor, but that way lies bikeshedding dragons. Splitting this issue like that would mean that we'd need to resolve an endless debate before moving much further with this one.

Would just building a SASS compiler into Drupal aleviate the (legitimate) concern about a Ruby dependency: http://code.google.com/p/phamlp/

I've not looked at it beyond checking the license (BSD, so we're good there), but we do plenty of CSS processing as is. :-) Would bringing SASS in-house be at all useful?

Does someone want to try writing a Drupal bridge package for it? It looks like Cake and Yii already exist.

There may well be other packages that do PHP SASS; this is just the first one I found googling. But I'd be more comfortable with adopting SASS if we were using a PHP SASS parser than a Ruby parser, for the reduced dependency count.

As for the compilers issue, there are a number of GUI compilers emerging that don't require people to manage Ruby or Gems. I prefer the command line, but I've auditioned each of these before and they seem to work well. I use Livereload every day. Sass/Compass compilation is a secondary function on that one.

http://compass.handlino.com/
http://mhs.github.com/scout-app/
http://livereload.com/

@canaryMason Yep, exactly. I think we would definitely need a team, as many core developers probably have no idea what Sass is. Even if we get them familiar with it, it will never be their domain (they like PHP), and since all issues end with core committers, we would absolutely need to prevent bottlenecks there. I think most front end developers that actually are involved with core development know Sass or at least one of the other preprocessors, so if people are willing to put their money where their mouth is, this could actually happen.

There are a lot of challenges here, but if we all work together to outline them and try to solve them, this could be a possibility. I mean really, we moved to Git... We can do this. And seriously, it's better to get a jump on this now instead of dealing with it reactively when it hits the specs. This is where CSS is going.

There may well be other packages that do PHP SASS; this is just the first one I found googling. But I'd be more comfortable with adopting SASS if we were using a PHP SASS parser than a Ruby parser, for the reduced dependency count.

This is a valid point that has come up a few times already. I think most core developers will feel the same way. I don't know anything about this parser, and would like to hear more about it and the pros and cons of using Ruby vs. PHP with Drupal, other than the obvious Ruby dependency.

@crell I asked Chris Eppstein about alternate compilers yesterday and this was his response:

It's hard to say how good they are. There's not a language spec nor are there implementation agnostic tests

I'm certainly open to it, and there are some real benefits to having an in-house compiler. However it would need to be in sync with the Ruby version. I've heard that the phamlp version isn't quite up to speed. Have you looked at the Cake or Yii versions yet? I'm curious as to whether they're using phamlp or rolling their own. I couldn't tell in the minute I spent skimming the Cake version. Is this the one you found?

https://github.com/m3nt0r/chaml---cakephp-haml-sass-integration

It should be noted that fubhy already has a project (http://drupal.org/project/sassy) thats adds a sass preprocess to the css.

are there security implications to having sass installed on your server? would it be possible to execute a sass file remotely if it's hanging out within a theme's directory? can parameters be passed to a sass file?

@technicalknockout you can always block access to scss files using .htaccess

@Crell: My main concern with these "ports" is already expressed by Chris, via canaryMason

I'm unsure as to how accurate these are, and how up-to-date they are with SASS. If there are discrepancies, it would become rather annoying to copy/paste complex mixins/functions from other projects... there are vast collections out there of very, very useful mixins (From V3.2 PHamlP includes a port of Compass)

I know dependencies are always annoying, but I don't think rolling our own system is the way, pretty sure we have enough of a code base to maintain

I'm gonna try and exclusively use PHamlP for like a week to see if I run into any snags... if that goes well, I guess my concerns were unsound

Speaking as a core developer that likes the idea behind SASS but has never actually used it (which I think is probably true for most core PHP devs), I am not comfortable with adding a dependency on a separate Ruby app to be able to write core-friendly CSS. However, building a SASS or SASS-ish precompile step into our CSS support, so that if you add a .scss file to a page it gets mutated into CSS on the fly with caching like the compressor does, that I could get behind.

I do not know SASS well enough to say what "SASS or SASS-ish" would mean in practice. :-) *goes back to his developer cave*

@Crell: That is exactly what SASSy (http://drupal.org/project/sassy) currently does. It uses PHamlP to achieve that but all the wrapping preprocessing functionality for the CSS works with the same basic logic as the core CSS preprocessing (aggregating and such). The weak spot here really is the PHamlP library as it does not cover 100% of the ruby version of SASS and might have 1 or 2 more bugs than the ruby version. It does ship with a Compass clone though...

@fubhy Since you probably have the most experience with phamlp here, do you think it can be brought in-line with all the Sass and Compass functionality? Or are there Ruby features that PHP lacks?

I see above that one weakness is that it doesn't do @extend well. I also know there are some interesting new features planned for Sass that I think we'd need to stay on top of.

@canaryMason PHamlP definitely lacks behind the Ruby version. Currently, in my mind, the features we are missing aren't critical and the PHamlP works fine in most situations... Sure, there are bugs and pitfalls (some of which exclusively exist for the PHamlP version obviously), but its not dramatic and can be fixed. We will never be able to keep up on speed with the development of the Ruby version as they are still and constantly working on it. But then again, we got jQuery in core which also isn't the latest version ... And it could surely be made so that the parser library is replaceable from within contrib (which might be able to keep up with the development of the rubhy version easier). Compass is even worse in this regard as it moves at an even faster pace. At some point (if we want it in core) we would just have to pick the version of our choice and use that, period. We got jQuery updater modules in contrib, so we might even have contrib modules for keeping those libraries up-to-date. I am all pro-PHP parser as it really gives us some great advantages plus doesn't add more dependencies. There is nothing in the Ruby parser that can't be done in PHP... PHamlP is just not perfect (yet).

PHamlP seems to screw up royally on underscore-prefixed filenames and the order of import statements :/

With regards to keeping a PHP port of SASS up to speed, I think an extensible method of maintainance would be great.

For each type of file (based on file extension, SASS, SCSS, LESS, etc) a hook_css_preprocessors (or hook_TYPE_preprocessor, or whatever) could be available to allow contrib modules to override the in-core transpiler. That way core can include PhamlP to cover most code and a contrib/optional module can use the Ruby version.

Pushing the actual compilation out to a hook/module would also allow Sassy to form the base for all preprocessors with regards to it's pre/post hooks, caching, and theme-trail handling.

Note that LESS now runs with Javascript locally, or server-side with Nodejs (just like Stylus actually) or even PHP (lessphp is a PHP compiler with a GPL license, but there may be others)
I wonder if using a javascript compiler at the dev stage can make things easier/faster for themers, as apposed to a Ruby one, or the LESS.app?

But aren't we thinking too far? If I understand correctly, JohnAlbin's proposition is to simply ship .scss files along with regular "compiled" CSS, not to add compiling features in Drupal core.
Some contrib themes already do exactly that (http://drupal.org/project/basic comes to my mind).
SASS lovers already have what's needed to compile it locally anyway, and those who don't would simply use the CSS files.

Seems like we'd do well to postpone this until the issues at http://drupal.org/node/1089868 are done. No sense building these against a moving target.

We still lack a coherent issue summary for non-designers (aka core committers) on why this is important and what benefits it would have.

First things first - a nice introductory resource on this topic is Claudina Sarahe's talk at this year's Boston Drupal conference titled 'Bringing sexy back to CSS: SASS/SCSS, LESS and Compass' -
Slides: http://www.slideshare.net/itsmisscs/2011-d4dboston
Video: http://techtv.mit.edu/videos/13399-bringing-sexy-back-to-css-sassscss-le...
For a tabular feature/syntax comparison of LESS/SCSS check out https://gist.github.com/674726
...
After skipping through this thread (and just before engaging my first SCSS based theme :), to me the consensus seems to be that having a state-of-the-art CSS preprocessor in D8 core

• would make theme code more flexible, coherent and maintainable at the same time
• thus making (core & contrib) theme development easier, more rapid and more fun

Fundamental requirements for such a preprocessor? It must be

• an actively maintained FOSS solution
• cross-platform, i.e. native PHP without obscure dependencies
• in sync/ adhering to upstream specification/reference implementation
• compatible to code 'out there' in the wild

From my research into this, there are some subtle syntax style peculiarities - and more relevant functianal differences between S[A,C]SS, LESS and xCSS. These include

• availability of math and color functions (=> xCSS lo0ses)
• flexibility in expressions (color notations, size formats)
• external references, scope of variables
• support for on-the-fly generation of inline images (DATA URIs) and sprites
• caching/incremental compiling
• ...

Weighing by features and usability, SCSS seems to be the leader of the pack - if not for its ruby nature conflicting with our PHPness... But there are several parser implementations in different languages:

• Ruby: https://github.com/nex3/sass - the master™ implementation ;-)
• Python: https://github.com/klen/python-scss - "has most of the funcitonality in Sass SCSS 3.2 and more."
• Python: https://github.com/Kronuz/pyScss - "fully compatible with SCSS (Sass) 3.2"
• JavaScript: https://github.com/bmavity/scss-js - incomplete implementation, last commit 2010
• JavaScript/Mootools: https://github.com/khrome/Midas.js/blob/master/Source/Midas.SCSSParser.js - #m0oO ^^
• PHP: http://code.google.com/p/phamlp/ - "Sass V3.x compliant" but has many open bugs, no commit since 2010
• PHP/ExpressionEngine: https://github.com/AboutWout/sassee.ee2_addon/tree/master/system/express... - internally uses vanilla PHamlP
• PHP/Drupal7!: http://drupal.org/project/sassy - forked PHamlP with bug and style fixes - YAY! :)

So the one that would suit our needs best, PHamlP is far from being broken beyond repair. It seems to be a rather good start and just needs lots of care (which sassy maintainer fubhy seems committed to)..

....and a TEST SUITE! Upstream SASS has one, and it lives here - it's all ruby though. But khrome, the guy who did the midas implementation, also ported the test suite - from ruby to JS! So a drupal/PHP implementation should be possible, and would allow us to fix the PHamlP code until all tests pass with either compass or sassy module.

So i guess the next action on the road to SASS in core: port them tests to simpletest so we can narrow down any diversions in rendering! And then, theming bliss :D

Looks like some info got added to the summary here. Is that sufficient? :)

No, because the summary doesn't note any of the downsides or blockers to being able to do this, which are many. (Mostly relating to requiring a Ruby environment in order to write core theme patches being a non-starter.)

Personally, I don't agree with it. make it to be a contribute project would be more suitable.

- for beginner, they don't need it.
- for core developer, add another barrier to patch it.

#45 lists a lot of tools but do not official supported, it could be dead at some point of time.

@Crell: which of the 'many' downsides remain when we bring sassy's fork of PHamlP into a autotest-verifiable state of coherence to up-to-date native ruby SASS/SCSS reference implementation? Explain, please.

ad #49: The port of PHamlP that SASSy currently uses is not quite there yet (some [minor] features of the ruby parser don't work 100% yet. Also, we are most likely going to rewrite quite a lot of the code that it currently uses.) @richthegeek is currently working on Unit Tests for the Parser. Anyways... As long as we don't have a 100% working and feature-equivalent version of the ruby parser this issue should remain in a "postponed" state. We should keep on working on this in contrib and reopen this once the PHP version of the parser is fully functional as (as Crell explained before) a Ruby dependency is no option.

@#50: Granted, thx fubhy. Hope we manage to fix it up in time for D8 core C:

The summary doesn't mention to need to do that in the first place. It just says "yay, Sass!" It should mention that it would require writing/modifying/leveraging a PHP port of Sass, which since Sass is an implementation-defined not spec-defined language will by nature have inconsistencies. (To be fair, PHP is also such a language.)

I'm not against using Sass, I'm just saying the summary is not yet complete as it does not list challenges and trade-offs. :-)

Hmm, when did this become about core themes? Changing the title back.

Here are my (admittedly young to Core contrib) two cents:

1) I think that it's been pretty much agreed upon in this thread, but just to add another voice, if we go forward w/a preprocessor, it should absolutely be Sass+Compass. Additionally, I don't believe we should ship both Sass and CSS files unless the CSS files are only there for rendering and are the straight builds off of the Sass (in fact, using Compass, we can spit out great compressed CSS). Doing this

2) While not requiring themers to have the gem installed for Compass would be a plus, I'm worried about keeping an up-to-date PHP version of Compass in Core. As was mentioned, this can be alleviated by choosing a version and sticking to it, but considering how fast the gem moves, I'm afraid that without a way of turning off the Core rendering (maybe via the .info file?) that some of us who really go at Sass won't enjoy that.
Another thing to consider is that Compass isn't just the collection of useful mixins on top of Sass, it's an entire extensible, pluggable framework. This includes some things such as Susy, Sassy Buttons, Pictos Free, and a tonne more that will really require the Ruby to at least get them initially set up in your project. We could alleviate this somewhat by including some of the more popular extensions in partial form already in an include in Core, but it won't solve 100% of the issues.

3) I like the idea of a "Sass Triage Team" and would be glad to be a part of it. Once thing that has been mentioned is a concern that someone writes a core patch to CSS instead of Sass, now I understand I'm probably going to get push back on this, especially because I've yet to contribute anything to core, but we tell them to re-roll in Sass because CSS is not what is actually what is in charge. It would become equal to submitting a patch to the rendered HTML of a Core block instead of the PHP that is in charge of that rendering.
Sass Triage Team may also be in charge of porting existing and useful Compass extensions into Core.

4) Finally, to all of the wonderful Core devs who don't know Sass, I'm sure us Sassy folk would be happy to teach you all you'd ever want to know about Sass (I know I'm more than happy to) whenever, but especially at DrupalCon (BoF or some such). Claudina Sarahe and I just gave a 2 hour talk plus 1 hour BoF on the subject at DrupalCamp NYC and all of our knowledge can be yours. That presentation is called @include Sass and can be found there (Prezi).

I think that's all for now!

With regards to keeping a php parser for sass up to date, ive been working on getting phamlp (Sassy) up to spec lately. So far im pretty much there with the exclusion of bugs and a wholesale rethink of the import system. generally it needa about a day a month to bring the parser and compass up to spec, and currently only myself and fubhy have any familiarity with the internals of the parser so if one of us dissappeared there would be a real problem with getting bugs fixed or new featuess implemented.

Regardless of the effort available to keep it up to spec, we will *always* lag behind the ruby spec and compass. If being alwayd a month behind upstream and with our own set of bugs to contend with isnt an issue then core is an option... as it is i think sticking to a contrib module or two would best for the time being, as much as i would like to see my code in core :)

With regards to the compiler specifically, the main issue at the moment is a low number of testers exposing bugs althugh big thanks to jacine and e-anima for their recent efforts in that regard. im generally optimistic that the number of bugs must eventually approach zero in a static system so we will eventually approach a time when sass compilation is hassle free.

Bypassing all of this, of course, is just using the gem but under that system it can *never* be core. Not sure if ive aaos anything constructive here but thats just my ill-typed thoughts on the matter...

Hey richthegeek, I didn't realize Sassy etc… was only about a month behind the gem; it sounded like it was much farther behind than that. If that is indeed the case, then that alleviates my concern about it keeping up w/the gem, but not quite my concern about the Compass extensions (although there are plenty of ways around that, and that's not as much of a blocker as keeping up was).

I'd be happy to test to help test/work on the compiler and help out. Send me a message with what I can do to help.

@snugnog: It is totally ridiculous to believe that you and Claudina can teach every core developer SASS. I've worked on a number of projects utilizing SASS and while there is a learning curve, it's certainly not too bad. There are thousands of developers in the "long tail" who has never been to a Drupalcon or camp, just make significant and substantial contributions to both the core and contrib spaces, and this would discourage their contributions.

@richthegeek: I need to profile your module, but my feeling is that it adds significant time to the page load time.

┌┤samkottler [Dec 24 08:47:58] ~/Sites/d8 on 8.x ?
└╼ cloc .
921 text files.
896 unique files.
565 files ignored.

http://cloc.sourceforge.net v 1.53 T=1.0 s (353.0 files/s, 58057.0 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Javascript 85 2537 4226 12024
PHP 127 2037 15589 9975
CSS 107 494 880 7624
Bourne Shell 17 261 139 1662
XML 12 3 0 441
ASP.Net 1 9 0 82
HTML 3 4 0 69
SQL 1 0 0 1
-------------------------------------------------------------------------------
SUM: 353 5345 20834 31878
-------------------------------------------------------------------------------

Obviously, each CSS file does not got called on each page load, but a number of them do (enough to make IE puke pretty often). Processing and caching them is an incredibly inefficient operation and makes the presentation dependent upon the SASS being rendered in an appropriate timeframe. This would also set a precedent for contrib modules to utilize SASS (or possibly have to) and that's assasine.

I clearly oppose this at all levels, and hope it never gets into core. It's just another barrier to entry for new devs, complex feature to manage, and library to depend upon. I would like to see this issue closed, it's nothing but a bideshed at this point, and a pointless one at that.

maintain:
opening my browser and see an error, I open firebug immediately to figure out "ul.menu li a:hover" was wrong. and then I open my SASS/LESS file and searching it, oh oh no !! NO FOUND!! I have locate to UL and then MENU and then.....etc

Readability:

ul {
margin: 0 0 1.5em 1.5em;
&.menu { // #3 OK, .menu li a .......
margin: 0;
list-style: none;
@extend .clearfix;
li { // #2, OK, li a and then what ??
float: left;
padding: 10px;
border-right: 1px solid $menuBorder;
&.last {
border-right: 0;
}
a { // #1, start from here ..... OK. "a", what's the parent ??
color: $menuLink;
text-decoration: none;
&:hover,
&:focus,
&:active,
&.active {
color: $activeMenuLink;
}
}
} // is it missing a "}" or not ?
}

I am curious how it looks on a loooooonger style blocks.

I think the ONLY benefit is @variables, easier to keep consistency. But all D8 stuff against Stark theme (almost without color, font-size, font-family...etc)

Skottler: we cache the compiled CSS for production sites, and even with the full compass stack included it compiles in under one second on a middling nix desktop. With regards to teaching and advocacy, that is an issue but nit an insurmountable one. Considering how many people use views, display suite, omega etc then i think its clear that the primary driver of adoption is usefullness, not ease. On top of this, SASS is entirely opt-in as its a superset of css.

Droplet: we have FireSASS support in Sassy, for Firebug. I use chrome but apparently drupleg finds it quite useful for Firefox. Adding to tjat, the language nesting encourages a style whereby each id/class is only written once so search should be quite efficirnt. So gar i havent found it to be an issue but i am kinda biased...

There are a lot more benefits than variables although enumerating them here is not somrthing i care for typing on a mobile keyboard...

@skottler I never once suggested that Claudina and myself would single handedly tech the entire core dev team Sass, I suggested that myself, along with I assume others, would be happy to teach those who want to learn. In addition, the SCSS syntax of Sass is a superset of CSS and any straight CSS you can write, you can write it exactly the same in Sass. The teaching doesn't come from learning how to write SCSS, it comes from learning about the additional power that can be had when you use things that are not already part of CSS. In fact, I can get you writing SCSS right now without any learning. See that CSS file you have? Rename it from a .css file to a .scss file and you've got a Sass file.
As for requiring contrib modules to use Sass, considering that my previous statement is quite literally all a contrib maintainer would need to do to use Sass, I hardly think that's a big ask. The advantage of having Contrib use Sass, IMO, far outweighs fear that people aren't going want to put an s infront of css, plus it would open all Contrib modules up to being more themer friendly. Take, for instance, the Fivestar module. The CSS required to create a new fivestar plugin is fairly standard, and if Fivestar was using Sass, they could simply present a partial that other modules could include (or maybe won't even need to depending on how the final CSS file actually gets generated) and call a single mixin to generate all of the CSS needed. Or what about Nice Menus? What if Nice Menus provided partials and mixins for the various CSS pieces that go into generating the look of the dropdowns? Sure us themers can use the hacks and repeated code that we've been using, but wouldn't it be easier and more maintainable for everyone if we didn't? If, for instance, fivestar or nice menus changed the format of the CSS they used, us themers wouldn't need to go and search and fix each and every line of CSS we've written to update it; if the update was to a mixin, all of our work (the themer's) would stay the same where the output would just change to the new CSS.
I agree with you that performance is the biggest issue with generating the CSS server side, but it seems as if you're out and out dismissing Sass because of other reasons.

@droplet as richthegeek said, there is FireSASS for Firefox, but more importantly, it's about knowing your codebase. There are many parts to Sass besides just nesting and variables. Mixins, functions, and partials are three other hugely important aspects of Sass, and learning how to use them effectively makes finding what you're looking for easier. What I do is I divide everything that's more than one nest into its own named partial for ease of finding. So, in your example, if that menu was the main menu, I wouldn't need to go hunting and pecking through 1k+ lines because the search didn't work, I would know it comes from sass/partials/header/_main-menu.scss for instance. Everyone can do partials their own way, but just how we have coding standards for Drupal's PHP, because Sass makes CSS more code like, we can have coding standards for Sass that will make finding what comes of nested selectors easier. Also, in the example you have there, you've forgotten to indent everything! Of course it's going to be hard to read if you don't indent or comment your work! Sass even supports short comments (//) that DO NOT get rendered in the final CSS file, so you can leave yourself notes as you go along. This is what that block of Sass should look like:

ul {
  margin: 0 0 1.5em 1.5em;
  
  &.menu { // #3 OK, .menu li a .......
    margin: 0;
    list-style: none;
    @extend .clearfix;
    
    li { // #2, OK, li a and then what ??
      float: left;
      padding: 10px;
      border-right: 1px solid $menuBorder;

      &.last {
        border-right: 0;
      }
      
      a { // #1, start from here ..... OK. "a", what's the parent ??
        color: $menuLink;
        text-decoration: none;
        
        &:hover,
        &:focus,
        &:active,
        &.active {
          color: $activeMenuLink;
        }
    }
  } // is it missing a "}" or not ?
}

It's now easier to read. In addition, Sass spits errors if you mess up your Sass (say, forgetting that }) so you would see while you're developing that oh no! You've messed something up, and here's the line in the partial that you've done so. Basically what I'm saying is, debugging Sass isn't so hard and the tool itself helps quite a bit with it.

@richthegeek, @Snugug
Thanks. I installed FireSASS and just don't know how to use it. I'm quickly look at the help and go to https://github.com/nex3/firesass. "Usage" is no help to me.

How about other browsers ? Anyone able to update the Issue summary initiative.

@Snugug,

I wouldn't need to go hunting and pecking through 1k+ lines because the search didn't work, I would know it comes from sass/partials/header/_main-menu.scss for instance.

Okay, it's a way. Personally, I don't like split the stylesheets into bundle of files, needs to open many files during development, really bad. It's biased.

Of course it's going to be hard to read if you don't indent or comment your work!

I used a wrong TAG on my comment above, it's indented. My views is when it indented very well, still hard to understand it.
"ul.menu li a:hover" = Immediately understand it.

any editors supporting it ? would it provide helpful error message ?

what happening if we make thing like this:

     a {
        color: $menuLink;
        text-decoration: none
        
        :hover,
        &:focus,
        &:active,
        &.active {
          color: $activeMenuLink;
        }

how do you organize the @variables? on one file ?

and one more thing, what we should do if SASS-like tools produce redundant code or bug. (suppose there have bugs on SASS-like tools)

There missing a real example and working plan in "Issue summary initiative".
- more real benefit examples
- required tools
- supports IDE, browsers
- debugging way
- coding standards plan
(It's information help to make decision.)

** anyone interested add CoffeeScript version of JS files. :) **

@droplet there are a lot of best practices already established in the Sass community to answer some of your questions. In general, a base partial (_base.scss) is kept for organizing variables, mixins, and functions that you are going to use across the various different style sheets and partials. The other key is partials. While it may feel strange at first running with a whole bunch of Sass partials, the thing to keep in mind with them is they are meant to help organize you and they do not get compiled unless imported into a non partial (many times, importing all of your partials into your style.scss or global.scss file, which gets compiled to style.css and global.css). canaryMason has written the Coding Designer's Survival Kit which uses Sass as its method of theming, take a look at that for an idea as to how Sass files and partials get put together. The Sass Way is another good resource. It's a Sass blog that has some great pieces as to what you can do with sass, maybe that will help explain some of the additional benefits of Sass.
As for required tools, it would either need to be the Compass gem (which I think we've all agreed we're not going to use) or a compiler in Core (which richthegeek and fubhy have worked on) would be needed. I'm not sure about the work that Rich and Fubhy have done (haven't taken a look at it) but Compass throws very helpful errors in the command line if you mess up Sass syntax and will break your page w/the error message (which is a bit annoying, but tells you something is wrong and where it is wrong). TextMate (and anything that supports TextMate bundles) as well as PHPStorm (probably others, those are the two I know off hand) have syntax support for Sass, and all Sass files get mixed down into regular old CSS, so ALL browsers support Sass output. Compass (the main compiler for Sass, what we should be using) has support for debugging built in (if you mess up Sass syntax, not if you forget the magical & in front of your :hover) and, like I said before, if you're working off specific partials (like just main menu) these things become easier to spot. I can tell you that I just finished work on a site with ~4300 lines of compiled CSS that was done entirely using a very broken up partials system (like I had mentioned, one partial per nest practically) and I never once had an issue finding what I needed to find when debugging. Work with Sass long enough (and by long enough, I basically mean one full project) and you will start to see the world in Sass not CSS.
Finally, for coding standards, if this is something that we really want written out sooner rather than later, I'm sure some of us (*cough* Mason, Jacine, John, Fubhy, Rich *cough*) would be happy to write a working draft of best practices for partials, mixins, variables, etc…

@Snugug,
umm. to my understand now, Contributors need GEM to help debugging (+browsers extension) and it's the only choose. Other tools won't throws helpful errors messages.

@droplet I haven't used phamlp yet, I was just assuming that it threw the same errors that the Compass gem did, if not that is something that I think is needs to be put in to a native implementation for Drupal. That being said, you don't need a browser extension for the Compass errors; they get thrown in the command line/compiled CSS (unless the browser extension needed is built into Chrome/FF/Safari). To debug where the Sass that powers a given CSS string is, yes, you need a browser extension (to my knowledge, only FireSass exists, with no options for us Chrome devs) but, like I've said, in the large project I just worked on, it's not that hard to figure out where something lives in a given partial. Part of this, of course, is based around a design-in-the-browser development philosophy, but that's a discussion for another thread.

compiling with expanded output style and a development environment makes it spit out CSS like this:

/* line 41, ../scss/_ie.scss */
.lte-ie7 input.form-submit {
  ...
}

which doesn't require any extension or PhD to figure out

if we ship with compiled CSS, I don't see any reason why we should also ship with a compiler and why we can't use the full power of the gems. It's easier to install than Apache ffs...

curbing this because it isn't PHP is short-sighted and pretty stupid

opening my browser and see an error, I open firebug immediately to figure out "ul.menu li a:hover" was wrong.

Haven't really seen CSS throw many errors, but if some prop/value pair in that selector is wrong, chances are it'll be in _menus.scss, the same way you assume that menu related stuff lives in the menu module... it just makes a steaming heap of sense

If you really do think variables are the only benefit to be gained here, think of the amount of classes we can simply drop ("clearfix", "element-invisible", to name a few), of how much easier it is to create matching colors (using lighten/darken and whatnot), of how much needless repetition can be avoided (using automated vendor prefixes or extending), of how much easier it is to create fallbacks only when they're needed (if a user downloads the "IE7 supporting package", he'll get CSS compiled with $legacy-support-for-ie7 enabled), which would all make it a lot easier to create packages designed to fit a specific need

Added possible advantages and a simple example

@snugug and I just spoke about this at the New York meetup. I am going to truly postpone this issue until we have a library that is stable enough for consideration. I will be working on writing the PHP library outside of Drupal along with whoever wants to help out! Please ping me (samkottler) in IRC if you'd like to help.

@skottler I really hope that means you will be collaborating with @richthegeek and @fuhby as they have already put a ton of work into just that in Sassy.

I was in attendance at tonight's NYC meetup with @skottler and @snugug.

I've been writing CSS for 10 years (the majority of which obliged allegiance to IE6), so I'm no newb. I've done a lot of CSS, and am extremely familiar with techniques and cross-browser compatibility. Inasmuch, I don't usually opt to use SASS or LESS, but I have worked on projects where others have opted to use SASS or LESS.

Certainly I understand the beneficial aspects. But I have also had the problems mentioned by @droplet especially when working on a codebase that you didn't write (nested syntax is garbage, imho). There are also numerous implementation details mentioned above.

I will echo @webchick's comments that we need more clarification of what we want in core and why it should be in core instead of contrib not just "yay sass!"

I also think something like @edward_or's suggestion of https://github.com/kriswallsmith/assetic has more traction here. Something that is more API-level, and pluggable, where people *can* use it if they elect. This also offers support for LESS, Stylus, and Coffeescript.

I'm with c4rl here. Do we really have that much CSS in Drupal Core to warrant the use of SASS? I'm all for what it accomplishes, but increased complexity will not improve our design. There isn't any reason why something like it couldn't live in contrib... Assetic would definitely help out the asset system, and I made a quick note about it not too long ago over at #352951: Make JS & CSS Preprocessing Pluggable.

If we want less complexity, with a better design, we need to hit up the CSS Cleanup issues before anything else.

@c4rl, I fear that having seen my nesting/control directive stuff last night may have thrown you. IMO, adding Sass to Core will not increase difficulty as a whole for the very reason that all of the things that make Sass Sass are optional. It's not a nested syntax, it gives you the option to write your selectors nested (and the reason most people who write Sass write with nested syntax is because after doing so, it becomes easier to read and find things in your file). If you don't want to use mixins or @extend, great! Don't use them! The years of experience you have writing A+ cross-browser compatible CSS? All of that still applies and can be written exactly as you are doing it now, all you would need to do is save your file as a .scss file instead of a .css file. Let me direct you to Sass's Official Website where you can see the examples they have. Very little (if any) nesting, and it's all normal looking CSS, with the exception of where it's demonstrating what's not. I wish I had (and maybe I will make this a session for February) had time for a proper explanation of what Sass is and why IMO it belongs in core.

As for a pluggable infrastructure, may I make an analogy to jQuery in Core? There isn't a pluggable system for jQuery, Prototype, Dojo, Mootools, etc… and everyone seems fine for that. Additionally, if there were (and as was mentioned earlier), Core would then either need to write all of its JS free from a JavaScript framework, or would need to maintain versions of all of its JS in each system the pluggable framework supports. Contrib would need to do the same. Imagine not being able to use Views because you prefer Dojo to jQuery. The idea with the preprocessor in core is to just hook into the preprocessed file (.sass, .scss) so we wouldn't be calling the CSS directly, so we would have the same issue as if we supported a pluggable JS Framework system.

As for why Sass over Less et al., consider this: between meetups, BoFs, Camps, and Cons over the past year, what have you seen more of out of in the Drupal community? Sass session or other CSS Preprocessor sessions? At DrupalCamp NYC, not only did we not have any sessions on any of the others, we had a two hour session plus one hour BoF on Sass. BadCamp, Session+BoF. NH same deal, BoF in London. Major talk in Denver on the subject. I'm sure I could dig through my tweets and the list would go on. Zivtech, to my knowledge, builds every single one of their sites using it. I'm trying to bring the same to WorkHabit and so far, succeeding. My point basically is that even in Sass's ruby-centric state right now, there has been enough movement to it from within our Community already to warrant placing it well above all of the other contenders, regardless of the fact that, to most who have compared the two, that Sass has come out the winner. So, accepting the premise that a pluggable infrastructure would add far more complexity than standardizing around a single "language" and that there is seemingly far more Sass support in the Drupal community than any other preprocessor (plus its significant external community), I think we can agree that the best road forward if we were to add a CSS Preprocessor to Core, would be to add a single one for Sass.

Why it shouldn't live in Contrib like everything else is a story for another post.

Why it shouldn't live in Contrib like everything else is a story for another post.

I look forward to reading it. :)

Sebastian and myself spoke to Sam Kottler today about him helping out with PhamlP and maybe Sassy, and one of the things that became clear is that currently the two are bound together relatively tightly (sort of).

The result of this conversion (other than skottler joining the team, yay!) is that we are planning moving towards a system like so:

• PhamlP will live on Github, and added to Drupal as a library
• We will write a module for handling the bridge between requests for compilation and language-preprocessor-providing modules (this has not been overly fleshed out yet, but the basic idea is that mutliple modules can offer to compile the same type of file, and that caching, settings, etc are all handled by the same code.)
• Sassy will hook into that bridge module and keep doing all the awesome stuff it does BUT it will no longer be a *requirement* for compiling SASS/SCSS on a Drupal site. It will also no longer handle the caching side of it.

This is similar to the framework I laid out about 30 posts ago, with the ultimate aim of both entirely decoupling PhamlP from Drupal, and decoupling Sassy from SASS/SCSS compilation.

This is kinda opposite to what @snugug is saying BUT it's the right way for a contrib module (as opposed to a core module, which Sassy is closer to - single module, single download, single issues queue). Look forward to updates both to the system above and PhamlP's capabilities in the coming weeks.

.. that sounded something like a press release, what my point was: we are doing this in real life so it's hopefully useful for future discussions..

(written by richthegeek)

External library geek butting in here for a moment: Are any of the libraries mentioned in #72 PSR-0 compatible? That would make it much easier to include them in core if we decide to do so. :-)

I still have no strong preference here as long as everything is PHP, but I'm just concerned about making sure we include external code in a clean fashion.

Crell: I don't know - link/enumeration of PSR-0 would be handy :)

#1240138: Adopt PSR-0 namespace convention for core framework classes
https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

mmm... don't know how come I've missed this issue until now (thanks @echoz for the heads-up).
I'm maintaining a theme called Sasson which implements a modified version of phamlp (we took the most recent version from github and built on top of that).
The reason we wanted to keep the css preprocessing in a theme (besides the fact that a theme cannot depend on other contrib) is that we believe this should live in the theme layer and not anywhere else - in other words, we wanted a theme that you can just enable, and start writing SASS/SCSS (well, Compass is a nice-to-have bonus too).

Seems like this issue is more about the inclusion of the compiler into core and not the conversion of the stylesheets, so changing title.

About the state of the compiler -
Our compiler is built on top of the most recent version of PHamlP from github, we have fixed many issues (with media-queries, with partials load_paths etc.) but we still have an issue with @extend and there might be others we haven't noticed yet.
@richthegeek and @fubhy seem to do some really great work on the compiler in SASSy, though I couldn't get it to work in my quick testing trials, probably more due to the lack of documentation and not the code :), I would really love to integrate the SASSy's compiler into Sasson and thus help making it even better, but unfortunately it is tightly integrated into the module and its sub-modules, making it impossible to be implemented in a theme ATM so we were left with the github version of phamlp.

About integrating into core -

• I don't think it makes sense to maintain a sass version of all of drupal's core css, the gain simply doesn't worth the maintenance load IMHO.
• +1 from me for integrating a (php) SASS compiler into core, though I strongly believe it will make most sense to put it in the theme layer, in the form of an optional theme engine, since phptemplate does so little there will hardly be any effort duplicates between the two engines.

[Edit] - just noticed @richthegeek has created a standalone version of SASSy's compiler on github (kudos), unfortunately, simply replacing Sasson's compiler with that one didn't work, so I can't tell if it's an improvement, we'll see about that when I'll find some time to put into that.

Tsi: the switch to a github-hosted version of PhamlP is only about 2 days old at this stage and hasn't yet been integrated into Sassy (or de-integrated out of?). I was planning on doing it this weekend but am ill instead :(

The idea of including it in the theme layer seems a bit odd to me - it doesn't support updates via update-manager, if I remember correctly?

Anyway, I'll be moving forward with the externalisation of PhamlP this week so i'll keep you updated exeternally to this issue queue.

@richthegeek - not sure I get your point about the updates support, if you're saying themes aren't tracked by update.module then no, you don't remember correctly :) but I'm not talking about including the preprocessor in a core theme, but in a theme-engine (probably not the default one, not sure what are the implications of this).
Seems to me that CSS should be dealt with on the theme layer like we do on Sasson, only separate the theme from the compiler that will be put in a theme-engine, can't think of any reason why this may seem odd.
Thanks for the (future) updates about the stand-alone compiler, I think you may post them here as the state of the compiler is exactly the reason this issue was postponed in the first place.

As promised, here's my little spiel on why Sass should go directly into Core instead of live in Contrib. While others may have different reasons, here's mine. As a side note, there will be times I use CSS and Sass interchangeably (use your context clues to figure out when I mean which and remember that any valid CSS you write is valid Sass).

tl;dr version: Less WET styling, easier to maintain styling, less selector overriding headaches, more powerful styling tools, more API/hook-like workflow in styling.

*gets out, gets on soapbox*

Writing CSS Sucks. It really does. Especially when you're dealing with a project as big as Drupal and with as many CSS files (and CSS writing styles) as there exists in the community. Sure, we have CSS Standards, but they more or less boil down to "Write Valid CSS" which, as far as a standard declaration goes, is more or less non-existent. Sure, there's suggestions on how to document, how to comment, and how to list properties (alphabetically, for those curious), but how many people, before I pointed this out, knew this existed? How many people actually follow those suggestions 100% of the time? For giggles, take a look at views.css and you'll see that neither the alphabetizing of properties nor the the comment blocks are actually done properly. Fortunately though, Views goes crazy with the classes it puts onto items, and the css is written in such a way that if I wanted to override .views-exposed-form label my CSS in my theme would be that easy. Not all modules's CSS is written in a similarly easy-to-override manner.

Let's take another example module and we'll (hopefully) begin to see where having a CSS Preprocessor in Core makes sense. Let's look at nice_menus.css (the Nice Menus module) to begin with. Besides not following Alphabetical Properties and Doxygen Documentation and declares its own clearfix on line 46 (and that's missing documentation so as a themer, if we didn't recognize that as a clearfix, we might be in trouble). What if, instead of Nice Menus writing its own clearfix, it (and every other place any module or theme would need to use a clearfix) could simply write:

selector {
  @extend .clearfix;
}

The ability to do this makes styling less WET and easier to maintain as each module or theme wouldn't need to write its own clearfix, they can just use Core's, maintained in a single place, written using (presumably) the best, most current CSS Best Practices.

Now let us take a look in nice_menus_default.css and even more will be made clear. Besides the fact that Alphabetical Properties and Doxygen Documentation isn't followed, there are inconsistencies in the file itself with how it handles properties (padding, for instance, sometimes is called in a single line, sometimes by each property) and the selectors used are very VERY specific, making it unintuitive at first to most themers how to override selectors. Say, for instance, I wanted to change the arrow image used for ul.nice-menu-right li.menuparent (line 70 for those playing along at home) for both hover and normal states. If you're looking at the DOM, my first instinct would be to write something like this for my CSS:

.nice-menu-right .menuparent,
.nice-menu-right .menuparent:hover {
  background-image: url(my-arrow-right.png);
}

Of course, because of the more specific selectors used in the actual CSS file, my override wouldn't work. Now I would write something like this:

ul.nice-menu-right li.menuparent,
ul.nice-menu-right li.menuparent:hover {
  background-image: url(my-arrow-right.png);
}

Now this would get my image in there, but it would override what was already there (because the main file is using a straight background tag, not divided up between background color and background image). This now gives me my arrow, repeated, as the sole background of those items with no background color. Additionally, because of the way the selectors are written, it would also mess up ul.nice-menu-right li li.menuparent and ul.nice-menu-right li li.menuparent:hover, which means that to just change the image for that arrow, instead of simply dropping in a new image path, I now need to write this CSS:

ul.nice-menu-right li.menuparent,
ul.nice-menu-right li li.menuparent {
  background: #eee url(my-arrow-right.png) right center no-repeat;
}

ul.nice-menu-right li.menuparent:hover,
ul.nice-menu-right li li.menuparent:hover {
  background: #ccc url(my-arrow-right.png) right center no-repeat;
}

That makes me feel all sorts of dirty, especially when the alternative Sass could look like this:

@include nice_menu_right_arrow_image(my-arrow-right.png);

What we have above is a theoretical nice_menu mixin that would write for us the CSS needed to override the image in those places. True, for this example, it may not be that useful, but it is one line of code that needs debugging instead of 9, and that already makes it easier to deal with. Some may cry that they prefer to write their own CSS, and in that case you can (again, all valid CSS is valid Sass using the SCSS syntax) but for those of us who prefer to stay dry, this would significantly speed up theming. Now imagine nice-menus had not just that mixin, but one for changing ALL of the arrow images. We could then include that and transform 30ish lines of CSS we would need to write down to 1; how's that for savings?

///
// Implements nice_menu_arrows()
///
@include nice_menu_arrows(my-arrow-down.png, my-arrow-right.png, my-arrow-left.png);

Hey! That kinda looks like the Hook system we have in PHP! And you know what? That's kind of what it becomes like.

One more example, this time using the Fivestar module. Let's say you wanted to write a custom fivestar widget. The image size is different than the default, so your'e going to need to not only create a custom image sprite with all that comes with that. The CSS for that would look something like this:

/* Static View-only Star Version*/
.fivestar-sass_fivestar div.fivestar-widget-static .star {
  width: 25px;
  height: 25px;
  background: url('sass_fivestar.png') no-repeat 0 0px;
}

.fivestar-sass_fivestar div.fivestar-widget-static .star span.on {
  background: url('sass_fivestar.png') no-repeat 0 -25px;
}

.fivestar-sass_fivestar div.fivestar-widget-static .star span.off {
  background: url('sass_fivestar.png') no-repeat 0 0px;
}

/* Javascript Star Version*/
.fivestar-sass_fivestar div.fivestar-widget .cancel,
.fivestar-sass_fivestar div.fivestar-widget .star {
  width: 25px;
  height: 25px;
}
.fivestar-sass_fivestar div.fivestar-widget .cancel,
.fivestar-sass_fivestar div.fivestar-widget .cancel a {
  background: url('sass_fivestar.png') no-repeat 0 0;
}

.fivestar-sass_fivestar div.fivestar-widget .star,
.fivestar-sass_fivestar div.fivestar-widget .star a {
  background: url('sass_fivestar.png') no-repeat 0 0px;
}

.fivestar-sass_fivestar div.fivestar-widget div.on a {
  background-position: 0 -25px;
}
.fivestar-sass_fivestar div.fivestar-widget div.hover a,
.fivestar-sass_fivestardiv.rating div a:hover {
  background-position: 0 -50px;
}

That's 38 lines of code, plus a custom image sprite you're going to need to deal with and position correctly, etc…. All of that is doable, but how much easier would it be to do the following:

///
// Implements fivestar_widget()
///
@include fivestar_widget(sass_fivestar.png, 25px);

That's pretty easy; a custom image sprite with the size defined. But a Compass implementation in Core can actually do you one better:

///
// Implements fivestar_sprite_widget()
///
@include fivestar_sprite_widget(sass_fivestar/*.png);

What's now happening is Compass is taking all of the individual images in that folder (meaning it's easier to edit individual images and can have them be different sizes) and putting them all in for you, with the right sizes /by magic/. Same amount of CSS, but easier to deal with the individual images. That, to me, is quite powerful and something I'd love to see in Core.

Now that I'm done with the examples of what Sass can do when multiple modules are implementing partials that can be shared between each other, the answer to the question of "Why in Core instead of Contrib" is a matter of adoption. There are very few modules that would think twice about spending the time to refactor their CSS around Sass and Partials if it wasn't in Core (this can all currently be done with the gem + SSSW module). As for why Sass instead of any of the other preprocessor, see My Previous Comment.

*gets off, puts away soapbox*

@Snugug - great explanation about the potential of bringing sass into core, I would also add 'performance' to the list of benefits as a well-written sass can produce a very efficient and minimal css (see Sasson's grid system compared to the standard 960gs) .

I agreed it write less code because it predefined all before you start. If your styles never reuse, it's same, even SASS get you do more than before. And when you do something similar, it's a copy & paste game. Doesn't it a problem for core development? I don't know.

SASS is portable script. You able to do automated sprite (and other similar features) in SASS and copy to drupal. It's no big different. And once it's done, you never change it all the time.

as I mentioned before. SASS is good for some projects but in Drupal core case may not.

Okay it has both Pros & Cons. Let's forget it first. Until now, what's the REAL PLAN.

- add SASS version of all CSS files;
- add a CSS preprocessor;
- add a SASS PHP compiler

above three options are totally different concept. It sounds like we're discuss to add all of THREE ??

- add SASS version of all CSS file;
Shoud it also include a PHP compiler in CORE?

- add a CSS preprocessor;
Okay, let you easy to use any compilers (LESS, SASS, XYZ). If that I think we should NOT include any compiler. (WYSIWYG-like API)

- add a SASS PHP compiler
We're going to manage one more code package? PHamlP doesn't seems like a popular open source project and unstable. (one man maintainer ?)

and while SASS compiler included in CORE, I bet drupal will not delivery with plain CSS file. so any compiler bug could be the release blocker. and anyone needs to learn SASS before hack the theme, NOT JUST CORE DEVELOPER.

I guess @JohnAlbin only want SASS version of all CSS files.

I sent few CSS patch in ISSUE list and no one review it. I'm interested what if it is a SASS version patch.

and we going to force all MODULES to add SASS version of CSS ??

You are correct in identifying the three stages of this task, so here's my thoughts on them:

1 - add a SASS version of all CSS files
The options available from this are:

1. Distribute with canonical SASS versions of all core styles, which are compiled on demand by a core-compiler.
2. Distribute with canonical SASS versions that should be patched, but distros use precompiled SASS files (a poor choice, but no core dependency)
3. Distribute with non-canonical SASS versions and no core compiler. That is, patches can be committed in either SASS or CSS and there is no core compilation by default.

I hope it's clear that #2 and #3 are pretty shoddy choices - if SASS is included in core it must be compilable, and if it's not compilable from a core-dep then patching will be a major issue as some people won't be able to compile (although if the majority of CSS patches come from a core group then it's not a huge issue).

2 - add a generic CSS preprocessor library
Myself and fubhy (and possibly skottler, and anyone else who has time) are working on this with the prepro module although so far nothing has been committed due to lack of free time on my part. The purview of this module is to track files that /can/ be preprocessed and offer them to a list of registered preprocessors, handling the loading, caching, and settings for these files in a single place rather than duplicating effort across preprocessors.

I think having a central preprocessor module is pretty much required for a core inclusion otherwise it hampers innovation and ties strongly to both a single language and a single parser.

3 - add a parser/compiler for SASS/SCSS
I'm biased here because I'm (along with Fubhy, skottler, anyone else who can help) working on the most up to date version of the compiler (http://github.com/richthegeek/phamlp) I know of, and whilst there are some large issues with it (code cleanliness, debugging is non-existent, @import rules are buggered) it is being developed with a TDD mentality. All issues get tests written and passed against. With the exception of @import-based failures, all tests pass at the moment.

I think the main issue with a compiler would be keeping it up to date with the ruby compiler which is on a quick rolling-release schedule. If we were to standardise against a single version of the compiler for each core version (say, 1st Jan 2012 for D8) then this would mean we have something solid to works towards. However, this is a bigger problem than it is with jQuery (I think) because a lot of the features are more than the "nice-to-haves" of later releases of jQ.

Whilst PhamlP is currently handled by a small number of developers (all improvements in the last month+ have been by me...), if we commit to it being in/near core then hopefully the number of developers interested in improving it will increase. Something of a chicken and egg situation here.

... back to work ...

@droplet As I've mentioned a few times, utilizing the SCSS syntax of Sass (which is what I think all Sass people can agree we'd be doing for Core files) any valid CSS you can write is valid Sass. Additionally, if you didn't want to take full advantage of Sass and just wanted to use plain CSS in contrib modules/themes, it is very literally as easy as renaming your CSS file .scss and you're set. Yes there is a barrier to entry for core patches if you don't know how to debug if/for loops or mixins with Sass, but it's the same type of barrier to entry as if you didn't know what :nth-of-type or :not was (i.e. you're not going to work on patches for CSS3 stuff if you don't know CSS3; likewise you're not going to work on patches for the more heavy-handed Sass stuff if you don't know Sass, but there is plenty in both Sass and CSS3 that you can debug without knowledge of either).

Just to reiterate, SCSS syntax is a Superset of CSS meaning that all of your CSS knowledge is the same, all of the performance and special targeting stuff you know, all of your years of experience with CSS does not, I repeat DOES NOT get thrown out the window. It is still very much useable and very much applicable; the only difference is now you can get to learn new techniques to improve your CSS coding abilities, allowing for less CSS writing and easier maintainability. Hell, if you choose not to use Sassy stuff in a SCSS file, you are very much so literally writing CSS. Even if you are, you are still just. writing. css. with the added ability to do something like color: $drupal-blue; instead of color: #52b0e9; everywhere you want to use Drupal's Blue. Once more for the hat trick. If you know CSS, you can write Sass; everything else Sass does is gravy that, and like new psuedoselectors in CSS3 or the -moz vs -webkit syntaxes for gradients, you can debug what you know and leave what you don't for someone else (oh, by the way, Sass will actually make it easier for people to debug CSS3 goodies because we can, and do, have mixins that knows how to write all of the different prefixed versions so all you really need to know is how to write the Sass one, and you can debug for all browsers).

@richthegeek I find myself with some extra time and the desire to help get a working Phamlp off the ground, let me know how I can help.

2 - add a generic CSS preprocessor library

This may be a great contrib module, but I think that if core wants to incorporate a css preprocessor it should choose one of the syntaxes, my vote goes to sass, obviously.
Actually it will be nice to get a core maintainer's POV here, as we might be way off here, this is not a minor feature request but a rather dramatic step, don't you think ?

oh, by the way, Sass will actually make it easier for people to debug CSS3 goodies because...

And don't forget @debug ! (which is kinda like dpm() for sass/scss), very usefull.

@richthegeek - not a lot of time to spare but will gladly help wherever I can, let me know...

@tsi (and anyone else with spare time or inclination to assist) add me on Skype or find me on IRC, always as "richthegeek"

I think regardless of the decision at the end of this with regards to Core/Contrib, I think any preprocessor needs to live in contrib for a while to ensure it's stability and adoption and really wether it brings up any unforseen issues.

Snugug: I have no serious horse in this race, as I'm not a themer. But I think you need to change your argument approach. You've done a fine job of laying out why Sass > CSS. That's been done elsewhere, too. However, the issue is that if core uses Sass by default and generates its CSS, it means *people who don't know Sass cannot write patches to core's theme layer*, because it will be full of @extends and other Sassy stuff.

That may be a good trade-off. It was for jQuery in core. But that's the argument you need to make, not just that Sass is cool but that it's benefits outweigh the higher barrier-to-entry for patching core.

Nice to see crell weighing in :)

Things that any CSS preprocessor provides us:

• DRY programming brought to the front-end. Pretty much all arguments for DRY modular programming on the back end are copied over here, and I don't know any arguments /against/ them other than "higher cognitive load".
• Additional functionality including maths, DB -> CSS writing directly (for example, we can easily add a drupal_get_path-like function into SASS) to, for example, provide a different color scheme for the current user or replacing the Color module's method entirely - variables become available directly just as $color-main or similar and can then be used throughout all stylesheets
• Advanced integration between module and theme. If we have some strict standards defined for naming color palettes then it would be possible for modules to automatically theme some of their elements to fit into the site in a nicer way by default. This would be a big win for a good first impression if done right.
• Being the first big CMS to do this - Drupal could be the leader in driving this tech forward if it went into d8 core. Personally I'm not a fan of this particular brand of evangelism but it's present nevertheless.
• Contrib modules/functionality - wether they provide new functions or new mixins, or do some clever stuff with optimising your stylesheets (Fubhy apparently has desires in this direction) for faster rendering, or otherwise integrate with your site... a preprocessor adds the possibility of allowing the same level of community contribution that Drupal core experiences expanded onto the theme side

I think we definitely need some coding standards defined if we move forward with SASS/SCSS/LESS anywhere near core, both for allowing automated integration but also to guard against naming conflicts and the like.

For those interested, the following changes have now occurred:

1. The picking/caching/settings of CSS preprocessing is now modularised with http://drupal.org/project/prepro picking up all the non-compilation stuff that Sassy used to handle. This means the following is enough to make all SASS/SCSS files be preprocessed by the ruby parser: http://pastie.org/3181947

2. Sassy now uses libraries for PhamlP and that is now hosted on http://github.com/richthegeek/phamlp (a few new features added and a few bugfixes also in the last few days)

3. dvessel has started an issue detailing missing features for PhamlP on teh Sassy issue queue: http://drupal.org/node/1404220 - keeping this list up to date and having multiple people working on it will be pretty important to bringing phamlp up to scratch.

Thanks for the advice Crell. While I don't necessarily agree with the fact that someone won't be able to contribute to Drupal Core w/o known Sass (afterall, Sass is not a language, it's a framework on top of CSS), I've gone through a few of the Core-shipped CSS files and broken out some places where Sass would improve maintainability and readability of Core-shipped CSS files. At the end of the day, after doing this little exercise, I now not only think Core would benefit greatly from Sass, but from a large restructuring of how Core handles its shipped theming assets, but that's a discussion for a different time/thread. Anyway, without further adue, some TL;DR for everyone!

Sass Improvements:
//////////////////////////////
// General
//////////////////////////////
Sass comments instead of CSS comments so final CSS provided to end user has no comments.
Less Repetition in selector writing
Colors used throughout Core can be reused making for better maintainability and easier overriding by contrib

As a general idea, I would also like to propose moving from .png files to .svg files and using background-size to size the background images appropriately. Reduces number of files needed, potentially reduces number of HTML calls, and we will never have to worry about our UI elements not looking right on different resolutions. I think this probably belongs under the HTML5 initiative's issue queue though.
That being said, if we moved to SVG, a mixin could be written along the following vein:

  @mixin message-image($message, $size: 16px) {
    background-image: url('../../misc/messages-#{$message}.svg);
    background-size: $size;
  }
  

Then it could be called as follows:

  $message-warning-color: #ed5;
  
  div.warning {
    @include message-image('warning', 24px);
    border-color: $message-warning-color;
  }
  

Which would turn into:

  div.warning {
    background-image: url('../../misc/messages-warning.svg');
    background-size: 24px 24px;
    border-color: #ed5;
  }
  

Doesn't do a whole lot just there, but considering there are 5 different message images at 2 different sizes a piece, only needing to maintain 5 images instead of 10 would be a boon for maintainability and being able to call a single mixin that has predictable and easily changeable results everywhere those five different message images in two different sizes are called is quite nice (especially, say, if when Core8 is released the images are all still thrown into /miscand then we want to move them to something more sensible like /modules/system/images. Needing to change one url in one place is much easier and friendlier to do than each of the places the five images in two different sizes gets called).

//////////////////////////////
// misc/vertical-tabs.css
//////////////////////////////
Nesting makes for readable (and hence more maintainable) code
Lines 35, 40-42, 45: Link Selectors
All selectors can be & combined and nested for easier readability
Lines 48, 52: Inconsistent Selection
l48 targets li.selected whereas l52 targets just .selected. Nesting ensures that both are selected in the same manner and therefore are easier to override by themers.
Lines 4, 11, 29: Repeated border style "1px solid #ccc"
#ccc can be turned into a variable to be referenced throughout the system for better maintainability
Whole style can be turned into a variable to be reused throughout the system.
Lines 70-72: Box Sizing
Mixin can be written (or may exist in Compass) for prefixing CSS3 properties like box-sizing, improving maintainability
//////////////////////////////
// misc/vertical-tabs-rtl.css
//////////////////////////////
Lines 4, 8: Inverse Properties
Variable can be made for DRY CSS property writing
Sass Math allows us to create inverse of variable, making maintaining easier.
//////////////////////////////
// modules/system
//////////////////////////////
Partials system would allow for one master CSS file with multiple partials, making it easier to find what you're looking for and, at the end of the day, providing a single CSS file for use in Core instead of 11.
Something like the following maybe (using Menu as an example):
modules/system/sass/system.scss
modules/system/sass/partials/menu/_menu-tree.scss
modules/system/sass/partials/menu/_menu-tree-rtl.scss
modules/system/sass/partials/menu/_links.scss
modules/system/sass/partials/menu/_breadcrumb.scss
modules/system/sass/partials/menu/_local-tasks.scss
modules/system/sass/partials/menu/_local-tasks-rtl.scss
//////////////////////////////
// modules/system/system.base.css
//////////////////////////////
Partials allow for the file to be divided up for easier finding of items
Nesting makes for readable (and hence more maintainable) code
Lines 13, 19, 25: Nesting makes for easier readability and Dry property writing
Multiple other places
Lines 32, 76, 104, 120, 123, 126, 165: Mixin for Backgrounds
A mixin for the various backgrounds that include background images would make for contrib overriding much easier.
Throbber background image is used twice. As a variable/mixin pair would be easier to maintain.
Lines 71-73: Box Sizing
Mixin can be written (or may exist in Compass) for prefixing CSS3 properties like box-sizing, improving maintainability
Lines 228, 238, 239: Element-Invisible as Mixin
Providing element-invisible as a nested mixin plus selector would allow for any contrib selector to be applied
Lines 249, 257, 261: Extendable Clearfix
Sass allows any class to be @extend ed, thus allowing any class (including contrib stuff) to have a clearfix applied w/o additional class markup or preprocessing to get the clearfix class on there.
//////////////////////////////
// modules/system/system.messages.css
//////////////////////////////
Partials allow for the file to be divided up for easier finding of items
Nesting makes for readable (and hence more maintainable) code
Especially useful here for grouping status, warning, error, and general messages together.
Background Image Mixins
As above.
Colors as variables can be repeated and easily overridden from Contrib
Let's not forget Color functions. It's entirely possible to change the hard colors currently used here into lighten/darken functions of a base color, again increasing maintainability
//////////////////////////////
// modules/system/system.menus.css
//////////////////////////////
Partials allow for the file to be divided up for easier finding of items
Especially important here as some of the stylings are not necessarily menu-specific.
Repeated colors can be turned into variables
Many colors used in menus.css are used elsewhere. Would be nice to be able to control them from a single place
Nesting makes for readable (and hence more maintainable) code
Mixins or variables for repeated code snippets
Menus uses 1px solid #ccc as does vertical tabs for a border definition. DRY and reusable across modules.
Padding and margin definitions get used over again, nice to control from variables.
//////////////////////////////
// modules/system/system.theme.css
//////////////////////////////
system.theme has additional selectors/properties for selectors/properties that exist elsewhere in system.*.css files. Moving to a partial system would group these various different places selection/properties occur into folders for better maintainability.
Repeated snippets (1px solid #ccc is quite abundant throughout system.*.css) can be condensed into variables/mixins for better maintainability and Dry property writing.
Lines 233-235: Mixins for CSS3 Selectors
Here it's border-radius instead of box-sizing, but same idea applies.
//////////////////////////////
// modules/system/system.admin.css
//////////////////////////////
Partials partials and more partials! This file needs to be broken up desperately.
Nesting makes for easier to read selection
Variables/mixins for less Dry property writing.
Compass float left/right mixins to ensure floating occurs properly in all browsers.
//////////////////////////////
// modules/menu/menu.css
//////////////////////////////
This file has 3 selectors w/1 property each in it. All other menu styling is in system.menu.css. Not necessarily a Sass thing, but shouldn't these be combined?
//////////////////////////////
// modules/field_ui/field_ui.css
//////////////////////////////
In some serious Partial and Nesting love. Very difficult to glance at and see what's going on.
Many of the selectors are the same one line selector. @extend can be of great help here to stack those selectors.
//////////////////////////////
// modules/user/user.css
//////////////////////////////
In some need of Partial and Nesting love. I see a "Permissions" partial, a "Roles" partial, a "Password Strength Indicator" partial with potential subpartials and/or a mixin or !default variable for easy overriding by contrib, and a "General User" partial.

Just to add onto @snugug, we don't even need distinct RTL stylesheets, instead setting a variable based on the site config.

That would allow the use of either the SASS @if or the Compass "if(statement, if_true, if_false)" syntax to put all the require bits into a single location, an example with the toolbar.css & toolbar-rtl.css from issue #11902100: http://pastie.org/3232001 (not tested, just a quick example).

That should hopefully make it easier to see where the differences between LTR and RTL lie, and any other situations where things need to change based on a system config option (note the namespacing $drupal-language-* for the Language module)

First, apologies to @webchick for posting this during her Sand Camp presentation, but it makes me want to do more community stuff!

Anyway, I had an idea that may help with the performance concerns of Sass in Core (yes, this is an implementation post as opposed to a philosophy post). One way we performance concerns can alleviated is if we add a function to be called using hook_update so it only gets recompiled when running update.php (if you're not developing). If you're developing, have some Sass settings in admin/config/development/performance that would include compression options for Sass CSS, true Sass line commenting, and rebuild CSS on on Page Reload. Doing this would also help alleviate the issue about trying to find where CSS stuff is coming from (actually, doubly so because it would include the Sas lines for all Sass on the site, including Core and Contrib).

Just throwing that out there.

@Snugug using SASS does not mean your CSS have to be dynamic. That's something crazy (dynamic css) but there are situations where it might come in hand (think UIs for styling). Prepro allows for it, which is great, but I wouldn't even consider it for Core as it relies on PHPSASS being mantained. SASS is a moving target. Porting it to PHP is a lot of an effort, as is libsass (a C++ implementation). But core SASS development is not moving away from Ruby any soon.

Anyway, using a preprocessor makes CSS a lot more manageable. Of course it adds to the complexity of contributing to Drupal core, but it is not a requirement to use it or extend it. This means besides those who really want to contribute back tweaks to core's stylesheets, everyone else can just ignore the existence of SASS. Unless you want to embrace it.

And if you want to go with LESS, Stylus or any other CSS preprocessor in your theme, you can just use it. Once compiled, SASS doesn't get in your way.

The creator of lessphp also has created scssphp, see http://leafo.net/scssphp/

I would argue (as a mainly-developer partly-themer new to SASS) that it looks like it would be easier, not harder, for me to contribute patches to core stylesheets if they were SASSified.

One obstacle would be in finding the source SCSS for a given CSS selector that I'd found using browser development tools (Firebug etc). All I'd ask is that, given the filename of an (un-aggregated) .css file, I could easily find the source .scss file. I might have to then hunt out other SCSS files if I find extends and mixins, but I'd ask that the filenames could be referenced in inline comments, or otherwise made obvious by naming conventions.

Beyond that, even if the SASS syntax wasn't easy, SASS brings with it quite a few simplifications for the casual CSS patcher. With extends, mixins, and variables, you can swiftly ignore code that doesn't relate to what you're looking for, provided it doesn't cause conflicts further down the cascade. The proliferation of classes in markup (clearfix etc. see #65) would be reduced and that may also contribute to removing horrible style-related code from PHP files (things like '#attributes' => array('class' => array('container-inline'))).

@pjcdawkins: Something like FireSass fro Firebug can really ease browser debugging, too. You just need to enable Sass's :debug_info option to use it.

@pjcdawkins @TravisCarden: Recent Chrome dev builds support source maps for SASS which solves this problem in the browser without plugins.

I've been mulling this over, and if cover freeze was a year away, then I'd mark this as a critical.
In the time since this issue was posted 2 things have happened.
1. CSS preprocessors have only gained in popularity, and SASS has the upperhand among current Drupal developers.
2. Drupal has adopted the use of Symphony 2 for core components.

What has Symphony 2 go to do with this?
Once of the arguments against SASS is that is raises the bar for 'newbies' or people unfamiliar with CSS preprocessors who want to contribute to core.
I'd argue that core development is increasingly complex already, but that is for a good reason.
Learning Symphony is now required for Drupal core development.
We're adopting best practices and approaches from elsewhere.
So if you want to develop Drupal's core CSS, then a requirement to develop in SASS should not be seen as blocker.

For a lot of Front end developers, developing without a CSS preprocessor seems backward at this stage.
Personally speaking, I struggle to work without SASS.

So onwards with SASS for Drupal 9!

Seriously, if SASS , backbone.js and Bootstrap come into drupal, nobody will ever think of leaving drupal. Is it too late to include SASS in D8?

IMO, Its too late.
Converting the files is the easy part.
Deciding on a workflow to best make use of SASS is a bit trickier.
Re-architecting Drupal's front end to best make use of SASS is a much bigger job again.
Convincing everybody that this is the best way forward - WAY tougher.

There is a lot of work underway to improve the theme layer right now.
Twig, Assetic, Js improvements.
This is where the focus for D8 should be.
Sass will have to wait, I reckon.

If we're to take it one step at a time, the first step would be getting Assetic in, wouldn't it ?
This will allow contrib themes\module to trivially include Sass files.
What is needed for this to happen ?

Currently we need help on:
#1784774: Remove Assetic component from core
#1762204: Introduce Assetic compatibility layer for core's internal handling of assets
#1751602: Use Assetic to package JS and CSS files
#352951: Make JS & CSS Preprocessing Pluggable

in this order... For the first one, just chime in and say why Assetic would be a great help for SASS and front-end devs :)

Step 1 #1784774: Remove Assetic component from core
Step 2 #1751602: Use Assetic to package JS and CSS files
Then we can look at this issue again perhaps

@nikkubhai: the problem with include backbone.js and bootstrap is that neither of them are universally accepted as "the right way". Backbone especially has it's uses in certain situations, but a long way from all situations are suited for it's use. Bootstrap, again, is limited in it's uses - it's wonderful for wireframing and quick apps but for any client work its not acceptable. SASS is "better", in that it's very close to LESS, Stylus, etc. so that the choice isn't one between two diametrically opposed tools but just different flavors of essentially the same idea.

@alanburke, tsi: PHPSass has Assetic support now, although I didn't do much more than accept the pull request. Considering assetic is highly integrated with Symfony already, getting it into core should be an easy win.

A further question with regards to development flow is whether there should be no .css files at all, and that everything is compiled with (something like) PHPSass on a cached basis, or that SCSS is only used in the core development with everything compiled down to CSS before shipping. The first option means that there is no issue with people fixing bugs in the CSS and having to translate them back, but it does mean basically forcing SCSS on everyone in the community.

Before we move towards having SCSS in core, PHPSass and Prepro both need a few improvements with regards to development flow and file handling; currently they are both less than optimal - having 100,000 files in your "public" directory is a good way to make it choke, for example.

Just to throw my $.02 in here. I strongly believe the following:

If Sass were to become the best practice for Drupal CSS authoring (which I believe it should), we should not use any port of Sass, but rather use the Ruby gem. This is doubly true because I believe it should be Sass+Compass as the best practice, not just Sass. Some very quick digging pointed me to a blog post showing how to use the Sass+Compass gems with Assetic. The closest thing I believe is an acceptable non-Ruby solution to Sass would be libsass (or a wrapper thereof, like node-sass is). Why? It's the only non-Ruby implementation I've seen Chris Eppstein (co-maintainer of Sass, creator of Compass) explicitly endorse as a viable alternative.

I believe getting Assetic into Core is a higher priority than a CSS Preprocessor, as it appears to cover more use cases than simply adding a single CSS Preprocessor; having a full, proper, seemingly plugable Asset Pipeline for Drupal Core would be an astounding advantage to the system.

While I would prefer to have no CSS files in Core and essentially disallow them in Contrib by forcing everyone to use a preprocessed CSS language, that is simply not feasible considering the array of environments that need to be able to run precludes the installation of Ruby gems (or Node for Less, etc…) so we need a way for those people to still have CSS. This is probably the largest stumbling block, but not something we can't overcome with enough time, which, unfortunately, we don't have.

The primary issue with libsass or the ruby gem is that they aren't PHP. That means they can't run on all environments, and so will never get into core. It's really as simple as that.

An advantage with PHPSass (or another PHP-based compiler, because PHPSass is getting close to just needing to be started over) is that it can interface with Drupal directly for doing things like contrib modules providing functions/variables/load-methods for SASS files.

But yes, getting Assetic in is a much bigger issue than choosing and moving towards a specific parser. It provides flexibility above constraint, something Drupal really needs sometimes.

I use Sasson, but couldn't work without Compass so use its Ruby option, but many shared servers aren't going to get Ruby any time soon and just a good/basic level of Sass functionality in core would be a huge boon to Drupal theming.

Looking to the future re libsass, googling gives sassphp and php-sass. I've never had to setup a PHP extension. Not easy on shared hosting..? I can't see anything specifically Symfony related other than just running Ruby.

How exactly does PHPSass differ from the various PHamlP forks? I know some have varying levels of Compass support, but apart from that, is PHPSass definitely furthest ahead on core support? How does its v3.1.15 support compare to scssphp's v3.1.20 support and the current Ruby v3.2.1?

Edit; I missed that Sassy has Compass support. How does that compare to Ruby based Compass?

@milkmiruku - we also got to the point where we realized none of the php ports will give us what we needed, mainly Compass support. that is why Sasson v3.x is all about integrating the ruby gem instead of a php compiler. this is why we are so excited about getting Assetic into core, but this will not solve the problem for rubyless servers (AFAIK) so we still need a php compiler as a fallback.
I guess that in this php compilers run, Sassy probably has the lead, mainly because of the compass support (which has improved a lot lately, still no sprites though).
I wish there was a single effort for a php compiler instead of all this different projects (I know that unfortunately, we also contributed to this fragmentation) but if you are into comparing them you should also consider scssphp with a drupal module here.

Another $0.02 (so we're probably up to about $0.32 in this thread):

Sass, specifically scss is becoming a front end standard. On large projects it leads to better, more maintainable, more performant CSS within that project.

Sass organization and workflow is not the same and CSS organization and workflow. Compiled scss doesn't necessarily look like the CSS we would have written without sass.

Conversion of core CSS files to scss will absolutely make core's scss more understandable at a glance, but will make core CSS more difficult to understand for those who don't use sass. To patch core CSS correctly you'd need to grok our sass *system*, by which I mean the way we choose to use variables, mixins, functions, and extends, not the syntax itself. That would bring some CSS issues closer to most php/ functionality issues on drupal.org: someone posts that this isn't working right and then maintainers/ pros/ triage team drop in and fix it.

Why the above isn't a bad thing: core modules should barely be putting out any CSS at all -- converting to scss will give a chance to remove and refactor as much as possible, making core's CSS better. For core themes, i think converting one or two and leaving one in pure css would be a good choice. Increasing the barrier to entry for *just* core CSS development is kind of a win -- the best people (knowing sass doesn't mean you're a better developer than someone who writes pure CSS right now, but with the adoption rate in the professional front end community in a year or two it probably will) should be working on the most important parts of Drupal.

Sass across contrib: obviously, sass should not be required for contrib. If a maintained decides to use it, there should be a Drupal sass style guide so we have some consistency, at least with modules.

The compiler issue: sass+compass is best with ruby. So forget about it, *sidestep the whole compiler issue*. Sass files, when they exist are canonical. When a patch is made, all sass files are compiled into CSS *on the patch writer's computer* (if they're authoring sass, they have ruby, period). That CSS is never edited, but is used on the server. Solved with workflow, no need to compile at run/serve time, no need to package ruby or an inferior php compiler, or add any more third party libraries to Drupal, done.

If people here can agree on that, we can change the issue to "convert core CSS to sass/scss".

All said, I have a feeling this may be a D9 issue. Or maybe a conversion after D8 feature freeze or even release -- you could consider it a refinement and would have no API changes... sort of.

My 2 cents in a nutshell: Assetic is enough, makes preprocessing a breeze and finally makes it trivial to just remove core CSS and use a SASS/Less/Stylus/Whatever style guide. I bet this can be iterated in contrib and we can see, for D9, if we want it in core.

So with Assetic, Ruby Sass is super easy. Look at potential core PHP solutions come D9, stick with PHPSass/Sassy for now for non-Ruby, and start creating a CSS preprocessor style guide covering basics such as colour/etc. variables as well as layout/grid/responsive methods, something that could spawn a proto/semi-'core' theme?

Crosspreprocessor support for such a good practice guide might be nice, but on balance, some systems might not be worth bending for. It would be interesting to see the comparisons, but at least enough Sass/SCSS folk are apparently interested to make a start for now? Saying that, should it always aim for the latest Ruby Sass (i.e. 3.2 has interesting additions)? At least the basics should be easily runnable or portable.

Related but not mentioned yet: #1087784: Add new theme to Drupal 8.1.x or another minor version

Sorry for rocking our little Sass boat here, but I've just noticed that the LESS project on DO has about 10x more users than any Sass compiler project.
I too, like Sass very much, and always encouraging people to use it arguing that Sass+Copass > LESS. but I guess the real comparison would be Sass+Compass against LESS+TwitterBS, wouldn't it ? and since I'm not that experienced with LESS, I'm not sure about who wins this round.
Are we still sure Sass is the preferred pre-processor ? even when Dries is talking about a TBS based theme in core ?

Because 99% of people compile their sass/scss with ruby, and most people do so with a hook or manually on sass/scss save, not at runtime like less, the installed module count isn't an accurate gauge of project adoption. In general, compiling sass on the server with a php based module isn't part of the sass workflow.

I believe we've established that sass is the clear winner in the wider front end community as well.

Changing the status to active as #1784774: Add Assetic component to core has been fixed.

tsi, read that comment again. He's in favor of a framework based base theme in core and uses TB as his example in that post (not that he's right about that sentiment either). Additionally, let's look at this upcoming BADCamp and work backwards to last year's BADCamp:

This year, there's 1 45 min session specifically about Less (the first Less session I've seen in all major Camps/Cons in the year we're looking at). There's also a 2.5 hour session on Sass there, which I believe means, hat tip to Sass.

In Munich, there was a full session only on Sass, none on Less, plus 3 BoFs specifically for Sass, again none for Less.

In Chicago, 4 BoFs specifically on Sass, one that mentioned both that mentioned that you should start with Less then move to Sass, and a handful of full sessions that mentioned Sass.

Last year ad BADCamp, there was a BoF plus session on Sass; to my knowledge none on Less.

It's fairly clear that the front end community in Drupal prefers Sass; like was stated, just because there isn't a widely used D.O project for it doesn't mean it's not widely used. In fact, I would be surprised if it was as most of everyone I know uses Sass through Ruby, of which Drupal is generally avoided in compiling.

The entire tier of top range Drupal themers are Sass people. Same with front end at large. There's no better example of this than the fact that Google Chrome is building in, right now, Sass (and specifically Sass) debugging directly into their dev tools. You can test it now in Chrome Canary. It's there, it's works, it's cool. There's no such talk about integrating Less (or for that matter Stylus) directly into browser dev tools. I think there's really no question that Sass is the clear winner.

With all this said, I'd love to see Ruby Sass integration now that Assetic is in Core.

Fair enough, it's not a secret I'm a Sass person myself, but I get complaints from people that (for some unexplained reason) develop on a shared server with no access to ruby. in this case, LESS has some kind of an advantage. Plus, you must agree that LESS+TBS is very powerful. but lets not go to deep into this since, bottom line, we all agree.

So, now that assetic is in (YAY!) where do we take this next ?

I'd love it if someone with some assetic know-how would share some thoughts about the implications of it getting into core regarding this issue.
Do we really need anything else ?
Are we talking about introducing a php compiler ? even now that we have assetic ?
Even if our main compiler is the ruby gem, do we provide a php fallback for people with no access to ruby ?

Next step is #1762204: Introduce Assetic compatibility layer for core's internal handling of assets

Personally, I'd go for both of the preprocessors, since Assetic is pluggable as well as (hopefully) our future preprocess workflow, add SASS, LESS or both would not add much overhead.

@snugug - BTW, the Sass debugger in chrome is (awesome!, and) already available on the beta (23.x) channel as well, if anyone is intrested, I've answered on SO about how to enable it not long ago.
One thing though, this is achieved by leveraging one of chrome's latest features - source maps - which will enable us to debug LESS/Stylus/Coffeescript or any other meta-language of this kind, the implementation of Sass is only the first POC, I guess.

I like the idea of adding functionality to core to make preprocessing files easier.

My only concern is adding a new major requirement to core to get the full Drupal experience, which adding files to core that depend on Ruby SASS would do.

As it stands right now, Drupal has a fairly short list of requirements, and to include Ruby as an additional core requirement should not be taken lightly. Not only would we be endorsing a broader footprint for potential security vulnerabilities, but now core issue queue would also have to deal with support for Ruby installations (not saying it should, but the issues will appear regardless).

Before I created the LESS module, I was interested in SASS first. At the time I had no control over the server environment so any solution that I arrived at had to be PHP based. The reason I went with LESS at the time is that the php version had closer functional parity with the then Ruby version than SASS's php equivalent did with its Ruby version. Again tho, the major drawback of this is that you are always chasing the "canonical" version, which again is not the preferred option.

When it comes to pure language merits I think SASS > LESS, so if core is to adopt one, that would be the one to choose.

IMO it comes down to 3 options, the third being the safest option.

1. Add Ruby as a core requirement to support core use of Ruby SASS.
2. Add core supported PHP implementation of SASS, requiring chasing functionality of Ruby SASS.
3. Add hooks to core so slim contrib module can handle SASS, LESS, etc..., and not having SASS in core.

Also, some people are comparing this to adopting jQuery in core, but that doesn't seem like a valid comparison. There is nothing additional needed by either developers or users to get the benefit of jQuery. You have a browser, it works. Yes, there is a learning curve, but there are no technical hurdles going from plain javascript to jQuery.

I think I covered most things I was trying to, if there is something I'm missing, please let me know.

SASS vs LESS vs SCSS? It's all personal taste. One could argue it's node vs Ruby, but I'm not into religious wars. There are PHP implementations of both (and modules for them) that could achieve what we're looking for. Not saying those are the correct solutions, just stating that Corey's #3 solution is available and already working.

With #1751602: Use Assetic to package JS and CSS files, having the files dynamically compile themselves would be much easier and faster.

Corey, whatever the preprocessor, the output always is (as should always be) editable and readable vanilla CSS. There is no requirement for a preprocessor even if one is used to develop core styles. It will always be opt-in from the site-builder / front-end developer POV. Core developers, though, would be encouraged (forced) to patch both SCSS and CSS files, just as we now enforce simpletest tests for any patch. Although a CSS patch can be trivially ported to SCSS.

LESS/SASS Comparison

https://gist.github.com/674726

Right now the only thing you need to develop for Drupal core, beyond Drupal installation requirements, is a text editor.

If we are to have core build its CSS from SCSS, contributors will have to either install Ruby SASS on their machines or they will have to depend on someone else to port their CSS patch back into SCSS.

As far as I know this is a new, unique situation in core development as core does not require something outside of the installation requirements to do development. Putting a requirement on core contributors to install Ruby to provide patches has the potential to impede core contributions.

If we make Ruby SASS a requirement to contribute to core I'm concerned this could be only the first of core-only requirements, possible hurdle to core contributions, will be possibly changing outside functionality, but it will also make maintaining core styles much easier.

If we include PHP SASS, we maintain the ease to contribute to core, lock in a "version"/feature-set of SASS, but that would be a new large library that would have to be supported in core, along with support issues as why core SASS doesn't do new thing Ruby SASS does. Core maintained SASS library would also suggest/endorse contributed modules using SASS.

If we do neither, we have larger more time consuming to maintain CSS in core, and we maintain the ease to contribute to core.

I might be playing a little bit of devil's advocate here, but I just want us to arrive at well thought out decision. If we're fine with adding new requirements/hurdles to contribute to core, then we should proceed with Ruby SASS, but is this something we really want to do?

I was thinking of this thread when @JohnAlbin posted this piece about CSS coding standards for Drupal 8 - http://groups.drupal.org/node/277223

There hasn't been much movement at all on SASS in Core, but I think most of us are going to be moving to a preprocessor when theming D8 if we aren't already.

Having talked to many SASS/Drupal people in person, I think the general consensus is that we don't want a PHP Sass port in Core. Fortunately, we've got Assetic in Core which we'll be passing our CSS through, and with the magic of a Compass filter for Assetic, we can effectively have Ruby Sass+Compass in Core.

Whilst I have to agree that having something like PHPSass in core would be bad-news-bears, the core "CSS Preprocessor" in core would be a pretty good thing. Something like Prepro's current responsibilities are quite nice to have.

Things we could do with a more flexible preprocessor:

1. Have custom filters/modules for reformatting/compressing our CSS
2. Rewrite filepaths/URIs as required, such as to a CDN (ie, the parser finds all files, uploads them to AWS, and replaces filenames on the fly)
3. Move the entire CSS file to a CDN
4. Provide more intelligent file concatenation, such as splitting them up better or providing better performance
5. Allow per-user or per-role file modifications, such as color schemes or similar, without hammering the cache so much
6. Compile files with PHPSass (out of core) or any other similar tool.

Currently we have this functionality totally baked into core with the CSS aggregation and path rewriting but without the ability to modify it ourselves (in drupal 7 at least).

One obvious change for #125 would be to have filter chains, as opposed to just a single processor per filetype.

This is almost precisely what Assetic does.

Then let's use Assetic! I've not kept up with D8 has in it, i'm not really involved with Drupal in a professional way any more.

Agreed! And it's already in! Huzzah!

Why does this need to be in core? Could this not live in contrib? Anyone savvy enough to use SASS is savvy enough to download a contrib component, no? What if something better than SASS comes out? Core moves slowly, while contrib can adapt quickly, often the same day. Drupal 8 will live through 2016 or later, in all likelihood. Is SASS in core really the best assumption for what the front-end world needs now, let alone 4+ years from now?

At most, I think 118 option 3 would be the most this issue should entertain.

Add hooks to core so slim contrib module can handle SASS, LESS, etc..., and not having SASS in core.

I know that #smallcore is a dream of the past, but this strikes me as, well, feature bloat.

@130, i believe that this is what Assetic provides without it being reduced to something only capable of doing a single-step processing. So yes, I agree! Tying ourselves to SASS is a bad idea.

Assetic has a bunch of filters. We're not going to be using the Sass filter out of the box, but because we're using Assetic to begin with, we are able to, on a project by project basis, choose to use the Sass or Compass filter, or the Less one, or the CoffeeScript one, or build our own. Again, this is precisely what Assetic being in Core allows us to do; choose the way we handle our asset output. See the following:

• How to Use Assetic for Asset Management
• How to Apply an Assetic Filter to a Specific File Extension
• Symfony2: Make your own Assetic Filter

Assetic itself is in core, but it's not used for any of this yet. So if you actually want to be able to use it, please help out and review the issues.

i'd be interested in configuring assetic so that you can parametrize your sass from the theme settings (think color module, breakpoint module)

I agree with @snugug, a php compiler shouldn't be living in core and since we have Assetic filters, we already have a bridge to external compilers. shouldn't we close this as won't fix? or even better, change it to add a core theme that compile scss via Assetic.

Following @catch's comment, here are some Assetic related issues:
#1871596: Create a PartialResponse class to encapsulate html-level data [Moving to sandbox]
#1751602: Use Assetic to package JS and CSS files

@dasjo, Sasson v3.x is using Assetic as a bridge for compiling Sass files with Sass & Compass, while configuring some settings (e.g. image-url) via the theme_settings form, it is very rough and I have no idea how something like this should look in core but it's a nice POC.

at 47:00 of the recent shoptalkshow podcast they talk about using Sass for Wordpress core.
http://shoptalkshow.com/episodes/050-with-daryl-koopersmith/

here are some notes:

• wordpress core doesn't use sass at the moment
• wp core should adapt sass, because the workflow isn't standard yet. rather themes should go ahead and experiment with it
• with preprocessors you have the problem that you do that locally and need to commit compiled code in addition, which complicates the patch workflow
• it adds another dependency (sass, ruby in addition to currently just php, mysql)
• they think about using grunt.js for compiling sass on-the-fly (compare using Assetic filters as explained in #135)

If everyone don't mind, can we start a new discussion with new directions? I bet many discussions here is outdated.

#2658650: [META] Optimize Frontend Workflow in Core Development
Pros:
- Performance
- Official Supports
- no Drupalism (not limited by PHP libs)
- Many Great NODEJS tools

I guess some idea like that would be perfect in the ideas issue queue.

@droplet I'm a 'theme system' sub system maintainer, and closed it as a duplicate until this discussion get's resolved. Changing the component to CSS though because I think @JohnAlbin and that component would be better suited for this topic. Also it doesn't need to touch the theme system, technically speaking.

@joelpittet,

OK, I respect your decision.

** Skipping my comments above #140, it's not suitable for 2016.

Can this be closed as outdated? See CR: Drupal core using PostCSS for development | Drupal.org

Closing as outdated given that core already uses PostCSS.