Tag Archives: CSS

Organising IE specific SASS stylesheets

So last week I spoke about using SASS to create IE specific stylesheets. This is a good idea if you’re using SASS (Or any CSS pre-compiler really) and, like me, you prefer to keep your dirty IE fixes away from proper styling.

At the end of that I said I’d talk about how we’re organising these. Unfortunately, thinking about it, this isn’t too exciting. Premature promises, eh? So here it is in brief:

Every version of IE has its own bundle. There is also a bundle for all IEs. The All IE bundle includes the regular CSS bundle and anything we want applied to all versions. Then, each specific IE version bundle includes the All IE bundle and anything specific to that version.

Fixes are (as far as practical) kept in separate, small files with names describing what they’re for and which versions they should apply to.

This means, for example, that we have a single file for applying a polyfill for gradients which is then imported into the relevant IE version bundles.

That’s about it really. Have a good week.

Advertisements
Tagged , , , ,

IE Specific Stylesheets with SASS

Recently I’ve been concerning myself with fixing IE. Well obviously not fixing it, but navigating around its idiosyncrasies. We’re trying to develop the site for modern browsers with fallbacks and fixes appended for old ones (IE) in such a way that when they go obsolete we can whip them out quickly and easily. In styling terms this means we need a way to apply rules to elements in IE only, or even in some cases to specific versions of IE only.

Keeping styling rules separate seems to be somewhat contentious. Paul Irish for whom I have great respect prefers the IE specific rules to be next to the other rules styling an element. His complaint is that it can be hard to identify which stylesheet a rule is coming from if it’s from an external one. I see his point but still have a personal preference for keeping them separate as it means the main CSS is cleaner and I’ve never really had a problem with identifying the source stylesheet for anything.

In previous projects we’ve adopted one of two approaches. We’ve used JavaScript to detect if it’s IE and add a class to the body tag and then included these IE specific rules with the proper CSS. I dislike this approach because it keeps the IE specific rules in with the main CSS. More significantly, it introduces a hard JavaScript dependency. I’m all for ignoring IE users without JavaScript on the grounds that they’re clearly being willfully awkward, but apparently that’s not allowed.

We’ve also used IE Specific stylesheets. This approach uses Conditional statements in the html. These are ignored by real browsers but picked up by IE, meaning you can add an extra stylesheet to IE full of fixes. I like this because it keeps the IE fixes separate and only punishes IE users with the extra (admittedly tiny) download size and it doesn’t depend on JavaScript. On the down side however, this adds an extra http request to IE uses.

Paul Irish has discussed this. In brief, his solution was to use IE Conditional comments to add classes to the html tag. This bypasses the need for JavaScript but lets you put your styling in amongst your code proper. This is an elegant solution and I like it, but as I’ve said I don’t want my IE styling rules in my main CSS. Instead we’re taking advantage of SASS to do something a little different.

Because SASS’ stylesheet import copies the whole imported sheet it does not create extra http requests. This means that if we create a special stylesheet for each version of IE and import our regular stylesheet bundle into it, we can have IE specific rules in a separate stylesheet for development but bundled up for the user meaning it only needs one http request. Then, using the same conditional comments we were using for import an extra stylesheet we can import the single bundle for each version of IE. The only change needed to these is the addition of a not IE selector to import the regular bundle

<!--[if !IE]><!-->
<link rel="stylesheet" href="/css/desktop/bundle.css"/>
<!--<![endif]-->

<!--[if IE 7]>
<link rel="stylesheet" href="/css/desktop/ie/ie7-bundle.css"/>
<![endif]-->
<!--[if IE 8]>
<link rel="stylesheet" href="/css/desktop/ie/ie8-bundle.css"/>
<![endif]-->
<!--[if IE 9]>
<link rel="stylesheet" href="/css/desktop/ie/ie9-bundle.css"/>
<![endif]-->
<!--[if IE 10]>
<link rel="stylesheet" href="/css/desktop/ie/ie10-bundle.css"/>
<![endif]-->

Do take note of the extra <!--> in the not IE selector, this means that the stylesheet is still loaded in in not-IE browsers while the others are ignored as html comments.

Now we’re not actually keeping all the IE fixes in a file each for every version of IE. But I won’t talk about how we’re doing it now, that’ll be something to talk about next time.

Tagged , , , ,

Setting up Compass with or without Grunt

Setting up Compass wasn’t massively complex, but did involve a bit of thought. Mostly this thought was to get around the limitations imposed by my specific situation but I’ll recount them for anyone in a similar one.

To install SASS, and therefore Compass, you first need Ruby to be installed. Because the main language we use at work is Java I opted to use JRuby in case it became useful at some point in the future. Other people on the team just used Ruby and had no problems though.

Get Ruby

