Friday, April 17, 2015

Grid Item Animation Layout

Grid Item Animation Layout

A responsive, magazine-like website layout with a grid item animation effect that happens when opening the content.

Today we'd like to share a simple animated grid layout with you. The responsive layout has a sidebar and grid items that animate to a larger content area when clicked. In the first demo the content area fills the grid (inspired by a concept by Virgil Pana) and in the second demo, the whole layout moves to the left while the grid item is expanding (inspired by this Dribbble shot by Sam Thibault).

The expanding element (which is a dummy element and not the grid item itself) is not animating in width and height but instead its original dimensions are already of the expanded size and we simply scale it down initially. By setting classes, we control the transitions of all the elements: the grid item elements' disappearance and the content elements' appearance (and vice versa when we close an opened content panel).

Grid Item Animation Layout

The layout is responsive down to mobile using a media query technique that involves setting the breakpoints based on the grid item size and the sidebar. For this we use Sass, which allows us to set these kind of variables easily. The approach we are using here is mainly mobile-first, but we also do some specific restructuring for small screens.

* Please note that this layout uses some modern techniques that involve viewport units, transitions, flexbox and other properties that will only work in modern browsers.

The second demo is a bit more experimental and it might not behave as expected in all browsers. Internet Explorer seems to have some issues with transitions on transforms that use calc().

This layout is focused on the expansion effect of the grid item and many elements are simple dummies (the loader, the filter in the top bar and the "load more" in the footer of the grid).

The main markup looks as follows:


The Sass files of this project are divided into a main style file and two partials, one for the base styles and one for the media queries. Each of the demos will have a unique style Sass file (style1.scss and style2.scss) where we initiate some variable and redefine some styles if necessary (as in demo 2). There are many ways of organizing your project in Sass; this was one convenient way to do it for these two demos. If you'd like to use one of them, make sure to refactor your style declarations. If you are not familiar with Sass, you can simply use and adjust the generated CSS files.

An example for the main demo Sass file is as follows:

$item_width: 300px;
$sidebar_width: 300px;
$color_primary: #fafafa;
$color_secondary: #fff;
$color_link: #81c483;
$anim-time: 0.5s;

@import "base";
@import "mediaqueries";

The variables needed in the base and the media queries Sass files are defined here.

Grid Item Animation Layout

The media query breakpoints are defined by the amount of items we want to be visible in the grid and the sidebar (no prefixes shown):

/* Viewport sizes based on column number and sidebar */
$viewport_xs:  $item_width + $sidebar_width; /* 1 column */
$viewport_s:  $item_width * 2 + $sidebar_width; /* 2 columns */
$viewport_m:  $item_width * 3 + $sidebar_width; /* 3 columns */
$viewport_l:  $item_width * 4 + $sidebar_width; /* 4 columns */
$viewport_xl:  $item_width * 5 + $sidebar_width; /* 5 columns */
$viewport_xxl:  $item_width * 6 + $sidebar_width; /* 6 columns */

@media screen and (min-width: $viewport_xs) {
 html, 
 body, 
 .container, 
 .main {
  height: 100vh;
 }

 .main {
  height: 100%;
  margin-left: $sidebar_width;
 }

 .content__item {
  font-size: 1em;
 }

 .grid__item {
  padding: 45px 45px 30px;
 }
}

@media screen and (min-width: $viewport_s) {
 .grid {
  display: flex;
  flex-wrap: wrap;
 }

 /* 2 columns */
 .grid__item {
  width: 50%;
  border: none;
 }

 .grid__item::before {
  top: 5px;
  right: 5px;
  bottom: 5px;
  left: 5px;
  border: 1px solid rgba(74,74,74,0.075);
  transition: opacity 0.3s;
 }

 .grid__item:hover::before,
 .grid__item:focus::before {
  border: 3px solid rgba(129,196,131,0.5);
 }

 .grid__item--loading.grid__item::before {
  opacity: 0;
 }
}

@media screen and (min-width: $viewport_m) {
 /* 3 columns */
 .grid__item {
  width: 33.333%;
 }
}

@media screen and (min-width: $viewport_l) {
 /* 4 columns */
 .grid__item {
  width: 25%;
 }
}

@media screen and (min-width: $viewport_xl) {
 /* 5 columns */
 .grid__item {
  width: 20%;
 }
}

@media screen and (min-width: $viewport_xxl) {
 /* 6 columns */
 .grid__item {
  width: 16.66%;
 }
}

/* small screen changes for sidebar (it becomes an off-canvas menu) */
@media screen and (max-width: $viewport_xs - 1px) {
 .sidebar {
  transform: translate3d(-100%,0,0);
 }
 .sidebar.sidebar--open {
  transform: translate3d(0,0,0);
 }
 .sidebar.sidebar--open ~ .main {
  pointer-events: none;
 }
 .top-bar {
  padding: 22px 15px 10px 60px;
 }
 .menu-toggle {
  display: inline-block;
 }
 .sidebar .close-button {
  opacity: 1;
  top: 15px;
  right: 15px;
  pointer-events: auto;
 }
 .title--full {
  font-size: 2em;
 }
 .content__item {
  padding: 80px 20px 40px;
 }
 .close-button {
  padding: 10px 20px;
 }
 .close-button::before {
  content: '';
  position: absolute;
  top: 0;
  right: 0;
  background: $color_secondary;
  border-bottom: 1px solid $color_primary;
  width: 100vw;
  height: 50px;
  pointer-events: none;
  z-index: -1;
 }
}

This technique can come in handy when dealing with grid layouts. Optimally, we'd not have that last media query at all if we want to strictly follow a mobile-first approach. But since these styles are exclusively valid only for small screens, we don't want to be redefining and overwriting styles for larger screens.

Have a look at the layout and the effect and dig into the source, we really hope you find this template useful and inspiring!

View Demo or Download the files

Tuesday, April 14, 2015

Keeping it simple: coding a carousel

coding a carousel

One of the things that drives me crazy in our "modern development" world is our fetish of over-complicating things. We build solutions, and then we add layers and layers of complexity for the sake of "making them easier to maintain". In many cases, this is a fool's errand as the layers of complexity and with them the necessary documentation make people not use our solutions. Instead, in many cases, people build their own, simpler, versions of the same thing and call it superior. Until this solution gets disputed and the whole dance happens once again.

In this article I want to approach the creation of a carousel differently: by keeping it as simple as possible whilst not breaking backwards compatibility or have any dependencies. Things break on the web. JavaScript might not be loaded, CSS capabilities vary from browser to browser. It is not up to us to tell the visitor what browser to use. And as good developers we shouldn't create interfaces that look interactive but do nothing when you click them.

