rowid,title,contents,year,author,author_slug,published,url,topic
18,Grunt for People Who Think Things Like Grunt are Weird and Hard,"Front-end developers are often told to do certain things:


	Work in as small chunks of CSS and JavaScript as makes sense to you, then concatenate them together for the production website.
	Compress your CSS and minify your JavaScript to make their file sizes as small as possible for your production website.
	Optimize your images to reduce their file size without affecting quality.
	Use Sass for CSS authoring because of all the useful abstraction it allows.


That’s not a comprehensive list of course, but those are the kind of things we need to do. You might call them tasks.

I bet you’ve heard of Grunt. Well, Grunt is a task runner. Grunt can do all of those things for you. Once you’ve got it set up, which isn’t particularly difficult, those things can happen automatically without you having to think about them again.

But let’s face it: Grunt is one of those fancy newfangled things that all the cool kids seem to be using but at first glance feels strange and intimidating. I hear you. This article is for you.

Let’s nip some misconceptions in the bud right away

Perhaps you’ve heard of Grunt, but haven’t done anything with it. I’m sure that applies to many of you. Maybe one of the following hang-ups applies to you.

I don’t need the things Grunt does

You probably do, actually. Check out that list up top. Those things aren’t nice-to-haves. They are pretty vital parts of website development these days. If you already do all of them, that’s awesome. Perhaps you use a variety of different tools to accomplish them. Grunt can help bring them under one roof, so to speak. If you don’t already do all of them, you probably should and Grunt can help. Then, once you are doing those, you can keep using Grunt to do more for you, which will basically make you better at doing your job.

Grunt runs on Node.js — I don’t know Node

You don’t have to know Node. Just like you don’t have to know Ruby to use Sass. Or PHP to use WordPress. Or C++ to use Microsoft Word.

I have other ways to do the things Grunt could do for me

Are they all organized in one place, configured to run automatically when needed, and shared among every single person working on that project? Unlikely, I’d venture.

Grunt is a command line tool — I’m just a designer

I’m a designer too. I prefer native apps with graphical interfaces when I can get them. But I don’t think that’s going to happen with Grunt1.

The extent to which you need to use the command line is:


	Navigate to your project’s directory.
	Type grunt and press Return.


After set-up, that is, which again isn’t particularly difficult.

OK. Let’s get Grunt installed

Node is indeed a prerequisite for Grunt. If you don’t have Node installed, don’t worry, it’s very easy. You literally download an installer and run it. Click the big Install button on the Node website.

You install Grunt on a per-project basis. Go to your project’s folder. It needs a file there named package.json at the root level. You can just create one and put it there.

 package.json at root

The contents of that file should be this:

{
  ""name"": ""example-project"",
  ""version"": ""0.1.0"",
  ""devDependencies"": {
    ""grunt"": ""~0.4.1""
  }
}

Feel free to change the name of the project and the version, but the devDependencies thing needs to be in there just like that.

This is how Node does dependencies. Node has a package manager called NPM (Node packaged modules) for managing Node dependencies (like a gem for Ruby if you’re familiar with that). You could even think of it a bit like a plug-in for WordPress.

Once that package.json file is in place, go to the terminal and navigate to your folder. Terminal rubes like me do it like this:

 Terminal rube changing directories

Then run the command:

npm install

After you’ve run that command, a new folder called node_modules will show up in your project.

 Example of node_modules folder

The other files you see there, README.md and LICENSE are there because I’m going to put this project on GitHub and that’s just standard fare there.

The last installation step is to install the Grunt CLI (command line interface). That’s what makes the grunt command in the terminal work. Without it, typing grunt will net you a “Command Not Found”-style error. It is a separate installation for efficiency reasons. Otherwise, if you had ten projects you’d have ten copies of Grunt CLI.

This is a one-liner again. Just run this command in the terminal:

npm install -g grunt-cli

You should close and reopen the terminal as well. That’s a generic good practice to make sure things are working right. Kinda like restarting your computer after you install a new application was in the olden days.

Let’s make Grunt concatenate some files

Perhaps in our project there are three separate JavaScript files:


	jquery.js – The library we are using.
	carousel.js – A jQuery plug-in we are using.
	global.js – Our authored JavaScript file where we configure and call the plug-in.


In production, we would concatenate all those files together for performance reasons (one request is better than three). We need to tell Grunt to do this for us.