JRuby, however, did provide a problem. There is apparently a bug in it that means that when it is running in Ruby 1.9 mode, SASS doesn’t work. This is a problem with JRuby becuase Ruby 1.9 proper is fine. The solution was simple though, I just had to change JRuby to run in 1.8 mode. This was done by adding a new Environment Variable called JRUBY_OPTS with a value --1.8.

Bypass your proxy

With Ruby working, the next thing to do is to install SASS or Compass. Compass and SASS are both gems, which are packages of Ruby code which can be easily transported and installed.

Unfortunately, it requires some wrangling to install gems when you are behind a proxy like I am at work. Fortunately, it’s not that hard. I set an environment variable called http_proxy with the value proxy.myworkproxy.co.uk:myworkproxyport.

Install Compass

To install SASS go to the command line and type gem install sass. But also, don’t do that, because if you install Compass it brings SASS with it and Compass is better.

To install Compass, go to the command line and type gem update --system and then gem install compass. And with that, Compass is installed on your local machine.

You can then use the Compass watch command to start polling for changes to your SASS/SCSS files. There is a SASS watch command too, but if you really want to avoid compass I’m sure you’re capable of finding it yourself. You contrary kraken.

Set up Compass in a project without Grunt

With Compass installed on the machine, you still need to add it to any given project. The Compass website provides a tool for creating config options. You may find that useful, I found it more confusing than it needed to be. If you already have a project set up then use the command line to navigate to it and type compass install compass. If you are starting a new project using compass then go to the folder you want it with the command line and type compass create myProject. Probably not myProject though, call it whatever you want. Do that somewhere and take a look at what you get is my advice, after that the tool provided by Compass should become useful for guiding you through the set up. I’m not going to because I have barely used this method, preferring instead to use Grunt.

Set up Compass in a Grunt project

Let’s assume you have a Grunt project already set up. Installing Compass to your project is easy.

First, get Ruby, bypass any proxy you may need to and install Compass to your machine as described above. Then, in the command line navigate to the folder holding your Gruntfile and type npm install grunt-compass.

This installs grunt-compass, the grunt plugin for compass to your project. Npm stands for Node Package Module and is a similar concept to a Ruby Gem.

Then you need to add this line to your gruntfile
grunt.loadNpmTasks('grunt-compass');
This registers the newly installed node module to Grunt in your project. Compass is now installed to your Grunt project, but not doing anything. Let’s configure it.
Add something like this to your Grunt initConfig. I won’t go into massive detail about the configuration because the grunt-compass documentation is already good.

 compass: {
    src: 'sass',
    dest: 'css',
    forcecompile: true
    },

The three options we’ve set are src, which tells it where to find your SASS files and dest, which tells it where to put your css files. forcecompile is also pretty important for our purposes because we’re about to add Compass to the Grunt watch, which means we need to force it to compile and replace older versions of the css. There are many more options available but I’m not going to mess with them now.

To add compass to your watch in grunt go to the watch section in your Grunt initConfig, it should already be there and add path/to/scss/**/*.scss to the files and compass to the tasks. Like so

    watch: {
      files: 'scss/**/*.js ',
      tasks: 'compass lint'
    },

There we have it though, setting up Compass.

Tagged , , , ,

Improving SASS with Compass

On Sunday I talked about why CSS is dumb and SASS is awesome, today I’m going to talk about how SASS is dumb and Compass is awesome. That’s not entirely fair, Compass relies on SASS, but it is the thing that really unlocks the potential of SASS with limited effort on your own part.

What is Compass for?

SASS is a language for writing Stylesheets, Compass is a framework built in SASS. This means that while SASS enables all sorts of cleverness, Compass applies that cleverness in ways that should be useful to almost anyone.

Why use Compass?

The two features of compass which are most exciting me right now are CSS3 helpers and Spriting. It does other things too – helpers to automatically adjust values, text styling, a reset file and layout support. These all sound marvellous but I’ve not touched the things yet. Let’s talk about the bits I have played with.

CSS3 helpers are a collection of mixins to help with CSS3. I’m sure this is a surprise to no one. What it means is, rather than writing out multiple lines of browser specific code for any given CSS3 feature, instead you just use one of Compass’ mixins to produce the same result. This resolves the annoyance of writing the same command more than once and also means that when if the browsers settle down and we stop needing the browser specific versions, we can change it in one place and update our commands everywhere.

There’s no reason you couldn’t write this out yourself in SASS, but Compass has had more time put into each mixin than you’re likely to want to and is a hell of a lot easier.

Spiriting, on the other hand, can’t be done without something extra. There are other libraries that do this for you, but the fact that its integrated with your Stylesheets is nice. But what the hell do I mean when I say spriting?

Well, with Compass you can use a diverse set of individual images which can be automatically turned into a single sprite image, with the positioning worked out automatically. Gone are the days of remembering the offset necessary to get a specific icon, instead you just use the icon image and let Compass turn it into a Sprite. I believe the phrase is having your cake and eating it too.

So that’s Compass, a way to really leverage using SASS without re-inventing the wheel or straining yourself in any significant capacity.