So, let's have a go at building a very simple carousel that works across browsers without going overboard. You can see the result and get the code on GitHub.

The HTML structure of a carousel

Let's start very simple: a carousel in essence is an ordered list in HTML. Thus, the basic HTML is something like this:

  1. 1
  2. 2
  3. 3
  4. 4

Using this, and a bit of CSS we have something that works and looks good. This is the base we are starting from.

The basic CSS

The CSS used here is simple, but hints at some of the functionality we rely on later:

.carouselbox {
  font-family: helvetica,sans-serif;
  font-size: 14px;
  width: 100px;
  position: relative;
  margin: 1em;
  border: 1px solid #ccc;
  box-shadow: 2px 2px 10px #ccc;
  overflow: hidden;
}

.content {
  margin: 0;
  padding: 0;
}

.content li {
  font-size: 100px;
  margin: 0;
  padding: 0;
  width: 100%;
  list-style: none;
  text-align: center;
}

The main thing here is to position the carousel box relatively, allowing us to position the list items absolutely inside it. This is how we'll achieve the effect. The hidden overflow ensures that later on only the current item of the carousel will be shown. As there is no height set on the carousel and the items aren't positioned yet, we now see all the items.

coding a carousel

The carousel visuals in CSS

A lot of carousel scripts you can find will loop through all the items, or expect classes on each of them. They then hide all and show the current one on every interaction. This seems overkill, if you think about it. All we need is two classes:

  • We need a class on the container element that triggers the functional display of our carousel. This one gets applied with JavaScript as this means the look and feel only changes when the browser is capable of showing the effect.
  • We need a class on the currently visible carousel element. This is the odd one out. All the others don't need any classes.

We can hard-code these for now:

  1. 1
  2. 2
  3. 3
  4. 4

All we need to show and hide the different carousel items is to change the height of the carousel container and position all but the current one outside this height:

.active {
  height: 130px;
}

.active li {
  position: absolute;
  top: 200px;
}

.active li.current {
  top: 30px;
}

You can see this in action here. Use your browser developer tools to move the current class from item to item to show a different one.

coding a carousel

Interaction with Javascript

To make the carousel work, we need controls. And we also need some JavaScript. Whenever you need a control that triggers functionality that only works when JavaScript is executed, a button is the thing to use. These magical things were meant for exactly this use case and they are keyboard, mouse, touch and pen accessible. Everybody wins.

In this case, I added the following controls in our HTML:

  1. 1
  2. 2
  3. 3
  4. 4

Now, here is where the hard-liners of semantic markup could chime in and chide me for writing HTML that is dependent on JavaScript instead of creating the HTML using JavaScript. And they'd be correct to do so. There is nothing that stops me from wrapping this chunk of HTML in a DOM call or innerHTML write-out. However, as buttons are meant to trigger JS functionality, I think it is easier to just keep that in the HTML and allow us thus to style them with much less hassle. As a security precaution, we hide them in the non-active state and show them when the "active" class has been applied:

.active .buttons {
  padding: 5px 0;
  background: #eee;
  text-align: center;
  z-index: 10;
  position: relative;
}

.carouselbox button {
  border: none;
  display: none;
}

.active button {
  display: block;
}

.offscreen {
  position: absolute;
  left: -2000px;
}

The offscreen parts are there to explain what these buttons really mean as the triangle is not enough for some people.

All that is left to make the carousel work is the JavaScript. And here it is:

carousel = (function(){
  var box = document.querySelector('.carouselbox');
  var next = box.querySelector('.next');
  var prev = box.querySelector('.prev');
  var items = box.querySelectorAll('.content li');
  var counter = 0;
  var amount = items.length;
  var current = items[0];
  box.classList.add('active');
  function navigate(direction) {
    current.classList.remove('current');
    counter = counter + direction;
    if (direction === -1 && 
        counter < 0) { 
      counter = amount - 1; 
    }
    if (direction === 1 && 
        !items[counter]) { 
      counter = 0;
    }
    current = items[counter];
    current.classList.add('current');
  }
  next.addEventListener('click', function(ev) {
    navigate(1);
  });
  prev.addEventListener('click', function(ev) {
    navigate(-1);
  });
  navigate(0);
})();
As you can see, by relying on CSS and its built-in crawling of the DOM, there is no need for any loop whatsover. Here's what's going on in this script:
  • We grab all the HTML elements we need with querySelector.
  • We set the counter to 0 – this is the variable that keeps track of which item of the carousel is currently shown.
  • We read the amount of items in the carousel and store them in a variable – this allows us to loop the carousel.
  • We set the current item as the first one in the carousel. The current variable will contain a reference to the element currently visible. All we do when the carousel state changes is remove the CSS class from it and shift it to the other one.
  • We add the class of active to the container element to change its styling and trigger the CSS functionality explained earlier.
  • The navigate method takes a parameter called direction which defines if we should go backwards (negative values) or forwards in the carousel. It starts by removing the current class from the current carousel item, thus hiding it. We then modify the counter and make sure it doesn't go beyond the amount of items available or below 0. In each case we move to the other extreme, thus making the carousel an endless rotating one. We define the new current item and add the class to show it.
  • We apply event handlers to the buttons to navigate forwards and backwards.
  • We show the first carousel item by calling navigate with 0 as the value.
Pretty simple, isn't it? By allowing CSS to do what it is good at, our JavaScript more or less is only about keeping state and shifting classes around.

Getting fancy

The showing and hiding of the items by positioning them in a container with overflow hidden should work in any browser in use these days – even the ones who should be retired. And as all we do is add and remove CSS classes, we can now tap into the beautiful features browsers have these days. Using transition, opacity and transformation, we can add a pretty effect with a few lines of CSS:

.active li {
  position: absolute;
  top: 130px;
 
  opacity: 0;
  transform: scale(0);
  transition: 1s;
}

.active li.current {
  top: 30px;
 
  opacity: 1;
  transform: scale(1);
  transition: 1s;
}

coding a carousel
The beauty of this is that the performance handling, the timing (in case you click too fast) is handled by the browser for us. No need to count FPS or juggle timeouts. As CSS is a one-off state, this also means that browsers that do not support these features simply don't show them instead of throwing an error.

Bullet-proofing our Javascript

When a browser in use doesn't support some JavaScript feature we use, things get trickier. We get an error and things break. Thus, it makes sense to test for the things we use and move on only when there is support for them. In this code, we rely on classList and querySelector, so let's just check for this:

if (!document.querySelector || !('classList' in document.body)) {
    return false;
}

We could get much more paranoid and ensure that all the DOM elements are available before proceeding but this is overkill. If a maintainer forgets to add the carouselbox class to the main element, the error thrown is pretty obvious.

Bonus round: stacking with CSS