But wait. Grunt actually doesn’t do anything all by itself. Remember Grunt is a task runner. The tasks themselves we will need to add. We actually haven’t set up Grunt to do anything yet, so let’s do that.

The official Grunt plug-in for concatenating files is grunt-contrib-concat. You can read about it on GitHub if you want, but all you have to do to use it on your project is to run this command from the terminal (it will henceforth go without saying that you need to run the given commands from your project’s root folder):

npm install grunt-contrib-concat --save-dev

A neat thing about doing it this way: your package.json file will automatically be updated to include this new dependency. Open it up and check it out. You’ll see a new line:

""grunt-contrib-concat"": ""~0.3.0""

Now we’re ready to use it. To use it we need to start configuring Grunt and telling it what to do.

You tell Grunt what to do via a configuration file named Gruntfile.js2

Just like our package.json file, our Gruntfile.js has a very special format that must be just right. I wouldn’t worry about what every word of this means. Just check out the format:

module.exports = function(grunt) {

    // 1. All configuration goes here 
    grunt.initConfig({
        pkg: grunt.file.readJSON('package.json'),

        concat: {
            // 2. Configuration for concatinating files goes here.
        }

    });

    // 3. Where we tell Grunt we plan to use this plug-in.
    grunt.loadNpmTasks('grunt-contrib-concat');

    // 4. Where we tell Grunt what to do when we type ""grunt"" into the terminal.
    grunt.registerTask('default', ['concat']);

};

Now we need to create that configuration. The documentation can be overwhelming. Let’s focus just on the very simple usage example.

Remember, we have three JavaScript files we’re trying to concatenate. We’ll list file paths to them under src in an array of file paths (as quoted strings) and then we’ll list a destination file as dest. The destination file doesn’t have to exist yet. It will be created when this task runs and squishes all the files together.

Both our jquery.js and carousel.js files are libraries. We most likely won’t be touching them. So, for organization, we’ll keep them in a /js/libs/ folder. Our global.js file is where we write our own code, so that will be right in the /js/ folder. Now let’s tell Grunt to find all those files and squish them together into a single file named production.js, named that way to indicate it is for use on our real live website.

concat: {   
    dist: {
        src: [
            'js/libs/*.js', // All JS in the libs folder
            'js/global.js'  // This specific file
        ],
        dest: 'js/build/production.js',
    }
}

Note: throughout this article there will be little chunks of configuration code like above. The intention is to focus in on the important bits, but it can be confusing at first to see how a particular chunk fits into the larger file. If you ever get confused and need more context, refer to the complete file.

With that concat configuration in place, head over to the terminal, run the command:

grunt

and watch it happen! production.js will be created and will be a perfect concatenation of our three files. This was a big aha! moment for me. Feel the power course through your veins. Let’s do more things!

Let’s make Grunt minify that JavaScript

We have so much prep work done now, adding new tasks for Grunt to run is relatively easy. We just need to:


	Find a Grunt plug-in to do what we want
	Learn the configuration style of that plug-in
	Write that configuration to work with our project


The official plug-in for minifying code is grunt-contrib-uglify. Just like we did last time, we just run an NPM command to install it:

npm install grunt-contrib-uglify --save-dev

Then we alter our Gruntfile.js to load the plug-in:

grunt.loadNpmTasks('grunt-contrib-uglify');

Then we configure it:

uglify: {
    build: {
        src: 'js/build/production.js',
        dest: 'js/build/production.min.js'
    }
}

Let’s update that default task to also run minification:

grunt.registerTask('default', ['concat', 'uglify']);

Super-similar to the concatenation set-up, right?

Run grunt at the terminal and you’ll get some deliciously minified JavaScript:

 Minified JavaScript

That production.min.js file is what we would load up for use in our index.html file.

Let’s make Grunt optimize our images

We’ve got this down pat now. Let’s just go through the motions. The official image minification plug-in for Grunt is grunt-contrib-imagemin. Install it:

npm install grunt-contrib-imagemin --save-dev

Register it in the Gruntfile.js:

grunt.loadNpmTasks('grunt-contrib-imagemin');

Configure it:

imagemin: {
    dynamic: {
        files: [{
            expand: true,
            cwd: 'images/',
            src: ['**/*.{png,jpg,gif}'],
            dest: 'images/build/'
        }]
    }
}

Make sure it runs:

grunt.registerTask('default', ['concat', 'uglify', 'imagemin']);

