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.

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.

I find that it’s best not to argue with JS Lint, just fix the problem.

One that I had encountered quite a bit while running jQuery through JS Lint was “Implied global: $”.

Up until a week or two ago, I was just blowing it off, because, I mean, come on, it’s a $, it kind of is global when using jQuery. For whatever reason I had a quick talk with @akira_x and we figured out what was going on and how to fix it.

The solution is actually similar to how we build jQuery plugins, but without the real plugin model, just normal site code.

Evolution of the the document.ready

When jQuery first came out, this is how we would used document.ready as a wrapper for custom jQuery:

$(document).ready(function() {
// jquery code here
 });

Then we moved on to the short cut method:

$(function(){
// jquery code here
});

Both of these methods are technically fine, but they both leave “$” as an implied global. This may not be an issue for most of us since we only use jQuery, so who really cares is $ is global, right?

We can, however make sure (just in case, because we’re all good coders) that there are no future library or JavaScript collisions by containing the scope of $ with:

(function($) {
	// jquery here
}(jQuery));

This will still cause JS Lint to throw an “implied global” alert, but it will be for “jQuery” rather than “$”. Personally, I feel like it’s better.

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!

For years (and by “years”, I most likely mean “the years since I started using jQuery… maybe 2″), there’s been one aspect of jQuery that’s bugged the crap out of me, the animation speed.

View demo

We’ve all probably seen the problem that happens in many drop down menus of varying height. We set slideDown(300) (or whatever you set it to) on all the submenus and leave like that. Inevitably, menus grow and shrink based on the content and we get this weird and mildly annoying behavior of really fast moving tall menus vs. shorter menus that move painfully slow just because there’s not much content in there.

This problem stems from where we set the speed of the animation; the value isn’t actually a speed, it’s how long it takes (in milliseconds, I think) for the animation to finish. So you can see why you get varying behaviors based on the element height.

It’s true, that you can use the built-in speed values like “fast” and “slow”, but if you want more fine-grained control over your animation, you’ll have to use a value.

Problem Child ∞

This is what our problem menu looks like all collapsed, just 2 clickable headings (h2) that will slide open to expose content (p)

Normally our jQuery would look something like this:

$(function(){

$('h2').toggle(function(){
    /* get the next element */
    var next_element = $(this).next();

    /* open it  if it's closed */
    next_element.slideDown(500);
},function(){
    /* get the next element again */
    var next_element = $(this).next();

    /* close it if it's open */
    next_element.slideUp(500);
});

});

Note: just example code, I didn’t check to see if it actually works

This is our menu fully expanded. As you can see, the first item has a lot more content then the second. Using the code above will make menu #1 move noticeably faster than menu #2; which, to me, creates an odd user experience. Because you’re like “Why’s is moving so slow?”

So let’s see if we can’t fix that.

Ben Healy (Solution) ∞

What we’re looking to do here is get the height of each collapsed item, do some JS math, and set a speed (animation time) value based on the height.

jQuery functions we’ll need

• next()
• height()
• slideDown() / slideUp()

The Code

$(function(){

	/* Variables to set */
	var id = '#heightCheck';
	var click_element = 'h2';
	var height_value = '100';
	var tall_menu_speed = 400;
	var short_menu_speed = 250;

	/* System variables, probably don't change */
	var target = id +' '+ click_element;
	var menu_content = $(target).next();

	/* Hide the element after the click_element, whether it's a
	div, p, ul, whatever you choose to wrap the items in */
	menu_content.hide();

	$(target).toggle(function(){
		/* save the menu items in a variable */
		var this_menu = $(this).next();

		/* get the menu height and save it */
		var menu_height = this_menu.height();

		/* Calculate the animation speed based on the element height */
		/* if the height is greater than the height set above use the
		tall menu height */
		if(menu_height > height_value){
			var speed = tall_menu_speed;

		/* If it's smaller, use the short menu height */
		} else if(menu_height < height_value) {
			var speed = short_menu_speed;
		}

		/* slide the menu down */
		this_menu.slideDown(speed);

	},function(){
		/* this is the same but reversed to close the menu */
		var this_menu = $(this).next();
		var menu_height = $(this).next().height();

		/* Calculate the animation speed based on the element height */
		if(menu_height > height_value){
			var speed = tall_menu_speed;
		} else if(menu_height < height_value) {
			var speed = short_menu_speed;
		}
		this_menu.slideUp(speed);

	});

});

That should give you a little more control over the menu speed. I'm sure it needs to be tweaked based on the menu you're using, but the general concept is there, and it should work pretty well. I hope it was helpful. Let me know if you have any additions to the code or suggestions to improve it.

View demo

]]> http://www.csskarma.com/blog/conditional-animation-speed/feed/ 2 http://www.csskarma.com/blog/qt2-bringing-search-back/ http://www.csskarma.com/blog/qt2-bringing-search-back/#comments Mon, 29 Jun 2009 14:29:05 +0000 Tim http://www.csskarma.com/blog/?p=546

This is something I use on all my projects now. It’s designed for a search box, but can be used with any sort of input field.

The great thing about this is that the field value “Search” will only come back onBlur if the field is empty (or doesn’t say “Search”). So if you started typing something it won’t erase your text, which is something that has always irritated me about search boxes.

