Much like the other CSS preprocessors, CSS Crush offers a range of features designed to make your life easier. Although these including functions that let you do things like manipulate the opacity of a colour value, or generate a data uri from a relative file path, I’m going to talk about some of the other features that I have experience with.
The first, and possibly most important of these, is vendor prefixing. There has been a lot of talk in recent months about non-webkit browsers adopting the -webkit prefix, which has been spurred on by the fact that, to be honest, vendor prefixes are a pain in the arse.
CSS Crush helps solve issues like this by automatically adding all relevant prefixes to the properties that support them, meaning that this:
div { background: #fff linear-gradient( left, red, white ) no-repeat; }
will automatically be converted into this:
div { background: #fff -webkit-linear-gradient( left, red, white ) no-repeat; background: #fff -moz-linear-gradient( left, red, white ) no-repeat; background: #fff -ms-linear-gradient( left, red, white ) no-repeat; background: #fff -o-linear-gradient( left, red, white ) no-repeat; background: #fff linear-gradient( left, red, white ) no-repeat; }
This is something that (so far as I’m aware) none of the other CSS preprocessors offer out of the box – although some creative use of mixins does offer something similar – but by using CSS Crush as a git submodule, you’ll always have access to the latest prefixes available.
Another helpful feature is that of being able to define and use variables. This allows for uniformity across all your stylesheets, meaning you can define variables such as:
@define { /* fonts */ title: "Times New Roman", Georgia, serif; body: Verdana, Arial, Helvetica, sans-serif; /* colours */ primary-rgb: 89,168,15; primary: rgb($(primary-rgb)); primary-text: #FFFFFF; secondary-rgb: 158,213,76; secondary: rgb($(secondary-rgb)); secondary-text: #FFFFFF; background-rgb: 240,242,221; background: rgb($(background-rgb)); background-text: #222222; }
then if you need to change a value at a later date, rather than having to do a find/replace, and risk missing some, you simply update the value is one place, and CSS Crush does the rest for you.
One of the things I found particularly useful was the ability to use @import
to manage different CSS files for responsive sites. A practical example of this would be something like:
@import url( "mobile.css" ); /* Mobile first */ @import url( "tablet.css" ) screen and (min-width: 768px); /* Tablet and higher */ @import url( "desktop.css" ) screen and (min-width: 992px); /* desktop and higher */
which not only imports the files directly into a single stylesheet, would also put the correct @media
tags around the imported code, and then performs minification on it all.
I’m actually using CSS Crush in my limeBase WordPress starter theme, so that could be a good way for you to get started, but if you wanted to create your own implementation, it couldn’t be simpler:
cssCrush
require_once 'cssCrush/CssCrush.php';
<link>
code with
<?php echo CssCrush::tag( TEMPLATEPATH.DIRECTORY_SEPARATOR.'style.css' ); ?>
Upon viewing your page, CSS Crush will create two new files: .csscrush and style.crush.css, and output the relevant <link>
code linking to the new style.crush.css file.
If, before further page views, the original style.css gets updated, CSS Crush will detect the change, and generate a new crushed file for you, otherwise it will continue to serve the cached file.
If you’re already happily using LESS or SASS, then I’m not sure there is much that CSS Crush can offer you. If, however, you’re more interested in a simple way of automatically adding vendor prefixes and performing minification on your CSS, then you can’t go far wrong with CSS Crush.
]]>But what’s the fun in that? So rather than do the sensible thing, and just upload the site, I instead chose to start fresh and build the site all over again from scratch.
Why? Well, there are a couple of reasons.
The first is that I had spent a good portion of the last week updating the limeBase theme on which the Lime Blast site was based. These updates included the latest versions of HTML5 Boilerplate, improved CSS structuring, improved media query responsiveness, and quite a lot of tweaks to the WordPress specific functionality.
The second is that the majority of time spend building the initial site was experimentation to see what was possible. I’m still new to WordPress, and while I’m much better at building for it than I was four months ago, I know I’ve still got a lot to learn. I’m also starting to understand HTML5 and CSS3 much better than I did before, but the downside of this was the labrynth of HTML and CSS that I had left behind. Pretty much the same thing happened with the Ghost Design site.
The way I see it, this site is my most important showcase – if I can’t show the world how good I am on my own site, then how good am I going to be working on someone else’s site?
]]>