The URL is an important piece of user experience in any Web site or application. We like using, what we call “talking URLs” so they’re easy to say and remember, like clearleft.com/is/richardrutter (one of the best all time).

But as we build complex ajax and javascript-base apps with wild interfaces, we sometimes forget about the URL and just how important it is.

The HTML 5 History API aims to deal with that problem by letting you access the address bar directly and create pushes to change the URL and inject (same domain) history into the browser.

Feature detection

Step 1 to using any of the new HTML 5 goodies is testing for support. The History API works where you would expect it to (Gecko & Webkit, not sure about IE9). Testing for support is pretty basic:

Regular JS

if (typeof history.pushState !== "undefined") {
    //history api is supported
}

With modernizr

if (Modernizr.history) {
     // history api is supported
}

The History Push

if (typeof history.pushState !== "undefined") {
     history.pushState([state to track], '[page title]', '[pushed URL]');
}

The pieces

State: This data will be passed into the “popstate”, which deal with things like when the user click the back button.

Page title: This is the title that you see when you click and hold the back button (the menu that pops up) – not totally supported yet

Pushed URL: this is the url you want to display in the address bar. It’s only limitation is that is has to be in the same domain (security).

Worked out history push

if (typeof history.pushState !== "undefined") {
     history.pushState(null, 'I love dogs', 'dogsrock.html');
}

In this demo, you can see the URL changing but the page not reloading.

This is basically a slimmed down version of the Dive in HTML5 documentation with some modifications to the history code, I slimmed down the detection a bit.

As usual, any comments, questions, criticisms are welcome. I left the back button broken so you can see it actually working.

One of the commentors mentioned using yepnope for this instead of loading the jQuery validation plugin by default. Since modernizr has yepnope now anyway, I thought it was a good idea. And here we are with some ne code to look at.

View the demo

Dependencies

• jQuery
• Modernizr (with yepnope)
• jQuery Validate plugin

The HTML

<form action="" method="post">

    <ul>
        <li>
            <label for="name">Name</label>
            <input type="text" name="name" id="name" required>
        </li>
        
        <li>
            <label for="email">Email</label>
            <input type="email" name="email" id="email" required>
        </li>
    
        <li>
            <button type="submit">Submit</button>
        </li>
    </ul>
    
</form>

The JS

(function ($) {

	// set and cache some variables, change var forms to whatever forms you want to validate
	var forms = $('form'),
		formsCount = forms.length,
		items = forms.find('input[required]'),
		count = items.length;

	// check for "required" input support with modernizr
	if (Modernizr.input.required) {

		// do something else, maybe customize the output messages?

	} else {

		// loop though each required input and set the required and type class jQuery validate needs
		for (var i = 0; i < count; i += 1) {
			var obj = items[i];
			$(obj).attr('class', 'required ' + obj.getAttribute('type')).removeAttr('required');
		};

		// after the classes are set, load in the plugin with yepnope , you can do this with Modernizr.load as well
		yepnope([{
			load: 'js/validate.js',
			complete: function () {

				// after the plugin is loaded, call the method on each form listed at the top
				for (var i = 0; i < formsCount; i += 1) {
					$(forms[i]).validate();
				}
			}
		}]);

	} // if required supported

}(jQuery));

I’m not really a fan of script loaders, especially when using them to load a core script file, like jQuery, but I think this is actually a pretty good use of yepnope.

I don’t know about you folk(s), but I’ll be using this moving forward. Any comments/corrections are obviously welcome.

One of my favorite features of the HTML 5 forms is the “required” attribute. But unfortunately, support isn’t totally there yet. So we need to create fallbacks.

It works in the modern browsers you’d expect it to (FF4, Safari, Opera, etc) but in older browsers, form validation isn’t something you can really ignore (like border-radius) or you’ll get flooded with all sorts of nastiness and spam. Sure we should be doing it at the server level anyway, but you still want that client side layer to add a bit of UX charm to your form.

We can still use the new required attribute effectively by creating a JavaScript fallback for unsupported browsers.

In this demo, I’m using:

• jQuery
• jQuery Validation
• Modernizr

The HTML

The HTML is very basic, just an HTML5 form, with 2 inputs: text (name), and email (email). I’m using 2 form types to show how we add classes to support the jQuery Validation. You can, of course, use whatever validation method you’d like.

<form action="" method="post">
<label for="name">Name</label>
<input type="text" name="name" id="name" required>