Next week, how to set up SASS and Compass.

Tagged , , , , ,

Improving CSS with SASS

Syntactically Awesome Style Sheets is a CSS Pre-processing language. It is not the only one, but it is the one we’ve chosen to use. The other major players in the CSS-Pre-Processor-Fight are LESS and Stylus. Our decision making process between these three and countless others that exist but have less press was not massively sophisticated. We looked at some articles which generally seemed to prefer SASS. That said, they all had good things to say about the others just claimed SASS had a slight edge.

Because writing CSS-Pre-Processor is going to get old fast, I’m going to stop talking about them in general and instead talk just about SASS. Everything about why to use SASS is generally applicable to them all.

What is SASS for?

CSS is stupid. As your selectors start having to get more specific, so you start writing the same thing over and over. If you need to use similar bits of styling with minor differences multiple times (I’m looking at you border-radius), then you’re writing it out again. If you want to keep a consistent colour palette you’ve got to remember what colours you’re using and if you’re changing them, you’ve got to change them all manually. These are hallmarks of a stupid language.

But it doesn’t have to be. What if we stopped writing CSS and instead let it become an output, like what happend to Machine Code back in the mists of time? This sounds radical, but it isn’t really. We’re already pre-processing our CSS before serving it to a client by minifying it, why not expand that process to allow us to write CSS intelligently?

So why use SASS?

Enter SASS. It is a cleverer langauge than CSS which compiles down into valid CSS. This means that using SASS doesn’t create any sort of compatability issue or overhead for your user, just adds some weight to your compile step. But what do you get for this added weight beyond vague claims of cleverness?

As ever, the SASS homepage provides a better summary than I will here, and indeed a better in depth discussion too. But here’s my own summary.

How to use SASS

Nesting

Ever written anything like this?

.aClass { 
	width: 100px
}
.aClass .anotherClass { 
	height: 200px
}

With SASS you can write it like this

.aClass { 
	width: 100px
	.anotherClass {
		height: 200px;
	}
}

This gives you a syntax which better represents the relationship between selectors and involves writing .aClass one less time. Result!

Selector Inheritance

How abou this? Ever needed this?

.aClass, .extendedClass {
	width: 100px;
	border: solid 1px red;
}
.aClass.bigText, .extendedClass.bigText {
	font-size: 2em;
}
.extendedClass {
	border-width: 3px;
}

SASS let’s you extend classes like this

.aClass {
	width: 100px
	border: solid 1px red;
}
.aClass.bigText {
	font-size: 2em;
}
.extendedClass {
	@extend .aClass;
	border-width: 3px;
}

Again, less writing and a better representation of the relationship between classes. But what about the .aClass.bigText selector? That meant writing .aClass twice and writing things twice is everything I stand against. We can’t nest it as before because that would produce .aClass .bigText rahter than .aClass.bigText, but have no fear!

.aClass {
	width: 100px;
	border: solid 1px red;
	&.bigText {
		font-size: 2em;
	}
}

The & represents the original selector and lets us nest the .bigText inside .aClass.

Variables

Let’s say you wanted to have a standard version of blue used across your whole site. Rather than remembering its hex code, you can store it in a variable

$blue: #3bbfce;
.aClass {
	background: $blue;
}

Mixins

Mixins provide parameterizable reusable sections of code. For example, whenever we want a broder radius we need something like this

.aClass {
	-webkit-border-radius: 5px;
	-moz-border-radius: 5px;
	border-radius: 5px;
}

.anotherClass {
	-webkit-border-radius: 2px;
	-moz-border-radius: 2px;
	border-radius: 2px;
}

With SASS, we can boil it down to this


@mixin border-radius($radius) {
	-webkit-border-radius: $radius;
	-moz-border-radius: $radius;
	border-radius: $radius;
}

.aClass {
	@include border-radius(5px);
}
.anotherClass {
	@include border-raidus(2px);
}

I should also include a note clarifying the difference between SASS, SCSS, and SASS.

SASS is a CSS Pre-processing language. Originally its syntax was modelled on haml and was very terse, keeping keystrokes to a minimum. This was popular with many people but also put others off. I am in the second camp, I want write my CSS using CSS syntax with logical extensions.

To cater to the likes of me a new syntax was developed, Sassy CSS or SCSS. SCSS is a syntax for SASS which looks a lot like CSS and is how I choose to write my SASS. However they didn’t deprecate the old syntax which still exists and is called SASS. So, SASS is a pre-processing language, SCSS is a syntax for SASS, and SASS is also a syntax for SASS. Clear as mud? Good.

I will almost never mean SASS the syntax when I talk about it, because I don’t use it. I also have a habit of using SASS and SCSS interchangeably. Sorry.

And that’s your whistlestop tour of SASS. It makes writing and maintaining your CSS easier without creating problems for the client.

Tagged , , , , ,
Advertisements