Run grunt and watch that gorgeous squishification happen:

 Squished images

Gotta love performance increases for nearly zero effort.

Let’s get a little bit smarter and automate

What we’ve done so far is awesome and incredibly useful. But there are a couple of things we can get smarter on and make things easier on ourselves, as well as Grunt:


	Run these tasks automatically when they should
	Run only the tasks needed at the time


For instance:


	Concatenate and minify JavaScript when JavaScript changes
	Optimize images when a new image is added or an existing one changes


We can do this by watching files. We can tell Grunt to keep an eye out for changes to specific places and, when changes happen in those places, run specific tasks. Watching happens through the official grunt-contrib-watch plugin.

I’ll let you install it. It is exactly the same process as the last few plug-ins we installed. We configure it by giving watch specific files (or folders, or both) to watch. By watch, I mean monitor for file changes, file deletions or file additions. Then we tell it what tasks we want to run when it detects a change.

We want to run our concatenation and minification when anything in the /js/ folder changes. When it does, we should run the JavaScript-related tasks. And when things happen elsewhere, we should not run the JavaScript-related tasks, because that would be irrelevant. So:

watch: {
    scripts: {
        files: ['js/*.js'],
        tasks: ['concat', 'uglify'],
        options: {
            spawn: false,
        },
    } 
}

Feels pretty comfortable at this point, hey? The only weird bit there is the spawn thing. And you know what? I don’t even really know what that does. From what I understand from the documentation it is the smart default. That’s real-world development. Just leave it alone if it’s working and if it’s not, learn more.

Note: Isn’t it frustrating when something that looks so easy in a tutorial doesn’t seem to work for you? If you can’t get Grunt to run after making a change, it’s very likely to be a syntax error in your Gruntfile.js. That might look like this in the terminal:

 Errors running Grunt

Usually Grunt is pretty good about letting you know what happened, so be sure to read the error message. In this case, a syntax error in the form of a missing comma foiled me. Adding the comma allowed it to run.

Let’s make Grunt do our preprocessing

The last thing on our list from the top of the article is using Sass — yet another task Grunt is well-suited to run for us. But wait? Isn’t Sass technically in Ruby? Indeed it is. There is a version of Sass that will run in Node and thus not add an additional dependency to our project, but it’s not quite up-to-snuff with the main Ruby project. So, we’ll use the official grunt-contrib-sass plug-in which just assumes you have Sass installed on your machine. If you don’t, follow the command line instructions.

What’s neat about Sass is that it can do concatenation and minification all by itself. So for our little project we can just have it compile our main global.scss file:

sass: {
    dist: {
        options: {
            style: 'compressed'
        },
        files: {
            'css/build/global.css': 'css/global.scss'
        }
    } 
}

We wouldn’t want to manually run this task. We already have the watch plug-in installed, so let’s use it! Within the watch configuration, we’ll add another subtask:

css: {
    files: ['css/*.scss'],
    tasks: ['sass'],
    options: {
        spawn: false,
    }
}

That’ll do it. Now, every time we change any of our Sass files, the CSS will automaticaly be updated.

Let’s take this one step further (it’s absolutely worth it) and add LiveReload. With LiveReload, you won’t have to go back to your browser and refresh the page. Page refreshes happen automatically and in the case of CSS, new styles are injected without a page refresh (handy for heavily state-based websites).

It’s very easy to set up, since the LiveReload ability is built into the watch plug-in. We just need to:


