At the December 2015 SydCSS meetup I gave a talk on local scope in CSS, which I have written about previously.

In the talk I discuss a few techniques we can use today to achieve encapsulation in CSS, including build tools like CSS Modules with Webpack, and examine the future specifications of the language (CSS4) which aim at introducing local scope.

• Slides: http://matt-d-rat.github.io/deck-css-360-no-scope
• Webpack & CSS Modules demo: https://github.com/matt-d-rat/css-360-no-scope-webpack-demo

In the past, deploying changes to production was as simple as uploading the edited files with an FTP client. But with the modern complex applications we build for the web today, often as part of a distributed team, deploying to production in this manner simply isn't fit for purpose.

So what's the solution? Spend thousands of dollars on a deployment solution? No. Chances are if you had that sort of cash then you would already be doing that.

If you already use Git as your version control software, we can leverage some of Git's more powerful and perhaps lesser used features to automate deployments to a remote server.

In this article I will introduce you to Git bare repositories and Git hooks, specifically the post-receive hook, and show you how you can use them together to automate deployment to a remote server.

Prerequisites

This article assumes you're already familiar with the basics of Git and how to use it via the terminal/command line. This article also assumes you're familiar with basic terminal commands and how to access a remote server via SSH.

The instructions in this article are for a remote server running on Ubuntu 14.04, and a local dev machine running Mac OSX Yosemite 10.10.3, but they should also work for other OS's with a little tweaking. Both environments should already have Git installed on them, if they do not, please install Git before continuing.

Finally, please ensure you make backups of your data before following this guide. I accept no responsibility for any loss of data, misconfiguration or damage otherwise caused. Sigh, it's a sad world we live in when we have to cover ourselves legally, but there you have it. Right, on with the guide!

Introduction to Git hooks

Git hooks are event driven, when certain events happen as a result of an action, such as pushing code, Git checks a series of hooks to see if there is an associated script to run.

Some scripts run prior to an action taking place, which can be used to ensure code compliance to standards, for sanity checking, or to set up an environment. Other scripts run after an event in order to deploy code, re-establish correct permissions (something git cannot track very well), and so forth.

Using these abilities, it is possible to enforce policies, ensure consistency, and control your environment, and even handle deployment tasks.

Git post-receive hook

This is run on the remote when pushing after the all refs have been updated. It does not take parameters, but receives info through stdin in the form of <old-value> <new-value> <ref-name>. Because it is called after the updates, it cannot abort the process.

What this allows us to do is for us to git push our local changes to production, and have Git on the server handle the deployment for us through a script that checks out the changes.

Git bare repository

Since we will never be directly editing the files checked out on the remote server, and nor shouldn't we, we will be using a bare repository instead of a working repository.

What's the difference between a bare repo and a working repo?

Jon Saints sums this up nicely in his article 'What is a bare git repository?':

Repositories created with the git init command are called working directories. In the top level folder of the repository you will find two things:

• A .git subfolder with all the git related revision history of your repo.
• A working tree, or checked out copies of your project files.

Repositories created with git init --bare are called bare repos. They are structured a bit differently from working directories:

First off, they contain no working or checked out copy of your source files. And second, bare repos store git revision history of your repo in the root folder of your repository instead of in a .git subfolder.

So in essence, a working repository is for working, and a bare repository is for sharing.

The way in which we will be using a bare repository is by configuring Git to store the Git related revision history in a not-publicly web accessible folder, as this most likely contains sensitive information, and to checkout our project files into a separate publicly web accessible directory so that are project can be viewed.

Configuring the remote server for deployment

Now that we understand a bit more about Git hooks and Git bare repositories we can start to configure our remote server for push-to-deploy deployments.

Initialise a Git bare repository

Start off by SSHing into your remote server and creating a directory in your user directory. This directory will be used to hold our git bare repository:

$: mkdir ~/myproject.git
$: cd ~/myproject.git
$: git init --bare

Note: the '.git' suffix to the folder name is just a convention and is not necessary.

This initialises the bare repository, and all of the files that would otherwise be stored in a .git hidden folder in a working repository are stored at the root of this folder.

Create a post-receive hook

Next we need to setup the script that will run as part of the post-receive hook. Open up the following file in a text editor:

$: vim hooks/post-receive

