I found myself having to create a completely REST-enabled API for an in-house solution, so what better way to do this in .NET than leveraging ASP.NET Web API?

While Web API makes mostly everything about the process simple and easy, considering that this is going to be a full-fledged REST API, I had to consider allowing cross-domain requests to the API, which normally meant that I had to enable cross-origin resource sharing (CORS) on it.

I found a nice handful of good resources for ASP.NET Web API CORS support, but I found Carlos Figueira’s take on it the most helpful, so I went ahead and adapted his code into my own small AOP library for use with future projects.

Using the library should be as easy as just adding [CorsEnabled] on your API actions and/or controllers. It provides a bit of additional functionality if you need it (like specifying allowed domains if you want).

Feel free to get the code here. I wholeheartedly welcome comments on it, and if you find that you want to fork it, be my guest.

A sample project for this discussion is available over on my Github.

There are countless use cases where I found myself needing to use Razor syntax (in ASP.NET MVC 3+) inside Javascript, CSS and other asset files. While there are many different ways to get Razor output into external JS files (for example, getting a Url.Action() call into a JS file’s jQuery.ajax() call), I find that most feel like beating around the bush. After all, views in MVC don’t always have to be HTML files, at least in the traditional spirit of MVC.

So why not create a Javascript view?

If you think about it, there’s nothing really stopping you from creating a controller, adding in a view, then writing up the view in Javascript syntax (save for the less-than-tasty syntax highlighting and Intellisense in Visual Studio, since it kind of expects that views are HTML files).

The key thing is to modify the Content-Type of the response to the appropriate value, based on what you’re returning. So Javascript files will be text/javascript, CSS files will be text/css. It’s the same basic idea with, for example, returning image data through the wire.

For example, this controller action:

public class AssetController : Controller {
 
    public ActionResult Styles () {
 
        Response.ContentType = "text/css";
 
        var model = Context.GetEntity();
        return View(model);
    }
}

… can have the following view:

@model Entity;
 
#entity {
    color : @Model.Color;
    background : url(@Model.BackgroundImage.Url);
}

… and can be wired into your markup just like any other stylesheet:

<link rel="stylesheet" href="@Url.Action("Styles","Asset")" />

Taking all that a bit further, we can write up an Attribute to easily maintain the corresponding Content-Type to each action:

public class ContentType : FilterAttribute, IActionFilter 
{
    private string contentType;
    public ContentType (string ct) {
        this.contentType = ct;
    }
 
    public void OnActionExecuted(ActionExecutedContext context) { /* nada */ }
    public void OnActionExecuting(ActionExecutingContext context) {
        context.HttpContext.Response.ContentType = this.contextType;
    }
}

… and just mark our actions with it:

[ContentType("text/css")]
public ActionResult Styles() {
    // ...
    return View();
}

All that notwithstanding though, you’ll still have to deal with two problems when you do this:

1. Visual Studio assumes that all views are HTML. You don’t get accurate color highlighting and Intellisense in your asset views. I don’t know about you, but the countless ways that VS pushes back when I do this kind of irks me off.
2. You don’t get bundling (in ASP.NET MVC 4), and unless you wire it up somehow with WebGrease, you don’t get minification either. Caching is possible, but the whole point of dynamic assets are just that: they’re dynamic. You still can cache via normal ASP.NET MVC methods if, for example, you can manage to scope your use cases into unique URLs (via query strings probably), or you could opt to write your own caching mechanism for this.

If you want to try this out, I’ve prepared a very simple VS 2012 MVC 4 project ready to go over on my Github. Feel free to clone, fork, and/or contribute!

With all that said and done though, I believe that this is the way to correctly use views in an MVC framework, and that Visual Studio should perhaps allows for better leniency for use cases such as this. I’d love to hear your ideas on the topic though.

If you want to use the LESS dynamic CSS language in your .NET web applications, using the dotless (formally .less) library is the popular way to go, so that your .less files are compiled server-side.