Anyway, I’ve been sitting on this post for a while, but I really wanted to get it out. So here it is:

XHTML

<div id="search">
<form method="post" action="">
   <label for="field">search</label>
   <input type="text" id="field"/>
   <button type="submit">go</button>
</form>
</div><!--/search-->

jQuery

$("#search input").focus( function() {
if ($(this).val()=="Search") {$(this).val("");}
});

$("#search input").blur( function() {
if ($(this).val()=="") {$(this).val("Search");}
});

The word “Search” in the jQuery is case sensitive, so watch out for that.

]]> http://www.csskarma.com/blog/qt2-bringing-search-back/feed/ 6 http://www.csskarma.com/blog/this-week-in-links-12/ http://www.csskarma.com/blog/this-week-in-links-12/#comments Tue, 16 Dec 2008 15:52:53 +0000 Tim http://www.csskarma.com/blog/?p=284

10 Tips to Improve Your UI

Smashing Magazine, once again, has a great article about user interface. This article gives you some quick and helpful tips on improving your user interface design. A lot of stuff we should all be doing.

Anti-RSI

This is a Mac program to help prevent RSI (which is basically carpal tunnel). I saw some pictures of people with RSI, it’s gross and looks very painful. I use Anti-RSI now, and I think you should as well. I’m not posting the pictures, but if you Google it, I’m sure they’ll turn up.

Helpful hyperlinks with JS

An article from the boys over at SitePoint. This bit of JavaScript will pop an icon on the end of your links, letting the user know what they’re about to click. This can also be done with CSS 2.1, but by using JavaScript we’re making it available for… well let’s just say it… IE6 users.

]]> http://www.csskarma.com/blog/this-week-in-links-12/feed/ 0 http://www.csskarma.com/blog/this-week-in-links-8/ http://www.csskarma.com/blog/this-week-in-links-8/#comments Mon, 27 Oct 2008 16:04:50 +0000 Tim http://www.csskarma.com/blog/?p=213

Better CSS Font Stacks

A good article on how to jazz up your stacks to try and take advantage of users who have more fonts installed. I’m all for this, and as long as it’s done carefully, can get a nice version of progressive enhancement.

5 Terrible SEO Ideas

Richard Bradshaw goes over some trendy (and terrible) things that are common in SEO such as: keyword stuffing, dupe content, link farms, splash pages, and cloaking.

Fun with Overflows

I think this is a great idea (check out the demo). It creates a very similar interface to that of Plurk, the twitter competitor.

Tweet What you Spend

This is a pretty cool service that uses the Twitter API to track spending. I know it can seem kind of geeky (as is reading articles about CSS…), but tracking your spending is a great way to save money, it gives you a lot of power when you know exactly how your paycheck disappears every month. Provided you don’t mind sharing your expenses with the Twitterverse, this is a good service and very easy to use.

]]> http://www.csskarma.com/blog/this-week-in-links-8/feed/ 1 http://www.csskarma.com/blog/active-navigation-with-jquery/ http://www.csskarma.com/blog/active-navigation-with-jquery/#comments Wed, 08 Oct 2008 15:46:31 +0000 Tim http://www.csskarma.com/blog/?p=155 I was building a site last week and came across some jQuery code for active navigation. It’s very simple and works real well. I’m using it on some secondary navigation and still using my body class for the main nav.

Active navigation with a body class

body.home #nav ul li.navhome{font-weight:700;}

So I’m still doing that, but then for the internal page navigation, rather than loading the CSS up with long declarations for the numerous sub nav links, I used this jQuery:

Active vavigation with jQuery

$("#nav a").each(function() {
var hreflink = $(this).attr("href");
if (hreflink.toLowerCase()==location.href.toLowerCase()) {
	$(this).parent("li").addClass("selected");
}

Breaking it down

Let’s try this line by line for those who want to know what’s happening here.

This targets each link in contained in #nav.

$("#nav a").each(function() {

This line just saves the href attribute of each #nav a to a variable. It makes the code a little cleaner and easier to work with.

var hreflink = $(this).attr("href");

This converts the href of each link in #nav, makes it lowercase (it should be already, but just in case) and checks the current URL of the page and sees if they match. Also making the current page URL lowercase.

if (hreflink.toLowerCase()==location.href.toLowerCase()) {

If the current URL matches the href for one of the links it looks to the parent element (in this case it’s a list item) and adds a class of “selected” to it.

$(this).parent("li").addClass("selected");

This is just closing the function, I really don’t know why I didn’t include it in the above code for the purpose of this post. But no matter.

}

Issues

The only problem I ran into with this was that you have to make sure the you use a consistent href for pages.

For example

If you’re sub nav contains a link to http://www.csskarma.com/contact/, you have to make sure that you don’t link to http://www.csskarma.com/index.php; or the active navigation won’t work.

It’s not a huge deal, but definitely something to be aware of, I just had to go through a site and clean up a bunch of links up because I applied this jQuery pretty late in development. You can probably rework the code to strip out the file name and extension or do it with some PHP, if you’d like.

Actually, if anyone does that, let me know and I’ll update this post with the code.

]]> http://www.csskarma.com/blog/active-navigation-with-jquery/feed/ 3