In case you missed this post, I have started using the Compass and Sass CSS frameworks on a new project. I wanted to share a little magical Sass action that I came across while working on a new site.
A Browser-wide Opacity Mixin
Probably the most outstanding feature of Sass is the ability to create “mixins.” A mixin is nothing more than a small block of styling code that you create once – and then simply call out later (similar to calling a function in javascript). Sass’ Mixin’s can preform many actions that you would expect from a normal programming language such as accepting parameters, variables, and even preforming those ‘hard’ maths. I happened to create a simple mixin that uses all three of these features to render a desired opacity across all browsers (hat-tip:
Chris Coyier for the cross-browser opacity code).
As Chris pointed out, each browser accepts opacity styles in a slightly different way. (I know, you’re shocked…shocked!!) With regular CSS – you have two options:
1) Create a .transparent_class and apply this to all html elements you wish to apply the opacity shift to. While this works, it is somewhat undesirable – because you are adding specific style information into your markup. In effect, to add/remove a design aspect you would need to alter your markup – when the ultimate goal is to separate the markup/structure from the style/design.
2) Apply all 4 opacity style rules to each individual element you select through CSS. This is technically better, but obviously a pain in the butt, and can really muck up your CSS. Unless you use a code editor such as Textmate which supports code snippets – you will be failing to keep your code DRY (Don’t Repeat Yourself).
As a side note, don’t feel bad if you happen to use either of these methods. Coding ideals are just that: ideals. Coding ideals are often nice (though lofty) goals that will spare you headaches over time. However, in my experience – the difficulty and time involved coding rises exponentially the more rigidly you attempt to adhere to a coding ideal.
But there is good news. The Sass Framework can greatly help in this department.
Here is the Sass Mixin I created for opacity:
Declaring the Mixin:
Explanation:
The first line is the mixin name that you will refer to later, followed by the actual opacity parameter variable.
The next several lines are each of the 4 browser opacity style rule variations. Each one refers to the !opacity variable that you will pass the mixin. Because Internet Explorer takes the parameter in a different format (e.g. IE: 50, Others: 0.5 ) – I use a little simple math to calculate the value. Zing!
(By the way – the strange format is just one of the ways to write Sass code. You can read more about that on the
Sass website.)
Calling the Mixin:
Explanation:
To call the mixin, all I have to do is add +opacity rule and pass the actual value I want inside the parentheses. (note: the +shadow line is calling another mixin I created that accepts many parameters)
Sass code is then compiled to CSS (in this case, automatically by compass anytime I save a change) and adds…
filter: alpha(opacity= !opacity * 100); -moz-opacity: 0.7; -khtml-opacity: 0.7; opacity: 0.7;
…to the class .book-shadow, or anyplace else I call +opacity.
With Sass – it allows me to have the best of methods 1 and 2, which I mentioned above. I don’t have to add design specific classes into my markup, as in method #1. Also – if I want a different opacity value, I don’t have to create a separate .transparency_lighter_class, for example. I simply pass a different value. Sass also cuts out the suck of method #2, because I only have to repeat the one rule +opacity(howMuch) to any element.
Now – you do still end up with repetitive rules in your CSS files anytime you call +opacity – but you don’t have to deal with them. Plus, Sass can be told to compile your CSS into a variety of modes, from expanded – to compact, which will trim down the size of your CSS, if you want it to.
Mixins are just one of the many great features of Sass. So far, my workflow has been greatly enhanced, and that’s a Win in my book.
Happy coding.
-Adc
Posted via email from Andrew Colclough
Will Facebook users feel more comfortable trusting their credit card information with the company instead of social game developers and other payment providers when they go to buy virtual goods? If the answer is yes, we may see a new surge in revenue for developers, and for Facebook.