One last trick to mention is that if you were to stack all the elements of the carousel visually and only use opacity to blend them then there is a problem with links. You'd always get the link of the first item, no matter which one is shown.

The trick to work around that is user pointer-events: none in your CSS:

.active li {
  position: absolute;
  top: 130px;
 
  pointer-events: none;
  opacity: 0;
  transform: scale(0);
  transition: 1s;
}

.active li.current {
  top: 30px;
 
  pointer-events: auto;
  opacity: 1;
  transform: scale(1);
  transition: 1s;
}

You can see this workaround in action here.

Where to go now

The natural drive as a developer now is to enhance this to allow users to define a different starting element to show, to define lots of preset effects that can be chosen with the data attribute, to allow for non-looping carousels and to define an API to allow other components on the page to interact with the carousel. And an API to create and remove and shuffle items of the carousel. And, and and... All of these are great exercises, but let's ask ourselves: who do we do that for?

We have such amazing functionality built into the platform of the web now. Maybe it is time to stop writing the perfect generic re-usable widget and just stick with simple things and let people extend them when they need to? Who knows, by not doing the work for them, people might learn to be better coders themselves.

Tuesday, April 14, 2015

Understanding Variable Scope in Sass

Variable Scope in Sass
In this article, we'll take a deeper look at variables and variable scope in Sass. The scope of a variable describes the context within which it's defined and therefore where it's available to use.

To start, I'll cover which scopes Sass supports. Then, I'll explain two useful flags we can use to customize the value of a variable. Finally, I'll briefly present the available functions for checking whether a variable exists or not.

Sass Variable Scope

Sass supports two types of variables: local variables and global variables.

By default, all variables defined outside of any selector are considered global variables. That means they can be accessed from anywhere in our stylesheets. For instance, here's a global variable:

$bg-color: green;

On the other hand, local variables are those which are declared inside a selector. Later, we'll examine how we can customize that behavior. But for now, let's see our first example.

Here we define a mixin and then the btn-bg-color variable within it. This is a local variable, and is therefore visible only to the code inside that mixin:

@mixin button-style {
    $btn-bg-color: lightblue;
    color: $btn-bg-color;
}

Next, we can call the mixin as follows:

button { @include button-style; }

The resulting CSS:

button { color: lightblue; }

Imagine, however, that we also want to use this variable (not the mixin) in another selector:

.wrap { background: $btn-bg-color; }

This would give us the following error:

Undefined variable: "$btn-bg-color".

That was to be expected, right? We tried to access a mixin variable, which is locally scoped. Don't worry though, as mentioned above, we'll fix this issue in an upcoming section.

Nested Selectors

It's worth also mentioning that if we declare a variable inside a selector, any other nested selector can access it. Here's an example:

.wrap {
    $bg-color: red;
    &:after {
        background: lighten($bg-color, 10%);
    }
}

This compiles to:

