Omega theme with Compass and SASS - what are the best practices?

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
decibel.places's picture

For background, I am using Compass on the command line with an Omega HTML5 starter kit subtheme. Also, I'm in local dev on Windows 7 and abandoned trying to use the Compass module, but I'm pretty sure that doesn't matter if I can use the command line.

I have created a compass project in my theme and I have the SASS default stylesheets ie.scss print.scss and screen.scss - I created a .scss file for each of the Omega stylesheets. They are then compiled to CSS and watched by Compass.

I understand I use @import to manage the Compass libraries - but how do I make Compass understand the responsive and mobile features of Omega?

Do I use SASS partials?

I have looked for documentation and tutorials but I'm still confused.

Comments

Take a look at a patch I made

Snugug's picture

Take a look at a patch I made to get Sass+Compass working with Omega:
http://drupal.org/node/1297464
If you're coming to the DrupalCamp NJ on Saturday, I'll give you a quick briefing of how to get this working. The long and short of it is edit your config.rb file to point to css instead of stylesheets for your CSS compilation, and inside of your Sass folder, have one .sass/.scss file for each of the CSS files that come with Omega. If you want to share variables/mixins/functions between those files, you're going to need to create a partial (most commonly called _base.scss) that you @import into each of those files, and that's where you put those items.

That's what I did, without

decibel.places's picture

That's what I did, without the patch - I edited the Compass config.rb and renamed the Omega stylesheets in my subtheme to .scss and added them to the sass folder to be compiled and watched.

I see the patch is adding @import to templates etc. But I seem to have it working fine without the patch, perhaps you could elucidate the benefits of patching the project? I would rather not fork the base project and keep all the mods in my subtheme. If it adds some automation for Compass, I have no problem with running compass compile path/to/my/project or compass watch path/to/my/projecton the terminal instead.

Yes, I am signed up for the Drupalcamp NJ on 2/4, looking forward to meeting up, I was a professional chef too!

My patch is quite out of date

Snugug's picture

My patch is quite out of date because they didn't take the time to merge it in when I originally built it, so if there are items like that beyond the Sass stuff (I believe the @import stuff is Sass @import of _base.scss), they're bygons of a older version of Omega

Drush Integration with Compass

decibel.places's picture

I think that's going to be a challenge, synchronizing any SASS files with regular CSS - and there is no backport tool to 'compile' CSS to SASS.

IMO your patch tries to do too much to be publicly useful. I think it's better to put together a guide, maybe we can powwow next Saturday

FWIW I have tried a shiny new Drush plugin for Compass and it seems to work just fine: http://drupal.org/project/drush_compass

but the docs are non-existent - like a lot of Drush tools, it's not a Drupal "module" - extract compass.drush.inc and the compass_actions folder into your drush/includes folder to install it

My patch adds a forked HTML5

Snugug's picture

My patch adds a forked HTML5 base theme w/Sass+Compass stuff because I didn't want to hack anymore of Omega to add a flag to Drush to put the Sass+Compass stuff in. Otherwise, it's the same thing you'er doing, plus the _base.scss partial w/imports (a best practice I'd advocate for either way).
As for Drush Compass, without looking at the code, it sounds like a Drush alias for compass watch (I will look further though).
The stylesheets you get with a base theme is blank to begin with, so all I'm doing with is importin the base partial to share variables, functions, and mixins across all of your stylesheets. As for not being able to convert between CSS and Sass, if you're using Sassy CSS syntax (.scss), all you need to do is rename your .css file .scss and you're good. There's also tools like this:
http://css2sass.heroku.com/
So yah, you can convert back from CSS to Sass. That being said, none of the CSS you get from a brand new starterkit from Omega have any CSS in them already, so this isn't an issue.

SASSY Module?

Sassy module is a whole other

Snugug's picture

Sassy module is a whole other beast all together and is an alternative to having Sass/Compass compiler running locally than best practices for Omega+Sass

So far Drush supports

decibel.places's picture

So far Drush supports Compass, but not Sassy.

Also, there is a good tutorial about setting up Compass and SASS with the Basic theme: http://thejibe.com/blog/11/1/getting-started-basic-sass-and-compass-drupal