So what do we need this script to do? When we push changes to the remote we want Git to checkout those changes to a publicly accessible folder in our web server's web root.

We can achieve this by adding the following lines:

#!/bin/bash
git --work-tree=/var/www/myproject --git-dir=/home/matt/myproject.git checkout -f  

Let's look at this command in more detail:

• --work-tree flag: specifies the directory to checkout our project's working files to, in this case a publicly accessible folder in the Apache web root: /var/www/myproject.
• --git-dir flag: specifies the git directory path for the project, in this case the bare repository we created in the last step in our user directory: /home/matt/myproject.git

This is great, but if we left the script as it currently stands, any branch that is pushed to the remote will be checked out. We need to add some logic to ensure that the only branch that can be pushed is master (or what ever branch you have designated as representing what is in production).

Fortunately as we learnt earlier, Git provides information about the change through stdin in the form of <old-value> <new-value> <ref-name>. We can use this to determine the reference for the change, ie: that it was the master branch that was pushed:

Add the following logic check to the post-receive hook:

#!/bin/bash
while read oldrev newrev ref  
do  
    if [[ $ref =~ .*/master$ ]];
    then
        git --work-tree=/var/www/myproject --git-dir=/home/matt/myproject.git checkout -f
    fi
done  

Let's break down what is going on in this code. First we read the stdin with a while loop, receiving three pieces of information (old rev, new rev, ref), separated by white space, for each ref.

Next we check for a master branch push by checking the $ref object for a reference that contains something like refs/heads/master via the if logical check.

This ensures that only changes being pushed from the master branch to the remote will be applied.

Seeing as for server-side hooks Git is able to pass messages back to the connected client, we will add some stdout to inform the user of what is happening:

#!/bin/bash
while read oldrev newrev ref  
do  
    if [[ $ref =~ .*/master$ ]];
    then
        echo "Master ref received.  Deploying master branch to production..."
        git --work-tree=/var/www/myproject --git-dir=/home/matt/myproject.git checkout -f
    else
        echo "Ref $ref successfully received.  Doing nothing: only the master branch may be deployed on this server."
    fi
done  

That's it for the script. Save and close when you're finished.

Now that we have written our post-receive hook we need to make it executable so that Git can run it:

$: chmod +x hooks/post-receive

Configuring our local machine

On your development machine change directory into your project's working directory:

$: cd /path/to/myproject

Next we will add a new remote to git called production. For this you will need to know the following information:

• The username that is used for your production server.
• The IP address or domain for the production server.
• The location of the bare repository you set up in relation to the user's home directory.

The command you'll run should look something like this:

$: git remote add production matt@server_domain_or_IP:myproject.git

That's it. You can now successfully deploy your master branch to your remote server by running the following command:

$: git push production master

Note: If you have not configured SSH keys, you may be prompted to enter your password.

Upon running the command above, you should see something similar to the following output in your terminal window:

Counting objects: 8, done.  
Delta compression using up to 2 threads.  
Compressing objects: 100% (3/3), done.  
Writing objects: 100% (4/4), 473 bytes | 0 bytes/s, done.  
Total 4 (delta 0), reused 0 (delta 0)  
remote: Master ref received.  Deploying master branch...  
To matt@xxx.xxx.xxx.xxx:myproject.git  
   009183f..f1b9027  master -> master

If we try to push a branch other than master to production, then you will see the following:

$: git checkout feature/test-branch
$: git push production feature/test-branch

Counting objects: 5, done.  
Delta compression using up to 2 threads.  
Compressing objects: 100% (2/2), done.  
Writing objects: 100% (3/3), 301 bytes | 0 bytes/s, done.  
Total 3 (delta 1), reused 0 (delta 0)  
remote: Ref refs/heads/feature/test-branch successfully received.  Doing nothing: only the master branch may be deployed on this server  
To matt@xxx.xxx.xxx.xxx:myproject.git  
   83e9dc4..5617b50  feature/test-branch -> feature/test-branch

Notice the remote's post-receive hook executed the else block on our logical check, resulting in no changes being applied.

Conclusion

As we have demonstrated in this article, it is possible to setup a sophisticated deployment mechanism with Git.

You can expand on the topics covered in this article further; adding remote post-receive hooks to other environments, allowing you to push code to a staging server for testing prior to pushing to production.

You can also extend this script to run other commands, such as installing package dependencies, or configuring the application prior to being deployed. The possibilities are endless.