.wrap:after { background: #ff3333; }

However, look at the example below where we define a function, then use that function along with a nested selector:

@function my-function() {
    $text-color: black;
    @return $text-color;
}
     
.wrap {
    color: my-function();
    &:after{
        background: $text-color;
    }
}

If we try to compile this, we'll get the same error discussed before. Again, that happens because we can't access the text-color variable. It isn't directly defined within the parent selector, but inside the function that our selector calls.

Variable Names

Global and local variables can have the same names. To demonstrate that behavior, we'll work on a fourth example:

$text-color: tomato;
 
@mixin button-style {
    $text-color: lime;
    color: $text-color;
}
     
@mixin link-style {
    $text-color: black;
    color: $text-color;
}

Here we've defined three different variables (text-color) with the same name. The first one is a global variable, while the other two are local.

Here are some styles making use of them:

button { @include button-style; }
a { @include link-style; }
.wrap { background: $text-color; }

And the generated CSS:

button { color: lime; }
a { color: black; }
.wrap { background: tomato; }

Is that what you were expecting?

Keep in mind that we won't see these styles unless we compile with the current version of Sass (3.4). For example, supposing that we use Sass 3.3, our CSS output would look like this:

button { color: lime; }
a { color: black; }
.wrap { background: black; }

Notice the difference in the background color of the .wrap selector. This happens because according to the earlier Sass versions (same for LibSass), if we locally redefine the value of a global variable (e.g. text-color), this will be the variable's new (global) value. So, in our example the compiled styles depend on the order we declare the variable and the mixins.

The default flag

This flag allows us to set the value of a variable in case it hasn't already been set or its current value is null (treated as unassigned). To better explain how we can take advantage of it in a real scenario, let's suppose that we have a project with the following structure:

Project-Name/
├── ...
├── css/
│ └── app.css
└── scss/
├── _config.scss
├── _variables.scss
├── _mixins.scss
└── app.scss

The app.scss file looks like this:

@import "config";
@import "variables";
@import "mixins";
     
button { @include button-style; }
 
// more styles

Let's see the contents of the partial files.

Firstly, the variables.scss file contains our variables:

$btn-bg-color: lightblue !default;
$btn-bg-color-hover: darken($btn-bg-color, 5%);
     
// more variables

Notice the default flag assigned to the btn-bg-color variable.

Secondly, the mixins.scss file includes our mixins:

@mixin button-style ($bg-color: $btn-bg-color, $bg-color-hover: $btn-bg-color-hover) {
    background-color: $bg-color;
    // more styles
    &:hover {
        background-color: $bg-color-hover;
        // more styles  
    }
}
     
// more mixins

Then, the generated app.css file will be as follows:

button { color: lightblue; }
button:hover { background-color: #99cfe0; }

So, our buttons come with default styles. But let's suppose that we want to have the option to overwrite them by applying our custom values. To do this, we can reassign the desired (default) variables in the config.scss partial file:

$btn-bg-color: chocolate;
// more variables

Setting the value of this variable to chocolate will result in ignoring the corresponding value (lightblue) that has received the default flag. Therefore, the generated CSS changes as we can see below:

button { color: chocolate; }
button:hover { background-color: #bc5e1b; }

Note: in case we haven't added the default flag to the btn-bg-color variable, our CSS would be, due to the cascading nature of CSS, as follows:

button { color: lightblue; }
// hover styles

The global flag

This second flag helps us change the scope of a local variable.

Do you remember the error we saw in our first example? Well, that happened because we tried to use the btn-bg-color variable in the .wrap selector. Let's modify our example to include this new flag. Here are the new styles:

@mixin button-style {
    $btn-bg-color: lightblue !global;
    color: $btn-bg-color;
}

button { @include button-style; }

.wrap { background: $btn-bg-color; }

As you can see below, thanks to this flag, the CSS compiles without any errors:

button { color: lightblue; }
.wrap { background: lightblue; }

The global flag is useful, but bear in mind that it's not always good practice to change a variable's scope.

Checking if a Variable Exists

Sass provides two introspection functions for testing whether a variable exists or not. We can use the variable-exists and/or global-variable-exists functions to check if our local and/or global variables exist respectively.

For example, here's a common use case where we define a variable containing the absolute path to a Google Font. Then, we choose to import that font in our stylesheets, but only if the relevant variable has been instantiated.

$google-font: "http://fonts.googleapis.com/css?family=Alegreya";

@if(global-variable-exists(google-font)) {
    @import url($google-font);
}

The result:

@import url("http://fonts.googleapis.com/css?family=Alegreya");

Conclusion

In this article, I introduced you to the concept of variable scope in Sass. To make things clearer we looked at different examples, so hopefully you now have a good understanding of how scope works. You can find all the examples of this article in this SassMeister gist.

Tuesday, April 07, 2015

Simple Inheritance with JavaScript

Simple Inheritance with JavaScript

JavaScript uses a different approach than C# or C++ to create an object-oriented language. It is a prototype-based language. The concept of prototyping implies that behavior can be reused by cloning existing objects that serve as prototypes. Every object in JavaScript decends from a prototype which defines a set of functions and members that the object can use. There is no class. Just objects. Every object can then be used as a prototype for another object.

This concept is extremely flexible and we can use it to simulate some concepts from OOP like inheritance.

Implementing Inheritance

Let's visualize what we want to create with this hierarchy using JavaScript:

Simple Inheritance with JavaScript

First of all, we can create ClassA easily. Because there are no explicit classes, we can define a set of behavior (A class so…) by just creating a function like this:

var ClassA = function() {
    this.name = "class A";
}

This "class" can be instantiated using the new keyword:

var a = new ClassA();
ClassA.prototype.print = function() {
    console.log(this.name);
}

And to use it using our object:

a.print();

Fairly simple, right?

The complete sample is just 8 lines long:

var ClassA = function() {
    this.name = "class A";
}
 
ClassA.prototype.print = function() {
    console.log(this.name);
}
 
var a = new ClassA();
 
a.print();

Now let's add a tool to create "inheritance" between classes. This tool will just have to do one single thing: clone the prototype:

var inheritsFrom = function (child, parent) {
    child.prototype = Object.create(parent.prototype);
};

This is exactly where the magic happens! By cloning the prototype, we transfer all members and functions to the new class.

So if we want to add a second class that will be a child of the first one, we just have to use this code:

var ClassB = function() {
    this.name = "class B";
    this.surname = "I'm the child";
}
 
inheritsFrom(ClassB, ClassA);

Then because ClassB inherited the print function from ClassA, the following code is working:

var b = new ClassB();
b.print();

And produces the following output:

class B

We can even override the print function for ClassB:

ClassB.prototype.print = function() {
    ClassA.prototype.print.call(this);
    console.log(this.surname);
}

In this case, the produced output will look like this:

class B 
I'm the child

The trick here is to the call ClassA.prototype to get the base print function. Then thanks to call function we can call the base function on the current object (this).

Creating ClassC is now obvious:

var ClassC = function () {
    this.name = "class C";
    this.surname = "I'm the grandchild";
}
 
inheritsFrom(ClassC, ClassB);
 
ClassC.prototype.foo = function() {
    // Do some funky stuff here...
}
 
ClassC.prototype.print = function () {
    ClassB.prototype.print.call(this);
    console.log("Sounds like this is working!");
}
 
var c = new ClassC();
c.print();

And the output is:

class C 
I'm the grandchild 
Sounds like this is working!

More Hands-on with JavaScript

It might surprise you a bit, but Microsoft has a bunch of free learning on many open source JavaScript topics and we’re on a mission to create a lot more with Project Spartan coming. Check out my own:


And some free tools: Visual Studio Community, Azure Trial, and cross-browser testing tools for Mac, Linux, or Windows.

Tuesday, April 07, 2015

CSS3 Multi-column Layouts

CSS3 Multi-column Layouts

The CSS multi-column layout uses new CSS properties which allow designers to break a layout into blocks. The two main properties which control the number of columns are: column-count and column-width.

Related Properties

  • column-width
  • column-count
  • column-gap
  • column-rule
  • column-rule-width
  • column-rule-style
  • column-rule-color
  • column-span
  • column-fill
  • columns

Degradation

Column properties are ignored by browsers which don't support them. To deal with that issue, create a single column layout for unsupported browsers and multiple columns with browsers that support them.

Note: To make sure you can use multiple columns, each property needs to be written three times: Once with the -moz prefix, once with the -webkit prefix, and once without the prefix.

Syntax

Here are some examples of how you would use the multi-column properties:

Here's how to use column-count:



Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut eu augue orci. Morbi tristique a felis et varius. Sed augue nunc, cursus sed congue sit amet, mollis sed risus. Aliquam sit amet fringilla nisl. Vivamus ullamcorper odio magna, ut sagittis justo accumsan at. Donec turpis turpis, sagittis vel nisl eget, sodales ullamcorper eros. Etiam ut velit non sapien tincidunt ultrices in et nisi.

You use the column-width property to set the smallest column width. If you don't set the column-count, the browser will take over and create as many columns as necessary to fit the width. Here's the code:



Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut eu augue orci. Morbi tristique a felis et varius. Sed augue nunc, cursus sed congue sit amet, mollis sed risus. Aliquam sit amet fringilla nisl. Vivamus ullamcorper odio magna, ut sagittis justo accumsan at. Donec turpis turpis, sagittis vel nisl eget, sodales ullamcorper eros. Etiam ut velit non sapien tincidunt ultrices in et nisi.

Here is an example which makes use of column-count, column-gap, and column-rule:


Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut eu augue orci. Morbi tristique a felis et varius. Sed augue nunc, cursus sed congue sit amet, mollis sed risus. Aliquam sit amet fringilla nisl. Vivamus ullamcorper odio magna, ut sagittis justo accumsan at. Donec turpis turpis, sagittis vel nisl eget, sodales ullamcorper eros. Etiam ut velit non sapien tincidunt ultrices in et nisi. Phasellus fringilla quam rutrum, semper neque pretium, fermentum justo. Suspendisse convallis, purus vitae mollis semper, est justo pretium neque, sit amet convallis nisi justo vel justo. Integer vestibulum, felis vel ultricies ornare, diam risus viverra odio, at tempus elit tellus quis purus. Sed porta, eros vel vehicula sollicitudin, nisi orci maximus magna, vitae commodo dui magna nec libero.

CSS3 Multi-column Layouts

Height Balancing

With the CSS3 Column specification the browser automatically sets the column height so the content in each column are similar. That said, you might want to set the height manually using the CSS height or max-height properties and then build your layout accordingly.

Resources


Tuesday, March 31, 2015

A Baseline for Front-End [JS] Developers: 2015

A Baseline for Front-End [JS] Developers
It's been almost three years since I wrote A Baseline for Front-End Developers, probably my most popular post ever. Three years later, I still get Twitter mentions from people who are discovering it for the first time.

In some ways, my words have aged well: there is, shockingly, nothing from that 2012 post that has me hanging my head in shame. Still, though: three years is a long time, and a whole lot has changed. In 2012 I encouraged people to learn browser dev tools and get on the module bandwagon; CSS pre-processors and client-side templating were still worthy of mention as new-ish things that people might not be sold on; and JSHint was a welcome relief from the #getoffmylawn admonitions – accurate though they may have been – of JSLint.

It's 2015. I want to write an update, but as I sit down to do just that, I realize a couple of things. One, it's arguably not fair to call this stuff a "baseline" – if you thought that about the original post, you'll find it doubly true for this one. One could argue we should consider the good-enough-to-get-a-job skills to be the "baseline". But there are a whole lot of front-end jobs to choose from, and getting one doesn't establish much of a baseline. For me, I don't want to get a job; I want to get invited to great jobs. I don't want to go to work; I want to go to work with talented people. And I don't want to be satisfied with knowing enough to do the work that needed to be done yesterday; I want to know how to do the work that will need to get done tomorrow.

Two, my world has become entirely JavaScript-centric: knowledge of the ins and outs of CSS has become less and less relevant to my day-to-day work, except where performance is concerned. I know there are plenty of very smart front-end developers for whom this isn't true, but I have also noticed a growing gulf between those who focus on CSS and those who focus on JavaScript. That's probably a subject for another blog post, but I bring it up just to say: I am woefully unequipped to make recommendations about what you should know about CSS these days, so I'm not going to try.

In short: if this list of things doesn't fit your vision of the front-end world, that's OK! We're both still good people. Promise.

JavaScript

Remember back in 2009 when you read that HTML5 would be ready to use in 2014, and that seemed like a day that would never come? If so, you're well prepared for the slow-but-steady emergence of ES6 (which is now called ES2015, a name that is sure to catch on any day now), the next version of JavaScript. Getting my bearings with ES6 – er, ES2015 – is hands-down my biggest JavaScript to-do item at the moment; it is going to be somewhere between game-changing and life-altering, what with classes, real privacy, better functions and arguments, import-able modules, and so much more. Those who are competent and productive with the new syntax will have no trouble standing out in the JS community. Required reading:

  • Understanding ES6, a work-in-progress book being developed in the open by Nicholas Zakas.
  • BabelJS, a tool that lets you write ES6 today and "compile" it to ES5 that will run in current browsers. They also have a good learning section.
  • ES6 Rocks, with various posts that explore ES6 features, semantics, and gotchas.

Do you need to be an ES6/ES2015 expert? Probably not today, but you should know at least as much about it as your peers, and possibly more. It's also worth at least entertaining the possibility of writing your next greenfield project using ES6; the future will be here before you know it.

New language features aside, you should be able to speak fluently about the asynchronicity of JavaScript, and using callbacks and promises to manage it. You should have well-formed opinions about strategies for loading applications in the browser and communicating between pieces of an application. You should maybe have a favorite application development framework, but not at the expense of having a general understanding of how other frameworks operate, and the tradeoffs you accept when you choose one.

Modules & Build Tools

There's no debate that modules should be the building blocks of client-side web applications. Back in 2012, there was lots of debate about what kind of modules we should use for building apps destined for the browser – AMD or CommonJS. The somewhat-gross UMD wrapper arose to try to avoid answering the question while still allowing code reuse – because hey, what's a few more bytes between friends?

I don't feel like this debate is anywhere near resolved, but this is the area where I feel like we've seen the largest transformation since my 2012 article, though perhaps that's a reflection of my personal change of heart. I'm not ready to say that I'm done with AMD, but let's just say I'm floored by how practical it has become to develop and deploy web applications using CommonJS, including modules imported with npm.

With much love for all that RequireJS has contributed to the module conversation, I'm a bit enamored of webpack right now. Its features – such as easy-to-understand build flags – feel more accessible than RequireJS. Its hot-swap builds via its built-in dev server make for a fast and delightful development story. It doesn't force an AMD vs. CommonJS decision, because it supports both. It also comes with a ton of loaders, making it fairly trivial to do lots of common tasks. Browserify is worth knowing about, but lags far behind Webpack in my opinion. Smart people I trust tell me that systemjs is also a serious contender in this space, but I haven't used it yet, and its docs leave me wanting. Its companion package manager jspm is intriguing, allowing you to pull in modules from multiple sources including npm, but I'm a bit wary of combining those two concerns. Then again, I never thought I'd break up with AMD, yet here I seem to be, so we'll see.

I still long for a day when we stop having module and build tool debates, and there is a single module system and sharing code between arbitrary projects becomes realistic and trivial without the overhead of UMD. Ideally, the arrival of ES6 modules will bring that day – and transpilers will fill in the gaps as the day draws closer – but I find it just as likely that we'll keep finding ways to make it complicated.

In the meantime, front-end developers need to have an opinion about at least a couple of build tools and the associated module system, and that opinion should be backed up by experience. For better or worse, JavaScript is still in a state where the module decision you make will inform the rest of your project.

Testing

Testing of client-side code has become more commonplace, and a few new testing frameworks have arrived on the scene, including Karma and Intern. I find Intern's promise-based approach to async testing to be particularly pleasing, though I confess that I still write most of my tests using Mocha – sometimes I'm just a creature of habit.

The main blocker to testing is the code that front-end devs tend to write. I gave a talk toward the end of 2012 about writing testable JavaScript, and followed up with an article on the topic a few months later.

The second biggest blocker to testing remains the tooling. Webdriver is still a huge pain to work with. Continuous automated testing of a complex UI across all supported browsers continues to be either impossible, or so practically expensive that it might as well be impossible – and never mind mobile. We're still largely stuck doing lightweight automated functional tests on a small subset of supported browser/device/OS combinations, and leaning as hard as we can on lower-level tests that can run quickly and inexpensively. This is a bummer.

If you're interested in improving the problem of untested – or untestable – code, the single most valuable book you can read is Working Effectively with Legacy Code. The author, Michael Feathers, defines "legacy code" as any code that does not have tests. On the topic of testing, the baseline is to accept the truth of that statement, even if other constraints are preventing you from addressing it.

Process Automation

You, hopefully, take for granted the existence of Grunt for task automation. Gulp and Broccoli provide a different approach to automating builds in particular. I haven't used Broccoli, and I've only dabbled in Gulp, but I've definitely come to appreciate some of the limitations of Grunt when it comes to automating complex tasks that depend on other services – especially when that task needs to run thousands of times a day.

The arrival of Yeoman was a mere 45 days away when I wrote my 2012 post. I confess I didn't use it when it first came out, but recently I've been a) starting projects from scratch using unfamiliar tech; and b) trying to figure out how to standardize our approach to developing third-party JS apps at Bazaarvoice. Yeoman really shines in both of these cases. A simple yo react-webpack from the command line creates a whole new project for you, with all the bells and whistles you could possibly want – tests, a dev server, a hello world app, and more. If React and Webpack aren't your thing, there's probably a generator to meet your needs, and it's also easy to create your own.

Given that Yeoman is a tool that you generally use only at the start of a project, and given that new projects don't get started all the time, it's mostly just something worth knowing about. Unless, of course, you're also trying to standardize practices across projects – then it might be a bit more valuable.

Broccoli has gotten its biggest adoption as the basis for ember-cli, and folks I trust suggest that pairing may get a makeover – and a new name – to form the basis of a Grunt/Yeoman replacement in the future. Development on both Grunt and Yeoman has certainly slowed down, so it will be interesting to see what the future brings there.

Code Quality

If you, like me, start to twitch when you see code that violates a project's well-documented style guide, then tools like JSCS and ESLint are godsends, and neither of them existed for you to know about them back in 2012. They both provide a means to document your style guide rules, and then verify your code against those rules automatically, before it ever makes it into a pull request. Which brings me to…

Git

I don’t think a whole lot has changed in the world of Git workflows since 2012, and I'd like to point out Github still hasn't made branch names linkable on the pull request page, for f@#$s sake.

You should obviously be comfortable working with feature branches, rebasing your work on the work of others, squashing commits using interactive rebase, and doing work in small units that are unlikely to cause conflicts whenever possible. Another Git tool to add to your toolbox if you haven't already is the ability to run hooks – specifically, pre-push and pre-commit hooks to run your tests and execute any code quality checks. You can write them yourself, but tools like ghooks make it so trivial that there's little excuse not to integrate them into your workflow.

Client-Side Templating

This may be the thing I got the most wrong in my original post, for some definition of "wrong". Client-side templating is still highly valuable, of course – so valuable that it will be built-in to ES2015 – but there can be too much of a good thing. It's been a hard-earned lesson for lots of teams that moving all rendering to the browser has high costs when it comes to performance, and thus has the "generate all the HTML client-side" approach rightfully fallen out of favor. Smart projects are now generating HTML server-side – maybe even pre-generating it, and storing it as static files that can be served quickly – and then "hydrating" that HTML client-side, updating it with client-side templates as events warrant.

The new expectation here – and I say this to myself as much as to anyone else – is that you are considering the performance implications of your decisions, and maybe not restricting yourself quite so thoroughly to the realm of the browser. Which, conveniently, leads to…

Node

You say you know JavaScript, so these days I expect that you can hop on over to the Node side of things and at least pitch in, if not get at least knee-deep. Yes, there are file systems and streams and servers – and some paradigms that are fundamentally different from front-end dev – but front-end developers who keep the back end at arm's length are definitely limiting their potential.

Even if your actual production back-end doesn't use Node, it's an invaluable tool when it comes to keeping you from getting blocked by back-end development. At the very least, you should be familiar with how to initialize a Node project; how to set up an Express server and routes; and how use the request module to proxy requests.

via rmurphey.com by

Wednesday, March 18, 2015

6 advanced web typography tips

6 advanced web typography tips

Elliot Jay Stocks reveals how to take your web-based typography to the next level.

Typography on the web has made huge leaps forward in recent years, allowing web designers to realise their designs with an almost print-like level of control. However, the details surrounding that control can still be challenging, and bleeding-edge technology like OpenType support is still in flux.



In his talk at Generate London, Typekit's creative director and 8 Faces founder Stocks took attendees through some of the most exciting recent developments that allow us to take web-based typography to the next level. Here are six tips of Stock's tips for upping your type game on the web…

01. Use font-feature-settings

Ligatures are very widely supported – they're on by default in Firefox and are very easy to turn on. This is often how people turn on ligatures and a bunch of other Open Type features: text-rendering: optimizeLegibility;

However, use with caution. A far more powerful way of doing so is: font-feature-settings.

This allows you to be a little more granular; to go in and say: "I want to turn this specific Open Type feature on or off". Also, optimizeLegibility isn't standardised and is a little bit buggy so generally not recommended – especially for body text.

02. Consider the typeface

The typeface is the design – the thing that exists in the ether that was created by the designer. Does the actual design contain swashes? Ligatures?

If it's not in the actual design, it's never going to make it into the font file and will certainly never make it to your browser. At the base level: did the person who designed this typeface actually design your secondary A style set option? Possibly not.

03. Consider the font file

Is it actually an OpenType font file being served? You're never going to be able to turn on an OpenType setting if you're serving a TrueType font, so this is a really important thing to consider. Even if it is OpenType, are the actual glyphs that you need inside the font file? Possibly not.

04. Consider the browser

Some browsers support some features, some they don't, some it's different on different operating systems. No matter how robust your CSS is, if you're testing it in a browser that physically doesn't support that feature, you're not going to see it.

05. Consider the user

Will the design break if ligatures are missing? Probably not. But it quite possibly will if the swash characters are missing and you're actually representing the company logo in web type. Perhaps, in that circumstance, you need to find another way of doing it.

06. Be responsible

Responsive web design is where our heads are at – but it's also about responsible web design. All these cool new shiny features are great, but we need to be mindful of when we use them. Pick the right features you want for the right scenario. This is a really exciting time to be working not he web because we've essentially caught up with what you can do in print.

Words: Elliot Jay Stocks

Wednesday, March 18, 2015

Important factors of on-page optimization and SEO checklist

optimization and SEO

Content

  • Content should be original and unique
  • Content will reached with reference
  • You have a clear content strategy
  • You have to write the content with related keywords in it's body

Friday, February 27, 2015

How to Make Your WordPress Site Blazing Fast

WordPress Site

Today's web users have the need for speed. With internet and cellular connections getting faster and faster, users expect sites to feel snappy. As developers, we must make sure we're doing our best to serve those pages quickly. This article will focus on what you should be doing to make sure your WordPress sites are as fast as possible.

Make your Wordpress site blazing fast

There are essentially two main categories that performance can be broken down into: front-end and back-end. Back-end is anything related to the server and how data is populated on a page (PHP code in your theme is the "back-end"). The front-end consists of all your assets (CSS, JavaScript, images, etc.) and markup. Everything a web browser reads and interprets is the "front-end". This distinction is important because it's good to know what you're optimizing and, even more importantly, where you need to optimize the most.

To actually test site speed, use a combination of WebPagetest and Google PageSpeed Insights. WebPagetest gives you a good idea of the actual time (in seconds) that a site takes to load, explaining where bottlenecks may be. PageSpeed Insights is best for looking at how your front-end is site is rendered by the browser.

Front-end performance

The golden rule of performance, according to Fastly's Steve Souders is that 80-90% of a page's total load time consists of the front-end. The back-end's 10-20% is crucially important, but even if you're using the fastest host around, your site still won't live up to its full potential without optimizing the front-end and users perceive it to load quickly. Perception is an important part of front-end optimization. A user doesn't care how many seconds a site takes to load. A user cares about how quickly they can interact with a site without a delay. Not that you shouldn't be worried about the actual load time (you should), but by following these techniques, you can make sure that your site is in a usable state fast, before loading the rest of the page assets.

WordPress Site

CSS

Before delivering CSS to the browser, it’s important to compress it and remove unused selectors.

Once your stylesheet is ready to go, the easiest (and standard) way to load it is to reference it in the head. The browser will load and parse it before the rest of the DOM is loaded. However, there's a new technique where "critical" styles are inlined in the head and then the full stylesheet is loaded asynchronously using JavaScript. This technique can be used when trying to get a site to load (or perceive to load) in under a second, but it's a great tool to keep in your arsenal. Check out this great extensive article on using this technique.

WordPress Site

JavaScript

The golden rule(s) of optimizing JavaScript are simple: serve as few JavaScript files as possible and minify and concatenate. Third-party WordPress plugins can bloat your document with unminified blocking JavaScript files, so it's important to be mindful when choosing plugins. Ideally, you'd concatenate ALL JavaScript files into one and then minify it. When that's not possible, HTML attributes called async and defer can be used to load JavaScript files asynchronously or once the rest of the page is loaded.

The most common place to reference JavaScript is at the bottom, right before the closing tag. However, there are more advanced techniques to load JavaScript. The Filament Group has several tools you can use for this. The best approach is to load scripts dynamically by inlining a small function in the head that appends script tags without blocking the rest of the page. For more information, check out the loadJS script.

Images

Images are often the biggest files on a page, responsible for the largest load time delay. The good thing about images is that, unlike CSS and JavaScript, most browsers load them asynchronously. That helps with the perceived performance of a page. But it's still important that A) you're serving as few images as possible and B) those images are compressed as much as possible.

