Browser support for SVG isn't quite as simple as yes or no. In addition to some quirks on how that support plays out, it depends on how that SVG is being used. One common way is right within an image tag, like <img src="image.svg" alt="description">.

How can you detect if a browser supports SVG use in that way?

It's one thing to just know which browsers do. The only real danger zones are IE 8- and Android 2.3. You could do user agent detection, and while I wouldn't want to get too judgey about that, it's generally a bad idea.

I was looking at SVGeezy, a mini JavaScript plugin specifically for helping with SVG-as-img fallbacks. Of course, in order for it to work, it needs to do a feature detect. In the source code, it's a simple a one liner:

supportsSvg: function() {
      return document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#Image", "1.1");
    }

I had never seen document.implementation.hasFeature ever before, so I asked around a bit, as it seemed a little too good to be true for something I'd never even heard of. Most documentation out there is pretty generic and suggest great browser support, making me even more skeptical.

The deal is: it's pretty much useless. It almost always returns true for everything. Except, apparently, in the case of SVG-as-img, when it's correct. As a skeptic, I went about creating a test to see if this was really true.

The first thing I did was check how Modernizr detects it, as the go-to source for feature detects. Important note here: Modernizr's default SVG test (Modernizr.svg) is not testing SVG-as-img support, it's testing SVG support as an <object> or <embed>. Just be aware of that when using it for fallbacks. Test the right thing (they have tests for all the ways you can use SVG).

They have a test specifically for SVG-as-img that was like this:

Modernizr.addAsyncTest(function () {
      var img = new Image();
    
      img.onerror = function () {
        addTest('svgasimg', false);
      };
      img.onload = function () {
        addTest('svgasimg', img.width == 1 && img.height == 1);
      };
    
      // 1px x 1px SVG; must be base64 or URI encoded for IE9... base64 is shorter
      img.src = 'data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==';
    });

This creates an new image element, injects a Data URI of a 1x1 SVG image then either waits for it to fail or load correctly.

Obviously different than the hasFeature test, so I created a Pen that showed the results of both methods. Then I tested in all kinds of different browsers. A mixture of those which are known to support SVG-as-img and those that do not. In all cases, the results were identical. Weird, but pretty cool!

The original Modernizr test is what they call an "async" test, meaning it relies upon callback functions to give an answer. Modernizr generally prefers "sync" tests in which as soon as the test is defined it has the right answer.

So, after talking about it with the Modernizr team, it is now the default test for SVG-as-img. It's not quite out in a release yet, so for now you'd have to just run it.

Modernizr.addTest('svgasimg', document.implementation.hasFeature('http://www.w3.org/TR/SVG11/feature#Image', '1.1'));

I'll update this post (and the version we run on CodePen) as soon as it's out.

Thanks to Patrick Kettner for overseeing it getting into Modernizr, Stu Cox for the feedback and OKing the replacement of his original method, Ben Howdle for knowing about the cool hasFeature() and using it in SVGeezy and Mike Taylor for verifying it's usefulness.

Oh, and if you you detect the browser doesn't support SVG-as-img, you'll want to flip out the src for an image format that is supported. Probably the-same-image.png either automatically based on a naming convention or selectively based on a data-* attribute.

Test for Support of SVG as img is a post from CSS-Tricks

The open source movement has been responsible for many great innovations over the past few decades. Linux, the Apache Web Server, and Rails are just a few examples of open source projects that have elevated the web industry to new heights.

In this post I want to discuss the ideas around the open source movement, and why you should consider giving up some of your free time to work on an open source project. Just to be clear, you don’t need to be a programmer to work on an open source project. In fact, it’s often the case that the people open source projects need the most are creative designers, copywriters, and translators.

Why Bother with Open Source?

The Open Source Initiative Logo

The open source software movement is something that many people outside the tech industry struggle to understand. Why would you give up your free time to work on something you’re not getting paid for?. I’ve heard this question many times when speaking with friends and colleagues from outside the industry. To them it seems counter-intuitive to work on something for free. So if you’re not getting paid for this work, why should you do it?

Note: Some people do get paid to work on open source projects. For example, Google engineers get paid to work on Chromium as it’s their full-time job.

There are many benefits to working on an open source project. For me personally, the biggest thing has been having the opportunity to work with some really great people. Open source allows you to make connections far outside your normal circle of friends and co-workers. Casting out into such a wide pool of talent can be daunting at first. You might have to deal with issues you haven’t encountered before, like language barriers or working with people in different timezones. All of this is good experience though, which leads me into my next point.

Working on an open source project allows you to develop your skills, learn new things, and gain valuable experience working on a collaborative software project. I can’t stress enough how important this is, especially if you’re a student or just starting out in the industry. The experience that you’ll gain through working on an open source project is invaluable. This isn’t just limited to developing technical skills. Being able to function as part of a team is also really important, and something that companies look for in job applicants.

Finding a Project

