Controlling color with Sass color functions

Sass comes with functions that can easily be applied to colors in your CSS properties. These functions, when used correctly, can be incredibly powerful. They take some of the sting out of choosing and manipulating colors. When used with variables, they can speed up development drastically.

Let’s start off with a creating variable for the color that we’re going to manipulate:

$base-color: #AD141E;

This is important for me for two ways:

1. It will allow color changes to be much more fluid and easy
2. Since I can’t be bothered to memorize hex values for each color, it helps me remember colors, eliminating the need to reference a photoshop mock every time I need a color.

Darken & Lighten

These two adjust the Lightness of the color’s HSL values. Sass will parse our hex color variable to hsl, then make the adjustments. You call them on the color with a percentage value between 0 and 100. I usually stay in the range of 3-20%.

darken( $base-color, 10% ) 
lighten( $base-color, 10% )

Saturate, & Desaturate

These will will adjust the Saturation of the colors HSL values, much like Darken and Lighten adjusted the Lightness. Again, you need to give a percentage value to saturate and desaturate. 

saturate( $base-color, 20% ) 
desaturate( $base-color, 20% )

Adjust-hue

This adjusts the hue value of HSL the same way all of the others do. Again, it takes a percentage value for the change.

adjust-hue( $base-color, 20% )

Adding Alpha Transparency

Using our hex color we can do a few things to get it to be a little transparent. We can call hsla, rgba, opacify, and transparentize. All of them accomplish the same thing, just in different ways. I stick to rgba as it comes most naturally to me which takes a color and a value from 0 to 1 for the alpha.

rgba( $base-color, .7 )

Tint & Shade

Our very own Phil LaPier has added to those base color functions. Both of these are accessible in Bourbon. They mix your color with a value of white (tint) and black (shade) and are similar to Darken and Lighten. They take the color and a % value for the change.

tint( $base-color, 10% )
shade( $base-color, 10% )

Getting more advanced

Once you have those down and you are looking for more control you can look into some more advanced color control with adjust-color, scale-color, change-color. These are for multiple changes in one color function. You can easily lighten the color and add some transparency all in one.

Some of the best places to use these color functions are for gradients, borders and shadows. When you need a slightly darker border and a slightly lighter inset shadow just adjust a color variable and let Sass do the rest for you. Buttons provide the perfect place to test out the functions. Check out some of the functions used on the thoughtbot buttons:

border: 1px solid darken($base-color, 20%);
text-shadow: 0 -1px 0 darken($base-color, 10%);
@include box-shadow(inset 0 1px 0 lighten($base-color, 20%));

Learn more about Sass, CSS and HTML during my Advanced HTML & CSS Workshop on December 8th and 9th.

Climbing back up the mountain

Today is the end of my fourth week as a Design Apprentice here at thoughtbot and it’s been pretty crazy so far. Before I got started I was excited to start filling in all the minor gaps in my knowledge. My first week was spent looking at documentation and demos for new tools and languages and running through tutorials. It was exciting stuff, and all seemed pretty straightforward. All I had to do was jump onto a project and I’d be contributing in no time. I was confident that I could go from Photoshop jockey to front-end guru in a matter of days.

Then I started writing code that was actually intended for release to a client’s product. The panic set in pretty quickly. The “minor gaps” were quickly revealed to be “huge gaping chasms of inexperience.” I had worked with HTML and CSS plenty of times before, but the pace was leisurely, the deadlines few and far between, the complexity very low. Now I would go from discussing a new feature in the morning to the expectation of having it complete by lunch. 

This was a pretty big wake up call for me. At my previous job I was considered the design team’s authoritative source of development knowledge. Questions came to me first and my answers were accepted as absolute truth. On the rare occasion that the designers were expected to write code (the horror!) the task would be assigned to me. I was pretty comfortable on the top of my mountain, so to be body-slammed off of it so effortlessly was a serious bruise to my ego.

It’s been two more weeks since then. Things have gotten better. I’m not blazing fast, and I don’t always do things perfectly the first time, but my confidence is back (tempered with a good dose of humility). I’ve learned a few important things about tools and process during this time. If you’re an apprentice, or a designer that’s new to the expectation of delivering front-end code, hopefully this will be of some benefit to you.

Vim