Install the browser plug-in
Add to the top of the watch configuration:
. watch: {
    options: {
        livereload: true,
    },
    scripts: {   
    /* etc */

Restart the browser and click the LiveReload icon to activate it.
Update some Sass and watch it change the page automatically.


 Live reloading browser

Yum.

Prefer a video?

If you’re the type that likes to learn by watching, I’ve made a screencast to accompany this article that I’ve published over on CSS-Tricks: First Moments with Grunt

Leveling up

As you might imagine, there is a lot of leveling up you can do with your build process. It surely could be a full time job in some organizations.

Some hardcore devops nerds might scoff at the simplistic setup we have going here. But I’d advise them to slow their roll. Even what we have done so far is tremendously valuable. And don’t forget this is all free and open source, which is amazing.

You might level up by adding more useful tasks:


	Running your CSS through Autoprefixer (A+ Would recommend) instead of a preprocessor add-ons.
	Writing and running JavaScript unit tests (example: Jasmine).
	Build your image sprites and SVG icons automatically (example: Grunticon).
	Start a server, so you can link to assets with proper file paths and use services that require a real URL like TypeKit and such, as well as remove the need for other tools that do this, like MAMP.
	Check for code problems with HTML-Inspector, CSS Lint, or JS Hint.
	Have new CSS be automatically injected into the browser when it ever changes.
	Help you commit or push to a version control repository like GitHub.
	Add version numbers to your assets (cache busting).
	Help you deploy to a staging or production environment (example: DPLOY).


You might level up by simply understanding more about Grunt itself:


	Read Grunt Boilerplate by Mark McDonnell.
	Read Grunt Tips and Tricks by Nicolas Bevacqua.
	Organize your Gruntfile.js by splitting it up into smaller files.
	Check out other people’s and projects’ Gruntfile.js.
	Learn more about Grunt by digging into its source and learning about its API.


Let’s share

I think some group sharing would be a nice way to wrap this up. If you are installing Grunt for the first time (or remember doing that), be especially mindful of little frustrating things you experience(d) but work(ed) through. Those are the things we should share in the comments here. That way we have this safe place and useful resource for working through those confusing moments without the embarrassment. We’re all in this thing together!

 

1 Maybe someday someone will make a beautiful Grunt app for your operating system of choice. But I’m not sure that day will come. The configuration of the plug-ins is the important part of using Grunt. Each plug-in is a bit different, depending on what it does. That means a uniquely considered UI for every single plug-in, which is a long shot.

Perhaps a decent middleground is this Grunt DevTools Chrome add-on.

2 Gruntfile.js is often referred to as Gruntfile in documentation and examples. Don’t literally name it Gruntfile — it won’t work.",2013,Chris Coyier,chriscoyier,2013-12-11T00:00:00+00:00,https://24ways.org/2013/grunt-is-not-weird-and-hard/,code
20,Make Your Browser Dance,"It was a crisp winter’s evening when I pulled up alongside the pier. I stepped out of my car and the bitterly cold sea air hit my face. I walked around to the boot, opened it and heaved out a heavy flight case. I slammed the boot shut, locked the car and started walking towards the venue.

This was it. My first gig. I thought about all those weeks of preparation: editing video clips, creating 3-D objects, making coloured patterns, then importing them all into software and configuring effects to change as the music did; targeting frequency, beat, velocity, modifying size, colour, starting point; creating playlists of these… and working out ways to mix them as the music played.

This was it. This was me VJing.

This was all a lifetime (well a decade!) ago.

When I started web designing, VJing took a back seat. I was more interested in interactive layouts, semantic accessible HTML, learning all the IE bugs and mastering the quirks that CSS has to offer. More recently, I have been excited by background gradients, 3-D transforms, the @keyframe directive, as well as new APIs such as getUserMedia, indexedDB, the Web Audio API

But wait, have I just come full circle? Could it be possible, with these wonderful new things in technologies I am already familiar with, that I could VJ again, right here, in a browser?

Well, there’s only one thing to do: let’s try it!

Let’s take to the dance floor 

Over the past couple of years working in The Lab I have learned to take a much more iterative approach to projects than before. One of my new favourite methods of working is to create a proof of concept to make sure my theory is feasible, before going on to create a full-blown product. So let’s take the same approach here.

The main VJing functionality I want to recreate is manipulating visuals in relation to sound. So for my POC I need to create a visual, with parameters that can be changed, then get some sound and see if I can analyse that sound to detect some data, which I can then use to manipulate the visual parameters. Easy, right?

So, let’s start at the beginning: creating a simple visual. For this I’m going to create a CSS animation. It’s just a funky i element with the opacity being changed to make it flash.

 See the Pen Creating a light by Rumyra (@Rumyra) on CodePen

A note about prefixes: I’ve left them out of the code examples in this post to make them easier to read. Please be aware that you may need them. I find a great resource to find out if you do is caniuse.com. You can also check out all the code for the examples in this article

Start the music

Well, that’s pretty easy so far. Next up: loading in some sound. For this we’ll use the Web Audio API. The Web Audio API is based around the concept of nodes. You have a source node: the sound you are loading in; a destination node: usually the device’s speakers; and any number of processing nodes in between. All this processing that goes on with the audio is sandboxed within the AudioContext.

So, let’s start by initialising our audio context.

var contextClass = window.AudioContext;
if (contextClass) {
  //web audio api available.
  var audioContext = new contextClass();
} else {
  //web audio api unavailable
  //warn user to upgrade/change browser
}

Now let’s load our sound file into the new context we created with an XMLHttpRequest.

function loadSound() {
	//set audio file url
	var audioFileUrl = '/octave.ogg';
	//create new request
	var request = new XMLHttpRequest();
	request.open(""GET"", audioFileUrl, true);
	request.responseType = ""arraybuffer"";

	request.onload = function() {
		//take from http request and decode into buffer
		context.decodeAudioData(request.response, function(buffer) {
	    	audioBuffer = buffer;
	     });
		}
	request.send();
}

Phew! Now we’ve loaded in some sound! There are plenty of things we can do with the Web Audio API: increase volume; add filters; spatialisation. If you want to dig deeper, the O’Reilly Web Audio API book by Boris Smus is available to read online free.

All we really want to do for this proof of concept, however, is analyse the sound data. To do this we really need to know what data we have.

 Learning the steps

Let’s take a minute to step back and remember our school days and science class. I’m sure if I drew a picture of a sound wave, we would all start nodding our heads.

 

The sound you hear is caused by pressure differences in the particles in the air. Sound pushes these particles together, causing vibrations. Amplitude is basically strength of pressure. A simple example of change of amplitude is when you increase the volume on your stereo and the output wave increases in size.

This is great when everything is analogue, but the waveform varies continuously and it’s not suitable for digital processing: there’s an infinite set of values. For digital processing, we need discrete numbers.

We have to sample the waveform at set time intervals, and record data such as amplitude and frequency. Luckily for us, just the fact we have a digital sound file means all this hard work is done for us. What we’re doing in the code above is piping that data in the audio context. All we need to do now is access it.

We can do this with the Web Audio API’s analysing functionality. Just pop in an analysing node before we connect the source to its destination node.

function createAnalyser(source) {
	//create analyser node
	analyser = audioContext.createAnalyser();
	//connect to source
	source.connect(analyzer);
	//pipe to speakers
	analyser.connect(audioContext.destination);
}

The data I’m really interested in here is frequency. Later we could look into amplitude or time, but for now I’m going to stick with frequency.

The analyser node gives us frequency data via the getFrequencyByteData method.

 Don’t forget to count!

To collect the data from the getFrequencyByteData method, we need to pass in an empty array (a JavaScript typed array is ideal). But how do we know how many items the array will need when we create it?

This is really up to us and how high the resolution of frequencies we want to analyse is. Remember we talked about sampling the waveform; this happens at a certain rate (sample rate) which you can find out via the audio context’s sampleRate attribute. This is good to bear in mind when you’re thinking about your resolution of frequencies.

var sampleRate = audioContext.sampleRate;

Let’s say your file sample rate is 48,000, making the maximum frequency in the file 24,000Hz (thanks to a wonderful theorem from Dr Harry Nyquist, the maximum frequency in the file is always half the sample rate). The analyser array we’re creating will contain frequencies up to this point. This is ideal as the human ear hears the range 0–20,000hz.

So, if we create an array which has 2,400 items, each frequency recorded will be 10Hz apart. However, we are going to create an array which is half the size of the FFT (fast Fourier transform), which in this case is 2,048 which is the default. You can set it via the fftSize property.

//set our FFT size
analyzer.fftSize = 2048;
//create an empty array with 1024 items
var frequencyData = new Uint8Array(1024);

So, with an array of 1,024 items, and a frequency range of 24,000Hz, we know each item is 24,000 ÷ 1,024 = 23.44Hz apart.

The thing is, we also want that array to be updated constantly. We could use the setInterval or setTimeout methods for this; however, I prefer the new and shiny requestAnimationFrame.

function update() {
  	//constantly getting feedback from data
  	requestAnimationFrame(update);
  	analyzer.getByteFrequencyData(frequencyData);
}

 Putting it all together

Sweet sticks! Now we have an array of frequencies from the sound we loaded, updating as the sound plays. Now we want that data to trigger our animation from earlier.

We can easily pause and run our CSS animation from JavaScript:

element.style.webkitAnimationPlayState = ""paused"";
element.style.webkitAnimationPlayState = ""running"";

Unfortunately, this may not be ideal as our animation might be a whole heap longer than just a flashing light. We may want to target specific points within that animation to have it stop and start in a visually pleasing way and perhaps not smack bang in the middle.

There is no really easy way to do this at the moment as Zach Saucier explains in this wonderful article. It takes some jiggery pokery with setInterval to try to ascertain how far through the CSS animation you are in percentage terms.

This seems a bit much for our proof of concept, so let’s backtrack a little. We know by the animation we’ve created which CSS properties we want to change. This is pretty easy to do directly with JavaScript.

element.style.opacity = ""1"";
element.style.opacity = ""0.2"";

So let’s start putting it all together. For this example I want to trigger each light as a different frequency plays. For this, I’ll loop through the HTML elements and change the opacity style if the frequency gain goes over a certain threshold.

//get light elements
var lights = document.getElementsByTagName('i');
var totalLights = lights.length;

for (var i=0; i<totalLights; i++) {
  //get frequencyData key
  var freqDataKey = i*8;
	//if gain is over threshold for that frequency animate light
  if (frequencyData[freqDataKey] > 160){
    //start animation on element
    lights[i].style.opacity = ""1"";
  } else {
    lights[i].style.opacity = ""0.2"";
  }
}

See all the code in action here. I suggest viewing in a modern browser :)

Awesome! It is true — we can VJ in our browser!

Let’s dance!

So, let’s start to expand this simple example. First, I feel the need to make lots of lights, rather than just a few. Also, maybe we should try a sound file more suited to gigs or clubs.

Check it out!

I don’t know about you, but I’m pretty excited — that’s just a bit of HTML, CSS and JavaScript!

The other thing to think about, of course, is the sound that you would get at a venue. We don’t want to load sound from a file, but rather pick up on what is playing in real time. The easiest way to do this, I’ve found, is to capture what my laptop’s mic is picking up and piping that back into the audio context. We can do this by using getUserMedia.

Let’s include this in this demo. If you make some noise while viewing the demo, the lights will start to flash.

 And relax :)