Compression tools are necessary for squeezing out as much excess as possible on images. ImageOptim is a great free Mac compression app, along with OptiPNG and jpegtran for use with task runners like Grunt.

WordPress Site

Fonts

Web fonts are super common these days. Google Web Fonts make sites pop. It's easy to not realize the performance hit you take by just referencing them in the head. The performance hit is small, but every little bit counts! For best performance using web fonts, check out the the Web Font Loader, co-developed by Google and Typekit. It's an open source script that both manages the loading of your fonts from third parties like Google Web Fonts and allows them to load asynchronously (getting tired of that word yet?).

As to be expected, there's some configuration needed to get Web Font Loader integrated into your project, so check out the project on GitHub for setup info.

WordPress Site

Back-end performance

The front-end has all kinds of tricks for speed, but we're not so fortunate on the back-end. A server is either fast or it's not. It's critical that your site gets to the browser as quickly as possible, which can be accomplished by getting on a quality host. Managed hosts like Flywheel are the most realistic way to see true performance gains for WordPress sites.

Dedicated Wordpress Hosts

There are are a host of managed WordPress hosts (pun intended). What managed hosts typically provide is a dedicated VPS (virtual private server), a caching layer and other infrastructural bonuses that set them apart from your typical shared hosting. These all matter when it comes to loading your site fast, so the best and first step to a super fast WordPress site should be the host.