Vim will look clunky to you if you come from a background similar to mine. A few years of Dreamweaver, the eventual move to a better piece of software like Coda or Espresso, and then this? You want me to work in a text-based interface with a complete lack of familiar keyboard commands? It will seem insane, but there are some huge benefits and you should stick it out. Once you start to become familiar with it, the potential for amazing speed will become apparent. The hard part is making your hands learn all the new movements and commands. Once your muscle memory starts to kick in things will become faster. I wouldn’t say I’m great with Vim yet, but I’m at least as fast as I was in Espresso, and working hard to improve.

It’s important to note that I work in an office of Vim users. It makes sense for me to use it and I have a great support and learning network. If everyone in your office uses TextMate, or Espresso, or something else, you should probably use that too so that everyone’s on the same page.

Sass

Sass is amazing. If you know anything about CSS, just reading their documentation ought to get your blood rushing. My favorite part is the ability to nest selectors, which makes it incredibly easy to target elements correctly. Add in variables and mixins and you’ve got a very powerful extension to CSS.

If you want a set of great mixins, allow me to humbly suggest thoughtbot’s Bourbon.

Ruby on Rails

This was the hardest part for me to adapt to. I’m used to working on static sites, so finding where everything was located in the Rails framework was intimidating at first. Luckily, I get to attend workshops (for free, it’s a great perk) at thoughtbot and our Intro to Ruby on Rails workshop was incredibly helpful in teaching me to navigate an application.

Code/Design Reviews

Have someone else look at your work. A lot. More experienced people will be able to point out what you’re doing wrong and what you could be doing better. It’s important to correct these behaviors before they become habits. Don’t be timid about offering your own feedback either. Design is often a collaborative process, and talking about your ideas usually results in better work.

But what if you’re the only designer at your job, or a freelancer? Start by posting your work on Twitter or Facebook and asking other designers for some feedback. I’ve found that many people are willing to take the time to send you a short review. Dribbble can be another great place to get input.

Google

You can almost always find answers to your problems by searching for them online. The odds of encountering an issue that somebody else hasn’t run into and solved before are incredibly low. And in our industry we’re lucky to have a lot of knowledgeable peers who enjoy writing about their solutions. 

You will improve

Most importantly, try to stay positive. You’ll have ups and downs, successes and failures, but as long as you’re moving forward you’ll be ok. I’m lucky to have people at thoughtbot who are committed to making me a better designer and a better front-end developer. Try to find people like that for yourself, either in your workplace or online. We’ve got a great community full of intelligent, helpful people. Take advantage of it.

Danger, Danger: High Voltage! Use Rails 3.1 for Static Sites

I’m a big fan of Jekyll, but boy do I love SCSS and CoffeeScript. I recently set out to create a static site using Rails 3.1, to take advantage of the lovely Sprockets integration. There are alternatives (like Middleman, and Octopress) but I wanted to use Rails itself instead.

Our homebrewed high_voltage gem allows for static pages, so I wanted to use that to hook up my little static site that will eventually be dynamic. Here’s the process I used.

Fire in the disco

Generate the app:

gem install bundler --pre
gem install rails --no-ri --no-rdoc
rails new danger_danger

Swap out your Gemfile with:

source 'http://rubygems.org'

gem 'rails', '3.1.1'

gem 'flutie'
gem 'high_voltage'
gem 'jquery-rails'
gem 'redcarpet'

gem 'sass-rails',   '~> 3.1.4'
gem 'coffee-rails', '~> 3.1.1'
gem 'uglifier', '>= 1.0.3'

Rebundle and let’s remove some other cruft:

bundle
rm config/database.yml public/index.html
rm -rf app/{helpers,mailers,models} test/ doc/ db/

Rails includes all of the subframeworks (ActiveRecord, ActionMailer, etc) by default. We don’t need those, so at the top of config/application.rb, you can replace require 'rails/all' with:

require 'rails'
require 'action_controller/railtie'

There’s references to ActionMailer in the various config/environments/ files…it’s best to just comment them for now since we may want it back later.

# comment out this in config/environments/development.rb
config.action_mailer.raise_delivery_errors = false

# comment out this in config/environments/test.rb
config.action_mailer.delivery_method = :test

