Shopify Vision, Compass and Sass Combo
I have not used Vision lately in any of my Shopify development, but that has recently changed due to some new work habits.
Vision Direct link to this section
Currently hooked up to the latest version. Installed it in my /workspace. It runs using the command line, ruby vision.rb. I symlink a Shopify store into Vision's /themes directory allowing me to keep the actual code in my Shopify Github account on a per client basis. Every project I work on gets assigned to a directory in my Github account. When adding a new client or store, I simply do a git add <new_client_store>, and all my work is versioned and available to any of my computers, be it a laptop or desktop, home or away. Vision does not provide all the luxury of a real Shopify store, but for 80% or so of what I need, it is fine. I can quickly download a copy of a site once it is localhost:3232 approved, and then upload it to the client's account for live tests.
Shopify's Liquid templates have access to images in the /assets directory using the filter image_url. This convention is not pretty in that most people usually want to associate images during development with a location like /images. In fact, Compass, talked about further down has no plans to ever support keeping images in the same directory as the stylesheets, so setup of Compass will take some effort to work with Shopify. When referencing an image in a Shopify stylesheet, eg: background: transparent url('foo.png') 0 0 no-repeat !important; it is important to note that Compass will only ever produce a background: transparent url('/foo.png') 0 0 no-repeat !important; or a background: transparent url('../foo.png') 0 0 no-repeat !important; which means trouble when using Sass mixins that use images. There are not so many of those though, so for that aspect of development, the workaround is to use the mixin, examine the generated CSS, and then copy it back to the Sass where it can be converted to Sass and allow for the mixin to be removed. Clunky, but it actually rarely comes into play.
Compass Direct link to this section
Compass can be started with a number of options, included a stand-alone project, as well as one rendering one of the well known CSS frameworks like BlueprintCSS, 960gs, YUI, or Susy. I have had success with BlueprintCSS; 960gs has been somewhat harder to deal with, and I am sure YUI and Susy work well as there are few complaints about those options.
Once a stand-alone project is created, it can be added to Github for versioning the same as the Shopify site. I only add .gitignore entries for the .sass-cache files which you don't want versioned anyway. A line like .sass-cache/**/* added to .gitignore will not store any files or directories under the .sass-cache directory for example.
In the config.rb file, you can setup compass to work with relative files or not, and some other configurations. For the most part, I leave this at the defaults and check to make sure that any Sass files compile without errors using the command line compass -w. Keeping a terminal tab open with that alerts me to any errors in my Sass. Since compass is compiling Sass into CSS in the /stylesheets directory by default, it is important to link these into the Shopify project. In order to take advantage of Github, we cannot simply symlink the CSS files into the Shopify /assets directory. What I do, is tinker with the config.rb to tell compass to compile the Sass directly into the Shopify /assets directory. This works well, and means all the generated CSS and Sass code, are properly versioned and available to all my computers.
Sass Direct link to this section
Sass is a way of writing CSS using a higher level of code abstraction, practically like writing Ruby. Sass has excellent constructs like variables and the ability to declare a block of code by name for use as a mixin. For example, I can create a variable called !bg_color = #22ff44 and then refer to that in any further Sass files that descend from where that was declared. Sass file organization is up to the developer, and I choose to use a similar pattern to any Ruby views whereby I load in base classes as partials, and then put together all my Sass source in just one or two main files. That helps to keep the clutter at bay, and allows me the freedom to count on mixins and variables wherever and whenever I need them.
With respect to Shopify for example, I keep a partial file called _cart.sass handy for all the declarations specific to rendering a Shopping cart in the style required by the client. Any grid setup is stored in a partial called _grid.sass and likewise, basic text formatting is in a partial called _text.sass. A main Sass file would then just @include partials/text.sass to take advantage of the text setup for the site. A header example might be:
@import compass/utilities/text.sass
@import compass/utilities/links.sass
@import compass/utilities/lists.sass
@import compass/layout.sass
@import partials/base.sass
@import partials/cart.sass
@import text.sass
I used to work by tweaking Liquid templates and saving them, and then previewing the results. This was a terrible workflow that seriously diminished my capacity to work on Shopify sites with enthusiasm. Now with compass and the provided workflow advantages, developing Liquid, Javascript and integrating CSS is excellent and fun.
The latest Vim, Scribe and Textmate editors all allow code to be saved as soon as the code editing window loses focus. Compass has a watch command that compiles code as soon as changes are detected in a Sass file. Hence, the split second after moving focus from code editing to a browser, the code has been saved, compass notices this, and it compiles Sass to CSS, allowing reviews in the browser. Even further, Firefox (which I don't use much anymore) has a new watcher plugin called xrefresh which will auto-refresh the browser when it notices changes to provided files. This implies that as focus switches from code editing to the browser, you can always see the latest greatest code without doing much more than clicking the mouse once when done. The author of Sass, Nathan Weizenbaum has even provided the community with FireSass plugin for Firefox, allowing developers to see the exact line of Sass code responsible for CSS issues in the browser. I have not quite gotten that far to have tried that, but it is nice.