So far Drush supports

decibel.places's picture

So far Drush supports Compass, but not Sassy.

Also, there is a good tutorial about setting up Compass and SASS with the Basic theme by Steve Krueger

http://thejibe.com/blog/11/1/getting-started-basic-sass-and-compass-drupal

It explains how to install the profile with Drush Make

Alternatively you can check out his example profile at git clone git@github.com:stevekrueger/basic_compass_profile.git

None of that is needed. Go

Snugug's picture

None of that is needed. Go into any theme, ANY theme, and in the root of the theme, jump into command line, and do
compass init
It'll create your config.rb file, a Sass and Stylesheets directory, and creates default CSS/Sass files for you (print, screen, and ie), and makes the config.rb file point where you want. If you'd prefer your CSS in the CSS directory, edit config.rb to point to CSS instead of Stylesheets. If you have CSS files you'd like turned into Sass files, move everything in css into sass and rename .scss. No need for drush make files or complicated git stuff, if you have Compass you can get started with minimal work (actually, from looking at those instructions, less work than the tutorial)

I do what snugug does

abelb's picture

this is pretty much just a repeat of what snugug said but in more detail

my process is:

Create my subtheme using omega tools and drush by typing this into command line

drush omega-subtheme "Long Theme Name"

Duplicate my css directory in the subtheme and rename it scss

cp -R css scss

Rename all the files in scss directory by replacing .css with .scss
(Anyone know a quick command line way to do this? I have been doing it manually bc that seems faster)

so that the file names are now:

global.scss       
[THEMENAME]-alpha-default.scss
[THEMENAME]-alpha-default-narrow.scss  
[THEMENAME]-alpha-default-normal.scss
[THEMENAME]-alpha-default-wide.scss

Initiate a compass project

compass init

Remove the stylesheets and sass directories that are created by compass init

rm -rf stylesheets sass

Create images and js directory

mkdir images js

Edit config.rb like this:

http_path = "/"
css_dir = "css"
sass_dir = "scss"
images_dir = "images"
javascripts_dir = "js"

then have compass watch for changes in your scss files

compass watch .

Hope this helps!

A quick command line way to rename css files to scss

esod's picture

How about this?

ls *css | awk '{print("mv "$1" "$1)}' | sed 's/css/scss/2' | sed 's/YOURTHEME/MYTHEME/2'
which gives you a preview of what will happen.

Then do
ls *css | awk '{print("mv "$1" "$1)}' | sed 's/css/scss/2' | sed 's/YOURTHEME/MYTHEME/2' | /bin/sh
which will change the file names.

keep it simple

likewhoa's picture

Parameter Expansion a.k.a variable substitution in bash is all you need, no need for pipes and stuff ;) Also never parse 'ls' http://mywiki.wooledge.org/BashGuide/Practices#Don.27t_Ever_Do_These

cd scss && for i in *.css; do mv -v ${i} ${i/css/scss};done

bending technology to fit businesses.

Great. I was hoping someone would comment

esod's picture

Great. I was hoping someone would comment on my use of pipes, awk and sed. To make both changes, do I have to run it twice? Assume we're in the scss directory

for i in *.css; do mv -v ${i} ${i/css/scss};done
for i in YOURTHEME*; do mv -v ${i} ${i/YOURTHEME/mytheme};done

Can you combine both mv's into one statement? Just curious

Edit: Sorry. The asterisks don't print with Filtered HTML. Needs Filtered HTML -- No Markdown. That's better.

Very nice!

Elijah Lynn's picture

Very nice Fernando!

Thanks for this (and the link) ~ Elijah

converting from css to scss/sass ?

roninsa's picture

I thought sass-convert handled that job. Am I wrong?

Usage: sass-convert [options] [INPUT] [OUTPUT]

Description:
Converts between CSS, Sass, and SCSS files.
E.g. converts from SCSS to Sass,
or converts from CSS to SCSS (adding appropriate nesting).