I want to write templates in Markdown, so we’ll need to tell Rails to handle that. Drop this into config/initializers/redcarpet.rb, thanks to this gist. Hopefully in future versions of Rails this will be easier if Tilt is integrated into ActionView.

class ActionView::Template
  class Redcarpet < Handler
    include Handlers::Compilable

    def compile template
      ::Redcarpet.new(template.source).to_html.inspect
    end
  end

  register_template_handler :md, Redcarpet
end

Let’s start with just a homepage. Change vim to your editor of choice!

mkdir app/views/pages
vim app/views/pages/home.html.md

In that file, you can write Markdown as normal:

# Welcome to the home page!

This should say something important.

In your config/routes.rb, point to it:

root :to => 'high_voltage/pages#show', :id => 'home'

Fire up your server, and you should be able to see your home page!

rails server

Awesome! You should now see your home page rendered in markdown. What’s even better is that you can include CoffeeScript and SCSS like you normally would with a Rails app. The Rails Guide on the asset pipeline is a great read for this if you haven’t seen it.

For more static pages, you just need to drop different markdown files into app/views/pages, and high_voltage will render them as normal at /pages/:yourpage, like so:

echo "Fire in the" > app/views/pages/disco.html.md
open http://localhost:3000/pages/disco

I’ve put a repo up on GitHub if you want to check out a working version of this.

Don’t you want to know how we keep starting fires?

Ok sure, this is a lot of setup for a static site. The idea is that eventually I want to be using Rails anyway, so why not just use it to start? If I end up creating another one of these, I may end up making a Rails Template, which makes the legwork of setting this kind of Rails app up way easier. For now, this works great, and I hope it helps you out too!

Getting all your ducks in a column

While redesigning the thoughtbot site, I gave myself a challenge: create an easily editable and maintainable baseline grid. I figured that there had to be an easier way to do this with Sass than with plain old CSS. 

I started off going to the wonderful modulargrid.org to create my grid. I grabbed the png and threw it into the background so I could be certain everything is aligning perfectly. Then I created 3 variables based on the grid; one for the column unit width, the gutter width and line-height. This made things conceptually easier for me instead of trying to balance numbers.

$line-height: 20px; /*line-height for the site*/
$unit: 60px; /*column size*/
$gutter: 25px; /*gutter size*/

Getting some layout

Almost as soon as I had started, Sass 3.1 came out touting functions and in the change log examples I found this gem:

@function grid-width($n) {
  @return $n * $unit + ($n - 1) * $gutter;
}

This function calculates that width of the column by giving it the number of units you want it to span. Now all I needed to do is drop in grid-width() for any width and it will conform to the column sizes in my grid. For example, I wanted the grid to be 12 units wide, so on the wrapper for the site I put:

width: grid-width(12);

Of course this isn’t always perfect, the box model adds padding and the border to the width of the box and it breaks the grid. Bah. But Sass is wonderful and can do simple math and can apply that even to functions. So on a box that spans 4 columns but has 20px of padding on both sides I can subtract the padding to get the correct width of the column.

padding: 20px;
width: grid-width(4)-(20px*2);

Dealing with the baseline

The background image that I had for the grid also gave me guidelines for where the baseline should fall. Then all vertical spacing for the design uses the line-height variable. Everything from padding to the margin to the height of the images can all be declared with the line-height variable and some multiplication. 

height: $line-height*6;
margin-top: $line-height*3;
padding: $line-height;

Again, I ran into scenarios with the box model where I didn’t want to use the whole line-height. These changes and exceptions were easy to accommodate with a little math just like the grid-width().

padding: ($line-height*2)-(1) 0; /*Account for 1px border*/

Throughout all the Sass I’ve successfully avoided doing any real calculations and feed Sass a bunch of math problems. Updating and maintaining the layout is easy, anyone who goes into the Sass won’t have to figure out what the width of a 3 columns would be. It also has the ability to be easily adaptable to having a fluid layout.

Bonus

The grid-width function has also been incorporated into Bourbon, our default set of mix-ins and functions. Use variables $gw-column and $gw-gutter and then you are all set. No need to set up the function. 

If you’d like to get some more Sass and advanced HTML & CSS tricks come to my workshop on Sept. 26th & 27th.

Introducing Bourbon Sass Mixins