<label for="email">Email</label>
<input type="email" name="email" id="email" required>

<button type="submit">Submit</button>
</form>

The JavaScript

With the JavaScript, we first make the check for “required” support. I’m using Modernizr for this.

I left an open block in the if statement in case you want to do something else in there, but you could remove the else and replace the first line with it’s inverse if (!Modernizr.input.required) { if you don’t plan on using it for anything.

If “required” isn’t supported I’m running through all the form inputs on the page with a “required” attribute, adding a class of “required”, and the type of input (email, text, etc.). Setting the input type helps you use the validation plugin a little better and can also aid in styling for IE6.

NOTE: I’m using JavaScript’s native getAttribute() method to grab the input type because jQuery’s attr('type') returns “text” on the “email” input for some reason.

After all the appropriate classes are added, we can call the plugin. I’m doing it on each form, but targeting one specific form by it’s ID value is more traditional.

(function ($) {

	// check for "required" input support with modernizr
	if (Modernizr.input.required) {

		// do something else

	} else {

		// parse through each required input
		$('form').find('input[required]').each(function () {

			// add a class to each required field with "required" & the input type
			// using the normal "getAttribute" method because jQuery's attr always returns "text"
			$(this).attr('class', 'required ' + this.getAttribute('type')).removeAttr('required');

		});

		// call jQuery validate plugin on each form
		$('form').each(function () {
			$(this).validate();
		});

	} // if required supported

}(jQuery));

Older (unsupported) browsers will use the Validation plugin, and modern browsers will use the built-in HTML 5 validation.

That being said, I’m all for making the experience tolerable with a few tweaks. Today I set up some aliases in Terminal so I don’t have to remember some of the weirder commands I use often.

I thought I’d share the process for my fella command line haters / mac users.

The process

In your home directory, there’s a file name .profile. It’s hidden from the finder by default so you can get to it a few different ways:

• use a program that displays hidden files (like Houdini)
• Navigate to it through a text editor (I use coda)
• Open terminal and type cd ~, then press enter

Once you find it, open the file, it’s probably blank. If you’re in terminal you’d type vi .profile, then i to being editing.

Alias syntax goes like this: “alias [alias name]='[really long normal command]'”

And you’d put one per line. For example, my .profile file currently looks like this:

alias ..= 'cd ..'
alias ll='ls -al'
alias ls='ls -l'
alias home='cd ~

So if I want to navigate to my home directory I type “home” rather than “cd ~”. A small addition (and actually the same character count), but as you use these more and more to customize your environment you’ll see how much time and frustration you can save.

Anyway, save that file, restart terminal, and you’re good to go.
If you’re doing all this in terminal first hit [esc] to exit edit mode, then type :wq to save your changes.

Hope that helps some folks, I know it helps me, and I like posting stuff like this if for nothing else but having a place I can remember to go to find it.

But I digress.

CSS Performance

We’ve all seen the mass of articles & tutorials about JavaScript performance, how to optimize jQuery, and the JS Performance test suite. The market is flooded, ok, we get it. JavaScript is a beast of the Web that needs to be constantly tamed. It’s getting better, especially with lightning-fast JS engine , V8 looming around in Chome and NodeJS.

CSS performance is constantly overshadowed by JS performance (and rightly so), but that doesn’t mean we shouldn’t at least take a look at it every now-and-then as a form of checks and balances for our front-end code. After all, something like 90% of the load time for a site happens on the front-end and unless you’re Google, it’s probably not all JavaScript (little bit of a big there, sorry fellas).

OOCSS

Object Oriented CSS goes a little like this:

The CSS

.rounded{ border-radius:7px; }
.box-shadow{ -moz-box-shadow:0 2px 2px #333;box-shadow:0 2px 0 #333; }
.left{ float:left; }

The HTML

<div class="rounded box-shadow left"></div> <!--/.rounded .box-shadow .left-->

You’re basically just separating out the individual properties you’ll be using and modifying the HTML to reflect them. It’s very similar to a framework model in building and styling a site.

Whether you like it or not, there it is. There’s a lot of debate over this method, pluses and minuses, loves and hates. The most popular argument against it is that you’re embedding style information into your HTML and semi-collapses the progressive enhancement model of structure — presentation — behavior.

It’s tough for me to totally buy into OOCSS for that reason. I stick very closely to progressive enhancement while I’m building a site and really only stray from that when I’m styling for a CMS and I need classes like: “left”, “right”, “clear”, etc., which get applied by the user later on.

So, when styling for use in a CMS, I really do think OOCSS is dead-on. I’ve yet to fully use it just because I question it’s maintainability. But from a strictly performance stand point: Is OOCSS better? Yea, it’s better. It does perform better across the board than almost all of the CSS selectors (especially the advanced ones).

Lastly, on performance

We can all go through ySlow and JSLint to see where we may have some front-end memory leaks but getting down to the granularity of the way we’re constructing a page (OOCSS vs. non-OOCSS) is tough without running the explicit performance tests.

As the Web gets more and more advanced and browsers like Chrome pave the way for faster sites, I have no idea what the real answer for CSS performance is, but I do know that browsers will not help you write better code. We still need to explore the best practices, be it front-end, back-end or somewhere in the middle.

I’d like to get into this in more detail, but I have a group of tourists screaming at eachother in French next to me (trying out a new coffee shop), so I defer to the comments if you’re at all interesting in the OOCSS debate.

Anyway, I’ve been playing around with QR codes lately. Seeing what sort of information can be stored in them, if they’re a viable technology for the masses, and if they’re worth investing in. I thought I’d share my findings.

What is a QR code?

A QR code is much like a bar code, but they look a lot cooler and in theory can contain a lot more, and a wider variety of information. Everything from plain text to contact information and URLs. They’re actually very robust and there’s a ton of cool stuff we can do if they ever actually catch on and reach the public.

Most modern phones will have an available app for decoding QR codes. I’m not sure about Blackberry, but I know Android, iPhone and Palm all have free apps.

What can we use them for?

QR codes can be used for all sorts of things. Anytime you want to transfer data, a QR code can be used. I’m sure there are some limitations on the amount of data, but I haven’t encountered it yet. Many times a URL is embedded into the code and then the user is sent out to the Web for more information. This is basically a shortcut to help you get to the data without having to type in a URL (it’s actually a pretty big time saver).

One of the best use-cases for QR codes I’ve seen has been attaching them to a venue. For example: If, on the side of a building, you found a QR code you could decode it to find a calendar of events going on in that building, then choose which ones to add to your calendar, set reminders, etc. All by simply taking a picture of a QR code. Again, a bit time saver.

Since the QR code can basically be an extension of the Web, the possibilities are endless. The problem is… how will we let people know they exist? It’s not a problem in the Web community, but based on the speed most technologies like this are adopted, it could be a while.

Are they viable for the masses?

This is always a debate with a “geek technology”. We can use them, they’re very helpful at conferences for passing contact information from person to person or the location of presentation slides. But will everyone else use them? Probably not.

Don’t get me wrong, they’re a great technology with endless uses, but I’m not sure they’re going to catch on in the way we’d like. They’re pretty strange, and no one really knows what they are. They have a along road ahead, much like the way RSS quietly became popular. I think they’ll have the same fate in never really being a main stream technology, but stil very popular behind the scenes.

For some reason, these free technologies really struggle but the second Apple charges 99 cents, they take off like a rocket. Here’s hoping QR codes make the next Steve Jobs talk?

Are they worth investing in?

They are absolutely, 100% worth investing in. The upside of QR codes far outweighs the downside. The QR Code Generator I built took all of 2 hours to fully develop and launch. Most of that time was reading through the Google Charts documentation and testing out all the options.

I don’t see any reason we shouldn’t explore QR codes more, they have a very promising future and I look forward to see what we can make happen, especially when combined with RDFa, Microformats , and some of the new HTML 5 data embedding.

The upside

Everyone loves it, you’re a genius and you get piles of money handed to you on a daily basis for doing something innovative.

The downside

Most people many not get it, so they get the information the “old fashion way”. The worst-case scenario is that it totally fails and you wasted 2 hours. It’s very much like progressive enhancement for real-life.

• View Demo
• Plugin
• Minified Plugin

Version: 3.2 – Added a “className” option so you don’t have to use “.slider” as the wrapper

Version 3.1: Changed “children” to “find” so it will work with a UL. Thanks to Oro for the feedback

Version 3 of Sliding Labels brought some big changes, the largest being that I finally converted it into a working jQuery plugin.

Maybe it was the 200 e-mails requesting an official plugin, maybe it was my curiosity. Whatever it was, I heard everyone and I wanted to let you know that I’m listening to all the feature requests and bug reports; and I really do appreciate them.

Additions to version 3

Plugin status: Obviously creating an official plugin was the biggest change

Position: relative: It seemed like a lot of the questions I was getting had to do with adding position:relative to the .slider element in the CSS, so I just moved that into the script.

Animation speed: I added an option to easily control the animation speed. It can take strings like “fast” and “slow” or any numeric value.

Axis option: I got a lot of requests to add in some functionality to have the label slide up rather than only to the left. I added this in with an “axis” variable which can take either “x” or “y” for sliding direction

Subtractions to version 3

Label Color: Originally I had this in the script so it looked nicer inline to the field, but I got to thinking that this really should be defined in the CSS, and it’s just color; so I took it out.

Using the plugin

Just like the previous version, you need an element wrapping the <label> and <input> elements. I use a <div> in the demo, but you can use whatever you’d like. The only requirement is that it have the class name “slider”. I can change that if anyone finds it to be annoying, but let me know and I’ll update the script

HTML

<div class="form-slider">
<label for="user">User name</label>
<input type="text" id="user" name="user">
</div>

JavaScript

$(function(){ $('#contactform').slidinglabels({
/* these are all optional */
className : 'form-slider', // the class you're wrapping the label & input with -> default = slider
topPosition : '5px', // how far down you want each label to start
leftPosition : '5px', // how far left you want each label to start
axis : 'x', // can take 'x' or 'y' for slide direction
speed : 'fast' // can take 'fast', 'slow', or a numeric value
});
});

That’s all there is to it. Let me know what you think, any extra features you’d like and any bugs. I should be submitting this to jQuery.com in the next few days.

Lately, I’ve been having to work with a lot of redirects and I was going through different redirection options with a client. So I thought I would do a quick write up about the different types of redirection.

I also haven’t seen a collection of these in one place, so I thought I would put this together.

There are a few different types that are commonly use when redirecting users:

• .htaccess / apache
• php header
• javascript
• meta refresh

The top two are the one’s you’ll be using most often, I don’t really recommend the last two. But they are available, so I think they’re worth noting. So here they are in the order I would recommend:

.htaccess / apache redirects

Redirect /old_directory http://example.com/newdirectory

This redirection is most efficient at the apache level, but if you’re like me and are on shared hosting, getting into the apache installation probably isn’t an option. In that case you can put this in an .htaccess file in the root directory of your site.

Using an .htaccess redirection is great for moving entire sites because you can not only redirect a page, but you can redirect entire sites and subdirectories with one line of code.

PHP header redirects

<?php header('Location: http://example.com/newdirectory/'); ?>

PHP header redirects are good for single page redirects and if you’re not comfortable working with the .htaccess file. This code goes at the very top of the page you’re trying to redirect. If it’s not there you may get a “headers already sent” error.

If you’re publishing out static HTML files, you can still use this by adding this code into your .htaccess file:

AddType application/x-httpd-php .php .html .htm

This will let you execute PHP in an HTML file.

JavaScript redirects

<script type="text/javascript">
<!--
window.location = "http://example.com/newdirectory"
//-->
</script>

JavaScript redirects are generally not used unless you’ve exhausted the other two options. If you don’t have access to the .htaccess file AND you can’t run server-side script on your page, this is an OK fallback option, but you have to make sure to provide a link to the forwarding page incase a user is browsing without JavaScript.

Meta redirects

<meta http-equiv="refresh" content="0;URL=http://example.com/newdirectory">

As your last option, I don’t see this in the wild anymore, but it’s worth mentioning that it does exist and does technically work (I’m not sure about it’s validity in HTML 5). You would place this in the document HEAD with the rest of the meta elements.

content=0 is a second timer for the redirect, I have this one set to 0 so it will redirect immediately.

Those are the options I’ve used in the past; did I miss anything? Maybe an ASP redirect? Let me know!

Hi all,
I had a new article published over the weekend at Smashing Magazine. Check it out and let me know what you think!

Behavioral CSS

I wrote it quite a while ago and it seems to be showing a bit in the comments, but overall, I’m pretty happy with the way it came out and the reader responses it’s getting. Hope you enjoy Behavioral CSS

I know I haven’t posted in a while, but I wanted to stop by and let everyone know that I have a new article out on Noupe.com called “CSS Techniques I Wish I Knew When I Started Designing Websites”

It was pretty fun to write trying to think back to my beginnings in the Web and sort of relive that frustration. I tried to include something for beginners and some for the more advanced users, so hopefully everyone will be able to take something away from the article.

Let me know what you think!