Options:
-F, --from FORMAT The format to convert from. Can be css, scss, sass, less, or sass2.
sass2 is the same as sass, but updates more old syntax to new.
By default, this is inferred from the input filename.
If there is none, defaults to css.
-T, --to FORMAT The format to convert to. Can be scss or sass.
By default, this is inferred from the output filename.
If there is none, defaults to sass.
-R, --recursive Convert all the files in a directory. Requires --from and --to.
-i, --in-place Convert a file to its own syntax.
This can be used to update some deprecated syntax.
--dasherize Convert underscores to dashes
--old Output the old-style ":prop val" property syntax.
Only meaningful when generating Sass.
-C, --no-cache Don't cache to sassc files.
-s, --stdin Read input from standard input instead of an input file
--trace Show a full traceback on error
-?, -h, --help Show this message
-v, --version Print version

Thanks abelb! I followed

murat_halici's picture

Thanks abelb! I followed your process and it worked perfectly for me.

We're all saying the same

decibel.places's picture

We're all saying the same thing in different ways.

Since I set up Compass before I installed the Drush plug-in I used compass init [path/to/theme] and renamed the stuff and edited config.rb

abelb gives a great step-by-step process - I wonder if I can run compass outside its directory on my local Windows dev - but drush compass init should work

@snugug - the Drush make reference was for installing the Basic theme with Compass rapidly

[I know, why do I use Windows blahblah - it's because I like to bug the Drush maintainers! Actually, until the large majority of people DON'T use Windows, I prefer to test everything on Windows first]

{note to the Drush team: I just got Drush working in Cygwin, but not sure that's an improvement over using it in the Windows terminal}

My OP asked how to optimize Omega + Compass

decibel.places's picture

My OP asked how to optimize Omega + Compass for the responsive CSS features of Omega.

Of course you can add Compass to any CSS files - but are there any configs that are essential and are specific to Omega?

Let's do a BoF at Drupalcamp

decibel.places's picture

Let's do a BoF at Drupalcamp NJ on 2/4

Proposed BoF: Compass/SASS/Omega AND a Doc Sprint for the Drush Compass plugin: http://drupal.org/node/1421726#comment-5555034

1:30PM - 2:30PM After lunch following the Omega session

I, personally, am not

Snugug's picture

I, personally, am not particularly interested that BoF as I'm not a fan of Omega and I don't see the purpose of Drush Compass when you've got Compass already installed. I'd be happy to have Sass+Compass Responsive Design and Getting Started with Sass+Compass BoFs thought.

As for answering your question, you called my best practices "[do too] much to be publicly useful" whereas what I was suggesting is not just best practices for Omega, but for a Sass powered theme in general; namely divide into partials and @import. This best practice I feel actually holds doubly true for Omega projects where you have multiple distinct CSS files you're kicking out and you're going to want to be able to share functions, mixins, variables, and extendable classes between each distinct file.

@Snugug When I said "IMO your

decibel.places's picture

@Snugug When I said "IMO your patch tries to do too much to be publicly useful" I meant it's generally not useful to the community to patch/hack another Project to fit your specific needs. In fact your patch may have been useful to you at one point, but it is out of date and unusable. How does that make it "best practices"?

I admire your goal of creating a Compass + SASS responsive theme that is less complex and more lightweight than Omega, but that doesn't answer best practices for Omega + Compass, it suggests an alternative.

The BoF served a useful purpose, I do not think the participants were even ready to go beyond learning how to install Compass, there were some in NYC who did not attend who suggested a BoF organized around best practices for Omega + Compass. And I was able to do my own doc sprint on the Drush Compass plugin.

Why use Drush with Compass? I think the best reason is that Drush knows the path to the Compass project by giving it the theme name. Also, the Compass commands are registered with Drush, which means you don't have to invoke compass directly from the command line, when you are already using Drush eg drush compile [my_theme]

I'm sorry that my Sass

Snugug's picture

I'm sorry that my Sass session isn't the one that you wanted, but there were other BoF sessions available to propose a specific Sass+Compass+Omega BoF. If you took a look at what that patch actually did, or listened or took in the 4 or 5 times I told you exactly what that patch was meant to do (which, by the way, I believe it still does) you'd have grasped that the best practices for Sass+Omega (because Compass is simply a framework, it's not the, for lack of a better term, language) are the same best practices I specifically pointed out and specifically mentioned to you in the BoF: build everything around a OO-esque partial structure with Variables, Mixins, Functions, and Silent Extends imported into a Base partial, and import that partial into each of your Omega SCSS files. There is nothing about Omega that makes it so special that there needs to be, or should be, best practices beyond that. My responsive framework is my personal response to my frustration with Omega, but was not the point of that BoF and was mentioned to demonstrate the power of Sass and the fact that there are alternatives to Omega, but that may have been lost on you as you were only interested in Omega (as a side note, showed my work to Joel (aka BangHouse) and he throughly enjoyed it, so even the person who gave the talk on Omega at the camp was open to seeing other solutions to the responsive problem).