For example, let's take a look at Flywheel. Flywheel is a managed host, and their infrastructure is designed so your sites never touch another customer's. Compared to a host that crams as many sites as possible on the same server, having your site on a server by itself works magic for speed. It means that server's resources are just working for you, not for everyone else.

WordPress Site

Theme Logic

There are many things you can do while developing to make your back-end as performant as possible. Nasty loops that do tons of comparisons and use lots of memory slow down a site down. There are lots of articles on performant PHP, but just take care when writing theme logic!

Another important time saver during database queries is the Transients API. WordPress transients store cached data in the database temporarily, which means your logic only has to run once (whenever the first visitor loads the page). The results are then stored in the database. The Codex has good documentation on the usage of transients.

Caching

Caching assets is one of the best ways to improve performance. Once a user loads your site the first time, you can take advantage of browser capabilities to cache the contents of that site locally, so on the next visit the user already has them loaded. The most common WordPress caching tool is W3 Total Cache plugin. This plugin (or one similar) is needed on most shared hosts. However, WordPress specific hosts like Flywheel handle caching for you behind the scenes. With hosts like Flywheel, all of the caching is done on the server outside of WordPress, which means your sites are already tuned for max performance.

WordPress Site

GZIP

Gzip is a file format that's used to compress other files together, similar to just zipping files. Gzipping allows files to be sent over the web at a compressed size. Once a browser receives gzipped data, it unzips it to get the source data. Gzipping is super important for speed, as it sends your data over the wire in much smaller packages (50 - 70% smaller, in fact). Smaller file size equals faster load times!