The real benefit though is the automation this technique brings. As we have demonstrated we have removed some of the human error from the process, and streamlined what would otherwise be a tedious and repetitive task.

When building applications for the web at scale, the need for a proper scope and encapsulation in CSS is becoming ever more apparent, without it our applications are fragile to change, and the house of cards that is CSS can quickly come crashing down around us.

In this article I'll be examining some of the techniques we can use today to achieve encapsulation, and taking a look to the future with the currently proposed specifications that introduce scope at a language level.

What is scope and why is it so important?

Encapsulation, or scope, is often taken for granted, most programming languages support encapsulation in some form, be it through the use of classes in an object-orientated language architecture, or through the use of lexical closures in languages with first-class functions.

The use of encapsulation or scoping allows us to shape our application architecture by:

• Restricting access to some of the components implementation, allowing us to define a clear interface
• Facilitate the bundling of data with the methods (or other functions) operating on that data
• Avoid namespace collisions or accidentally overriding another part of the application by a later declaration

The last point is probably the most relevant when it comes to CSS.

CSS global scope

In CSS everything exists in the global scope. Declarations that come later can override other rules that have been previously declared.

The problem is further compounded by the language where by rules that are more specific will take precedence over rules that are less specific.

/* The background color will be red */
.foo.bar {
    background-color: red;
}

.foo {
    background-color: blue;
}

.bar {
    background-color: green;
}

This problem often arises when using third-party CSS libraries, where by the library styles can end up overriding the CSS rules for your project, even though your stylesheets are declared later.

Techniques for achieving scope in CSS

Language Design Methodologies

While CSS provides the ability to declare styles that cascade, it's often advantageous now a days to not use this feature of the language, as you'll find it difficult to scale a project as the complexity grows.

One approach for achieving a sort of "pseudo encapsulation" in CSS is through the use of language design methodologies, such as BEM or SUIT CSS.

In essence a language design methodology defines a set of rules for how to write CSS. These rules are enforced through linters and pre-compilers, which will break the build if this convention is not followed. In the case of BEM and SUIT CSS the language design methodology is taken a step further through a style that conveys a semantic meaning, while maintaining a set of shallow declarations that are additive by nature.

For example, in SUIT CSS you may declare a set of styles as follows:

.MyComponent {}
.MyComponent-descendent {}
.MyComponent--modifier {}
.MyComponent.is-state {}

As you'll notice, the styles are flat and the only combination selector is one that defines a components state.

These rules can optionally be prefixed with a namespace for the project for further encapsulation, this is especially useful if you are sharing a set of core styles between multiple projects or applications.

The advantage of writing CSS in this manner is that each component is responsible for defining how it looks, and the design encourages you to compose larger features from smaller components. The CSS in this design pattern is scoped to the component, and styles are not leaked into the global scope.

However, this still doesn't avoid the issue of namespace collision when using third-party libraries, and problems can still arise because this is still a manual process, which is fairly tedious, repetitive and prone to human error.

Pre-compiler scoping

As JavaScript workflows have trended towards building collections of components, CSS workflows have followed suit. However, any progress on the CSS front has been purely conventional, as seen by the language design methodologies above, and are not directly supported by the language itself.

One of the fundamental features of the Webpack loader (which is also core to JSPM and easily possible with Browserify) is the ability to explicitly describe each file's dependencies regardless of the type of source file. For CSS in a component workflow, that takes the following form:

// Marks the CSS as being a dependency of this JS.
// Depending on the loader, the CSS is either injected
// into the DOM or bundled into a separate CSS package.
require( './my-component.css' );  
module.exports = function() {  
    // component definition
};

Now, whenever my-component.js is loaded or bundled, the corresponding CSS is guaranteed to be present, just like any other dependency. This convention leads us to a new capability, and necessitates a new specification, enter css-modules.

css-modules

With css-modules we can emulate local scope and control dependencies in front-end components. By default, all class names and animation names are scoped locally. All URLs url(...) and @imports are in module request format.

For example, say I have the following styles declared for a component:

/* my-component.css */

.root {}
.image {}
.description {}

When css-modules processes this CSS file, it will automatically prefix each class selector making it globally unique. To apply these classes in our template we import (or require) it into a js file:

