@media screen and (device-pixel-ratio: 1.5) and (device-width: 683px) and (orientation: landscape), screen and (device-pixel-ratio: 1.5) and (device-width: 400px) and (orientation: portrait) { /* css */ }

And that’s not even the whole thing, you still need vendor prefixes to get it to work. This brings me to my point.

This intense form of a media query is getting dangerously close to targeting a specific device, which defeats the entire point of responsive design. It’s all about setting breakpoints, but if your breakpoints get too granular, it’s no better than targeting an iPhone directly. We have starting points because you need to have starting points, something like 800px, 480px, 320px, right? Typical breakpoints for your media queries. We’re missing the mark a little with using them out of the box like that though.

Not to point blame at any boilerplates, I think they’re actually really great to get you started, but when you use them out of the box, you start to get in trouble. They’re meant to be customized. — and wow, at least change that pink highlight.

The intention of breakpoints is to identify points where your design gets a little messed up, let’s say at 600px wide your design gets too cramped. In that case your first breakpoint would be at 600px. It’s different for every design. If you follow that basic model, you don’t have to worry about what a reference pixel for a device is. If the resolution for a device is 800px and your breakpoint is at 600px, it will look at intended. Don’t worry so much, you’re already doing it right.

As some may know, I’ve been writing a JavaScript book and I’ve been studying a lot of the basic history of the Web. Since its early conception we (as a community) have been hacking things together to deal with a device market that is struggling to get its sea legs. Normally what happens is that we’ll have a period of instability followed by developers & designers scrambling to rethink what they do and hacking something together to make it 100%, then it will get standardized and all the work you did to take a project from 95% to 100% is seen as a pile of dirty hacks (anyone remember the war between JavaScript and jScript?).

Now we use something called feature detection, which is a million times better.

When you work in the browser vs. on the server there are certain things you can’t control and you need to manage bottlenecks in the process rather than forcing control over an uncontrollable situation. The devices will do what they’ll do and if you try and plan for them all you’ll:

1. Go insane
2. Go broke purchasing all the devices
3. Create so much extra code that it will be unmanageable
4. Bog down performance
5. Ruin your JavaScript
6. Get to a point where it’s more efficient to detect for a device and serve up new markup on the server (and nobody wants crap that again)

What the moral of the story? I don’t know, stop over-thinking everything. It’s great to explore new stuff, but even better when you can recognize when new stuff isn’t that much better than the old stuff.

Some of my favorite people to speak with about the Web are, ironically enough, non-techies. They’re just normal users, friends, my parents, whomever. Sometimes I just sit and watch them use Facebook (I bet it’s creepy as hell). They give a real insight into the future of the Web; if these people don’t get it, no level of fist banging by “us” is going to make something successful.

We can all see what Google did with Google+: they mashed up the models of Facebook and Twitter and rolled in some Google services that already exist. Facebook with the overall concept and Twitter with the friending model (circles). Don’t get me wrong, I think it’s a great effort and I applaud them for continuously trying to break into the social networking scene but the amount of time and effort they’re putting into the weakest part of their portfolio is mind-boggling. It’s an area that really doesn’t advance the Web at all. Not pushing any boundaries, just re-packaging something someone else had success in.

Google has some of the greatest services on the Web: Docs, Calendar, Gmail, Reader, Maps… the list goes on. Maybe focus on some of those?

I guess I’d like to see some advances in their strengths rather than a continuous focus in the social atmosphere. Breaking down Google +, we have:

• A profile
• Pictures (picassa)
• Circles
• Posts
• Games
• Huddles

I will say that I love being able to have group video conferences (huddle), it’s pretty awesome. I also like the idea behind circles (but dislike the implementation).

Most users don’t care or understand the circles concept, but other than that stuff, what’s the benefit to switching over from Facebook for most people? I don’t see it. It’s a lot of duplicated services: posting, pictures, friending, games, profiles no one reads, etc.