Hopefully by now you’re sold on the idea of working on an open source project and eager to get started. But how do you find a project to work on?

The first thing you should do is to look at the software you use every day. Are any of those products open source? If so, those projects are the ones you should check out first.

The chances are you’re going to do much better work if you join a project that builds something you use regularly. You’re more likely to notice little bugs and things that could be changed to make the product easier to use. This concept is generally referred to as dog fooding.

The Explore GitHub page is a great place to find interesting projects to work on.

If you’re still stuck for a project to work on take a look at GitHub or Google Code and browse the projects until you find something you’re interested in.

There are exceptions to the ‘dog fooding’ rule. You might find a product that you won’t use every day, but if it’s having a real impact on the world, that might be enough to keep you motivated. The Google Person Finder project would be a good example.

Contributing to a Project

Now that you’ve found a project to work on, where do you start? The first thing you should do is check out the project documentation. Many projects have a wiki page that outlines how to get involved. This will usually explain the project’s mission and the process for making your contributions. It’s also worth looking out for a coding style guide that defines how your code needs to be formatted for it to be accepted into the codebase. Some projects will do things differently to others so it’s important to read through this information if it’s available. Again I’m falling back to my experience as a developer here, but you may find guidelines for designers, copywriters, or translators too.

The next place you should look is the project’s issue tracker. Browse through the list of issues and try to identify something you’d like to work on. Some projects (especially larger ones) maintain a list of issues that are ideal for newcomers to the project.

Some projects tag issues that are ideal for newcomers, as shown here with the Rails project.

Many projects have forums or chat rooms where members hang out and chat about the project (as well as other things). Don’t be afraid to jump in and introduce yourself to the community. These people are there for the same reason you are. They just want to build something meaningful and have fun along the way.

You Are Not Your Code

Okay so now you’ve joined a project, submitted your first pull-request, and are waiting anxiously for someone to review your code. Then an email drops into your inbox. You open it and find that your pull-request was rejected, or someone is questioning a design decision you made. It’s natural to feel a little disheartened at this point, especially if you’ve worked really hard on your contribution. The key here is to not get too defensive or start an argument. I’ve seen this happen many times and it almost always ends with someone leaving the project.

Just remember, you are not your code.

The objective of code review is to make sure that a project’s codebase remains high quality and sticks to a consistent style. It would actually be worrying if every patch or pull-request got accepted without any discussion. This would probably mean one of two things. Either your contribution just got blindly accepted, or you’re a genius programmer (hint: click the link, it’s a great talk).

That said, you can reduce the chances that your contribution will be held back by ensuring that you follow the guidelines in the project documentation. If you’re making any big changes it’s a good idea to discuss your design decisions with the community before you write any code.

Final Thoughts

The best thing about working on an open source project is that you have control over what you work on. Contributing to open source projects is fun, that’s why people do it. If you’re not having fun, you’re free to go work on something else.

If you’ve never contributed to an open source project before I strongly recommend that you give it a go. You’ll gain some great experience and meet some fantastic people along the way. You never quite know where the journey will take you.

Useful Links

• Explore GitHub
• The Myth of the Genius Programmer

The post Getting Involved in Open Source Projects appeared first on Treehouse Blog.

by Amelia Meman

The benefits of task runners in software development is obvious. They help to automate common, often tedious tasks and let you squarely focus on more important things, like writing awesome code. Seriously though, the ability to automate tasks such as image compression, minification, unit testing and much more is a huge time saver.

For many front-end developers, the goto task runner to-date has been Grunt which allowed you to define your tasks using JavaScript inside of a file called Gruntfile.js (AKA a Gruntfile). Basically, if you knew JavaScript then setting up a Grunt task was a fairly straightforward process and the breadth of third party plugins to for other tools such as JSHint, Sass and Uglify makes it one of the most flexible tools available.

For the most part, Grunt has been the task runner of choice but recently, a new one named Gulp.js has been getting a lot of attention for its ease of setup and incredibly easy configuration file format which makes it easily readable and manageable.

In this tutorial, I'll show you how to install Gulp and create a simple configuration file to get your feet wet with this great new task runner.

Installing Gulp.js

Gulp.js is a Node-based task runner just like Grunt and as such, you'll need to have Node.js installed to use it. This could be done several different ways, especially depending on your operating system. Being on OS X, I chose to use nvm, Tim Caswell's awesome script for managing multiple versions of Node.js. You can also download the binaries directly from the Node.js site. If you're totally new to Node.js, be sure to check out the Nettuts+ series on getting up-to-speed on Node.js.

Gulp.js comes packaged as a Node module making it incredibly easily to install using npm (Node Package Manager). To install Gulp, open up your terminal and type in the following:

npm install -g gulp

This pulls Gulp from the npm registry and configures it globally on your system so you can access via command-line.

For all intents, Gulp.js is installed at this point and you're ready to start using it with your projects.