As for Drush with Compass, I can understand the added convenience of having drush integration for on-server deploy-time compiling of Sass, but there's no reason to use it when developing locally because compass compile is very inefficient whereas cding into your theme's folder, running compass watch, and forgetting about it, is much much easier.

Sasson ships a PHamlP sass

tsi's picture

Sasson ships a PHamlP sass compiler built-in, I wonder if it would be possible to chain them both in a parent-sub-theme and enjoy both.
I'll try to find the time to see how possible this is and report back here.

I'm going to warn against

Snugug's picture

I'm going to warn against PHamlP. First and foremost, it doesn't have the full power of Compass behind it, it's quite out of date, and doesn't compile everything properly. The most up-to-date version of phamlp is currently being worked on by richthegeek, fubhy, and skottler and can be found here:
https://github.com/richthegeek/phamlp/
With that being said, even that doesn't fully work. Additionally, you'd be better off using Sassy than trying to frankenstein the two themes. Again, it's my opinion that if you're serious about using Sass+Compass in your theming, PHamlP isn't production ready and doesn't offer the full functionality as Sass+Compass proper.

I tend to disagree, the work

tsi's picture

I tend to disagree, the work done by the guys at Sassy delivers pretty much all of compass newest features and is working great AFAIK.
Compass is not included in the compiler you linked to but is in the module.
There are many cases where a php based compiler is a great benefit, even if not shipping the latest compass version.
Obviously, if all you want is Omega+Compass, using Sassy or a native compiler is far better then my little frankenstein experiment.

So I've come to the

Snugug's picture

So I've come to the conclusion that many people who talk to Compass talk about it in the same way as when they talk about Monty Python; they refer to the Sass-powered mixins/functions and not the other 2/3 of what makes Compass great (just as people generally know Monty Python as the guy who did the Holy Grail). What Sassy module provides is the Compass mixins, but it's missing the Compass plugin architecture and the non-Sass Compass stuff, like Compass Image Sprites. I know what the Sassy guys have done, been talking to them quite a bit, and what powers Sassy is that linked PHamlP compiler, which is a Sass compiler but doesn't mimic the full power of Compass.
Additinally, the PHamlP compiler is still playing catchup to Sass 3.1.x and fails for quite a few edge cases for quite a few of its various components, not to mention the fact that Sass 3.2 is just around the corner with a tonne of new features, many of them specifically targeted at responsive design, which you won't be able to use in the PHP Compiler. There are also plenty of performance issues to consider.
Basically, what I'm saying is, if all you want is to convert your CSS to an SCSS file and use variables, Sassy is probably fine for you, but if you're looking to start using deep partial structures and advanced Sass or Compass features, or want it to work 100% of your edge cases, there's absolutely no substitute for the Ruby gem, and quite honestly, it's not so hard use.

There's already a drush

decibel.places's picture

There's already a drush compass-compile [theme_name] command available through the Compass module http://drupal.org/project/compass

If that is the case, we probably don't need ANOTHER Compass integration since the most common command after installation would be "compass compile"

I wonder, has anybody measured the processing used by compass watch ?

The most common command is

Snugug's picture