Note: At the time of writing, you will need a build step for this part since most browsers don’t support import / require statement natively yet. There are css-modules implementations for webpack, browserify and jspm to handle this part.

// ES6
import styles from './my-component.css'  

// CommonJS
var styles = require('./my-component');  

Behind the scenes, css-modules exports the classnames of our stylesheets as an object, which gets assigned to the styles variable declared in the import statement of our js file.

We can then use this object in our templates to output the classnames in the correct parts of the DOM of our component:

<!-- using ES6 string literals -->  
<div class="${styles.root}">  
    <img class="${styles.image}" src="path/to/image.png" />
    <p class="${styles.description}">Lorem ipsum</p>
</div>  

<!-- using AngularJS (one-time binding) -->  
<div class="{{::styles.root}}">  
    <img class="{{::styles.image}}" src="path/to/image.png" />
    <p class="{{::styles.description}}">Lorem ipsum</p>
</div>  

Looking at the rendered HTML, you'll notice the classnames that are output is similar to the code we wrote in our CSS, except we have avoided any accidental namespace collision because css-modules has prefixed our component with a namespace.

<div class="_myComponent__root">  
    <img class="_myComponent__image" src="path/to/image.png" />
    <p class="_myComponent__description">Lorem ipsum</p>
</div>  

This means that we can avoid namespace collisions by also running third-party libraries through the same css-modules processor, prefixing them with a unique global namespace, and because the process is automatic, it is less prone to human error.

There are also lots of other cool features that css-modules provides such as composition, which I will be covering in a later article.

CSS :scope pseudo-class

Defined as part of the W3C CSS Selectors Level 4 (working draft) specification, the :scope pseudo-class provides scoping to CSS at a language level by representing any element that is in the contextual reference element set. A scoped <style> element is used to "scope" a selector so that it only matches within a subtree.

So what does this all mean? It means that instead of hanging styles off of the :root context, which by default is the <html> tag, we can declare a separate :scope context that is attached to a specified DOM subtree, all child elements of this subtree will be styled according to the scoping of the CSS, and sibling elements and their children will remain unaffected.

So with this information in mind lets illustrate this further with an example:

<style>  
    p {
        color: black;
    }
</style>

<p>I will be coloured black.</p>

<section>  
    <style scoped>
        p {
            color: red;
        }
    </style>
    <p>I will coloured red because my styles are scoped!</p>
</section>

<p>I will also be coloured black.</p>  

As you can see, the <style> tag is given the scoped attribute, this creates a new scope context, hanging off of the parent element, which in this example is the <section> element. All children of the <section> element will receive the new styling rules, and will be styled accordingly.

We can also @import an external CSS file and scope it like so:

<div>  
    <style scoped>
        @import 'path/to/stylesheet/main.css';
    </style>
</div>  

CSS @scope at-rule

One criticism of the CSS :scope pseudo-class is that we are back to mixing HTML and inline-styles again, and I am inclined to agree, I don't like to use inline <style> tags because more often than not you end up repeating yourself, the code is harder to maintain and I cannot leverage my favourite CSS pre-compiler anymore.

The @scope at-rule allows authors to create scoped style rules using CSS syntax, where the elements matched by the <selector> are scoping roots for the style rules in the <stylesheet>, and selectors of style rules scoped by @scope are scope-contained to their scoping root.

For example:

span {  
    color: black;
}

@scope div {
    span {
        color: red;
    }
}

@scope section {
    span {
        color: green;
    }
}

By default all spans on a page (which are attached to the :root scope context) will be coloured black, while spans inside of the div and section @scope context will be coloured red and green respectively.

This simple example illustrates how to create isolated scopes in CSS, the easiest way to think about it is to view the @scope at-rule as being similar to the @media at-rule, in that, the styles are conditionally applied given the context. Styles will not bleed outside of this context.

Importantly, styles that are declared after cannot affect rules that are scoped. For instance in the following example, the colour of the <p> element text will be red.

@scope aside {
    p { 
        color: red; 
    }
}

aside#sidebar p {  
    color: black; 
}

Even though the ruleset for aside#sidebar p is more specific, because aside is scoped, only the rules declared inside that scope context will be applied.

In the case of both the :scope pseudo-class and the @scope at-rule, at the time of writing, both are currently in a state of working draft proposals, so browser support is very light, and in the case of Google Chrome the feature was partially implemented behind an experimental flag and then later removed due to code complexity, favouring instead the next feature for discussion, the Shadow DOM.