Bourbon is a library, and also a Ruby Gem, of sass mixins that are designed to be written as vanilla as possible—meaning, whenever possible, they should not stray from the original CSS syntax. The mixins contain vendor specific prefixes on all CSS3 properties for support amongst modern browsers. The prefixes also ensure graceful degradation for older browsers that support only CSS3 prefixed properties.

Examples

# Bourbon syntax
@include box-shadow(0 2px 2px 0 rgba(0, 0, 0, 0.3));

# Output
-webkit-box-shadow: 0 2px 2px 0 rgba(0,0,0,0.3);
   -moz-box-shadow: 0 2px 2px 0 rgba(0,0,0,0.3);
    -ms-box-shadow: 0 2px 2px 0 rgba(0,0,0,0.3);
     -o-box-shadow: 0 2px 2px 0 rgba(0,0,0,0.3);
        box-shadow: 0 2px 2px 0 rgba(0,0,0,0.3);


# Bourbon syntax
@include box(horizontal, start, stretch);

# Output
        display: -webkit-box;
        display:    -moz-box;
        display:         box;
-webkit-box-orient: horizontal;
   -moz-box-orient: horizontal;
        box-orient: horizontal;
-webkit-box-pack: start;
   -moz-box-pack: start;
        box-pack: start;
-webkit-box-align: stretch;
   -moz-box-align: stretch;
        box-align: stretch;


# Bourbon syntax
@include animation-basic( (fadein, slideup), (2.0s, 1.0s), ease-in );

# Output
-webkit-animation-name: fadein, slideup;
   -moz-animation-name: fadein, slideup;
        animation-name: fadein, slideup;
-webkit-animation-duration: 2s, 1s;
   -moz-animation-duration: 2s, 1s;
        animation-duration: 2s, 1s;
-webkit-animation-timing-function: ease-in;
   -moz-animation-timing-function: ease-in;
        animation-timing-function: ease-in;

The tools

Bourbon contains a number of commonly used CSS3 properties, such as linear-gradient and border-radius. We’ve also built in support for the latest CSS3 animation and transition properties. Bourbon has flex-box and a number of other CSS3 properties covered.

Our functions are pretty useful too. Like the golden-ratio function which can be used for calculating heading font-sizes based on the golden ratio. Modularscale.com is an excellent web-based tool for calculating font-sizes.

How Bourbon was born

The designers at thoughtbot are huge fans of Sass. We’ve been using sass on all our projects for over a year now. Previously we had two or three sass mixins that we used across all our projects (primarily linear-gradient and border-radius). As we began writing more CSS3 which included vendor specific prefixes, our mixin library eventually grew larger. With multiple designers working on various apps and client projects, it became increasingly difficult to distribute and update our small set of mixins across all these environments. Before the library was formalized on git, versioning was difficult too—if I made improvements to a mixin, there was no efficient way to inform the other designers about the changes. Eventually the library grew large enough that it became clear that the best way to manage the mixins was through git, and distribute them with a gem. And thus Bourbon was born.

Why vanilla syntax?

Part of our core philosophy when creating Bourbon was to keep the mixins as close to normal CSS as possible. There is already learning required with all the new CSS3 properties, and let us not forget Sass syntax. We thought the best way to learn proper CSS3 was to keep the mixins as syntactically similar to CSS3 as possible.

Why not compass?

Compass is a great toolset for anyone using sass. We initially solved our own problems using the toolset we created—Bourbon. Building our own tools allows us to have finer control of our mixins, functions and addons, which we are particularly keen on. We didn’t set out to build a public library of sass mixins, but over time it became increasingly difficult to not share these tools for other to use. Bourbon has been, and continues to be, a toolset for which we have been learning from. By creating our own set of mixins, we are pushed to continuously think of innovative ways to improve our front-end development knowledge and resources.

What’s with the name?

Bourbon Vanilla is the most commonly used variety of vanilla extract—I also have a nose for the sweet vanilla notes in a fine bourbon whiskey ;).

We look forward to building out Bourbon to support even more CSS3 properties, as well as building useful addons and functions for providing designers and developers with an even greater set of development tools. Keep an eye out for more blog posts covering Bourbon.

If your palate can handle the sophisticated flavors, try a glass of our fine Bourbon.