The most common command is actually compass watch, if you're using compass compile whenever you want to update your CSS while you're working, you simply don't understand how to work with Sass+Compass. compass watch uses negligible system resources and is designed for active work. compass compile is for one-off compilation like if you need to recompile all of your CSS or if you're not committing CSS to your repo and need to do a one-off compile on server.
The Drush Compass module is a Drush wrapper for the Compass gem, and requires that gem and doesn't work without it. The other solutions proposed are about being able to compile Sass+Compass without the gem. There are plenty of reasons to have more than one way to compile Sass available, especially when one requires a dependency that many people don't have available to them on a server level and one that doesn't, so suggesting that we don't need another because we already have one is a bit short sighted, no?

@snugug I'm not interested in

decibel.places's picture

@snugug I'm not interested in fighting with anybody on this thread. I don't understand why you take each of my comments as personal affronts.

I said the Compass/SASS BoF served a good purpose for the people who attended, you, and me - what more do you want me to say?

I understand what compass watch does and in the comment to which you replied I asked if anybody actually had metrics for its resource use. If you're not actively editing your css, but you go in to make a change, then it seems that compass compile makes more sense for an instance.

If you want to contribute a patch to the Compass module that adds drush compass watch support I'm sure it would be welcome, but you don't want to use drush for compass anyway, so there's no need to comment on the decision of someone who has contributed a useful extension of drush to compile compass.

I would like this thread to continue as a discussion of Omega + Compass Best Practices - as in the title of the OP. You have made it clear you do not like Omega ("I'm not a fan of Omega"). You also should not assume that I did not listen "the 4 or 5 times I told you exactly what that patch was meant to do" - I just was not interested.

If you want to have an argument with someone else, please take it somewhere else.

‘Sir Drupal of Drupingtown, protector of all things Drupal-ly’

i have been following this

dasjo's picture

i have been following this discussion with interest, and it recently popped up as a notification.

the new omega 4.x is a fully SASS-driven base theme that follows most best practices snugug outlines above. check out http://drupal.org/node/1744592 for further information

if you want a deeper understanding of the differences of the site-builder oriented approach of omega 3.x and the tools that snugug prefers, check out the recent modules unraveled podcast on the aurora theme which also quickly mentions omega 3.x vs 4.x http://modulesunraveled.com/podcast/036-sam-richard-and-the-aurora-base-...

Subscribing...

webuxr@gmail.com's picture

...to this thread. I attended many SASS/Compass-related sessions and BOFs at DrupalCon Denver 2012 as well as this (now past) summer's DrupalCampWI (in Madison, WI). I'm looking forward to getting my hands dirty in Drupal/SASS/Compass theme code very soon and greatly appreciate the info and detail in this thread.

Thanks,
@webuxr

Ryan R. Smith
Columbus, WI USA
webuxr@gmail.com
@webuxr

Detailed instructions

Mark_L6n's picture

Here is what I did, and it is working well so far.
1) I looked at where the upcoming Omega v. 7.4 is placing compass/sass files, which is the root of your Omega subtheme. (So, the compass 'config.rb' is in the root, and there are /css and /sass subdirectories.)
cd /path/to/drupal/sites/all/themes/<theme name>
2) Create a bare compass setup matching the above description, using these command parameters:
compass create . --sass-dir=sass --bare
3) Copy your Omega CSS files from the /css subdirectory to the /sass subdirectory, and change the extensions to ".scss".

cp css/*.css sass
cd sass
for file in *.css; do mv "$file" "${file%.css}.scss"; done

4) Create a 'base partial' file that contains sass code that all files should inherit.
touch _base.scss
5) Edit global.scss, and import _base.scss by placing at the top:
@import "base";
Since all Omega files inherit global.css, _base.scss should thus be in all files.
6) Compile your sass files.
Return to the root directory of your theme, where config.rb is located. cd ..
Compile your theme with either:
compass compile --trace (without the --trace parameter, files with errors are not identified)
compass watch

Upon writing this, I figured I should add it to the documentation as well, which can be found at http://drupal.org/node/1808252 .

Hi All, I have been trying to

Red Sky Tom's picture

Hi All, I have been trying to use the instructions that Mark123 added to the Omega Theming Guide but have not been able to get the Watch or Compile to work. As I have tried it several different ways I
have seen several responses such as nothing to compile, if this is a new project you may have forgotten to include a directory path. Any help would be appreciated. Thanks.

Turns out I had to run the compass init command and all was good.

New York City

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week