One of the principles we build sites by is to never resize an image in HTML but rather size the image appropriately in Photoshop, Fireworks, or whatever you use. We do this so the user doesn’t have to waste bandwidth by downloading a larger image than is necessary for the situation. Sounds great right? Totally reasonable.

When media queries and responsive design began to get heavy traction images started to present a real problem because using a single image on a large screen with high bandwidth didn’t necessarily work on a small screen with low bandwidth (let’s face it, we’re talking about a phone here). Using a single image makes sense in theory, but maybe not so much in practice. The famous Boston Globe redesign was the first (notable) site to try and tackle this problem on a large scale. I’m not exactly sure why it’s apparently ok now to resize image with CSS, but still bad to do it in HTML, but that seems like a topic for another day.

I won’t get into the specifics about how they did it because I heard there were a lot of problems with the method (and I forget exactly what went on). The important thing that came out of successes and failures of that project was that it kick-started the discussion about what exactly we should do to deal with this image (or really asset management) problem.

Scott Jehl came up with an interesting solution via the picture element. While I don’t think inventing new standards is quite the answer, the method seems sound.

The Detection Stack

When I’m building a site I can generally boil an interface down to a couple detection points:

• detect screen size to modify the design
• detect for touch capabilities for modify the interface

I’d like to add one more to that: detect bandwidth level for asset management.

Detecting for Bandwidth

The focus of image loading, so far has been based on image dimensions and screen-size; I think what really matters there is file size and available bandwidth. Just because browser window is small doesn’t necessarily mean it can’t handle a high-res image.

On a recent project I was looking for a way to test online/offline state, I came across Using navigator.connection in Android. Which is a blog post covering the Network Information API.

I built out a simple demo based off the blog post which checks bandwidth and returns another image version. To set up the HTML, we’re using a normal <img> tag and loading in the small version of the image incase nothing works, you’ll get the small version:

HTML

<img src="images/small-fella.jpg" data-large="images/large-fella.jpg">

Using the data-large attribute let’s use store the image inside the <img> tag, so it feels more natural.

The JavaScript will check the bandwidth using the network information API, loop through all the img[data-large] and re-set the image src attribute.

JavaScript

(function(){

    // initialize some variables
    var connection,
        connectionSpeed,
        images = document.querySelectorAll("img[data-large]"),
        imageCount = images.length,
        i;

    // create a custom object if navigator.connection isn't available
    connection = navigator.connection || { 'type': '0' };

    // if statement checking for WIFI, ETHERNET or UNKNOWN
    if(imageCount > 0 && connection.type === '0' || connection.type === '1' || connection.type === '2') {

        // loop through each image with the data-large attribute
        for (i = 0; i < imageCount; i = i + 1) {

            var obj = images[i],
                largeImg = obj.getAttribute('data-large');

            // reset the image src to the larger version of the image
            obj.setAttribute('src', largeImg);

        }

    }
})();

In the demo there’s also a switch statement outputting a string for the connection type. I’m adding it to the HTML, but you could easily add it as a class to the body so it’s globally available and usable with the CSS.

Cool right?

Support

It doesn’t really work anywhere. There are rumors of Android support but I personally testing the demo I built for this write-up on the latest Android OS and it didn’t work. Hopefully we’ll get there soon because I think this a great API.

We’re not heart surgeons, or nurses, or even fire fighters; no one’s life depends on what we do and no one dies if we screw up. I try and remind myself of that fact when I get overly frustrated during a project as it helps keep complaining to a minimum and a little perspective (which is always good).

Yesterday was the first annual Global Accessibility Awareness Day (GAAD) and even though there was only about a month’s notice, cities around the world participated. Obviously, I wasn’t able to attend them all, but I was able to sit in on Boston’s version at The Carroll Center for the Blind, there really couldn’t have been a better venue.

I like to think that the sites and applications I build are as accessible as possible. I mean, it really doesn’t take any time to throw ARIA roles in there and make sure your alt text is meaningful. It’s actually one of my pet peeves when developers/designers take accessibility shortcuts. It’s so easy to dimiss these standards because we so rarely meet the people they effect.

Last night I met some of these people. I watched a visually impaired gentleman navigate New York Times with a screen reader. It was awful. I saw first hand why using “click here” and “read more” are terrible for link text (I had heard about it, but never saw it first-hand). I got confirmation that sometimes it’s best to leave alt text blank and why we leave the attribute empty rather than removing it (screen readers announce the file path if the alt attribute is missing).

Going into last night, I knew a lot about accessibility because it’s been a focal point of my career for years. But there is a huge difference between reading a blog post about Web accessibility and watching a visually impaired person go through 20 minutes of struggling to reach the main content of a Web site you would normally find in under a second if you could see.

I won’t lie, it’s pretty rattling to see folks with actual problems struggle to use a medium that we take for granted. Not just the Web either, we had a fairly full discussion about on-screen TV menus as well. A lot of things, I’ll admit, I don’t really think about in my day-to-day life.

Overall, I think the GAAD event was a great success and I hope it grows for years to come. It’s aways nice to have a reminder that even though we don’t save lives there’s one small part of our jobs that can positively effect the lives of others.

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