Shadow DOM

The Shadow DOM is a method of establishing and maintaining functional boundaries between DOM trees and how these trees interact with each other within a document, thus enabling better functional encapsulation within the DOM.

Unlike language design methodologies or pre-compiler scoping, which only emulate a local scope, the Shadow DOM provides us with an actual local scope for a component, and not just for CSS either, but for the HTML and JavaScript too!

At the time of writing though, browser support is light, and browsers who do support the feature normally have it turned off by default behind an experimental feature flag.

For example, if I had the following markup and JavaScript the output would be as follows:

Note that if the JavaScript asks for the host.textContent, the output would be Hello World instead of Lorem Ipsum, this is because the DOM subtree under the shadow root is encapsulated.

Summary (tl;dr)

• JavaScript and CSS have made great strides towards component based workflows, however CSS at a language level is still lacking the necessary features for achieving encapsulation
• Up until now, scope in CSS has been achieved through convention, by using language design methodologies like BEM and SUIT CSS
• Pre-processor scoping tools, such as css-modules, are helping to automate these conventions, reducing human error
• The Shadow DOM is a future specification which aims to achieve proper encapsulation for JavaScript, HTML and CSS. At the time of writing though browser support is light.

Personally I believe that the Shadow DOM/web components are the way we should be designing and building our application architecture, and as browser support picks up this will only become more prevalent.

In the mean time though we (unlucky few) still have to support legacy browsers, which unfortunately means we are unable to take advantage of these future specifications today. That being said, projects like css-modules are closing the gap between the future and today, and leveraging them will enable us to write decoupled, more maintainable code, that will scale as our architecture grows.

At the June 2015 SydCSS meetup I gave a five minute lightning talk on scaling CSS in large real-time applications. During this talk, I discuss some of the techniques we use at Lab49 to achieve scalability in CSS.

Video

Slides

CSS has evolved and changed much since its initial release {[{'1996-12-17' | age}]} years ago. Its introduction ushered in a new era of separation of concerns, keeping document content and its presentation separate from one another. Since then we have enjoyed a myriad of advancements in the language as it tries to keep pace with the ever changing design landscape of the web. But there is one area of the language that hasn't changed, the very foundation at the core of CSS, the cascading nature of the language.

As we strive to build applications that are ever increasing in complexity, the need for encapsulation is now greater than ever.

In this article I will be looking at SUIT CSS, "a styling methodology for component-based UI development". I will be looking at the goals and the naming conventions of the methodology, the build and linting tools available, and above all else, why you should be adopting SUIT CSS on your projects today!

What is SUIT CSS?

At its core, SUIT CSS is a language design pattern for CSS. Its focus is towards the development of reusable component-driven UI elements, that are semantic and encapsulated by nature, and maintain a presentational relationship between the nodes represented in the DOM without coupling the presentation to a specific DOM structure.

Released under the an MIT licence by Nicholas Gallager in June 2014, SUIT CSS leverages the ideas first introduced in BEM (another web development methodology) in having semantically meaningful class names which are able to express how a component is structured, its presentation modifications, and its state.

Overview of SUIT CSS

.ComponentName {}
.ComponentName--modifierName {}
.ComponentName-descendentName {}
.ComponentName.is-stateOfComponent {}

.u-utilityName {}

What makes SUIT CSS really powerful are the subtleties that the language form semantically communicates. Lets break down each of these ideas:

Components

.ComponentName {}

Components in SUIT CSS are written in pascal case giving them a clear semantic separation from all other rule definitions. The class name will sit at the root node of the component itself.

<aside class="SideDrawer">...</aside>  

If your library is going to be consumed by public projects, it is recommended that you prefix your component names with a namespace, written in lower case:

.namespace-ComponentName {}

Modifiers

.ComponentName--modifierName {}

Modifiers, denoted by a prefixed double dash (--), are written in camel case and form the suffix of the component to be modified, or the component descendent to be modified.

Their use is reserved for altering the base styles of a component in some form. They must always be used in addition to the base component class (multi-class pattern):

<button class="Button Button--primary">...</button>  

Descendants

.ComponentName-descendentName {}