Setting Up Your Project to Use Gulp.js

To use Gulp in your project there are a couple of key things that need to be done:

• Install two dependencies packages
• Install any plugins you'd like to use
• Create a Gulp.js file to define the tasks you'd like to run

These steps need to be done inside your project's directory so that the packages and configuration files are available to Gulp.

First, lets install the dependencies:

npm install --save-dev gulp gulp-util

Now, we'll need to install the Gulp plugins that will perform the tasks that we define in our configuration file. These plugins are also Node package modules so we'll use npm again to install them.

npm install --save-dev gulp-uglify gulp-concat

In my case, I'm installing two plugins which will allow me to minify/compress my JavaScript code using the Uglify.js compressor and concatenate all my JavaScipt files into a single source file.

Notice that I used the --save-dev flag for install the Gulp dependencies and the plugins I'll need for my project. This ensures that an entry for each one is made to my devDependencies list inside my package.json file like this:

{
      "devDependencies": {
        "gulp-util": "~2.2.13",
        "gulp": "~3.5.0",
        "gulp-uglify": "~0.2.0",
        "gulp-concat": "~2.1.7"
      }
    }

This ensures that any package dependencies for this project can be easily installed later on using npm. If you don't have a package.json file in your project, just type in npm init at the command line or open a new file in your editor, include opening and closing curly braces inside and save it as "package.json". Then rerun the npm commands listed above to update it. Note that adding the curly braces is required. Otherwise, when you try to use the --save-dev flag, npm will throw an error saying it's not a valid JSON file.

While I'm only using two plugins for my tutorial, Gulp offers over 200 plugins for all types of functionality including:

• LiveReload (gulp-livereload)
• JSHint (gulp-jshint)
• Sass (gulp-sass)
• CoffeeScript file compilation (gulp-coffee)

and many more.

The Gulpfile.js File

Like Grunt, Gulp has a namesake configuration file called gulpfile.js that defines all of the required plugins along with the tasks you'll be running. You'll need to create a file called into the root of your project folder.

The syntax is straightforward and terse making it very readable and easily understandable:

var gulp    = require('gulp'),
          gutil    = require('gulp-util'),
          uglify  = require('gulp-uglify'),
        concat  = require('gulp-concat');

This simply tells Gulp which plugins are required to complete the defined tasks.

Next up, we need to define the tasks that will be run by Gulp. In my case, I'm looking to do two things:

• Compress images
• Minify my JavaScript files

Defining a task is for all intents a JavaScript call. We use the Gulp method task() to define the task we want to run:

gulp.task('js', function () {
        gulp.src('./js/*.js')
            .pipe(uglify())
            .pipe(concat('all.js'))
            .pipe(gulp.dest('./js'));
    });

Looking at the code above, there's a mix of method calls from the plugins I specified as required. The first method, task(), takes a semantic name for the task (in this case ‘js') and an anonymous function which contains the real meat. Let's breakdown the code:

gulp.src('./js/*.js')

The src() method let's me specify where to find the JavaScript files I'd like to compress and turns them into a stream representing a file structure that can be passed to the plugins for processing. This is part of Node.js' Streams API and one of the reasons for Gulp's ability to have such a terse, concise API syntax.

.pipe(uglify())

The pipe() method takes the source stream derived from the src() method and passes it to the specific plugin being referenced. In this example, the uglify plugin would receive the source stream.

.pipe(concat('all.js'))

Like uglify, the concat plugin receives the source stream via the pipe() method and concatenates all JavaScript files into one file called "all.js"

.pipe(gulp.dest('./js'));

Finally, using Gulp's dest() method, all.js is written to my target folder. The process if very straightforward and very readable.

The last thing we need to do is update the default Gulp task to run our "js" task.

gulp.task('default', function(){
        gulp.run('js'); 
    });

By going back to the command line and typing in 'gulp', Gulp finds the gulpfile.js file, loads any required plugins and dependencies, kicks off the default task and runs my 'js' task. You can see the end result here of the minification and concatenation of my jQuery JavaScript file:

Taking this a step further, Gulp also provides another method called watch() which provides a means for automatically checking a specific resource for changes. This allows for great automation of tasks versus constantly having to manually type in 'gulp' at the command line.

gulp.watch('./js/*', function () {
         gulp.run('js');
    });

When this runs, Gulp will continue to monitor the specified directly for changes to files and if a change occurs, will re-run the 'js' task to minify and concatenate the JavaScript files. Very cool!

Shifting to Gulp.js

When I initially heard about Gulp, my first reaction was "Oh brother another tool!". Boy was I off. Gulp.js truly does have a compelling syntax and API that makes setting up your tasks a breeze. While it doesn't have the breadth of plugins that Grunt has, its plugin repository seems to be growing at a nice clip, especially now with so much developer interest.

I've already spoken with many developers that are actively migrating to it so it seems this is a great time to get into Gulp.js.