There you have it. Sit back, play some music and enjoy the Winamp like experience in front of you.

So, where do we go from here? I already have a wealth of ideas. We haven’t started with canvas, SVG or the 3-D features of CSS. There are other things we can detect from the audio as well. And yes, OK, it’s questionable whether the browser is the best environment for this. For one, I’m using a whole bunch of nonsensical HTML elements (maybe each animation could be held within a web component in the future). But hey, it’s fun, and it looks cool and sometimes I think it’s OK to just dance.",2013,Ruth John,ruthjohn,2013-12-02T00:00:00+00:00,https://24ways.org/2013/make-your-browser-dance/,code
23,Animating Vectors with SVG,"It is almost 2014 and fifteen years ago the W3C started to develop a web-based scalable vector graphics (SVG) format. As web technologies go, this one is pretty old and well entrenched. 

See the Pen yJflC by Drew McLellan (@drewm) on CodePen


Embed not working on your device? Try direct. 

Unlike rasterized images, SVG files will stay crisp and sharp at any resolution. With high-DPI phones, tablets and monitors, all those rasterized icons are starting to look a bit old and blocky. There are several options to get simpler, decorative pieces to render smoothly and respond to various device widths, shapes and sizes. Symbol fonts are one option; the other is SVG.

I’m a big fan of SVG. SVG is an XML format, which means it is possible to write by hand or to script. The most common way to create an SVG file is through the use of various drawing applications like Illustrator, Inkscape or Sketch. All of them open and save the SVG format.