Whether the services over on Google+ are better or not is kind of a moot point because, at their core, both Facebook and Google+ (and Twitter) are broadcasting services. We use them to say “hey look what I did here”. And that’s totally fine. I’m not judging anyone who does that all, I do it myself every time I upload a photo to Facebook or Tweet something out. But the main crutch of a broadcasting service is it’s users and the users just flat-out do not exist in Google+ right now. I don’t see a clear user migration path from Facebook (or Twitter) over to Google+ especially for non-Gmail users.

Yahoo Fantasy Sports

On getting non-Gmail users over to Google+… I think Yahoo Fantasy Sports is a great model to look at for something like this.

I have a Yahoo account. The only thing I use it for is Fantasy Football (I really don’t use Flickr). Why? Because they produced the best (by a mile) service on the Web for that niche. Honestly, no one’s even close, its at a point where I won’t even play anywhere else. I’ve actually had the pleasure of sitting down with their team of developers. They ripped apart my JavaScript worse than anyone I’ve ever seen. It was impressive and humbling to scroll through hundreds of lines of code and have someone point out every missing semi-colon. They’re the best group of UI/Front-end people I’ve ever had the pleasure of speaking with and it really shows in the product(s).

If Google wants users to migrate to +, they need to do what Yahoo! sports did and not only be the best, but be the best by such a large margin that if doesn’t make sense for anyone to use anything else. It takes time, but it can be done. And they’ll need to take some more risks.

Taking on a giant: users

I’ve gone on the record a few times saying that I don’t think anyone is going to take down Twitter or Facebook with a similar application. I think we’ve evolved past that. Looking at all the “Twitter” killers that have come along, many of them were better services, I really liked Plurk; amazing interface. But no one used it. Why? Because no one was on it. Sounds circular, I know. But like I mentioned ^ up there, these are broadcasting services and when there isn’t anyone to broadcast to, what’s the point?

I do think both Facebook and Twitter will fall at some point, I don’t know to whom, but I do know that it won’t be Google+ in it’s current state. There’s nothing over there, the hype is gone and the users are bored (dazed) and confused.

Also, I think they should bring back Wave, it had a lot of potential, just a little too much noise. It could certainly be massaged into something awesome over time.

I’m really wondering what people think about this stuff, so let me know. Tell me I’m wrong.

The talk will be on the Future of HTML5, stuff coming down the line that we have to look forward to. All sorts of wicked goodness right? I’m really looking forward to working with the folks at Carsonified, who always put together a great conference. I personally attended the Future of Web Apps conference in 2010 (or ’09 maybe?), when it was in Miami. It really was the best conference I’ve attended and it’s a great honor to be on the stage this year. The formats and venues are so unique and the speakers are so great and dynamic, it really will leave you wanting more.

They have an amazing line up coming to New York and a crazy-awesome topic list.

My Talk Description

HTML5 is evolving very quickly and staying on the bleeding edge can sometimes feel like a full-time job. In this session we’ll talk about what’s coming down the pipeline, discuss where we’re headed on the Web and dive into some hand-picked topics about the HTML5 hotness you can expect to use in the future.

Kinda awesome right? I love talking about that bleeding-edge stuff, you should totally come.

They’ll also be recording the sessions and I think the videos should be available later on (not sure on the time-frame for that).

Hope to see you there.

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 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.

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.

I do most of my article gathering through Google Reader, which has a “share” option at the bottom of each article you read. If you follow me on Google, you probably get these articles in the “shared by others” category, but for those of you who don’t, I use the RSS feed of shared items that Reader puts out piped through an RSS to Twitter service (personally, I use TwitterFeed).

It’s not a perfect service, it will only push out articles every 30mins or so, but I find it more than adequate for my purposes. If something really great comes along and TwitterFeed isn’t an option, I sometimes push it out by hand to Twitter. And I actually think the 30mins delay is a good buffer so I don’t flood anyone’s Twitter stream with articles.

Google Reader also has a bookmarklet for things you want to share that’s outside your subscriptions. It’s very nice, I highly recommend it. You can get the RSS feed and “Note in Reader” bookmarklet from the “Share” tab down the left side of the page.

That’s how you get the Tweets formatted like “Currently reading” and “From CSSKarma”. I also recently hooked up Pandora, LastFM and YouTube to the services… so look out.

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.