You should always check to see if your host supports Gzipping. Managed WordPress hosts like Flywheel enable Gzip compression by default, so it's one less to to worry about!

WordPress Site

CDN

A content delivery network (or CDN) is a network of servers that serves up your website and its assets from different locations based on the user's location. For example, let's say you're not using a CDN and your site is hosted in San Francisco. When someone from, say, Spain visits your site, they have to retrieve all your assets from your server in San Francisco. The long distance between the two locations clearly takes longer than if someone from San Francisco loads your site that's hosted in San Francisco. A CDN serves your assets from the closest geographical data center. Users will hit the server closest to them, speeding up the physical time and distance required to load the page.

Some of the most popular CDNs include Amazon Web Services, CloudFlare and MaxCDN. If you want a super easy setup, check out Flywheel's MaxCDN add-on.

WordPress Site

Conclusion

Tuning a web site to maximum capacity can be challenging. There are a lot of moving parts. By working through both the front end and the back end, a site can be designed or overhauled for maximum speed. On the front end, saving as much time and space as possible means the con-tent you’re serving gets to the content faster. But if even if your front end is brilliantly designed, none of that will matter the servers you host the site on aren’t running at their peak performance. Managed WordPress hosts tune sites to peak performance and take out the frustrations behind web hosting. Hosts like Flywheel will not only make your site fly, but make your hosting experience worry-free.