But, if SVG is so great, why doesn’t it get more attention?

The simple answer is that for a long time it wasn’t well supported, so no one touched the technology. SVG’s adoption has always been hampered by browser support, but that’s not the case any more. Every modern browser (at least three versions back) supports SVG. Even IE9. 

Although the browsers support SVG, it is implemented in many different ways.

SVG in HTML

Some browsers allow you to embed SVG right in the HTML: the <svg> element. Treating SVG as a first-class citizen works — sometimes. Another way to embed SVG is via the <img> element; using the src attribute, you can refer to an SVG file. Again, this only works sometimes and leaves you in a tight space if you need to have a fallback for older browsers. The most common solution is to use the <object> element, with the data attribute referencing the SVG file. When a browser does not support this, it falls back to the content inside the <object>. This could be a rasterized fallback <img>. This method gets you the best of both worlds: a nice vector image with an alternative rasterized image for browsers that don’t support SVG. The downside is that you need to manage both formats, and some browsers will download both the SVG and the rasterized version, becoming a performance problem.

Alexey Ten came up with a brilliant little trick that uses inline SVG combined with an SVG <image> element. This has an SVG href pointing to the vector SVG representation and a src attribute to the rasterized version. Older browsers will rewrite the <image> element as <img> and use the rasterized src attribute, but modern browsers will show the vector SVG.