A component descendent is a class that is attached to a descendent node of a component. It's responsible for applying presentation directly to the descendent on behalf of the component. Descendent names must be written in camel case and are prefixed with a single dash (-).

<aside class="SideDrawer">  
    <a href="#" class="SideDrawer-link">...</a>
</aside>  

Unless absolutely necessary, descendent classes should not communicate their depth in a component. This would otherwise couple the styles to a particular DOM structure, so you want to avoid the following:

/* Bad! */
.ComponentName-descendentName-anotherDescendent-andAnotherDescendent {}

/* Good! */
.ComponentName-andAnotherDescendent {}

Component State

.ComponentName.is-stateOfComponent {}

States are written in camel case as adjoining classes and should never be styled directly. This allows the same state names to be used in multiple contexts, but every component must define its own set of styles for that state, as they are scoped to the component.

<aside class="SideDrawer is-open">  
    <a href="#" class="SideDrawer-link is-active">...</a>
    <a href="#" class="SideDrawer-link">...</a>
    <a href="#" class="SideDrawer-link">...</a>
</aside>  

Utilities

.u-utilityName {}

Utilities provide low-level structural and positional traits and can be applied to any element within a component. Utilities are prefixed with u- and should focus typically achieving only one thing.

<img src="..." class="Post-img u-alignLeft" />  

Why is this important?

So this is all well and good, but why should you care? While SUIT CSS conveys semantic meaning to your CSS, it is so much more than that. Because the structure of your CSS is largely flat and most importantly, is encapsulated, maintenance and refactoring either the HTML or the CSS becomes a breeze, enabling you to scale your application as much as necessary.

Specificity wars, infamous !important overrides, and bleeding styles introduce so many defects and headaches in the long run, if your CSS has any of these problems, your architecture will be so much harder to maintain. Why put yourself through the pain?

SUIT CSS in practice

Let me elaborate a little with a more detailed example. Consider the following HTML:

<header class="Header">  
    <a href="#" class="Header-link">
        <img src="..." class="Header-logo" />
    </a>
    <nav class="Nav Nav--topMenu Header-nav">
        <a href="#" class="Nav-link is-active">...</a>
        <a href="#" class="Nav-link">...</a>
    </nav>
</header>  

The .Nav component keeps its styles entirely encapsulated from the .Header component. The only class that creates a relationship between the two is the .Header-nav descendent class, which would simply be acting on the .Nav component in a positioning and/or structural manner.

If in the future we needed to refactor this code and detach the .Nav component from the .Header it would be as simple as moving the HTML out, and removing the .Header-nav class.

All other styles should in reality remain largely unchanged due to how we have encapsulated our components.

Liberate your CSS

When I first started writing my styles in SUIT CSS parlance it felt strange, almost counter intuitive. I had become so used to inheriting styles, it was hard to realise the benefits. Until it came to refactoring, that's when it clicked.

Maintenance

What would have taken me hours of refactoring, and even longer to regression test, took minutes. I was able to make significant changes to the code base with 100% confidence that the only thing that was going to change was that particular component. It felt liberating. In the past CSS has felt like a house of cards, changing the smallest thing could cause the entire thing to come crashing down around you.

But what about code duplication? Computer science 101 tells us to always keep code DRY. Sure, with SUIT CSS there is potential for your code to become a little... erm, wetter, you could very well end up repeating yourself in a few places. But the wins you gain from a maintenance point of view far out weigh any negatives from code duplication in my opinion.

You can mitigate code duplication by using a pre-processor like SASS/SCSS, leveraging the @extend statement and utilising @mixin to keep your code DRYer. For example:

.Button {
   ...
}

.Button--primary {
   ...
}

.Dropdown {
   @extend .Button, .Button--primary;
   ...
}

But what about the output size of the CSS? Won't it be much bigger/bloated? While performance should always be at the forefront of your mind when building applications, the output size of a CSS file shouldn't be the deciding factor to how you write the code in the first place. Minified file sizes do not tell the whole story, once gzipped the comparisons are no more than ~5% in difference in overall size. As Nicholas Gallagher mentions in his article 'About HTML semantics and front-end architecture':

CSS developers using pre-processors don’t need to be overly concerned about a certain degree of repetition in the compiled CSS because it can lend itself well to smaller file sizes after HTTP compression. The benefits of more maintainable “CSS” code via pre-processors should trump concerns about the aesthetics or size of the raw and minified output CSS.