Tuesday, February 24, 2015

The Problem With Raw CSS

The Problem With Raw CSS

Writing raw CSS is not a pleasure nowadays. Pure CSS has a very simple and, as a side effect, very inflexible syntax that doesn't always suited our needs in building high quality products. The overall complexity of systems are increasing day by day and modern web developers need more and that's why CSS preprocessors exist.

The Overall Structure

In order to explain what a CSS preprocessor is and why we should use this kind of tools I'll build a little demo with raw CSS. After that I'll take this further by translating it in sass, the preprocessor of our choice for this article. This demo will be big enough to see the difference between each tool. I'll try also to explain along the way some new concepts about preprocessors pretty quickly, so that you can start using those right now.

For the rest of this article I'll use this HTML structure:

...

I'll skip the repetition from the code, just to be clear. You can taste full code listing and the demo in this codepen. Later we'll discuss about implementing this demo using sass, the preprocessor we used to talk about in this article.

See the Pen yyvBVZ by Andrei Glingeanu (@andreiglingeanu) on CodePen.


Sass: Syntactically Awesome Style Sheets

Installation

We have 2 options: to use command line or a GUI application.

If you have ruby installed on your system, be it windows, osx or linux, you can type into command line this line to install sass:

gem install sass

Now you should have sass binary on your computer. You can compile a file named input.sass into corresponding output.css using command below. We have --watch switch to indicate that we want to recompile automatically as we change the input.sass file.

sass --watch input.sass:output.css

Another option will be to use a tool like Prepros to compile sass files for you. Many other options at Official Installation Page.

Nesting rules

The most used feature that preprocessor gives us is rules nesting, just like we nest elements in each other in HTML. For example, when we write a rule like this:

#main-content {
    h1 {
        em {
            text-transform: uppercase;
        }
    }
}

it will generate the following CSS:

#main-content h1 em {
    text-transform: uppercase;
}

Using variables

We can treat variables as a named container, where we can put several things. For example we can store a color in a variable and use this color in multiple places. Storing a size in a variable, be it in pixels, percents or ems, is also a good idea. Let's see a demo using variables next.

$itemBackground: #867e7e;
$itemPadding: 5px;

ul.menu {
  list-style: none;
  padding: 0;
  
  li {
    display: inline-block;

    background: $itemBackground;
    transition: background .5s ease-in;
    
    // we can use several functions to modify our colors
    // here we lighten $itemBackground by 50% in order to ensure
    // that we are able to read the text
    color: lighten($itemBackground, 50%);
    
    padding: $itemPadding;
    // we can use arithmetic operations, if variable is a number
    margin-right: $itemPadding * 2;
    
    cursor: pointer;
    font-size: 2em;
  }

}


See how I defined variable $itemBackground in order to store background color for our menu? This is a very common pattern to define our palette of colors at the top and then use this colors throughout the file by explicit name. In this way we can change all colors very easily. In this demo we also have used rules nesting.

Another trick about storing colors in variables is that we can modify them using several predefined functions like:

  • lighten
  • darken
  • saturate
  • alternate

You can see full list of them and their usage on this great resource.

Parent reference

Sometimes, when using rules nesting we need a way to reference the element inside we nest rules. Let's say we need a way to target paragraphs inside an article, but only those who have the class special. We can express it this way:

article {
    p {
        color: #333;

        &.special {
            color: #f00;
        }
    }
}

The key idea here is to use & in order to reference the current element. Sass will give us back the following css:

article p {
    color: #333;
}

article p.special {
    color: #f00;
}

We can use this trick in order to target all the pseudo elements and pseudo classes of current element together. In this demo you'll see how I target :last-child in order to give it margin-right: 0; and also how to style :hover pseudo class for lis using &.

$itemBackground: #867e7e;
$itemPadding: 5px;

ul.menu {
  list-style: none;
  padding: 0;
  
  li {
    display: inline-block;

    background: $itemBackground;
    transition: background .5s ease-in;
    
    // we can use several functions to modify our colors
    // here we lighten $itemBackground by 50% in order to ensure
    // that we are able to read the text
    color: lighten($itemBackground, 50%);
    
    padding: $itemPadding;
    // we can use arithmetic operations, if variable is a number
    margin-right: $itemPadding * 2;
    
    cursor: pointer;
    font-size: 2em;
    
        
    &:hover {
      // another function which modifies color
      background: darken($itemBackground, 10%);
    }

    &:last-child {
      margin-right: 0;
    }
  }
  

}


Mixins and extending rules

In a nutshell, mixins are a way to encapsulate many useful properties into one block, and then using @include insert this properties into our rule. This is somewhat a similar concept to functions in JavaScript and PHP. The main idea is that you can pass different parameters to the mixin, and it will return you the right properties, depending on the parameters you passed. Let's see an example where we define a mixin in order to write vendor prefixes for transform property.

@mixin transform($transformation) {
  -webkit-transform: $transformation;
  transform: $transformation;
}

div {
  width: 100px;
  height: 100px;
  background: red;

  @include transform(translate(40px));
}


Let's see, here we have transform mixin, and we include it into div, using @include. As a named parameter $transformation we receive translate(40px). The generated css for this mixin will look like this:

-webkit-transform: translate(40px);
transform: translate(40px);

Another way of reusing existing styles is to @include already existing rules. This one is not so common as mixins, because it does not have the ability to pass parameters to it, therefore it is not so flexible. You'll have an example on using this technique in the final demo for sass.

Hence, we have many ways to not repeat ourselves by defining mixins and including already existing rules. There is available online many collections of predefined mixins for sass, which provide many neat things. Most popular ones are bourbon and susy. You can read about them by clicking on the links I provided for you. Among the others, susy is a great alternative to bootstrap grids and it will prevent your html being polluted with unsemantic classes like col-md-4. You definitely should check them out.

Reimplementing demo

Now let me give you a full reimplementation of our kitties using sass, you can skim through code on codepen, it is very simple. Try to reveal all the new concepts we've covered here in the code for this demo.

See the Pen JopZRj by Andrei Glingeanu (@andreiglingeanu) on CodePen.


Conclusion

As a conclusion, all the preprocessors and sass specifically gives us a more flexible way to structure our styles, in comparison to pure css. Now all the nesting from HTML is expressed very naturally in our stylesheets. We also don't repeat ourselves by writing colors and scalar values, which is highly error prone and is very easily to commit a mistake by using sass variables. The ability to group multiple rules under one named mixin is also a beautiful and readable way of structuring css.

These little explanations should really get you started on using sass. If you really want more you can go ahead and read official guide for this preprocessor. You may find useful documentation, which gives many more ideas and insights on using and integrating sass on different platforms and development stacks.