<svg width=""96"" height=""96"">
    <image xlink:href=""svg.svg"" src=""svg.png"" width=""96"" height=""96""/>
</svg>

It is a great workaround for most situations. You will have to determine the browsers you want or need to support and consider performance issues to decide which method is best for you.

So it can be used in HTML. Why?

There are two compelling reasons why vector graphics in the form of icons and symbols are going to be important on the web. With higher resolution screens, going from 72dpi to 200, 300, even over 400dpi, your rasterized icons are looking a little too blocky. As we zoom and print, we expect the visuals on the site to also stay smooth and crisp.

The other main reason vector graphics are useful is scaling. As responsive websites become the norm, we need a way to dynamically readjust the heights, widths and styles of various elements. SVG handles this perfectly, since vectors remain smooth when changing size.

SVG files are text-based, so they’re small and can be gzipped nicely. There are also techniques for creating SVG sprites to further squeeze out performance gains. But SVG really shines when you begin to couple it with JavaScript. Since SVG elements are part of the DOM, they can be interacted with just like any other element you are used to.

The folks at Vox Media had an ingenious little trick with their SVG for a Playstation and Xbox One reviews. I’ve used the same technique for the 24 ways example. Vox Media spent a lot of time creating SVG line art of the two consoles, but once in place the artwork scaled and resized beautifully. 

They still had another trick up their sleeves. In their example, they knew each console was line art, so they used SVG’s line dash property to simulate the lines being drawn by animating the growth of the line by small percentage increments until the lines were complete.

This is a great example of a situation where the alternatives wouldn’t be as straightforward to implement. Using an animated GIF would create a heavy file since it would need to contain all the frames of the animation at a large size to permit scaling; even then, smooth aliasing would be lost. canvas and plenty of JavaScript would be another alternative, but this is a rasterized format. It would need be redrawn at each scale, which is certainly possible, but smoothness would be lost when zooming or printing.

The HTML, SVG and JavaScript for this example is less than 4KB! Let’s have a quick look at the code:

<script>
var current_frame = 0;
var total_frames = 60;
var path = new Array();
var length = new Array();
for(var i=0; i<4;i++){
	path[i] = document.getElementById('i'+i);
	l = path[i].getTotalLength();
	length[i] = l;
	path[i].style.strokeDasharray = l + ' ' + l; 
	path[i].style.strokeDashoffset = l;
}
var handle = 0;

var draw = function() {
   var progress = current_frame/total_frames;
   if (progress > 1) {
     window.cancelAnimationFrame(handle);
   } else {
     current_frame++;
     for(var j=0; j<path.length;j++){
	     path[j].style.strokeDashoffset = Math.floor(length[j] * (1 - progress));
     }
     handle = window.requestAnimationFrame(draw);
   }
};
draw();
</script>

First, we need to initialize a few variables to set the current frame, the number of frames, how fast the animation will run, and we get each of the paths based on their IDs. With those paths, we set the dash and dash offset.

path[i].style.strokeDasharray = l + ' ' + l; 
path[i].style.strokeDashoffset = l;

We start the line as a dash, which effectively makes it blank or invisible.

Next, we move to the draw() function. This is where the magic happens. We want to increment the frame to move us forward in the animation and check it’s not finished. If it continues, we then take a percentage of the distance based on the frame and then set the dash offset to this new percentage. This gives the illusion that the line is being drawn. Then we have an animation callback, which starts the draw process over again.

That’s it! It will work with any SVG <path> element that you can draw.

Libraries to get you started

If you aren’t sure where to start with SVG, there are several libraries out there to help. They also abstract all browser compatibility issues to make your life easier.


	Raphaël
	Snap.svg
	svg.js


You can also get most vector applications to export SVG. This means that you can continue your normal workflows, but instead of flattening the image as a PNG or bringing it over to Photoshop to rasterize, you can keep all your hard work as vectors and reap the benefits of SVG.",2013,Brian Suda,briansuda,2013-12-07T00:00:00+00:00,https://24ways.org/2013/animating-vectors-with-svg/,