And I'm inclined to agree with him. Having confidence in the code you're changing is key to a happy software cycle.

Testing

The other big win we gain from encapsulating CSS by using methodologies such as SUIT CSS, is testing. Components should be tested firstly in isolation from one another and the application context. Without encapsulation and decoupling of components, this is not possible. When composing components together in the larger application context, your end-to-end tests round out the remainder of testing.

If we go back to the .Header / .Nav example above, where by we refactored the code to move the .Nav component out of the .Header, our tests around .Nav should remain unchanged, our end-to-end tests may be the only place that require updating.

There is also available a Rework plugin for SUIT CSS to check component style isolation.

SUIT CSS Tools

While at its core SUIT CSS is a language design pattern, it also comes with a number of tools (all of which are entirely optional), that you can incorporate into your build process:

• CSS pre-processor - A future facing pre-processor which uses W3C working spec CSS variables and module definitions
• Style foundation - A base set of styles which sit on top of a thing layer of normalize.css (also by Nicholas Gallagher)
• Style utilities - A set of common utility classes
• Style components - A collection of high-level components
• Encapsulation testing - A standalone tool for testing CSS compliance against SUIT CSS methodology. Note: the SUIT CSS pre-processor includes this already.

Conclusion

Fundamentally, CSS wasn't originally designed for the types of applications we are building for the web today. Back then, the web was little more than a simple collection of web pages; table based layouts, animated marquees and the ever present under construction GIF. Who could of imagined we would be building applications for the browser, capable of streaming 4K video, audio, rendering entire 3D environments, dynamically populating the page with data from an array of input devices, such as GPS, compass, gyroscopes, web cams and more?

While the language has managed to keep pace with the changing design landscape and the advances in technology (just), at its core the cascading part of stylesheets creates more problems than it solves when building web applications, not just simple web pages.

In order to build high-quality web applications, comprised of many different components, then we simply have to have encapsulation in order to create a boundary between the code of that component and the code that will consume it. With correct presentation scope, the order in which components are loaded and composed no longer matters, and their styles do not bleed into other components of the application.

While the Shadow DOM will probably end up delivering this much needed encapsulation to CSS at a language level, we are still years off from being able to use it in production applications (at the time of writing only webkit enabled browsers; Chrome, Opera and Safari (excluding iOS Safari) support it).

Until then, language design methodologies such as SUIT CSS help to provide some sanity and structure to the scopeless madness. Paired with pre-compilers, linters and other build tools, today the suite of CSS tools are extremely powerful and useful, so that we are able to build complex, component-driven web applications that are able to scale today, instead of tomorrow.

Further reading

• SUIT CSS Homepage
• SUIT CSS Documentation
• Introduction to SUIT CSS
• About HTML semantics and front-end architecture
• Custom CSS pre-processing
• Shadow DOM 101

Over the past few years design trends have seemingly accelerated, moving beyond skeuomorphic design into the brave new world of flat design, where minimalism and typography sit at the core of its methodology. As a result, it was time that my blog received a design facelift of sorts. In this article, I cover the design decisions I made, the inspirations I drew from, and I take a look forward to where I see the current design trends moving towards.

It is important to look at these design trends not just from a visual point of view, but to understand why they have evolved in this manner; what experience are they trying to convey? Design holistically is not about pretty pixels, it runs deeper than simply just that. Every design decision aims at supporting the end user experience in some form.

A look back

Over the past few years, my blog as taken on a visual design that is dramatically different to its predecessor. The most recent of which can be seen in this screenshot from 2011:

Even back in 2011, we can see the design for mattfairbrass.com was taking a minimalist approach, bringing the content to the front and centre. But the execution of the design was somewhat disjointed, the typography and iconography wasn't consistent throughout. The design had also become bloated with content from other sources, which ultimately detracted from the main goal of the blog, the blog posts themselves.

In 2011, the way in which we were consuming content had dramatically shifted from the ways five years prior, mobile accessibility had become a key factor in designing for the web, and the 2011 design simply didn't cater for this.

Re-thinking the design

The previous iteration on the design had surfaced some key ideas I wanted to maintain in the new design. At its core I wanted the design to express a minimalistic approach, but incorporate some of the other design ideas that have evolved over the past couple of years.

Hero Image

