Posts Tagged ‘sass’

Recently I launched a new website, Rena Men. It is deployed onto the Heroku platform and does quite a bit of cool stuff, so I thought I would document what I have done here.

Code

It is implemented in PHP, using the Rauma framework. Rauma is a project I developed for Learn Finnish and subsequently open-sourced.

Rena Men is built in several modules. There is a website, a content management system (CMS) and an image server. Because they use common functionality like the entity classes, there is also a shared library which is brought in as a Composer dependency.

The website itself is fairly straight forward. Beyond the PHP, there is only the CSS, pre-processed with SASS, and a tiny amount of JavaScript loaded in with require. The CMS is a bit more complicated, using Babel to transpile the ES6 JavaScript, and styled up with Bootstrap.

Deployment

Each module is deployed onto the Heroku platform. This makes it really easy to do as I can roll out an update just using git push. The code itself is stored in a series of private repos on BitBucket, and the Heroku build process fetches them from there.

In the case of the CMS, it also uses the Node build pack to run a Bower install. Third-party additions such as Bootstrap are pulled in on-the-fly just like we do with Composer dependencies. Heroku does not have SSH key integration for Bitbucket (it does for Github) so I’m using a ready-only account with Basic HTTP auth access.

The database is provided by one of the Heroku app add-ons. The storage is provided by Amazon S3. Heroku is built in AWS, so that fits nicely. We store originals in the file system and then crop them on-demand using the image server.

Delivery

Because cropping images is expensive, the image server originally had a local file cache where it would store each crop. However, as Heroku has an ephemeral file system, you cannot write to it, so I had to turn that off in production.

Instead, we’re using the AWS CloudFront CDN. This was super easy to implement. I just created the settings in AWS, pointed CDN subdomain at AWS and it started working. Like other web proxies, it caches your content based on the headers you send it.

Web browsers come in various shapes and sizes: different users will have different ones, and inevitably different versions of the same one. When CSS3 arrived browsers began adding support for it before the specification had been finalised and so used vendor prefixes.

The result, now we have a standardised CSS3, is that some users have proper CSS3 support and some have the support, but only behind a complicated series of vendor names. Therefore, if you want to use flexbox for example, you cannot just rely on display: fiex; as for some users it will only work with the appropriate vendor prefix.

This means you have to tediously insert all of these vendor prefix statements to get cross-browser compatibility. However, there is a tool called Autoprefixer that takes this hassle away. It is an NPM module that converts your regular CSS into CSS with vendor prefixes. You write:

display: flex;

And you get:

display: -webkit-flex;
display: -ms-flexbox;
display: flex;

This means you have to compile your CSS. However, if you are already compiling from LESS or SASS, it’s really easy to integrate it. On one of my current projects I already had Gulp compiling SASS, so it was one-liner to add the step in. SitePoint have a tutorial on how to set it up.

If you’re doing a lot of CSS in your web development, you may have taken to using SASS or LESS to allow you to better organise, code and maintain your stylesheets. These are both great tools. However, the one thing that annoys me is having to remember the command to compile them, given it is often different for each project.

Luckily Gulp, a Node-based task runner, can come to the rescue.

This has the added advantage that you can also pipe it through other tools, allowing you to create maps and minify the CSS all in one command that makes it super easy.

Firstly, you need to add the dependencies so that NPM knows what to install.

{
    "devDependencies" : {
        "gulp" : "*",
        "gulp-sass" : "*",
        "gulp-minify-css" : "*",
        "gulp-sourcemaps" : "*"
    }
}

You can then run NPM install to get all the modules you need. If these are the only modules you are using you will probably need to modify your .gitignore file to ignore the node modules directory.

node_modules/

Now we can create a gulpfile.js in the root of our project directory that will define the tasks we want to run.

'use strict';
 
var gulp       = require('gulp');
var sass       = require('gulp-sass');
var minifyCss  = require('gulp-minify-css');
var sourcemaps = require('gulp-sourcemaps');
 
gulp.task('sass', function () {
    gulp.src('./sass-files/*.scss')
        .pipe(sourcemaps.init())
        .pipe(sass().on('error', sass.logError))
        .pipe(minifyCss({compatibility: 'ie8'}))
        .pipe(sourcemaps.write('./sass-maps'))
        .pipe(gulp.dest('./stylesheets'));
});
 
gulp.task('sass:watch', function () {
    gulp.watch('./style/*.scss', ['sass']);
});

The first task creates a “gulp sass” command that takes the SASS file, converts it to CSS, minifies it, builds the source map and then writes it out. I’ve set the compatibility to ie8, though it could also be ie7, and defaults to ie9.

The second task creates a “gulp sass:watch” which watches the files for changes and then calls the first task whenever it detects a change.

If you are using LESS you will need a slightly different set of dependencies.

{
    "devDependencies" : {
        "gulp" : "*",
        "gulp-less" : "*"
    }
}

The tasks are slightly different too, but basically do the same thing.

'use strict';
 
var gulp = require('gulp');
var less = require('gulp-less');

gulp.task('less', function () {
  return gulp.src('./app/resources/less/*.less')
    .pipe(less())
    .pipe(gulp.dest('./app/webroot/css'));
});

gulp.task('less:watch', function () {
    gulp.watch('./app/resources/less/*.less', ['less']);
});

The end result of this is that rather than remembering what the specific paths for any project I want to work on, I can create a Gulp task and simply run “gulp sass” or “gulp less”. I could even just rename them to “gulp css” to use the same name on every project I work on.

Still writing regular CSS? Pfft, you’re living in the dark ages! These days it’s all about two new technologies that are almost identical, so I’m going to discuss them in the same post.

The idea is dynamic stylesheets – bringing concepts we use every day in regular programming and implementing them in stylesheets to avoid duplication and make everything cleaner, nicer and more up to update with current paradigms.

So what can you do with these tools? Here is a quick overview…

Variables

Using a colour everywhere that you might want to change later? No worries, just save it as a variable and if you do need to change it at a later date, you just update the variable and it will be changed everywhere.

@myColour: #FFCC00;

.header { background: @myColour; }
.footer { background: @myColour; }

Mixins

Inheritance! What a sexy thing to have in CSS. No longer do you have to place loads of DOM references in lots of different places. Now you can just write it once and included it wherever else you need it.

.bigBorder { border: #FF99CC 10px solid; padding: 5px; }
.header { .bigBorder; background: @myColour; }
.footer { .bigBorder; background: @myColour; }

Nested rules

This one is a huge time saver! How many times have you had to reference half a dozen elements in one DOM reference? Probably very rarely, but certainly two or three tags is the every day reality. No longer though, because you can now nest your rules.

.header {
	.bigBorder
	
	a {
		font-size: 200%;
	}

In this example, the 200% font size will only apply to a tags inside .header, just as if you had done .header a in your DOM reference.

Operations

Want to make a header colour slightly darker? No worries, just add two colours together.

@mainColour: #FFCC00;

.header { background: @mainColour + #333333; }

But these are just a few of the features of these languages. They allow you to do a lot more – including things like full blown functions that you can pass parameters into, guards and much more.

The main difference between LESS and SASS is that LESS is a client-side JavaScript library (although has now been ported to Node) – you send the browser your .less file and include a JavaScript library that converts it. Meanwhile, SASS is a Ruby Gem that compiles a stylesheet to send to the client each time you edit your .sass file.

To find out more, visit the LESS and SASS websites.