While dotless provides a no-brainer way to serve compiled .less files through its custom HttpHandler, this still forces the app to compile the .less files on every request (barring caching, etc). An arguably better way would be to pre-compile our .less files beforehand, so that we can work with LESS in development, while mindlessly serving minified CSS files in production.

This post will show how we can integrate the dotless package into your .NET web application, do all that crap I just described above, and making sure we do them in an automatic manner. A true set-and-forget system.

Major props go to my colleague @camemay, whose work I’ve built upon.

Let’s get started!

Installing the dotless package

For this post, I’ll be using an ASP.NET MVC 3 web application as a scapegoat. Having a ready MVC 3 project in hand (a new one off Visual Studio would be fine), installing dotless is a breeze over NuGet.

install-package dotless

This does a few things off the bat, but aside from the usual auto-adding of installed assemblies, the changes of more concern are those that silently happened in your web.config:

• The custom LessCssHttpHandler was registered in your httpHandlers declaration to handle *.less files.
• The same handler was also registered against the system.webServer declaration.
• A custom dotless configuration was defined, and a preliminary dotless config section was appended at the end of the file.

Let’s start by modifying the path="*.less" declarations (in two places) to path=".less.css". This allows us to open LESS files in Visual Studio automatically as CSS files, and therefore with CSS Intellisense. Take note that this modifies the handling declarations such that .less files won’t be handled by the dotless handler (they won’t be compiled!) — you have to write your LESS code in .less.css files.

If you’re particularly paranoid about it, you may opt to change verb="GET" to verb="GET,HEAD" as well.

<system.web>
    <!-- ... -->
    <httpHandlers>
        <add path="*.less.css" verb="GET" type="dotless.Core.LessCssHttpHandler, dotless.Core" />
    </httpHandlers>
</system.web>

<system.webServer>
    <!-- ... -->
    <handlers>
        <add name="dotless" path="*.less.css" verb="GET" type="dotless.Core.LessCssHttpHandler,dotless.Core" resourceType="File" preCondition="" />
    </handlers>
</system.webServer>

Setting up the automated LESS compilation script

Now that we’ve basically decided that LESS CSS code will be in *.less.css files, we can target that for automatic compilation.

The way we’re going to approach this is by writing a custom MSBuild script that executes the dotless compiler against *.less.css files, converting the LESS syntax to minified legal CSS, and renaming the files to *.min.css. These will be our files for production.

For most of this process, I’ve been referencing Ted Nyberg’s own post on the topic, with a few changes here and there.

Include the dotless compiler in your project

First thing we have to do is to include the dotless.compiler.exe in the project so we can refer to it later in the build script. If you followed this guide and installed dotless via NuGet, then this file will be in $(ProjectDir)/packages/dotless.x.x.x/tool. Just add this executable into your project. For purposes of this guide, I’ll be mirroring Ted’s folder naming convention as well, so I’ll be adding this into an [MSBuild] folder.

Write the build script to compile LESS

Next we’ll start writing our build script. I added an XML file into my [MSBuild] folder, and named it dotless.CompileLessToCss.targets. You can name it whatever you want, but by nature of what we’re going to be working with, a good practice is to name it as a *.targets file.

Let’s start with Ted’s script, and let’s work from there:

<?xml version="1.0" encoding="utf-8" ?>
<Project xmlns="http://schemas.microsoft.com/developer/MsBuild/2003">
  <Target Name="CompileDotlessCss">
    <ItemGroup>
      <Binaries Include="*.dll;*.exe"/>
    </ItemGroup>
 
    <!-- Compile dotLess CSS into minified full CSS -->
    <Exec Command="$(ProjectDir)..\[MSBuild]\dotless.Compiler.exe $(ProjectDir)..\css\main.css $(ProjectDir)..\css\main.min.css -m"/>
 
  </Target>
</Project>

This script will compile only one file in our project: main.css into main.min.css. Let’s modify this so that it’ll convert all *.less.css in our $(ProjectDir)..\css\ folder into their *.min.css counterparts.

We’ll have to make the build script identify all those *.less.css files. We can set up an ItemGroup declaration to do just that. Put this right before the <Target> declaration:

