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.

I think it’s a good talk folks might be interested in, if you agree a vote my way would be much appreciated.

Description

Carrying the Web wherever you go is the future, we can all agree on that, but how do you plan for the future of a technology that is still in it’s relative infancy? This session will address how to make your mobile strategy scale to the future. Should we be building for specific devices? Should be be building for the Web? What technologies should we be using to create a unique and memorable experience? We will talk about how to design and develop with scalability in mind from the start so we don’t hit roadblocks along the way which can not only derail a project but create long term problems and scope creep that can damage the user experience. We’ll also talk about jQuery, HTML5, CSS3, performance and how it all fits into the overall picture. You will hopefully leave this session with the knowledge to create a framework for the future of your portable-Web strategy while saving development, design, maintenance, and buckets of cash in the process.

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.

I’d like to preface my thoughts here with a saying that the publisher did send me a free copy of the book with the intention of writing up a review somewhere. However, if I thought the book was crap I would have sent it right back. You can be assured that it’s a quality book and appears to be targeting at a mid-level CSS-minded designer/developer.

If you don’t want to read through the whole review, I’d recommend scanning the chapter listing and if there’s anything that you need real work on, go ahead and buy it. I will say that even in something I’m researching quite a bit about, I did learn elements of media queries that I didn’t know beforehand.

Chapter Listing

1. Introducing CSS3
2. Media Queries
3. Selectors
4. Pseudo-classes and Pseudo-elements
5. Web Fonts
6. Text Effects and Typographic Styles
7. Multiple Columns
8. Background Images
9. Border and Box effects
10. Color and Opacity
11. Gradients
12. 2D Transformations
13. Transitions and Animations
14. 3D Transformations
15. Flexible Box Layout
16. Template Layout
17. The Future of CSS

Overall Content Structure

I really liked the chapter order for the book, it made pretty good sense. Starting off with some basic things like selectors and pseudo-classes/elements; the things that are basically “hey, this is what this looks like”. There isn’t a whole lot you can say about CSS selectors, believe me, I’ve tried.

Many of the selectors mentioned in the book have been around for a very long time (in Web years), and to be honest, I was confident that they where actually in the original spec for CSS 2.1. That was a small point of confusion.

However out of place in the overall flow, I did much prefer the chapter on media queries being so far in the front (Ch. 2). After the introduction is seemed like it was amping up to be one of those books where you don’t get to the really cool stuff until the end, and by the time you’re there, your tired of reading.

There are a lot of surprisingly basic things to cover in CSS3 and I think Peter did a good job of architecting the information in a meaningful manner.

Things I Really Liked

I really liked the chapter on media queries and Peter’s writing style; he made everything pretty easy to follow.

The chapter on WebFonts included very current examples like the bullproof @font-face syntax, which makes the book seem very timely.

Stuff I didn’t find super-useful

Being completely honest, I’m tried of hearing about the template layout model. I first read about it in Andy Clarke’s Transcending CSS book… 4 years ago (?). It’s very cool, and kinda rocks, but being at a point where we can’t get border radius and gradient working in all browsers, it’s a far shot away to start using a new layout model.

The gradient chapter is a little out of date (I think the webkit syntax is changing), but that’s what happens with books; they get old pretty fast. Other than that there isn’t a whole lot negative about the book. It’s a little late to the game in regards to how long we’ve been dealing with CSS3, but that also means the information is pretty solidified.

Conclusion

Overall, I did really like the book. It was well written and put together in a unique way. I am however torn in telling you if you should go out and buy it right now because I sort of feel like we’ve all being practicing most of the techniques in the book for a long time. I found myself getting a little bored at times reading about the color formats, selectors and older things like that.

If you’re like me, you’re really reading a book like this for the cutting edge elements that haven’t been blogged about over and over again (chapters 13-17) and you don’t want to read through the CSS3 spec (and you shouldn’t, because it’s awful). Those chapters are actually very good and give you a strong base in what’s coming down the pipe. You can also use the other chapters to tighten up your general CSS3 knowledge.

I almost feel like I wasn’t the real target audience for the book, but with that being said, I did still learn enough stuff to justify the price tag. So should you buy it? Yea, you should buy it.

Also, I really like the cover art.

It was way cool. check out a quick demo I threw together.

I inserted 2 breakpoints in the demo. One at 800px and another at 480px, so you should see the design adjust twice.

The CSS

header h1 a,
article h1,
article h2,
article{
     -moz-transition: all .5s linear;
     -webkit-transition: all .5s linear;
     transition: all .5s linear;
}

Put that in with the base CSS (not the media query) and you’ll get a nice animation effect as you resize the browser window.

You can’t animate all the properties, but things like: color, margin, padding, color, font-size, etc are all fair game. I’ve mostly been using transitions for softening hover effect lately, but I think this, if tastefully done, can be a nice hidden (and light weight) gem.

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.

First off, I feel like I need to explain what a scaling design is exactly. It doesn’t make a whole lot of sense since the term “scalability” is tied pretty closely to back end work. When you hear it you think of large elaborate databases, PHP frameworks, cloud computing and high traffic web sites. Not this time though; the scalability of a web site based on traffic, has little or nothing to do with the actual design comp. Of course your code needs to be efficient, but what about your designs?

If I promised you that overall development time can be cut in half with a little forward thinking, would you be interested in something like that? I know I would.

It’s not desktop vs. mobile.
It’s not designing mobile-first.
It’s not responsive Web design.

It’s knowing how to design a scalable web site, a skill that for some reason is escaping many of us… stay tuned for the story.

I also gave a talk at Cascade LA a couple weeks ago called “Mobile, Media, & Touch” on the same topic (it actually goes into a little more depth). You can view the slides on slideshare

Let me know what you think!

Obviously, I highly recommend all those these books, as they’ve had a pretty large impact on me as a designer & a developer. The best part about them is that they’re all pretty easy reads, they’re not the kind of books you have to spend a week or 2 reading.

Does anyone else have books like this? Or do we all just read blogs now?