A long standing layout challenge for front end folks has been the “sticky footer” layout. A sticky footer is one that sticks to the bottom of the page if there's not enough content to fill up a minimum of 100% the screen height, but also one that gets pushed further down the viewport like normal if there is enough content.

![Sticky footer visual](//images.ctfassets.net/rex0us6r928o/4Lh0I4fMog7BWHpsRkmgjX/400d8607840dcc29a17f6393ea8df678/sticky-footer-visual.png)

Nowadays, it's pretty simple to achieve this layout! We're going to explore two ways:

1. Using [Flexbox](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout)
2. Using [Grid](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout)

But first, let's look at some common HTML and CSS for our layout.

## The Common HTML and CSS

I'm going to structure my layout pretty simply, with a `header`, `main`, and `footer`, and I'll wrap all of those in a `.wrapper` element:

```html
<div class="wrapper">
  <header></header>
  <main></main>
  <footer></footer>
</div>
```

This gives me a pretty contained structure to work with, and some easy targets for my layout. As far as the styling goes, we'll want to make sure that our `.wrapper` element is at least the height of the viewport at all times:

```css
.wrapper {
  min-height: 100vh;
}
```

**Note: I use [normalize.css](https://necolas.github.io/normalize.css/) in pretty much all of my projects, which does quite a bit of “normalization” of CSS across browsers. If you're not keen on using a library, then the one important thing of note is the margin reset on the `body` tag:**

```css
body {
  margin: 0;
}
```

Right! Let's jump into the specifics.

## The Flexbox Way

With Flexbox, my thought process is that I first need a [column based `flex-direction`](https://developer.mozilla.org/en-US/docs/Web/CSS/flex-direction). With that, I can then set my `header` and `footer` to occupy as much space as their contents require, while the `main` should always fill up a minimum of all of the available space left. Here's what the CSS looks like:

```css
.wrapper {
  display: flex;
  flex-direction: column;
}

header,
footer {
  flex: 0 1 auto;
}

main {
  flex: 1;
}
```

Voila! Simple. Here's a little [CodePen demo](https://codepen.io/callmenick/pen/xeRWOg) of the Flexbox version.

## The Grid Way

With CSS grid, things become even easier! Grid is such a powerful spec and is perfect for controlling these overarching layout setups like this. All we need to do in this case is target the `.wrapper` element and define our grid layout there. We'll want three rows, and like before, we'll want the `main` row to occupy a minimum of the remaining viewport height after the `header` and `footer` take up as much space as they need. Here's the (dead simple) CSS:

```css
.wrapper {
  display: grid;
  grid-template-rows: auto 1fr auto;
}
```

And that's it! Here's a [CodePen demo](https://codepen.io/callmenick/pen/rbWJpE) for the Grid version.

## Browser Support

Support for both of these APIs is really great, with [Flexbox](https://caniuse.com/#feat=flexbox) edging out [Grid](https://caniuse.com/#feat=css-grid) by just a bit due to it being around longer. If you're worried about supporting old browsers, then maybe Flexbox is for you. With this particular layout though, I'd choose CSS Grid anyway. The fallback would be extremely graceful on browsers that don't support it, as they'd just render the three blocks stacked one on top the other with no sticky footer.

Wrap Up
-------

That's just about it! We've taken a look at two powerful CSS APIs and really simplified a once non-trivial layout implementation with just a few lines of CSS. Thanks again for reading, and if you have and questions, comments, or feedback, feel free to reach out.

CSS Sticky Footer with Flexbox and Grid

## The Floated Labels Technique

When we’re dealing with inputs, there’s a host of techniques to consider in order to give users the best experience. We need to make sure that we’re giving users necessary information at all points in time, and that means finding the balance between too much and too little. Two pretty important pieces to the UX puzzle are:

1.  The `label` element which [according to the MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#The_%3Clabel%3E_element), is the only way to provide explanatory information about a form field that is _always_ appropriate

2.  The `placeholder` attribute for the `input` element, which [according to the MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#The_placeholder_attribute), lets you specify a text that appears within the `<input>` element’s content area itself when empty. It’s intended to be used to show an example input, rather than an explanation or prompt.

These two elements can be used in tandem to create instructive form UI, and one pleasant way of doing so is what I call the “floated label technique”. In this UI implementation, the user encounters this flow:

1.  They see an `input` with a `placeholder` showing some descriptive example input, and the `label` is initially hidden.
2.  When they focus on the `input` and start typing, the meaningful `label` animates and _floats_ above the input.
3.  As long at the input has a value, the label remains visible and floated above the input to remind users the original meaning of the input

This UI technique does indeed slightly bend the definitions of `label` and `placeholder` listed above, in the sense that we’re giving the `placeholder` more initial importance in having to explain the input to the user, but it’s a tradeoff for a neat UI component, and one that I’m personally comfortable making. Here’s a quick preview of what we’re going to build.

![Floated Labels Demo](//images.ctfassets.net/rex0us6r928o/1JTY6RBNrAaeURJckBc0ww/fe22abdc25fd11daa573a31f2ffecb54/floated-labels-with-placeholder-shown-demo.gif)

## Floating Labels With Only CSS

Registering a focus event, determining if an input has value, animating a hidden element into view, deciding whether it needs to stay in view or not depending on input value… this seems like a job for JavaScript, right? **Wrong!** We’re gonna use a neat CSS pseudo class, [`:placeholder-shown`](https://developer.mozilla.org/en-US/docs/Web/CSS/:placeholder-shown), to achieve the effect. From the MDN:

> The **:placeholder-shown** [CSS](https://developer.mozilla.org/en-US/docs/Web/CSS) [pseudo-class](https://developer.mozilla.org/en-US/docs/CSS/Pseudo-classes) represents any [`<input>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input) or [`<textarea>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea) element that is currently displaying [placeholder text](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-placeholder).

In other words, if an `input` has any value in it, we can safely assume that the `:placeholder-shown` pseudo class will never be reached in our CSS.

Here’s the train of thought I came up with to achieve the floated labels technique using this info:

1.  Structure my markup such that I could target my `label` as a [adjacent sibling combinator](https://developer.mozilla.org/en-US/docs/Web/CSS/Adjacent_sibling_selectors) from my `input`, and wrap the two elements in a containing `div`.
2.  Style my `input` and `label` accordingly, including the `::placeholder` pseudo element.
3.  Move the `label` to its starting position, which is vertically centred in the containing `div`, and hide it.
4.  Determine when to show the label by using a combination of the `:not`, `:focus` and `:placeholder-shown` pseudo classes:
    1.  If there’s no placeholder shown, then show the label — `input:not(:placeholder-shown) + label`
    2.  If the input is focused and the placeholder isn’t shown, then show the label — `input:focus:not(:placeholder-shown) + label`

With that in mind, let’s get to the HTML & CSS!

## Building it all

After digesting all this info, the build is actually pretty simple. Here’s the markup I came up with:

```html
<div class="Input">
  <input type="text" id="input" class="Input-text" placeholder="Your first name, e.g. Nicholas">
  <label for="input" class="Input-label">First name</label>
</div>
```

And here’s the CSS scaffolding with some comments about what’s happening at each step. The final demo down below has the full CSS, which is written up with [CSS variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables) for easy modification and maintenance.

```css
.Input {
  /**
   * Relative positioning on the wrapper is important, beecause we'll use the
   * wrapper to position the label in default and floated positions.
   */
  position: relative;
}

.Input-text {
  /**
   * Input text styles here. The font size and line height of the input are
   * important for determining precise positioning of the label. These will be
   * stored in CSS variables eventually.
   */
  display: block;
  margin: 0;
  width: 100%;
  /**
   * These props will be added in the demo once variables are defined:
   *
   * padding
   * font-size
   * line-height
   */
}

.Input-text:focus {
  /**
   * Focused input styles here.
   */
}

.Input-label {
  /**
   * The label gets absolute positioning, and a calculated set of  sizes,
   * positioning, and transforms, based on relativity to the container element
   * and input text styles.
   */
  display: block;
  position: absolute;
  opacity: 0;
  /**
   * These props will be added in the demo once variables are defined:
   *
   * bottom
   * left
   * font-size
   * line-height
   * transform
   * transform-origin
   * transition
   *
   * They will give the label default positioning and styling.
   */
}

.Input-text:placeholder-shown + .Input-label {
  /**
   * While the placeholder is visible, we want to hide the label.
   */
  visibility: hidden;
  z-index: -1;
}

.Input-text:not(:placeholder-shown) + .Input-label,
.Input-text:focus:not(:placeholder-shown) + .Input-label {
  /**
   * While the placeholder is not shown - i.e. the input has a value - we want
   * to animate the label into the floated position.
   */
  visibility: visible;
  z-index: 1;
  opacity: 1;
  /**
   * These props will be added in the demo once variables are defined:
   *
   * transform
   * transition
   *
   * They will give the label floated positioning and styling.
   */
}
```

## Full Demo In Action

If any of the above was unclear, here’s a full working demo in action for you to take a look over!

## Browser Support

Support is pretty good so far, with IE & Edge falling behind:

* **Chrome:** 47+
* **Firefox:** 51+
* **IE:** No support
* **Edge:** No support
* **Opera:** 34+
* **Safari:** 9+

You can get around lack of support by using some [fun CSS browser hacks](http://browserhacks.com/) to target IE and Edge browsers for some conditional styles to the input and label.

## Wrap Up

And that’s a wrap! I love when I discover new things in CSS, but I love even more when I can find neat ways to make them applicable. I hope you learned something and can come up with fun new ways to use the `:placeholder-shown` pseudo class. Thanks again for reading, and if you have and questions, comments, or feedback, feel free to reach out.

CSS Only Floated Labels with :placeholder-shown pseudo class

I had an idea recently. I wanted to create an “Infinity” loader using only CSS. With a small bit of digging and playing, here's what I came up with:

But how!? Before you peep at the resulting code in the above pen, take a read below to learn about some fun and new CSS properties.

## Introducing CSS offset

The `offset` property in CSS is [defined by the MDN as](https://developer.mozilla.org/en-US/docs/Web/CSS/offset):

> a shorthand property for animating an element along a defined path.

It's a fairly new and fun property that was formerly defined as `motion`. But what exactly does it entail? If you're unfamiliar with SVG, then I'll quickly point you over to my [Getting Started with Inline SVG](http://callmenick.com/post/getting-started-inline-svg) tutorial. If you are familiar, then great. The `offset` property consists of 3 separate properties working together:

- `offset-path` - specifies the path on which an object gets positioned
- `offset-distance` - specifies the object position along an `offset-path`
- `offset-rotate` - specifies the direction of the object while positioning it along an `offset-path`

In this tutorial, we're only going to make use of the first two mentioned properties. But before we have any fun, let's dig a bit further into them.

## Understanding offset-path and offset-distance

We know what an `offset-path` is now, but how do we define one? Let's grab some more source content from the MDN:

> An offset path is either a specified path with one or multiple sub-paths or the geometry of a not-styled basic shape. Each shape or path must define an initial position for the computed value of “0” for offset-distance and an initial direction which specifies the rotation of the object to the initial position.

The formal syntax definition also gives us additional implementation details, such as what we can use to define our offset path. For now, let's pay attention to paths.

## Defining our Infinity Path

The easiest way (for me, at least) to create an infinity path was to use Adobe Illustrator. From there, I flexed every ounce of my design strength, and came up with this:

I exported this as an SVG, then got the path coordinates and bounding box dimensions:

```
width: 65px
height: 28px
path coordinates: M23.71 5.21l17.58 17.58a12.43 12.43 0 0 0 17.57 0 12.43 12.43 0 0 0 0-17.57 12.43 12.43 0 0 0-17.57 0L23.71 22.79a12.43 12.43 0 0 1-17.57 0 12.43 12.43 0 0 1 0-17.57 12.43 12.43 0 0 1 17.57-.01z
```

Based on that data, we're easily able to apply the offset path to a CSS selector:

```css
.selector {
  offset-path: path("M23.71 5.21l17.58 17.58a12.43 12.43 0 0 0 17.57 0 12.43 12.43 0 0 0 0-17.57 12.43 12.43 0 0 0-17.57 0L23.71 22.79a12.43 12.43 0 0 1-17.57 0 12.43 12.43 0 0 1 0-17.57 12.43 12.43 0 0 1 17.57-.01z");
}
```

So far, things make sense, but as of now, there's absolutely no visual feedback. Let's get things moving.

## Applying Styles and Animations to our Element

Let's assume that we want to call our loader in our HTML like this:

```html
<span class="loader"></span>
```

Based on our data, we can initialise our loader CSS like this:

```css
.loader {
  position: relative;
  display: block;
  width: 65px;
  height: 28px;
}
```

Now that our bounding box is defined, let's create two dots. The idea here is that the dots will be chasing each other along the path of the infinity symbol. I'll use CSS pseudo elements `::before` and `::after`:

```css
.loader::before,
.loader::after {
  position: absolute;
  top: 0;
  left: 0;
  display: block;
  width: 10px;
  height: 10px;
  background-color: #FFEB3B;
  border-radius: 50%;
  content: "";
}
```

So far so good. Two dots have been rendered, they're yellow, and they're hanging out. Now, let's position our dots along the path by applying the `offset-path` property:

```css
.loader::before,
.loader::after {
  offset-path: path("M23.71 5.21l17.58 17.58a12.43 12.43 0 0 0 17.57 0 12.43 12.43 0 0 0 0-17.57 12.43 12.43 0 0 0-17.57 0L23.71 22.79a12.43 12.43 0 0 1-17.57 0 12.43 12.43 0 0 1 0-17.57 12.43 12.43 0 0 1 17.57-.01z");
}
```

Awesome, it's coming together. Next up, we need to define our animation keyframes. We'll want to animate the dots along the path, so we'll be starting with an offset distance of 0%, and moving along to an offset distance of 100%:

```css
@keyframes loader {
  0% { offset-distance: 0%; }
  100% { offset-distance: 100%; }
}
```

Now, let's apply the animation to our pseudo elements. I'm using a [cubic bezier](http://callmenick.com/post/level-up-your-css-animations-with-cubic-bezier) ease-in-out function:

```css
.loader::before,
.loader::after {
  animation: loader 1500ms cubic-bezier(0.645, 0.045, 0.355, 1) infinite;
}
```

There's motion! But the two dots look like one. Let's delay the movement of the second dot:

```
.loader::after {
  animation-delay: 100ms;
}
```

And voila! Once again, the result:

<p class="codepen" data-height="300" data-default-tab="result" data-slug-hash="KqMgaB" data-pen-title="Infinity Loader" data-user="callmenick" style="height: 300px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;">
  <span>See the Pen <a href="https://codepen.io/callmenick/pen/KqMgaB">
  Infinity Loader</a> by Nick Salloum (<a href="https://codepen.io/callmenick">@callmenick</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://public.codepenassets.com/embed/index.js"></script>

## Support

This is a super new property on the market, so support is pretty weak. Chrome supports it, but older versions of Chrome use `motion`. Is’ under consideration for Edge and Firefox. I recommend coupling usage of this with [CSS @supports](https://developer.mozilla.org/en/docs/Web/CSS/@supports) to ensure a fallback.

## Wrap Up

Today, we looked at the new `offset` CSS property, coupled it with CSS animations, and made something cool. The possibilities continue to grow with CSS, so I encourage you to try it out. Thanks again for reading, and ff you have and questions, comments, or feedback, feel free to get in touch.

Let's Build an Infinity CSS Animating Loader!

In [part 1](https://dev.callmenick.com/posts/cooking-with-webpack-part-1-introduction-and-basic-implementation), we plunged into webpack and gained a better understanding of what it is and some of its capabilities. We were able to write a script, require a module in it, and output a bundle using webpack. One really important takeaway from all of that was that we **bundled** up some **modules**. At this point, it's time to understand that a module can refer to many different things, not just a JavaScript file. Out of the box, webpack only supports JavaScript modules. But what if we wanted to bundle up some CSS in our output file? What if we wanted to grab some HTML templates from HTML files for usage in our script? Enter loaders.

## What is a Loader?

[According to the docs:](http://webpack.github.io/docs/using-loaders.html)

> Loaders are transformations that are applied on a resource file of your app. They are functions (running in node.js) that take the source of a resource file as the parameter and return the new source.

In other words, by using a loader, we can tell webpack to apply *transformations* to certain file types, and load it into the output. For example, if we used a CSS loader, we could require a CSS file in any of our JavaScript files. Then, webpack would step in, transform it to parsable JavaScript, and spit out the bundle. Webpack has a [ton of loaders](https://webpack.github.io/docs/list-of-loaders.html) ready for you to use. Let's take a look at some of them by implementing them and observing the output.

## Syntax of a Loader Configuration

In our configuration file, we need a new key called `module`. This is where we will place all our loaders, which are stored as an array with key `loaders`. We'll be building upon our work in part 1, so go ahead and copy over the files. For quick reference, our file should now look like this:

```javascript
module.exports = {
  entry: path.join(__dirname, 'src/index.js'),
  output: {
    path: path.join(__dirname, 'dist'),
    filename: 'index.bundle.js'
  },
  module: {
    loaders: []
  }
};
```

In the most basic sense, each loader is represented as an object with a RegEx test followed by a string or array of loaders to apply. For example:

```javascript
loaders: [
  {
    test: /\.extension$/,
    loader: 'some-loader'
  },
  {
    test: /\.differentextension$/,
    loaders: ['some-loader', 'another-loader']
  }
]
```

A particular point of interest comes in the second loader configuration. We're able to chain loaders together, which is sometimes useful and necessary. Let's add our first loader and put it to the test.

## Basic Templates with the HTML Loader

Let's imagine a scenario where we have a simple JavaScript application, and based on some user's interactions, we want to display some HTML template. For the sake of separating our concerns, we wanted our HTML to reside in its own file, and for us to some how be able to require it and bundle it in on demand. The [HTML loader ](https://github.com/webpack/html-loader) is the perfect tool for the job. Let's go ahead and install it:

```console
npm install html-loader --save-dev
```

Now over in our webpack configuration, let's add the loader:

```javascript
{
  test: /\.html$/,
  loader: 'html'
}
```

Now, let's create the HTML template in `src/hello.html`:

```html
<h1>Hello!</h1>
<p>Welcome to this awesome application. I hope you enjoy it.</p>
<button>More awesome</button>
```

Over in our entry file `src/index.js`, let's remove what we had before for now. Now, let's simply observe what happens when we require the HTML template and log it to the console:

```javascript
var hello = require('./hello.html');

console.log(hello);
```

Now, let's create our bundle by running:

```console
npm run build
```

Let's observe the `dist/index.bundle.js` file to see what happened during bundling. If we scroll down to the first module, we'll see that we're assigning the result of `__webpack_require__(1)` to the variable `hello`. Then, in the second module (which is at index 1 in the array), we can see that the loader applied the correct transformations to the HTML template, and converted it to a string with the necessary new line characters. Let's witness that first hand by running our bundle in node:

```console
node dist/index.bundle.js

output:

<h1>Hello!</h1>
<p>Welcome to this awesome application. I hope you enjoy it.</p>
<button>More awesome</button>
```

Naturally, if we're using HTML, we'd want to inject it into the DOM somehow, so let's do that. Let's create a basic web page:

```
touch index.html
```

In it, let's outline a basic HTML5 app, and include a div to add our HTML to, and a reference to the bundled JavaScript:

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Cooking With Webpack Part 2 - Using Loaders</title>
</head>
<body>
  <div id="app"></div>
  <script src="dist/index.bundle.js"></script>
</body>
</html>
```

Back in our `src/index.js` file, let's write some simple JavaScript to inject the template in our app when the script runs:

```javascript
var hello = require('./hello.html');
var app = document.querySelector('#app');

app.innerHTML = hello;
```

Save, compile using `npm run build`, and now open up `index.html` in the browser. If you're like me, and you get extremely happy with simple successes, then what you see in the browser should make you jump off your seat in excitement. We've successfully included an HTML template in our JavaScript, transformed it with a loader, and used it in our bundled script to inject it into the DOM.

## Injecting Styles with the Style and CSS Loader

Apps and websites are pretty boring with plain old rendered HTML. Let's load some styles into our app and make it look pretty!

*Sidenote: In the example that follows, we're going to be requiring CSS in our JavaScript, and injecting it into the DOM directly. There's a lot of hot debate about this methodology. On one hand, if the CSS is small enough, then it saves an HTTP request round trip. On the other, if it's huge, then it can be a lot to handle. For now, we're going to inject it into the DOM, but when we look at plugins in the future, we'll see how we can use webpack to spit out a traditional stylesheet based on our bundle requirements.*

When working with styles, there are two loaders that need to be considered:

1. The [style loader](https://github.com/webpack/style-loader) - injects CSS into the DOM by adding a `style` tag
2. The [CSS loader](https://github.com/webpack/css-loader) - interprets CSS properly and resolves paths etc

Let's install both of them:

```console
npm install style-loader css-loader --save-dev
```

Now, let's configure webpack to use the loaders:

```javascript
{
  test: /\.css$/,
  loaders: ['style', 'css']
}
```

This time, we used an array of loaders. Webpack allows us to chain loaders by adding multiple loaders to an array with key `loaders`, instead of just the one `loader`. Next up, let's create our first stylesheet:

```console
touch src/style.css
```

And let's populate it with some basic styles:

```css
*,
*::before,
*::after {
  box-sizing: border-box;
}

html {
  font-size: 10px;
}

body {
  font-family: sans-serif;
  font-size: 1.6rem;
}
```

Over in our entry file, let's require the styles at the top:

```javascript
// index.js
require('./style.css');

var hello = require('./hello.html');
var app = document.querySelector('#app');

app.innerHTML = hello;
```

Now, let's build using `npm run build`, and open up `index.html` in the browser. You should see the styles applied. Exciting! Let's look under the hood in `dist/index.bundle.js`. Webpack creates another module for us that gets loaded with the `__webpack_require__` when it's needed. This time, it transforms our stylesheet into readable JavaScript, then it runs through it, parses it, and injects it as a `style` tag into the DOM's `head` tag. If you open up the elements tab in the browser console, you'll see that the styles are indeed there. Sweet!

Let's go a step further and refactor our app a little. Over in our `index.html` file, let's add a button and a container that'll render some hellos for us:

```html
<button class="js-add-hello">Add Hello</button>
<div id="hellos"></div>
```

Now, in our `hello.js` file, let's comment out what we had before for now, and just let our module require some css, and return the hello template:

```javascript
require('./hello.css');

module.exports = function() {
  return require('./hello.html');
};
```

We're going to need to create that `hello.css` file, so go ahead and do that:

```console
touch src/hello.css
```

Now, populate it:

```css
.Hello {
  margin: 2rem 0;
  padding: 2rem;
  border: solid 1px #ddd;
}

.Hello-title {
  margin-bottom: 1rem;
  font-size: 1.6rem;
}
```

In our `hello.html` template, let's change it up to this for now:

```html
<div class="Hello">
  <h3 class="Hello-title">Hello, World!</h3>
  <p>The best and most beautiful things in the world cannot be seen or even touched - they must be felt with the heart.</p>
</div>
```

And now, finally, in our entry `index.js` file, let's tie it all together:

```javascript
require('./style.css');

var hello = require('./hello.js');

var button = document.querySelector('.js-add-hello');
var hellos = document.querySelector('#hellos');

button.addEventListener('click', function(e) {
  e.preventDefault();

  hellos.insertAdjacentHTML('beforeend', hello());
});
```

Let's bundle it all up using `npm run build`, and now let's open up the `index.html` file in the browser. Voila, we have a working app!

You're probably thinking that a lot of what we just did has nothing to do with webpack. I'd like to point out otherwise though. Sure, we could've written all of this in on JavaScript file and one CSS file. However, what we did accomplish is that we've exposed some of webpack's true powers. We were able to truly separate our concerns here, and group together the markup, styling, and logic of the “hello” component. Webpack allowed us to work on our “hello” component in isolation, and bundle it up with the rest of our project code later on.

To prove this point a bit, let's work solely on our “hello” component. For it to be more template-like, let's use handlebars instead of just plain old HTML:

```console
npm install handlebars handlebars-loader --save-dev
cp src/hello.html src/hello.hbs
```

In our webpack config, let's enable handlebars transformations:

```javascript
{
  test: /\.hbs$/,
  loader: 'handlebars'
}
```

Now, in our handlebars template, let's add a `name` variable:

```handlebars
<div class="Hello">
  <h3 class="Hello-title">Hello, {{name}}!</h3>
  <p>The best and most beautiful things in the world cannot be seen or even touched - they must be felt with the heart.</p>
</div>
```

Let's change up our `hello.js` module now to accept a name, and render the handlebars template with that name:

```javascript
require('./hello.css');

module.exports = function(name) {
  if (name === undefined) {
    name = 'World';
  }

  return require('./hello.hbs')({
    name: name
  });
};
```

If we build and refresh the page, we should still see the same result, which is good! We've successfully worked on our component in isolation, accessing the relevant files we needed, when we needed. Let's quickly edit our entry file now to put the component to better use. First though, let's add an input field to our `index.html` file:

```html
<input type="text" class="Input js-add-hello" placeholder="Type a name and hit enter">
```

And now, the JavaScript:

```javascript
var input = document.querySelector('.js-add-hello');
var hellos = document.querySelector('#hellos');

input.addEventListener('keyup', function(e) {
  if (e.keyCode === 13) {
    hellos.insertAdjacentHTML('beforeend', hello(e.target.value));
    input.value = '';
  }
});
```

Build, refresh, and voila. Beautiful.

## Moving to Modern JavaScript with the Babel Loader

To wrap this all up, I'm going to introduce to you one more loader that'll allow you to write next generation JavaScript using [babel](http://babeljs.io/). Babel is a JavaScript compiler that gives us a large configuration set. We'll keep it simple for now though. As with all other loaders, we need the [babel loader](https://github.com/babel/babel-loader), as well as some other dependencies based on their docs:

```console
npm install babel-loader babel-core babel-preset-es2015 --save-dev
```

The `babel-loader` package is required for the actual loading in webpack, the `babel-core` package is required to actually compile the JavaScript, and the `babel-preset-es2015` package is required so that we have a preset to base off of. In our webpack configuration file, we can set up the loader like this:

```javascript
{
  test: /\.js$/,
  exclude: /node_modules/,
  loader: 'babel-loader',
  query: {
    presets: ['es2015']
  }
}
```

This time, we're using two more loader properties:

1. `exclude` to specify via RegEx what to exclude from the transformation
2. `query` to send some information to the babel configuration

Now, we can change up all our JavaScript:

```javascript
// index.js
import './style.css';

import hello from './hello.js';

const input = document.querySelector('.js-add-hello');
const hellos = document.querySelector('#hellos');

input.addEventListener('keyup', e => {
  if (e.keyCode === 13) {
    hellos.insertAdjacentHTML('beforeend', hello(e.target.value));
    input.value = '';
  }
});

// hello.js
import './hello.css';

import helloTpl from './hello.hbs';

export default function(name = 'World') {
  return helloTpl({
    name: name
  });
};
```

Build, refresh the browser, and boom! More awesome magic. We're now able to write next generation JavaScript wherever we want thanks to webpack's loading and transformation functionality in tandem with babel. Exciting stuff!

## Wrap Up

Phew! This time, we plunged into the world of loaders and saw how they apply transformations to our bundles. Loaders are extremely important in the world of webpack, and I hope I've imparted enough wisdom for you to go out in the wild and configure them yourself. Thanks again for reading, and if you have and questions, comments, or feedback, feel free to send me a tweet.


Cooking With Webpack Part 2 - Understanding & Using Webpack Loaders

I'll begin this article the way many a webpack article begins - with a simple, underwhelming, and slightly confusing description of what webpack is. From their docs:

> Webpack is a module bundler. Webpack takes modules with dependencies and generates static assets representing those modules.

In this series of tutorials though, I promise to take you way beyond the basics, and into some of the more intricate parts of webpack.

In a most basic sense, webpack looks at a source file, examines its dependencies, and compiles an output bundle. So if our source file requires another modules (CommonJS of AMD), webpack will do some stuff under the hood in the build and bundle in that module, producing a file that's ready for consumption in any JavaScript environment.

Something that confused me up front as well was the endless commingling of the [command line interface](http://webpack.github.io/docs/cli.html) as well as the [configuration file](http://webpack.github.io/docs/configuration.html). When webpack runs, it looks for both of these things, and often times, a lot of command line clunkiness can be moved into the webpack configuration file. In these guides, I'll be primarily using the configuration file with occasional command line arguments.

## Setting Up Our Project

First things first, let's get a project set up by running:

```bash
npm init
```

Let's also create a very basic folder structure, and add an empty JavaScript file to it:

```bash
mkdir src && touch src/index.js
```

Then, let's add webpack as a development dependency:

```bash
npm install webpack --save-dev
```

We're now able to run webpack scripts from our project as npm scripts. Let's add a basic npm script to our `package.json` file:

```json
{
  "scripts": {
    "build": "webpack"
  }
}
```

Now, we can run `npm run build`. Naturally though, there are errors. Notably, it's telling us that we don't have an output filename configured, and pointing us to the cli docs.

## Making Our First Bundle

At its core, webpack needs an entry point and some output configurations.We can achieve this via the updating our build task to this:

```json
{
  "scripts": {
    "build": "webpack --entry ./src/index.js --output-filename ./dist/index.bundle.js"
  }
}
```

Here, we're using the `--entry` argument to specify the entry file, and the `--output-filename` argument to specify where our bundle should compile to. If you rerun `npm run build`, you'll see that webpack successfully created the bundle at `dist/index.bundle.js`. It should contain some webpack boilerplate code, which we'll get into later.

We're not going to continue on with the cli though. Instead, we're going to create a configuration file.

## Setting Up The Configuration File

Webpack configuration files can be supplied via the `--config` argument in the command line:

```json
{
  "scripts": {
    "build": "webpack --config ./config.js"
  }
}
```

The above assumes that a webpack configuration file named `config.js` was found. However, by default, the webpack task looks for the `webpack.config.js` file in the same directory as it gets run from. So we can just revert back to this:

```json
{
  "scripts": {
    "build": "webpack"
  }
}
```

And now, we can create our webpack configuration file:

```bash
touch webpack.config.js
```

Let's now move our command line script from above over to the webpack configuration file. A webpack configuration is just an exported object. For the most part, each of those cli arguments above map to some key-pair values. For example, `--entry` maps to `{entry: ''}`, and `--output-filename` maps to `{output: {filename: ''}}`. Here's ours:

```javascript
const webpack = require('webpack');
const path = require('path');

module.exports = {
  entry: path.join(__dirname, 'src/index.js'),
  output: {
    path: path.join(__dirname, 'dist'),
    filename: 'index.bundle.js'
  }
};
```

Now, once again, if we run `npm run build`, we'll see that our entry script gets bundled and compiled to the specified output. This time, we used two output options:

- `path` - specifies the output path of our bundle
- `filename` - specifies the filename of our bundle

These will demonstrate more importance in the future. For now, it's just an easy way to split up our configuration into a more digestible format.

## So…All That For What Exactly?

At this point, we've quite literally taken an empty project, added webpack as a dependency, and created some configuration setup that takes an empty JavaScript file and adds a bunch of weird code to it. Let's write some actual code, populate our `index.js` file, require a module in it, and peek under the hood a bit.

First, let's create a new file called `hello.js`. This will be a module that we can use in `index.js`.

```bash
touch src/hello.js
```

Our hello module will accept an argument, `name`, and return the most wonderful string of all time: “Hello `name`”. Out of the box, webpack can bundle CommonJS and AMD style modules. For starting purposes, we'll use CommonJS. Let's go ahead and write the code for `hello.js`:

```javascript
// hello.js
module.exports = function(name) {
  if (name === undefined) {
    name = 'World';
  }

  return 'Hello, ' + name + '!';
};
```

It's pretty simple. Our function accepts a `name` argument, and if that's undefined, it assigns the string `World` to it. It then returns the full string “Hello, `name`”. Back in our `index.js` file (which is our entry file for webpack), we can require this module and use it:

```javascript
// index.js
var hello = require('./hello.js');

console.log(hello()); // should log "Hello, World!"
console.log(hello('Nick')); // should log "Hello, Nick!"
```

Now, if we run our build task again using `npm run build`, we'll get some neat output. We can also verify that our code is working by running it simply with node:

```bash
node ./dist/index.bundle.js

output:

Hello, World!
Hello, Nick!
```

## What's Inside The Compiled File?

If you're curious like me, then you're probably wondering what's happening under the hood. I won't get into too many details, because I've only glanced at the surface. There are a lot of generated comments though, so it's pretty easy to follow. In a nutshell:

1. webpack wraps everything in an IIFE, which gets invoked with all the modules (as an array)
2. webpack creates a `__webpack_require__` function, which internally requires modules when needed
3. webpack kicks off by running the first module (which is the entry module, `index.js` in our case) using the `__webpack_require__` function
4. all previous `require` statements get replaced with an invocation of `__webpack_require__` with the correct module index from the passed in array

If the above confuses you, then forget about it and don't dwell too much on it. The good news is that webpack did some heavy lifting for you, and you're now able to run this code in any JavaScript environment. To quickly see it working in the browser, open it up, go to the dev tools, and copy paste the entire `index.bundle.js` code into the console. You'll see it execute perfectly!

## Wrap Up

Here, we took a plunge into webpack, and skimmed the surface of its huge well of potential. We took a quick look at the webpack cli, and another look and implementation of the webpack configuration file. Then, we created our first bundle which was making use of CommonJS modules. Next time, we'll look into loaders! Thanks again for reading, and if you have and questions, comments, or feedback, feel free to get in touch.

Cooking With Webpack Part 1 - Introduction and Basic Implementation

A few days ago, I ran into a little problem when using SVGs. I'd created a reusable set of SVG symbols for a project I was working on, and started sprucing it up with all the pretty icons my designer gave to me. As we all know, one of the biggest benefits to using **S**VG is the “scalable” part of it, meaning that graphics render perfectly at and size, no matter the original size of the graphic. I'm a huge fan in general of SVG, and implementing them into this project was a no brainer for me.

However, a few of the icons in the design consisted of strokes, and those strokes were always `1px` in width, no matter the size. When you scale an SVG, it scales everything about it, so an icon that's scaled up two times would have stroke widths that are double the size of the original. One such example was a “+” icon that indicated there was more content. I had to reuse that icon at small and large sizes, but:

1.  I wanted the stroke width at all sizes to be `2px`
2.  I wanted to create one graphic that I could reuse at any size without scaling the stroke width

## Enter The Vector Effect Attribute

One of my favourite things about programming is being faced with a problem. It challenges you to research and find solutions. In this case, I stumbled upon the [`vector-effect` attribute](https://web.archive.org/web/20170727101027/https://www.w3.org/TR/SVGTiny12/painting.html#VectorEffectProperty), which conveniently has `non-scaling-stroke` as one of its values. It does exactly what it says, i.e. prevents strokes from scaling as an SVG scales.

My original SVG symbol looks something like this:

```html

<svg>
  <symbol id="Icon-plus" viewBox="0 0 50 50">
    <circle cx="25" cy="25" r="20" fill="none" stroke="#fff" stroke-width="2"/>
    <path d="M25 15 L 25 35" fill="none" stroke="#fff" stroke-width="2" stroke-linecap="round"/>
    <path d="M15 25 L 35 25" fill="none" stroke="#fff" stroke-width="2" stroke-linecap="round"/>
  </symbol>
</svg>


<svg width="50" height="50">
  <use xlink:href="Icon-plus"/>
</svg>
```

Notice how the `viewBox` dimensions are perfectly aligned with the `width` and `height` dimensions. With this version of the icon, the `2px` wide stroke displays at `2px`, as expected. However, if I reuse that icon elsewhere at a bigger size, like this:

```html
<svg width="200" height="200">
  <use xlink:href="Icon-plus"/>
</svg>
```

I'd see a scaled up icon including scaled up effects. This one's dimensions are 4 times the size of the original view box. As such, the stroke would render at `8px`. In order to circumvent this, I added the `vector-effect` attribute to the paths on the original graphic, and set the value to `non-scaling-stroke`, like this:

```html
<circle vector-effect="non-scaling-stroke" />
<path vector-effect="non-scaling-stroke" />
<path vector-effect="non-scaling-stroke" />
```

Now, at any size, the stroke would render at `2px` as desired!

## Wrap Up

And that’s a wrap! I really wanted to share this simple tip with you as it's served me beautifully in recent times. Thanks again for reading, and if you have and questions, comments, or feedback, feel free to get in touch.

SVG Vector Effects

Transitions and animations are making waves across web development, and rightfully so. They are awesome, easily useable (and abusable), and have the ability to take your front end components and interfaces from good to great. The anatomy of declaring transitions and animations are similar, and only two things are required:

1. In the case of transitions, you select the property you want to transition. For animations, you select the keyframe block.
2. You then declare the duration length for the animation or transition.

Some typical CSS might look like this:

```css
.box {
  opacity: 0;
  transition: opacity 0.3s;
}

.cat {
  animation: fadeIn 0.3s;
}

@keyframes fadeIn {
  0% { opacity: 0; }
  100% { opacity: 1; }
}
```

Transitions and animations also have another shared property that controls how the intermediate values between states are calculated, and that's called the [transition timing function](https://developer.mozilla.org/en-US/docs/Web/CSS/transition-timing-function). It's optional, and defaults to `ease`. The following timing functions are available to us by default:

- `ease` - speeds up a little through the middle, and then slows down towards the end
- `ease-in` - starts of slowly, and accelerates through to the end
- `ease-out` - starts of quickly, and decelerates through to the end
`ease-in-out` - starts slowly, accelerates through to the middle, then decelerates through to the end
- `linear` - constant animation speed throughout
- `step-start` - steps to the final state in the first frame of the animation
- `step-end` - steps to the final state in the last frame of the animation
- `steps(n, start|end)` - steps through n frames for the duration of the animation, "eating" a frame either at the start or the end

When dealing with simple animations and transitions, it's unlikely that you've touched the `step` functions - those are more geared towards keyframe cartoon-style animations, which is a very specific use case. However, you've probably used a lot of the other built in timing functions to reasonable effect when building nicer buttons, menus, modals, and other stateful components. Have you ever thought that despite the induced animation effect, it doesn't look and feel quite right?

## Cubic Bezier to the Rescue!

Let's digress a little bit. Anyone with any animation experience will know that software like Flash and After Effects come packed with a ton of easing functions - `easeInQuint`, `easeOutSine`, `easeInOutCubic`, just to name 3 of many. These timing functions aren't available to us through CSS keywords like `ease` and `linear`. However, it's important to note that **all** of these functions, including the ones that have valid keywords in CSS, are just cubic bezier functions. But what exactly is cubic bezier? Let's take a look at the image below:

![Cubic Bezier Chart](//images.ctfassets.net/rex0us6r928o/5zok0XEii8prWZPO6mEPUG/d2c17e88a883b199c9c7767d6ab15eeb/bezier.png)

It's a graph that lives on a 1x1 axis, and it represents the cartesian cubic bezier coordinate system. Side note: plot points on this graph can go above and below 1 on the y-axis (property axis), but not on the x-axis (time axis). The grey line represents the axes, the orange line represents the timing function curve, and the blue lines and dots represent the control points and lines of the bezier curve. These control points are responsible for shaping the curve itself, and are one of the fundamental underlying concept in vector graphics softwares such as Adobe Illustrator.

A specific type of bezier curve - the cubic bezier curve - is available to us in the field of animation, and it can be mathematically defined by four control points in the plane of the graph shown above. In world of CSS animations though, we're only concerned with control points `p1` and `p2`, and that's because `p0` is always going to be `0, 0`, and `p3` is always going to be `1, 1`. So how then do we define out cubic bezier function in CSS? It looks like the following:

```css
cubic-bezier(x1, y1, x2, y2)
```

where:

* `x1` is the x coordinate of control point `p1`
* `y1` is the y coordinate of control point `p1`
* `x2` is the x coordinate of control point `p2`
* `y2` is the y coordinate of control point `p2`

I created the graph above just as a demonstration, but you can imagine that the cubic bezier declaration for it might look something like this:

```css
cubuc-bezier(0.5, 0.31, 0.84, 0.05)
```

If you're good with numbers, or you have a grasp of bezier curves or animation functions in typical animation software, you may immediately see the immense power this gives us. Think about it this way, animations are supposed to tell a story and give context and mood to the state we're animating to. If every animation was linear or a normal ease, they would all look the same, and invoke the same mood. If a very important dialog were to appear after a user action, and you really wanted to draw some attention to that, you'd probably want a custom timing function. Cubic bezier curves give us this fine tuned control.

## I'm No Good with Numbers - Help

If you're no good with numbers or are having a hard time visualizing what the end result will look like, then fear not. There are many resources out there to help you. First and foremost, a quick Google search will yield heaps of results on traditional easing functions ported to their CSS cubic bezier equivalents. However, two excellent resources that I use are:

1. [easings.net](http://easings.net/) - A collection of traditional easings (timing functions) and their corresponding CSS cubic bezier implementations
2. [cubic-bezier.com](http://cubic-bezier.com/) - A playground and visual interface for making your own cubic bezier functions, and seeing the results in real time.

Both are excellent, and you'll likely use them together.

## A Little Example

Let's demo up a little example to compare two timing functions. Below, there are two blue boxes of the exact same size. When you hit the animate button, they will translate 20rem from left to right for a duration of 600ms. Everything about them is the same, except the easing functions. The first one takes on the function **ease in**, which is accessible via the CSS keyword `ease-in`. The second takes on the function **ease in out back**, and you can grab the cubic bezier function from [easings.net](http://easings.net/). Below is the result:

I don't know about you, but in my opinion, the second animation has a lot more character! Putting in just a little bit more effort yielded amazing results.

## Wrap Up

Understanding cubic bezier curves is one part of the equation of mastery of CSS animations. Putting them to use is another part. Always remember though that animation is not just a slap-and-go tool, and you shouldn't abuse it. Animation is a long practiced art, and we should treat it with respect and research accordingly. Timing functions all invoke different meanings to the subject, and it's up to you to make sure you're sending the right message. Cubic beziers can dramatically help this, so get acquainted. And that’s a wrap!

Level Up Your CSS Animations with Cubic Bezier

## Introduction

In modern websites and applications, interactions and UX play a huge part in consumer retention. CSS animations have paved the way for us as far as enhancing user experiences goes, but it can be taken a step further with a little thought. In this tutorial, we're going to build what I like to call a “last in, first out” item animation, or a “stack” animation. What this means is that when some sort of toggle action is hit, items animate into view in a sequence. When the toggle action is hit again, the items animate out of view in a reverse sequential order (in relation to the animation in). I'll demonstrate it with some basic divs, but the application of this trick is what matters.

## A Visual Representation

To understand more clearly what we're trying to achieve, let's step through the process with some images. At a neutral, or base state, all of our divs - let's call them bars - are occupying a small amount of fixed space. Here's a representation:

![LIFO transitions step 1](//images.ctfassets.net/rex0us6r928o/6V6k6MOTPd3kueO6L8xSBp/21db188caa8fd55c3d857321b4558dc2/last-in-first-out-css-transitions-step-0.png)

Imagine now that we've hit a toggle button of sorts, and we want all the bars to expand sequentially to 100% width.  Here's a visualization of that in action:

![LIFO transitions step 2](//images.ctfassets.net/rex0us6r928o/1Lnt9gTxmF8mcLSpIwB6gE/d59beea47fd65740f2f9a9bbbe9b2b00/last-in-first-out-css-transitions-step-1.png)

When all bars have finished transitioning, they should occupy the full width of their container:

![LIFO transitions step 3](//images.ctfassets.net/rex0us6r928o/5OlmRgUO2tgwrAFzZQWhuG/02830b3411e11b8cf3910e94fa65c1c0/last-in-first-out-css-transitions-step-2.png)

At this point, hitting the toggle again should transition the bars back out, but in a reverse sequential order. That is, the last bar to transition in should be the first bar to transition out. Here's a visual representation:

![LIFO transitions step 4](//images.ctfassets.net/rex0us6r928o/3FktZxdgqIWMQVjle71bmR/af7777048c2cdba986aa63274fb4bd82/last-in-first-out-css-transitions-step-3.png)

Finally, when this transition ends, all bars should return to their original state, as represented by the first image:

![LIFO transitions step 5](//images.ctfassets.net/rex0us6r928o/2Hm6azIFbOsIXOmoYVNhmN/14b64f9ff692bab655b4b120a8b93212/last-in-first-out-css-transitions-step-4.png)

## Setting Up The Demo

Let's get a simple set up going on for our demonstration. The markup is fairly simple, with a containing element (`c-bars`) and 5 child elements (`c-bars__bar`). We'll also have a toggle button that will toggle an `is-expanded` class on all bars. Here's the HTML:

```html
<button class="c-btn">Toggle</button>

<div class="c-bars">
  <span class="c-bars__bar">1</span>
  <span class="c-bars__bar">2</span>
  <span class="c-bars__bar">3</span>
  <span class="c-bars__bar">4</span>
  <span class="c-bars__bar">5</span>
</div>
```

The JavaScript to toggle the class is really straightforward as well:

```javascript
<script>
  var btn = document.querySelector('.c-btn');
  var bars = document.querySelectorAll('.c-bars__bar');

  btn.addEventListener('click', function() {
    for (var i = 0; i < bars.length; i++) {
      bars[i].classList.toggle('is-expanded');
    }
  });
</script>
```

In a real world application, your script may look much different. The point here is that hitting some sort of toggle switch toggles the `is-expanded` class to all elements in question.

## Base Styling

Now that our markup is good to go, let's add some basic CSS. Our bars container will be visible via a border, and each bar will be a block element with an initial width. Because we're transitioning the width of the bars from initial to 100%, we'll have to apply that transition property as well. Here's some CSS:

```css
.c-bars {
  padding: 12px;
  border: solid 4px #25b7a8;
}

.c-bars__bar {
  display: block;
  margin: 0 0 12px 0;
  padding: 2px 0;
  width: 24px;
  color: #fff;
  background-color: #25b7a8;
  text-align: center;
  transition: width 0.5s;
}

.c-bars__bar:last-child {
  margin-bottom: 0;
}
```

As mentioned above, the `is-expanded` class will be toggled on the bars when the button is clicked. This is where we can apply the width change to the bars:

```css
.c-bars__bar.is-expanded {
  width: 100%;
}
```

At this point, clicking the button should invoke the transition, with all bars transitioning smoothly from their initial width to 100%. Clicking again will revert them to their initial width.

## Trick #1 - Applying Sequential Transitions

As it stands, all elements transition in and out at the exact same time. In order to invoke the transitions sequentially, we need to use the `transition-delay` property. We know we have 5 bars, so let's target each of them with the `nth-child` selector, and delay each bar by `0.1s`. Here's the additional CSS:

```css
.c-bars__bar:nth-child(1) {
  transition-delay: 0s;
}

.c-bars__bar:nth-child(2) {
  transition-delay: 0.1s;
}

.c-bars__bar:nth-child(3) {
  transition-delay: 0.2s;
}

.c-bars__bar:nth-child(4) {
  transition-delay: 0.3s;
}

.c-bars__bar:nth-child(5) {
  transition-delay: 0.4s;
}
```

Try toggling again. This time, the first bar starts transitioning immediately, and every bar after that starts transitioning 0.1s later than the previous one. This is a great step! However, when you click the button again and the `is-expanded` class gets removed, you'll notice that they transition out in the same order that they transitioned in. This isn't quite what we want, so let's take a look at trick #2.

## Trick #2 - Last In, First Out

In order to achieve the “last in, first out” transition pattern, we need to assess two states of the demo. The first is the initial state, and the second is the expanded state. We already saw how to transition the bars sequentially from the initial to the expanded state. When they are expanded, we essentially need to revers the `transition-delay` properties on each bar. Luckily, achieving that is very simple.

When we click the toggle button, the `is-expanded` class gets immediately added to the elements. That means that while they are transitioning in, they have the `is-expanded` class. When the bars are expanded and the button gets clicked again, the class gets immediately removed from all of the bars. This presents us with an opportunity to target both transitional phases:

1. Transition delays from initial to expanded should be applied to the `is-expanded` class.
2. Transition delays from expanded to initial should be applied to the base class.

With that in mind, here's the modified CSS:

```css
.c-bars__bar:nth-child(1) {
  transition-delay: 0.4s;
}

.c-bars__bar.is-expanded:nth-child(1) {
  transition-delay: 0s;
}

.c-bars__bar:nth-child(2) {
  transition-delay: 0.3s;
}

.c-bars__bar.is-expanded:nth-child(2) {
  transition-delay: 0.1s;
}

.c-bars__bar:nth-child(3) {
  transition-delay: 0.2s;
}

.c-bars__bar.is-expanded:nth-child(3) {
  transition-delay: 0.2s;
}

.c-bars__bar:nth-child(4) {
  transition-delay: 0.1s;
}

.c-bars__bar.is-expanded:nth-child(4) {
  transition-delay: 0.3s;
}

.c-bars__bar:nth-child(5) {
  transition-delay: 0s;
}

.c-bars__bar.is-expanded:nth-child(5) {
  transition-delay: 0.4s;
}
```

Check out the two transitional states now - voila! You've successfully implemented the last in, first out transition technique, and it looks awesome.

<p class="codepen" data-height="460" data-default-tab="html,result" data-slug-hash="VMNOpq" data-pen-title="CSS Transition Tricks - Last In, First Out" data-user="callmenick" style="height: 460px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;">
  <span>See the Pen <a href="https://codepen.io/callmenick/pen/VMNOpq">
  CSS Transition Tricks - Last In, First Out</a> by Nick Salloum (<a href="https://codepen.io/callmenick">@callmenick</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://public.codepenassets.com/embed/index.js"></script>

## Simplification With Sass

There is a fundamental mathematical nature involved in creating this transition effect, which means that Sass (or any CSS pre-processor with looping and variables) can be of great assistance. The Sass block that I used to generate the CSS was as simple as this:

```scss
$n: 5;
$delay: 0.1;

@for $i from 1 through $n {
  $in: $delay * ($i - 1);
  $out: $delay * ($n - $i);

  .c-bars__bar:nth-child(#{$i}) {
    transition-delay: #{$out}s;
  }

  .c-bars__bar.is-expanded:nth-child(#{$i}) {
    transition-delay: #{$in}s;
  }

}
```

Simply changing `$n` (the number of items) and `$delay` (the transition delay) will update the entire output for you.

## Wrap Up

And that's a wrap! We just took on an awesome, small challenge in CSS, creating sequentially stacked transitions. Thanks again for reading, and if you have and questions, comments, or feedback, feel free to send me a tweet.


Last in First Out CSS Transitions

In this article, we're going to have a very quick primer on Gulp, talking a bit about why it's so fast and efficient. Then, we'll set up a basic project with Gulp, set up some tasks, and automate the flow. Let's dig in!

## Gulp - What & Why?

As I mentioned above, Gulp is a task runner that enables automation and crunching of monotonous tasks all in one swoop. In a modern workflow, there are probably a host of tools that you're using in development and production. Some of the more popular ones are script concatenation and minifaction, and Sass compilation. But the well runs deep, and goes into the likes of automated testing, image manipulation, sprite generation, and a host of others. At the time of writing, Gulp has 1438 plugins available. These days , I'm all aboard the Gulp train, and here's why:

1.  Based off of personal experience, Gulp runs much, much faster. Tasks get crunched quicker, and the time you spend between writing code and seeing the changes in the browser is significantly less. Why is this? According to Gulp, it uses the power of node streams, giving you fast builds that don't write intermediary files to disk. I'm no expert on the topic, but if you want to read more about node streams, [check out this article.](http://www.sitepoint.com/basics-node-js-streams/)
2.  The configuration and setup of a Gulp file is pretty easy to read and write.

Let's move on to setting up a Gulp project.

## Setting Up A Gulp Project

If you don't have node set up on your machine, [go ahead and do so.](https://nodejs.org/) The `npm` command line tool comes bundled with node, so you'll be ready to roll after this. Next, create a new project directory, and `cd` into it. Let's initialise our directory by running the following command:

```
npm init
```

It'll prompt you to set up some configuration variables and then generate a package.json file. Right now, let's just leave it at bare minimums:

```
{
  "name": "Gulp",
  "version": "1.0.0"
}
``` 

Next up, let's create an empty `gulpfile.js` in our root directory. This is where all the configuration and task set up will take place. Now, let's bring in our first package, the Gulp package:

```
npm install --save-dev gulp
```

You'll notice that the `node_modules` directory has been created, and back in our package.json file, gulp has been added to the dev dependencies. In our gulp file, we can now reference it like this:

```javascript
// require gulp
var gulp = require('gulp');
```

We can also now set up our default task (which will do nothing):

```javascript
// default task
gulp.task('default', function() {

});
``` 

And there you go, we're ready to begin using gulp. At this point, we can successfully run `gulp` from the command line, and all will be well. It's a bit useless at this point though, so let's set up some dummy files and implement some tasks.

First, let's configure our directory structure like this:

```
gulpfile.js
package.json
src/
  --> js/
  --> sass/
dist/
  --> js/
  --> css/
```

If you don't use Sass, don't worry. This article isn't about Sass. Rather, we just want to demonstrate the running of multiple tasks. In the `src/js` directory, create two JavaScript files and populate them like this:

```javascript
// hello.js
function helloWorld() {
  console.log("Hello World!");
}

// goodbye.js
function goodbyeWorld() {
  console.log("Goodbye World!");
}
```

Silly, I know, but it's just for demonstration purposes. Now inside the `src/sass` directory, create a `style.scss` file, and give it some basic SCSS:

```scss
$blue: rgb(40, 170, 220);

p {
  color: $blue;
}
```

We're now ready to set up the tasks.

## Task Set Up

Given the above dummy data, we'll want to do the following before taking our app to production:

1.  Concatenate the scripts into one file called `app.js`
2.  Minify and rename `app.js` to `app.min.js`
3.  Compile the Sass to a `style.css` CSS file
4.  Minify and rename `style.css` to `style.min.css`

We'll need the necessary packages to perform these functions, so let's pull them in. We'll want the [concatenation package](https://www.npmjs.com/package/gulp-concat), the [uglify package](https://www.npmjs.com/package/gulp-uglify), the [Sass compiler plugin](https://www.npmjs.com/package/gulp-sass), the [CSS minifier package](https://www.npmjs.com/package/gulp-minify-css), and the [renaming package](https://www.npmjs.com/package/gulp-rename). We can pull in all of these packages in one swoop like this:

```
npm install --save-dev gulp-concat gulp-uglify gulp-sass gulp-minify-css gulp-rename
``` 

Before we dig into the task set up, let's take a look at three different parts of a typical gulp task:

1.  We start the task by returning a chain of events. The files passed into the chain of events are accessed by `gulp.src()`, which takes a glob as its parameter. A glob is either a string to a collection of files, or a string to a direct file.
2.  We can then `pipe` each event or method onto our sequence of files.
3.  Finally, we will specify a destination for the output using the `dest` command.

Let's import our new packages into the gulp file:

```javascript
// require other packages
var concat = require('gulp-concat');
var cssmin = require('gulp-minify-css');
var rename = require("gulp-rename");
var sass = require('gulp-sass');
var uglify = require('gulp-uglify');
``` 

The order doesn't matter. My preference is just to sort them alphabetically. Now, let's focus on the JavaScript task. First, let's create a new task:

```javascript
// scripts task
gulp.task('scripts', function() {

});
``` 

Let's break it down into steps now. We want to fetch all the files with a `.js` extension in the `src/js` directory, concatenate them, and save it as `app.js` in our `dist/js` directory. We then want to minify this file and rename it to `app.min.js`, and save it again in the `dist/js` directory. Here's the full task:

```javascript
// scripts task
gulp.task('scripts', function() {
  return gulp.src('./src/js/*.js')
    .pipe(concat('app.js'))
    .pipe(gulp.dest('./dist/js/'))
    .pipe(uglify())
    .pipe(rename({
      suffix: '.min'
    }))
    .pipe(gulp.dest('./dist/js/'));
});
```

It's quite readable, and walking through each step should paint a clear picture of the tasks being run in order. Go back to the command line and run:

```
gulp scripts
```

You should see your scripts successfully concatenated, uglified, and renamed! Let's move on to the CSS side of things. First, let's create a new task for styles:

```javascript
// styles task
gulp.task('styles', function() {

});
``` 

Let's look at the order of our tasks now. We want to compile our Sass and output it to a `style.css` file in the `dist/css` directory. Just as with the JavaScript, we then want to minify and rename it to `style.min.css`, and save it in the same directory. Here's the full set up:

```javascript
// styles task
gulp.task('styles', function() {
  return gulp.src('./src/sass/*.scss')
    .pipe(sass())
    .pipe(gulp.dest('./dist/css/'))
    .pipe(cssmin())
    .pipe(rename({
      suffix: '.min'
    }))
    .pipe(gulp.dest('./dist/css/'));
});
````

Go ahead and run the following in the command line:

```
gulp styles
``` 

Voila, the Sass has been compiled, and the CSS minified.

## Automating With Gulp Watch

Wouldn't it be great if tasks would automatically run when a change is made in a file? It would be pretty counter productive, for example, if you had to run `gulp styles` every time you made a change to a Sass file. Gulp makes that incredibly easy with the `watch` function. Using this function, we can specify a glob to look at for changes, and specify some tasks to run when changes are seen on any of those files. Here's a very simple setup for our demonstrated case:

```javascript
// watch task
gulp.task('watch', function() {
  gulp.watch('./src/js/*.js', ['scripts']);
  gulp.watch('./src/sass/*.scss', ['styles']);
});
````

Now we can run `gulp watch` in the command line, and go ahead and edit our files as we wish. Let's go ahead and edit our Sass file. I just added the following:

```css
strong {
  font-weight: 700;
}
```  

Save it, and check the terminal. You'll notice that the correct task ran as soon as you saved your changed file without any interruption in the work flow. How simple was that?

## Further Streamlining With The Default Task

Remember that default task that we set up in the beginning that did nothing? That's a Gulp default, and it allows us to run the plain and simple `gulp` command. Now that we're all set up with our other tasks, we can edit the default one to something like this:

```javascript
gulp.task('default', ['scripts', 'styles', 'watch']);
``` 

Next time we type just `gulp` in the command line, it will run the script task, the styles task, and the watch task, compiling all our changes and watching for new ones. Pretty neat, huh?

## Wrap Up

We covered some good stuff here in this article, from implementing Gulp into your workflow, and setting up and automating tasks. Thanks again for reading, and if you have and questions, comments, or feedback, feel free to reach out.

An Introduction To Gulp.js

As CSS continues to evolve, interesting selectors and functions are always on the horizon. One that I came across some time ago is the `calc()` function, which allows you to actually perform a unit calculation and return a result. The real beauty in it for me though is that you can mix and match unit types, offering interesting ways to compute layout dimensions, particularly when building responsive layouts. In following snippets, we'll look at some very basic implementations of the `calc()` function, then step it up a notch with a real world scenario, implementing a neat calc-based solution to it. Let's dive in!

## Basic Implementation

In its most basic form, the `calc()` function takes on some values and returns the calculated dimension. According to the W3C:

> The calc() function allows mathematical expressions with addition (+), subtraction (-), multiplication (\*), and division (/) to be used as component values. The `calc()` expression represents the result of the mathematical calculation it contains, using standard operator precedence rules. It can be used wherever `<length>`, `<frequency>`, `<angle>`, `<time>`, `<number>`, or `<integer>` values are allowed.

So in essence, we could do something like this:

```css
.element {
  margin: calc(20px - 10px);
}
```

This of course is a totally useless example, because you can easily just set the margin to 10px to begin with. But it does give us a simple insight into what `calc()` can do. As I mentioned above, the function allows us to mix and match units, so something like this becomes possible too:

```css
.element {
  margin: calc(2em - 5px);
}
```

Again, this example might not be the best, but we're opening up ourselves to the power of the function. Because we're allowed to perform 4 mathematical operations, we can even get all weird and needlessly complicated with something like this:

```css
.element {
  margin: calc(10%/2em + 10px*4rem);
}
```

I'm not sure why you'd do something like this, but again, this is just an eye opener for you. Let's move on to that real-world scenario where `calc()` can help out greatly.

## Stepping It Up A Bit

Here's the scenario. We want to build a simple fixed-sidebar fluid-content layout. So imagine we have some markup like this:

```html
<div class="container">
  <div class="fixed">I am fixed</div>
  <div class="fluid">I am fluid</div>
</div>
```

You might want a fix-sized margin of 40px in between the two columns, so leveraging some negative margin and padding techniques, you'll probably do some math. I'd first set the size of the fixed column, add that to the desired fixed margin, pad the container, apply a negative left-margin on the fixed element, apply the right margin, and float the two elements. Exhausting, tough to change, but hey, it works. Here's the CSS:

```css
.container {
  padding-left: 340px;
}

.fixed,
.fluid {
  float: left;
}

.fixed {
  margin-left: -340px;
  margin-right: 40px;
  width: 300px;
}

.fluid {
  width: 100%;
}
```

What if now, we wanted to change the width of the fixed margin, or the fixed column size? We'd have to do over the calculations again, and re-apply. It can get tricky. Sass might be able to save us here, but what if we're not using Sass? Let's turn this up a little bit with the calc function and see how we can avoid the excessive calculations. Above, we made use of a 40px fixed margin, so let's do the same this time. Here's how simple this layout becomes:

```css
.container {
}

.fixed,
.fluid {
  float: left;
}

.fixed {
  width: 300px;
}

.fluid {
  margin-left: 40px;
  width: calc(100% - 340px);
}
```

Notice now that we don't even need to pad the container anymore, and there are no negative margins involved. We have one simple math calculation to make before setting up our CSS, and that's it.

Now, with flexbox coming of age amongst many other neat grid-type CSS formulas, the above might still seem a tiny bit dated. But calc plays nicely with flexbox, and based on experience, can come quite in handy there too. Nonetheless, the CSS above represents a completely valid and helpful use-case of the `calc()` function.

## Support

[Support is quite high for this](http://caniuse.com/#search=calc), and if you're mindset is in the modern sphere of things and your target audience is accessing your site/app from modern browsers, then there's no reason not to implement it in your projects today. It is a [candidate recommendation on the W3C](http://www.w3.org/TR/css3-values/), and due to it's incredible usefulness, it's here to stay.

## Wrap Up

That’s all, folks. Are you using the CSS `calc()` function? I'd love to hear about it and see an example, so feel free to reach out and let me know. Thanks again for reading, and if you have and questions, comments, or feedback, feel free to reach out.

The CSS Calc Function and Some Uses

In this tutorial, we're going to take an in-depth look into CSS perspective, and some use-cases where it can give users more natural and cool experiences.

## What Is Perspective?

In the context of the two-dimensional world, perspective gives users the illusion of an object’s depth, width, height, and position in relation to another object, when viewed from a particular point. Perspective allows artists to create scenes that look like they are going “into” the paper, or draw buildings of different sizes on a street moving away from our position. Objects will also have a vanishing point, which is the point in the 2-D plane where an object’s depth vanishes. Let’s illustrate this with a simple diagram:

![Vanishing Point](//images.ctfassets.net/rex0us6r928o/5MVbwtQi0NAu9GjgfmzldB/2d222c2c92b7f9a36be608dd44da0721/vanishing-point.png)

The above diagram depicts three objects, all rectangles, in a 2-D plane. When they are moved around the plane, lines of perspective can be drawn towards the vanishing point, and 3-dimensional objects can be extrapolated.

Since the web is viewed on two-dimensional surfaces (i.e. device screens), perspective can play a part in helping to create some similar depth. In the world of web and CSS transforms, perspective is defined like this (taken from the MDN):

> The perspective CSS property determines the distance between the z = 0 plane and the user in order to give to the 3D-positioned element some perspective. Each 3D element with z > 0 becomes larger; each 3D-element with z < 0 becomes smaller. The strength of the effect is determined by the value of this property.

The vanishing point is placed by default at the centre of the element, but we can reposition it with the `perspective-origin` property. Let’s look at a basic example.

## Demo 1 – A Basic Perspective Example

Let’s take a very primitive shape – a square – and use the perspective properties to give it a bit of depth. For the first sequence of demos, I’ll use some helper classes to show-off the following perspective ranges:

*   no `perspective`
*   100px `perspective`
*   200px `perspective`
*   `perspective-origin` at `[0, 0]`

Note that perspective properties must exist on the parent container of the element we want affected. With that in mind, the markup for the three demos will be really simple:

```html
<div class="perspective-container perspective--none">
  <span class="surface"></span>
</div>

<div class="perspective-container perspective--200">
  <span class="surface"></span>
</div>

<div class="perspective-container perspective--100 perspective-origin--00">
  <span class="surface"></span>
</div>
```

Let’s now apply the necessary CSS perspective properties:

```css
.perspective-container {
  width: 200px;
  height: 200px;
  background-color: #eee;
}

.perspective--none {
}

.perspective--100 {
  perspective: 100px;
}

.perspective--200 {
  perspective: 200px;
}

.perspective-origin--00 {
  perspective-origin: 0px 0px;
}

.surface {
  display: block;
  width: 100%;
  height: 100%;
  background-color: #377CFF;
}
```

If we refresh our browser, we will see three identical squares. Why? Because none of our objects have actually moved in the perspective plane. To see how the perspective properties affect our objects, let’s translate them along the z-axis into the plane using `transform`. We’ll add the following CSS to our `.surface` class that governs our objects:

```css
.surface {
  transform: translateZ(-50px);
}
```

Now, we can see three different results:

1.  The first remains unchanged, because without any perspective rules in place, translating along the z-axis (i.e. in and out of the screen) causes no change in depth.
2.  The second appears to have moved into the screen a bit, because we set the `perspective` to `200px`. Remember from the definition above that the perspective property determines the distance between the `z = 0` plane and the user.
3.  The third appears even smaller still, and has moved to the top-left corner of our perspective container. This is because of the `perspective-origin` property set on the parent container.

Here it is in action:

<p class="codepen" data-height="300" data-default-tab="result" data-slug-hash="BvOzZz" data-pen-title="A Basic CSS Perspective Example" data-user="callmenick" style="height: 450px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;">
  <span>See the Pen <a href="https://codepen.io/callmenick/pen/BvOzZz">
  A Basic CSS Perspective Example</a> by Nick Salloum (<a href="https://codepen.io/callmenick">@callmenick</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://public.codepenassets.com/embed/index.js"></script>

## Demo 2 – Rotating Shapes With Perspective

At this point, the above effects could’ve just been achieved by simply scaling the elements. That’s a fair point, but in that case, we’d lose all perspective properties. Visualizing the perspective in the first demo might also be a bit difficult because ultimately, it’s just a smaller square. Let’s look at a slightly more advanced implementation, and paint a clearer picture.

This time, we’ll have the same three squares, but we will rotate them about the y-axis, making them rotate “into” the screen. We will use a CSS transition effect coupled with the `:hover` pseudo-class to animate how perspective properties affects the rotation. Here’s the markup:

```html
<div class="perspective-container perspective--none">
  <span class="surface"></span>
</div>

<div class="perspective-container perspective--400">
  <span class="surface"></span>
</div>

<div class="perspective-container perspective--400 perspective-origin--00">
  <span class="surface"></span>
</div>
```

This time, I added a perspective helper class at `400px` also like this:

```css
.perspective--400 {
  perspective: 400px;
}
```

Finally, let’s take a look at the CSS for our new shape:

```css
.surface {
  display: block;
  width: 100%;
  height: 100%;
  background-color: #377CFF;
  transition: transform 1s;
}

.perspective-container:hover > .surface {
  transform: rotateY(180deg);
}
```

Hovering over the three different implementations results in three different outcomes:

1.  With no `perspective` set, the object rotates about the z-axis in a very flat manner. Nothing seems to pop in our out of the screen.
2.  When we set `perspective` to `400px`, we can see that the object now looks like it is spinning out and back into the screen. This is because of `perspective`.
3.  With the `perspective` set to `400px` and the `perspective-origin` moved to `[0 0]`, a similar effect to number 2 is achieved, but this time viewed from the perspective origin.

Here it is in action! Now, we’re starting to see the power of CSS perspectives.

<p class="codepen" data-height="300" data-default-tab="result" data-slug-hash="ebLzKj" data-pen-title="Rotating Shapes with CSS Perspective" data-user="callmenick" style="height: 450px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;">
  <span>See the Pen <a href="https://codepen.io/callmenick/pen/ebLzKj">
  Rotating Shapes with CSS Perspective</a> by Nick Salloum (<a href="https://codepen.io/callmenick">@callmenick</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://public.codepenassets.com/embed/index.js"></script>

## Demo 3 – 3D Cube With Variable Perspective Origins

Now, we’re going to get a little funky. We’re going to create a cube (with 6 faces) using CSS `transform`, and give that cube some depth using `perspective`. We will also set up a controller system so that we can edit the perspective and perspective origin on the fly, giving us a superior grasp on how perspective really affects everything.

We’ll set up our cube using 6 different `span` elements inside a parent `div` with the class of `cube-face`. Each `cube-face` will represent a different face of the cube. The cube itself will now reside inside a perspective `div`, called `cube`. Here’s the markup:

```html
<div id="cube" class="cube">
  <div class="cube-faces">
    <span class="cube-face cube-face--front"></span>
    <span class="cube-face cube-face--back"></span>
    <span class="cube-face cube-face--top"></span>
    <span class="cube-face cube-face--bottom"></span>
    <span class="cube-face cube-face--left"></span>
    <span class="cube-face cube-face--right"></span>
  </div>
</div>
``` 

We’ll set up some defaults for the perspective wrapping container, and the cube container will have relative positioning so that each of the cube faces can be absolutely positioned inside, and transformed accordingly. Assuming we want a cube where each side is `200px` in length, our CSS will look like this:

```css
.cube {
  perspective: 1000px;
  perspective-origin: 0px 0px;
}

.cube-faces {
  position: relative;
  margin: 100px auto;
  width: 200px;
  height: 200px;
  transform-style: preserve-3d;
}
```    

Notice that I initially set the `perspective` to be `1000px`, and the `perspective-origin` to be `0px 0px`. This will give us some depth to work with initially so we can see transformed objects moving into and out of the plane. Remember, without `perspective`, transformed objects would not achieve that third-dimensional depth that we’re after.

Let’s examine the faces of the cube now. First of all, each face needs to be absolutely positioned and have a `width` and `height` of `200px`. I’ll apply some inner shadows to each face also, for visualisation purposes. Here’s the common CSS for the faces:

```css
.cube-face {
  position: absolute;
  top: 0;
  left: 0;
  display: block;
  width: 200px;
  height: 200px;
  background-color: rgba(#377CFF, 0.3);
  box-shadow: inset 0 0 0 2px #fff;
}
``` 

Now, let’s look at each individual face. We set up our cube to be `200 x 200 x 200`. But we want to give some depth in general. So let’s pull the front face towards us by `100px` and push the back face away from us by `100px`, leaving us with that perfect `200px` square as the center plane of our cube on the x-y axis. The back face should also be rotated `180deg`, so that it is facing outwards. So we’re translating each face first, then rotating where necessary. Here’s the CSS:

```css
.cube-face--front {
  transform: translateZ(100px);
}

.cube-face--back {
  transform: translateZ(-100px) rotateY(-180deg);
}
```    

Now, let’s look at the left and right faces. The left face needs to be translated to the left by `100px`, then rotated by `–90` degrees about the y-axis. The right face does the opposite. These rules will get them into position:

```css
.cube-face--left {
  transform: translateX(-100px) rotateY(-90deg);
}

.cube-face--right {
  transform: translateX(100px) rotateY(90deg);
}
```

Now, let’s take a look at the top and bottom faces. The top face needs to move upwards `100px`, and rotate about the x-axis by `90` degrees, while the bottom needs to to the opposite. These rules place them in position:

```css
.cube-face--top {
  transform: translateY(-100px) rotateX(90deg);
}

.cube-face--bottom {
  transform: translateY(100px) rotateX(-90deg);
}
```

And voila, now we have our CSS cube, using transforms and perspective! Let’s take it a step further though add some controls now that will allow us to change `perspective` and `perspective-origin` on the fly. I’ll use the range `input`, and wire up three of them to handle the respective properties. Here’s the markup:

```html
<input id="p" type="range" min="500" max="5000" value="1000" step="1">
<input id="pX" type="range" min="-5000" max="5000" value="0" step="1">
<input id="pY" type="range" min="-5000" max="5000" value="0" step="1">
```

And here’s some JavaScript to give us a playful little demo:

```javascript
var cube = document.getElementById('cube');
var p = document.getElementById('p');
var pX = document.getElementById('pX');
var pY = document.getElementById('pY');
var pVal;
var xVal;
var yVal;

p.addEventListener( 'input', function() {
  cube.style.perspective = `${p.value}px`;
});

pX.addEventListener( 'input', function() {
  cube.style.perspectiveOrigin = `${pX.value}px ${pY.value}px`;
});

pY.addEventListener( 'input', function() {
  cube.style.perspectiveOrigin = `${pX.value}px ${pY.value}px`;
});
```

And now, we have an interactive demo of a 3D cube, creating using CSS3 transforms and perspectives. The demo should truly give you a grasp on how perspective is handled in the browser. Check it out here below!

<p class="codepen" data-height="600" data-default-tab="result" data-slug-hash="MZqedq" data-pen-title="3D CSS Cube using Perspective" data-user="callmenick" style="height: 600px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;">
  <span>See the Pen <a href="https://codepen.io/callmenick/pen/MZqedq">
  3D CSS Cube using Perspective</a> by Nick Salloum (<a href="https://codepen.io/callmenick">@callmenick</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://public.codepenassets.com/embed/index.js"></script>

## Browser Support

Perspective, transitions, and animations are supported in IE10 and up, whereas transforms are supported in IE9 and up. Fallbacks should be easy to implement as a result of this. I tested all the code above in new versions of Chrome, Safari, and Firefox, so you’re safe there. Make sure to add all then necessary vendor prefixes though!

## Wrap Up

And that’s a wrap! We’ve just taken an in depth look at CSS3 perspective, and some of the possibilities available when combining perspective with transforms, transitions, and animations. Thanks again for reading, and if you have and questions, comments, or feedback, feel free to get in touch.

.css-5tz8fq{color:var(--chakra-colors-gray-900);-webkit-text-decoration:none;text-decoration:none;}.css-5tz8fq:hover,.css-5tz8fq[data-hover]{color:var(--chakra-colors-gray-900);}CSS Sticky Footer with Flexbox and Grid

CSS Sticky Footer with Flexbox and Grid