<ItemGroup>
    <LessFiles Include="css\*.less.css" />
</ItemGroup>

That aside, we can modify the Exec command to this:

<Exec Command="[MSBuild]\dotless.compiler.exe -m %(LessFiles.FullPath)" />

This will take care of running the dotless compiler against all our *.less.css files. Only thing left to do is to specify what filename to use for the compiled + minified CSS code (and not rely on the compiler’s defaults).

Unfortunately, there’s no easy way to call a string.replace on LessFiles.FullPath. I’m personally using the method described in this StackOverflow answer, but there are others suggested on the same page. Use the method most comfortable for you. This modifies my command to this:

<Exec Command="[MSBuild]\dotless.compiler.exe -m %(LessFiles.FullPath) $([System.String]::Copy('%(LessFiles.FullPath)').Replace('.less.','.min.'))" />

Lastly, add the AfterTargets="AfterBuild" property to the Target tag. This will tell MSBuild to run this script after the AfterBuild “event” in the project build process.

Our final build script will be as follows:

<?xml version="1.0" encoding="utf-8" ?>
<Project xmlns="http://schemas.microsoft.com/developer/MsBuild/2003">
    <!--    
    This MSBuild Script will compile all [*.less.css] files in the /CSS folder to their [*.min.css] counterparts.
    -->
    <ItemGroup>
        <LessFiles Include="css\*.less.css" />
    </ItemGroup>
    <Target Name="CompileDotlessCss" AfterTargets="AfterBuild">
        <ItemGroup>
            <Binaries Include="*.dll;*.exe"/>
        </ItemGroup>                
 
        <!-- Compile dotLess CSS into minified full CSS -->
        <Exec Command="[MSBuild]\dotless.compiler.exe -m %(LessFiles.FullPath) $([System.String]::Copy('%(LessFiles.FullPath)').Replace('.less.','.min.'))" />
 
    </Target>
</Project>

Invoking our script when the project builds

The last thing we have to do is to make sure our script gets run when the project actually builds. I’m not at all adept with MSBuild (crash courses! ugh!) so you might prefer doing this another way, but this is the method I found closest to heart. Feel free to adjust.

The .csproj file that defines your web application also has MSBuild instructions on how to build it on compile. We’ll just manually plug in directions to include our script.

To be able to edit the .csproj, we’ll first need to unload the project. Right-click on the project in your Solution Explorer, and choose to Unload Project.

With your project unloaded, right-click on the project again, and choose to edit it. You’ll be presented with delicious XML.

Somewhere in all that XML, just plug in an Import command:

<Import Project="[MSBuild]\dotless.CompileLessToCss.targets" />

I’m particularly paranoid, so I put this somewhere towards the end of the file.

And that’s it!

If we did everything correctly, our project should automatically compile our *.less.css into *.min.css whenever we build the project.

Try it out! Add a style.less.css into your project, and slap this inside:

@foo : #beefff;
 
body {
    background : @foo;
    div#main {
        padding : 2px;
    }
}

Compile your project, then navigate to style.less.css in your browser, and you should get the following:

body {
  background: #beefff;
}
body div#main {
  padding: 2px;
}

Navigating to style.min.css should net you:

body{background:#beefff}body div#main{padding:2px}

Use the *.less.css files for development and debugging, and the *.min.css files for production.

It’s really careless programmer-slash-security things like this that piss me off. Have a look at the Bank of the Philippine Islands’ (BPI) personal internet banking login screen:

Although it’s not as restrictive as the one on BPI’s website, here’s the equivalent login service provided on Banco de Oro’s (BDO) website:

I can think of absolutely no use case where, as a software architect, programmer, what-have-you, I would want to limit the number or kind of characters a user can assign for a password. It’s an absolute no-no. It’s a Bad Thing™. It’s what your mother had been warning you not to do when you were a kid, right after those sermons against playing with fire and sharp objects.

But, limiting characters saves database space!

Point well taken, and honestly, that would make a lot of sense provided that we weren’t talking about passwords.

If this was any other kind of field (like a username, or an address input), limiting the characters a user can input may not just be helpful: it may well be essential. By controlling that amount of data anyone can save into any data field, we can control how fast the size of the underlying database bloats (because databases take up expensive hard drive space too, you know).

Passwords are an exception though. To start off, websites (or anyone for that matter) should not be storing your password in plain text.

It’s simple. No one but you should know your password. Not even the websites you use your passwords on. Ever wonder why (most) websites allow you to reset your password, but they don’t (can’t) give you your password when you forget it? Well, this is why.

But then, you’d ask: if websites don’t know my password, how do they know that I’m using the right password for my account then? Again, simple. They use what’s called a hash.

The thing is, websites can “hash” any piece of text, and it will generate an (ideally) constant string of text that looks randomized, and is hard to remember. Here are a few examples using SHA256 hashes:

// "password"
5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8
 
// "passworD"
9e78de733c6a51c0cc954c1d956d8929ad1310513e1042d81edc375219c6a2ef
 
// "1234"
03ac674216f3e15c761ee1a5e255f067953623c8b388b4459e13f978d7c846f4
 
// "a"
ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb

This is what websites (should) use in checking if your password is correct. It stores the hash of your password in its database, so whenever you try to login (and provide a password), it hashes that, and compares the resulting hash to the hash it has in its database.

Why does that matter then? Well, one of the unique things about a hash is that no matter how long the original piece of text is, it always always always results in a hash of constant length (for example, the SHA256 hashes above are always 64 characters long).

So if you’re storing that in a database, you know that you’re always storing text that is 64 characters long no matter what the password is. What’s the sense of limiting my password to 12 characters then?

More importantly, what does that tell me?

Either BPI and BDO are unnecessarily making their users use passwords that are significantly less secure than possible, or they’re storing your passwords in plain text. I just hope it’s not the latter.

But 12 characters in a password is more than enough.

Again, point well taken. If you use numbers, lowercase and uppercase letters, and symbols in your password, a 12-character password will take a hacker years to break (only hours or even minutes if you only use letters!).

But then again, passwords like that look like *HU9J67+0G3% and are generally hard to remember. This is exactly the reason why there has been debate about the usability of the passwords we use everyday.

Passwords, to make a long discussion short, are hard to remember. Passphrases (like pleasedontmilkmycow, on the other hand, are more efficient on both security and human usability aspects. But to make use of them, I need more than just 12 characters. It’s a somewhat touchy topic, but hey, you’ve got to at least agree on the usability part.

Please don’t store my password.

Let me just take this opportunity to say it again: there’s absolutely no justification as to why you’d want to limit your users’ password length. As far as I’m concerned, if you limit the length of my password, I know you’re storing my password. And that, my friend, is a big no-no.

I’ve had a somewhat extensive experience with jQuery so far. I’ve had the pleasure of reviewing peer jQuery code, mentoring potential web devs, teaching in classroom settings, and bashing heads over on StackOverflow, but one thing I’ve noticed all this time is just how hard it is to make developers do one simple thing in jQuery.

And when I say hard, I mean hard. Convincing jQuery developers to use delegate more in their code has got to be one of the more resilient challenges for someone teaching the jQuery craft.

The problem with the learning part of this (what I think at least) is that for devs coming into jQuery, you see bind() and then you see live(), and immediately think that those’re all you’ll need for working with events. Think about it: how long did it take you to know about delegate() from the time you learned about live()?

There’s a lot of argument for delegate out in the interwebs, and I’ve chucked my share in as well somewhat, but let me offer one more compelling reason to use delegate.

Buff your events with a bit more shine

It’s easy to get lost when working with events in jQuery, even for just the somewhat harmless reason that everything is just so easy to do. For example, consider this:

<ul>
    <li>This</li>
    <li>is</li>
    <li>a</li>
    <li>simple</li>
    <li>list</li>
</ul>

jQuery(function($) {
    // we're assigning an event handler to each li element
    $('li').on('click', function () {
        $(this).toggleClass('selected');
    });
});

One would write this code and probably won’t give it a second look. After all, we’re writing our jQuery in pretty much a good form.

What most don’t realize, however, is that to some degree, this comes with it’s inefficiencies, particularly in the fact that binding an event listener in this way automagically attaches a distinct instance of the handler function to each distinct element in the jQuery wrapped set. That means that, for this particular example, we’re creating five references to a function, because each of the li elements gets its own piece of the pie.

If you’re interested in optimizing your code further, you could do this instead:

jQuery(function($) {
     // we're delegating the event handler here
     $('ul').on('click', 'li', function () {
         $(this).toggleClass('selected');
     });
});

What we’re doing here instead is that we’re assigning one (just one!) reference of the function to the ul element, and we’re telling it to fire it whenever a click occurs in any li inside it (hence, delegating).

Now, at first glance, that may not be much, but you’ll be surprised at how fast the performance hits can add up, to the point that there are arguments that delegate may actually be even more efficient to use in a majority of applications than bind.

It’s a pretty simple thing to do in your jQuery code (now even more so because of the unified on() function), so do keep this in mind whenever you’re writing to optimize your jQuery performance.

On the topic of making Internet Explorer behave, one of the easiest things you can do to make sure the dreaded Internet Explorer 6 is up to reasonable snuff is to include a single Javascript snippet on your page.

Chrome Frame

The Google Chrome Frame is not new. It’s an IE plugin that acts as an additional rendering engine that delivers more or less the same features, offerings, and HTML5 + CSS3 goodness as the standard Google Chrome. Long story short, it’s a Google Chrome running inside your Internet Explorer. The ultimate problem was that it needed to be installed by a user with administrative rights.

And then the “non-admin” Chrome Frame came around. It’s a Chrome Frame that can be installed by any user on a client computer. Now, there’s virtually no reason anymore not to install it if you’re stuck on a legacy Internet Explorer for some reason.

Getting users to install Chrome Frame

Now, in order to be able to deliver all the cutting-edge HTML 5 rainbow goodness for your clients, you just have to make sure that install the Google Chrome Frame. How to do that?

Just include the following inside your markup, preferably right before the closing tag:

<!--[if lt IE 7 ]>
  <script src="//ajax.googleapis.com/ajax/libs/chrome-frame/1.0.3/CFInstall.min.js"></script>
  <script>window.attachEvent("onload",function(){CFInstall.check({mode:"overlay"})})</script>
<![endif]-->

That’s pretty much it. If your webpage is loaded inside an Internet Explorer 6 or lower, a very prominent overlay attempts to convince your user to install Chrome Frame.

Of course, to make the most use of Chrome Frame, you’ll have to include the appropriate X-UA-Compatible value as detailed in this HTML5 Boilerplate article.

If you want to know more about the Google Chrome Frame, hop on over to the FAQ.

This blog is written by a Filipino, maintained by a Filipino, and proudly Filipino. Most of the content were typed by my own hand, code crafted by my own mind, and none of it is infringing copyright in whatsoever way (hooray for open source).

So why the blackout? Why the care for stopping SOPA and PIPA?

Honestly, this video gets all the explaining done quickly and effectively, so I’ll just coax you to watch it in its entirety.

January 18 is Stop SOPA Day. I encourage you to join sites worldwide in protest. If you run a WordPress, Tumblr, blog or whatever, post about it / embed the video.

If you’re on Twitter, do tweet about this. Here, I’ll make it even easier for you:

Tweet

If you’re on Facebook, likewise. Post about it, tell your friends about it, and hopefully we can help generate a bit of additional buzz.

The HTML5 Boilerplate is well-known across web programmers as a powerful starting template for (as the project homepage puts it) building fast, robust, future-proof sites. Out of the box, it provides HTML, CSS and Javascript code arranged in such a way to drive as much oomph into your pages as possible. Every nook, cranny, and design decision borrows from widely-accepted standards, and is supported by countless hours of research and testing.

While the HTML5 Boilerplate is awesome as a starting foundation for building awesome sites, it is also packed with code snippets and patterns you should be using for your projects. Just in case you’re not using the HTML5 Boilerplate for some reason.

Making Internet Explorer behave

As if it wasn’t enough that web developers had to keep track of different Internet Explorer versions, it must also be said that computers that run IE also have multiple rendering engines. That is, if a user had IE 8, for example, you can be sure that it has the IE 8 rendering engine. However, it also has a readily available mock of the IE 7 engine as well, so a version 8 Internet Explorer may render a page as if it was version 7. If that wasn’t enough, it must also be said that these rendering engines aren’t exact copies: a version 8 IE using the version 7 rendering engine will not behave in the exact same way as a true blue version 7 IE. And that sucks.

Circumstantially, sites viewed from an intranet also trigger Compatibility View, something like a glorified quirks mode, by default. That sucks even more.

As it turns out, you can explicitly tell Internet Explorer browsers to use its latest available rendering engine using a meta tag:

<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">

The IE=edge half of the meta value tells Internet Explorer to use its latest rendering engine for your page. That, in itself, is already a boon and a half.

The chrome=1 part tells it to use the Chrome Frame rendering engine if it is installed on the client computer, which basically brings Chrome rendering power to Internet Explorer (yes, even version 6).

Taking it one notch higher

Now, this doesn’t come without any imperfections. First of all, this won’t work completely as expected inside a conditional comment, so you might as well scratch that idea.

Secondly (and arguably more important to some), is that this line breaks validation. Now, to some, that can be quite a deal breaker.

If you’re absolutely picky about your HTML validation (’cause I’m most often not), a way to work around this is to send the meta value above as an HTTP header instead. That should work just as well.

If you are hosting from an Apache web server, you can send the X-UA-Compatible headers by editing your httpd.conf file and adding in the following:

<Location /mypath>
    Header set X-UA-Compatible "IE=edge,chrome=1"
</Location>

If you are serving off an IIS server, the easiest way to send a custom header is to set a custom configuration setting in your web.config file:

<system.webServer>
    <!-- ... -->
 
    <httpProtocol>
       <customHeaders>
           <add name="X-UA-Compatible" value="IE=edge,chrome=1" />
       </customHeaders>
    </httpProtocol>
 
    <!-- ... -->
</system.webServer>

Doing any of the above let’s you completely remove the tag from your markup.

You might want to read the other articles in this series as well:

• Part 1 : Conditional HTML tags

The HTML5 Boilerplate is well-known across web programmers as a powerful starting template for (as the project homepage puts it) building fast, robust, future-proof sites. Out of the box, it provides HTML, CSS and Javascript code arranged in such a way to drive as much oomph into your pages as possible. Every nook, cranny, and design decision borrows from widely-accepted standards, and is supported by countless hours of research and testing.

While the HTML5 Boilerplate is awesome as a starting foundation for building awesome sites, it is also packed with code snippets and patterns you should be using for your projects. Just in case you’re not using the HTML5 Boilerplate for some reason.

Making browsers behave the same way

Browsers are not made equal. And this makes our work that much harder.

Different browsers (and browser versions) all behave differently, and so it is not uncommon to see code like this:

<link href="style.css" rel="stylesheet" />
<!--[if lte IE7]><link href="style.ie7.css" rel="stylesheet" /><![endif]-->

Conditional comments such as these are meant to load different asset files into the HTML document, depending on whether or not a specific version of Internet Explorer (or even just Internet Explorer) is used. (Yes, IE is that notorious.) It’s meant to introduce additional assets that enforce additional rules that make sure that misbehaving browser quirks render as consistently as possible.

Alternatively, one can also make use of CSS hacks.

#content { margin: 10px; _margin:20px; }

CSS hacks don’t validate, and rely on browser bugs. Good luck to you when those bugs get patched.

Conditional comments, on the other hand, also present a few disadvantages:

1. They introduce additional (arguably unnecessary) HTTP requests.
2. They have to be located in the <head>, which means that they can block loading and rendering.
3. Just imagine the added complexity of working with multiple stylesheets.
4. Conditional comments can significantly slow your page down due to a browser bug in Internet Explorer 8.

Conditional HTML tags

To address these, the HTML5 Boilerplate uses the following markup instead:

<!--[if lt IE 7 ]> <html class="ie6 no-js oldie"> <![endif]-->
<!--[if IE 7 ]>    <html class="ie7 no-js oldie"> <![endif]-->
<!--[if IE 8 ]>    <html class="ie8 no-js oldie"> <![endif]-->
<!--[if IE 9 ]>    <html class="ie9 no-js"> <![endif]-->
<!--[if (gt IE 9)|!(IE)]><!--> <html class="no-js"> <!--<![endif]-->

The HTML5 Boilerplate uses conditional comments to dynamically assign classes to the <html> tag. However, since none of these comments are used to load asset files into the page, the previously mentioned browser bug does not occur.

With this markup, your <html> tag dynamically gets assigned a corresponding iex class that you can target in your CSS in a valid manner:

#content { margin:10px; }
.ie7 #content { margin:20px; }

This promotes the use of a single stylesheet for your page, and (hopefully) keeps related style rules together for easier maintainability. This markup still does not validate, but what’s arguably more important is that your page renders correctly in any browser nonetheless.

If you’re wondering what the no-js class is, it is used by Modernizr, a Javascript library that helps you build future-proof pages by allowing you to detect a browser’s capabilities, and react accordingly. When it loads, it changes the no-js class to js, letting you know if Javascript is enabled in a client’s browser.

Modernizr is included with HTML5 Boilerplate out of the box. We’ll discuss using it effectively in a future post.

You might want to read the other articles in this series as well:

• Part 2 : X-UA-Compatible, and making Internet Explorer behave

The latest version of jQuery (that is, 1.7.1, or 1.7.x) has been around for a good while already, and the new .on() and .off() functions still come to me as the shiniest new toys that came along with it. Not only are they shorter, more intuitive and better at what they do, but they also promote (generally) accepted jQuery good practice that has been around for quite a while.

What am I talking about?

If you’re any jQuery programmer worth your salt, then you know of, at the very least, .bind() and .live() when it comes to DOM event handling. The main difference being that the former is preferred for present elements, and the latter is “mandatory” for future element handling.

One or two rungs up the jQuery programmer ladder, and you’d know of .delegate() as well. If you actually use it with convicted priority over .live(), then you’re golden. An explanation of why would require a good grasp of how jQuery handles events behind the scenes, followed by a primer on why using .live() is bad.

It’s admittedly a pet peeve of mine. And I’d like to think that the reason why .live() persists so sturdily when .delegate() is most clearly a better choice (aside from the fact that the latter was introduced one major version step later in the jQuery lifetime), is that .live() is so much easier to type.

Isn’t it? I mean look at it.

// live
$('a').live('click', do_backflips);
 
// delegate
$(document).delegate('a', 'click', do_backflips);

Sheer convenience.

.on() and .off()

Which is a big reason why I -heart heart heart- the new .on() and .off() functions in jQuery 1.7.x. It streamlines all your event handling into just two functions, whether or not you’re taking into account present or future elements.

If you’re not familiar, the usage for .on() is like this:

// for present elements
$('a').on('click', do_backflips);
 
// for future elements
$('#container').on('click', 'a', do_backflips);

I’d suggest you also take a look at the official documentation for the on and off functions as well. Pretty spiffy.

What’s really nice is that both versions of .on() map to .bind() and .delegate() respectively, which has the added benefit of simplifying the question of what function to use on any given case, and cleaning up syntax. And, hey, it’s also easy and intuitive to use.

Additionally, .live() has also been deprecated as of jQuery 1.7.x. I quote:

As of jQuery 1.7, the .live() method is deprecated. Use .on() to attach event handlers. Users of older versions of jQuery should use .delegate() in preference to .live().

Frankly, one could argue that good practice is being forced down the programmers’ throats. But as it plays on clear improvements on jQuery’s event model, I don’t mind that one bit.