One of my favourite design trends that emerged with great success is the hero image. Defined by Wikipedia as:

A term used in web design for a specific type of web banner. A hero image is a large banner image, prominently placed on a web page, generally in the front and center.

The hero image is normally used to draw the attention of the users focus towards a call to action, supported by the product itself, or other imagery that is used to invoke a certain feeling in the user.

Hero images are typically full width, breaking through the normalised padding definitions of the site. This helps to separate it from the rest of the content, allowing it to deliver more impact.

They are used heavily by minimalistic websites, as they help to inject colour and vibrancy into pages which would other wise be awash in a black and white colour palette.

This was a trend I wanted to incorporate into the new design, but with a slight twist. I took inspiration from the login screen design in Mac OSX Yosemite, where by the wallpaper of the users desktop has a blur effect applied to it.

I decided to introduce this as an animation aspect for when the user scrolled down the page, gradually blurring the image more and more as the user scrolled further down, helping to enforce the call to action to explore the content cards below.

The blurring of the hero image brought with it its own technical challenges, which I will discuss at another time in a dedicated article.

Cards

Another design trend that has emerged over the past year is the rise of cards. Popularised by Google in Google Now, which debuted on Android 4.1 (Jelly Bean), and since has seen wide adoption as part of their Material Design language, as well as by other vendors, cards aim at providing aggregated snippets of information in a consistent UI manner.

I adopted a card based layout for the main pages that show lists of posts. Using a container pattern that follows a masonry design (popularised by Pinterest in 2010), the form creates an experience of discovery, rather than one of a linear narrative.

The other advantage to using a card based layout for this type of content was that it would scale to any viewport size. This was key to accessibility when consuming the content on a mobile device vs a 4K display.

For more information on card based design, check out CardStack, a great resource aimed at unifying the way in which card based design is executed by:

Building a Card Ecosystem based on Open Web technologies and Open Source ethos that fights back against rampant lock-in.

Material Design

Having embraced cards within my new design I opted to fully adopt Material Design as well. This helped to anchor a number of design elements (inputs, buttons, typography etc..) in a familiar tactile reality of that of the physical world, with the flexibility of a design principle which is able to create new affordances that supercede those in the physical world, without breaking the rules of physics.

Exploring the Z-Axis

I was really inspired by this article over on A List Apart which talks about the importance of designing for the third-dimension as we begin to face design challenges for an increasingly diverse array of shapes and sizes.

The obvious places where I have incorporated this principle is for the comment modal and share bottom sheets on the cards themselves. Modals are nothing new, but they serve an important role, allowing users to quickly interact with a card without needing to leave the exploration of other content.

A more subtle place I incorporated the z-axis is within the main container on each page itself. The hero image is anchored in a fixed position, as you scroll down the page the main content slides up over the top, creating a sudo-parallax effect. This subtle use of the z-axis allows me to communicate what is important at that point in time to the user.

A look to the future

No one can say with any degree of certainty the direction design for the web will take in the future, but there have been some key indicators in the latest design trends which might suggest a nod at the direction designers are going.

I predict the key areas we will see dramatic design improvement and focus in the coming year will be with the use of animation and the z-axis.

We're already seeing it with the card design paradigm, and the evolution from flat design to material design. Apple heavily revamped animations and transitions in iOS7, expanding further with this principle in iOS8. They also heavily use the z-axis with design elements that utilise translucency and blurring of lower layers.

The shift to card layouts will also continue to play a heavy influencing role. My hope from a developer point of view is that we will begin to see a set unifying API's that define how cards from one application act in another. From a designer point of view, I hope to see a unified set of design principles adopted by all card layouts that facilitate this integration, without the overall design becoming a disjointed frankenstein mess.

Conclusion

The new design of my blog is anchored around one key element, the content. The content of any blog is the single most important thing, after all it's what adds value to the site, which would otherwise become just another domain taking up space in a server rack somewhere.

I wanted the content to always be front and centre to the reader, creating a more relaxed, accessible, and hopefully more enjoyable reading experience. This single goal led every single design decision, from choice of typography, colour palettes, to the right amount of negative space to use, or even how the content is going to be consumed. The design should almost melt away into the background, serving only to support the content.

Working on the re-design for mattfairbrass.com has reinvigorated my passion for writing, and I look forward to actively blogging more often. Here's to the next post.