I received, opened and read the HTML5 for Web Designers book by A Book Apart in 2 days. If you know me, that means it’s a good read. While reading I started taking notes on my iPad, thinking it would be good to do a review. Now this turned out to be part review, part notes, and part rant. A great mix i reckon. Get a cuppa and enjoy the read now, or Instapaper it for later.

Coming home from the gym this morning i found my long awaited HTML5 for web designers book had arrived. After admiring the package for a brief moment, * ooh, Happy Cog. ooh, New York *, I threw away the idea of taking unboxing photos, and had a hot shower. Don’t get to excited, I came from the gym remember?

Breaking up the fresh book I dove straight into it over breakfast. It’s thin, only 85 pages, though I already knew that thanks to Twitter not being able to keep it’s mouth shut. The typography and layout makes it pleasant to read. And thanks to the foreword I now know that i can change my bio to “Accessible, standards-based designer-developer”, with a dash of “CSS author”. I haven’t been this excited about a book in a long time (since Web Form Design to be exact). I guess rich semantics are closer to my heart then GTD, business and project management, agile work methods, and even UX.

Chapter 1

The first chapter gives a brief summery of markup. Funnily enough it feels like reading a blog article, I’m pretty sure I’ve read a lot of this before, even in this exact wording. I don’t mind to much though, I’m not expecting the rest of the book to be the same. And it’s kept very short, concise, and straight to the point in an easy to understand way. I wish there were books like this when I started out with this webology.

Chapter 2

Chapter 2 sheds some enlightenment upon why certain elements are kept, deprecated, obsolete, changed, and what the difference is. It also has the first bits of markup in the book. HTML5 allows us to do sloppy markup, but there’s no need to throw all our lowercase closing tag goodness out the window. It allows sloppiness for all those old websites that are still out there. No need to break the web here. But for the sake of simplicity I’ll say goodbye to XHTML in regards to the boolean attributes. We also get simplified doctype, character encoding, script tags and stylesheet links. I for one like this, I hate it when the head element has more content the the body itself. And one big one, which I’m already using in client work – “The a element on steroids” – wrap your anchors around other elements, even block elements. The joy!

Death to Flash! Aka. Chapter 3 –  Rich Media – talks about the canvas, audio, and video elements.

Thought there isn’t much that’s new to me, it’s being explained in a very easy to understand way. I’ve consumed my fair share of HTML5 articles, tweets, blogs, comics, infographics, tables and podcasts, and have come across pretty much everything in the book (so far). But the book does a damn good job at explaining it better then the accumulated info in my head.

I finally understand how canvas differs from SVG, when and how to use it, and when it shouldn’t be used. As with many things HTML5 fresh it’s dependent on JavaScript to work. Which I find strange to say the least. What about accessibility? We now have these wonderful alternatives, but have to provide a pile of fallbacks because of politics, history, worst/best case scenario etc. More so for the audio element, and heaps more for the video element. Ideally the video element is just that one element. But by the time it’s ready for a client site it looks more like this: video > source.ogv + source.mp4 + flash object > param + direct download link. I’ll still use them though. The same way I’ve always used any new techniques I can, with fallbacks, so I can be as ready as possible when we finally pull the plug on antique browsers and charge full speed ahead without having to learn lots of new scary stuff.

A minor complaint: Figures/illustrations/code that aren’t  on the same page as the text they illuminate. This is a bit odd I reckon. It’s something I’ve gotten used to seeing in ePub books, though I don’t like it. But in a print book? From the superstars of A List Apart fame? I’m just gonna let that hang there.

Of the three I’m actually most excited about the canvas element, probably because it’s a whole new thing to play with. Understandably audio and video is going to be, or already is, much more exciting for the social media industry, porn, and friends. And what I’ll spend more time working on then the canvas. I don’t know if the user will ever be able to tell any difference between Flash video and the video element. The only difference they should notice is that its easier to use and crashes less often. A good challenge for us designers and developers.

Chapter 4 – web forms 2.0

Now it gets exciting! Forget about better video penetration. Web forms is the original half of what has turned into the HTML5 specification. Forms are the hard to complete, annoying, intrusive, roadblocks of the information superhighway (did I really say that?). Anything that can make it less annoying to complete a form must be a good thing. And here we have (kind of) 50% of an entire HTML specification. I’m worried that this is also what will take browser vendors the longest to implement. Forms just can’t compete with YouTube in mainstream media. Gotta love the irony though, without forms there wouldn’t be any way to upload the videos in the first place.

Very much of HTML5 has come about by taking a good look at what is commonly used by developers via workarounds, for example jQuery UI date pickers, and creating a native HTML element for it. Paving the cowpaths as they say. In the case of forms, there’s a LOT to cover. I think the book might be worth it for this chapter alone. There’s placeholder, autofocus, required, autocomplete, datalist, search, email, URL, tel, sliders, number, color, and a plethora of date and time. And the good news is that you can use all of them today. It also explains how to check for browser compatibility using JavaScript so you can serve a fallback to the incompatibles. I’d like to see a Modernizr-like library that does all the heavy lifting for me. But instead I see a CSS nightmare. It’s highly unlikely that even bleeding edge browsers will have the same styling of all the new properties and attributes. Apparently they don’t allow for any styling at all for some of the elements. Though you might be able to work your way around that with javascript.

Chapter 5 – Semantics.

Tasty tasty semantics. I love semantics. They keep order on the anarchic web. I could spend hours discussing when to use a data list versus an ordered list. If I could find someone to discuss with.

This chapter covers what I first got interested in HTML5 for. The new elements. You know – header, footer, nav, section, time, aside, article. And some peculiar ones – progress, meter and mark. And did you know that HTML5 don’t have inline elements anymore? They are now “text-level semantics”. This makes sense, as we’re not supposed to describe elements by the way they appear on a display. There is some information on microformats, and good explanations on how to use the attributes for the new elements. I think the datetime would’ve kept me googling for a bit to get right.

There’s some pretty good explanations of when to use the new structural elements – header, footer, aside et al. I know I’ll be looking this up again when I get around to continue working on my HTML5 pet project. Maybe next decade. But sadly there’s no clear-cut answer to the difference between section and article. I personally feel like it’d make more sense to let a section be higher in the DOM then an article, even though that’s not a rule at all. And I’ll change my mind on this as soon as I read some more upon the subject.

Sectioning content.

It’s increasingly common that I don’t know in what context, part of a page or site, that a particular section (not the element) goes. It may be a widget, a blogpost, unordered list or anything. I’m doing my best to use OOCSS practises to stay clear of to much duplication, but whenever a change shows up a couple months down the road there will always be something. The new HTML5 outlining method should help combat more of this. To use the example from the book – a blogpost title might be a H2 in the frontpage, with the site title being a H1. But reading the blogpost by it self the title would probably be a H1. Wrapping the post in section, or more likely, an article element now allows you to use a H1 regardless. Because it is only belongs as a header to which section it is direct child of. Thus you can use the same markup and CSS no matter where you insert the blogpost.

The final chapter. Use HTML5 today.

I wasn’t sure what the last chapter would be, but this was bloody obvious. So we get to know that it’s pretty much a go ahead, except for IE, which needs a special treatment as always. I know IE9 is gonna blow our socks off, even Andy Clarke is excited about it, but really – it’s still going to be IE.

A very useful bit was the info on ARIA role attributes. It’s a very easy method to add a needed flavor of accessibility.  This is mainly a note to self to start using that actively.

Finally it rounds off with some well wishes (thank you Jeremy) and a few quality links which I must now go and bookmark.

In conclusion, it is a great little book. You can read it anywhere, there’s no need to sit by the computer to try out the code examples. I’ll be using it to look up details later, or to prove a point in a heated discussion on semantics. There was a point where I wished the book was bigger and went more in-depth, but in the end I’m quite happy it wasn’t. I’ve probably spent more time writing this then it took me to actually read the book. So if you care about making good web, you know what to do. Happy reading!

But that has all changed. It appeared to me that after all, forms are about user experience, and user experience is something I’m quite passionate about. But what really made me get into forms where a combination of events. I finally got hold of Web Form Design by Luke Wroblewski. And I cannot believe I haven’t read it earlier. It’s been out since 2007 for something’s sake!

But it’s clearly a popular book, because I’ve been trying to get it of Amazon before, where it’s been sold out. Then I forgot about it. Then I remembered again as I stumbled across a link to the publishers own website (rosenfeldmedia.com). Enter creditcard details. While I was there I picked up a copy of Donna Spencer’s Card Sorting as well, also recommended. But for now I’ll stick to the forms.

I thought Web Form Design was going to be all about how to get your head around writing semantic HTML and valid CSS for forms without ending up in an asylum in the process. I was wrong. It is much better. There isn’t a single line of code in the book. At least not that I can remember. It puts all it’s emphasis on making forms user-friendly. This is clever, as it makes it almost timeless, something you can’t say about most HTML/CSS trends. And it really makes you think further about what Every. Single. Element does.

Why is there? What does it do? Could it be better? Do I even need it?

And the flow of going through a form. Now I’m aware of how to get a user into a form, through the form, submit the form, and what to do after the form is submitted. This is something most designers never think about. I know I didn’t. And I gotta say, it feels good to make these decisions based on research and facts, rather then a vague feeling. Sure, it takes me a bit longer to make a form now, but damn! – it turns out heaps better.

I usually get the graphic designs handed over from designers who know little or nothing about CSS, HTML, or JavaScript. I’m not sure how many times I’ve had to point out that a link usually has slightly more than one state. So imagine the forms. Now, luckily the people I work with welcome feedback and are happy to learn. But this time I’ve made a clear demand:

Read this book before you ever design another form!

Which means that my book is out on loan at the moment. I have to remember to get it back before I leave Sydney. It is definitely part of my library.

And as it happens, after finishing the book I was cleaning up my email, where among others a few hundred emails from the WSG mailing list needed deleting. And as it turned out, there was a meeting, in Sydney, where Jessica Enders (formulate.com.au) did a presentation on forms. Count me in! At the same time Sitepoint launched another book, Fancy Form Design, which I’m currently reading. In short I’d say it makes a good appendix to Web Form Design. I have learned a lot from all this. And interestingly, nothing of this is new. No HTML5, no AJAX, no social media guerilla branding campaign (sic). Just plain old markup and solid dose of human behavior. I am really happy I’ve been able to improve so much in such a short time.

So now I don’t hate making forms anymore. Instead I hate how horrible some of the forms I’m forced to fill out are. And occasionally I get to love how well it can be done.

Designing for the Web is a web design book that will still be valid next year, which is a novelty in the genre. This is because it is not about code examples, glossy buttons or Javascript GUI-animations.

It takes a look back at the roots of graphic design and shows us why we shouldn’t throw all that knowledge away, even though “the web is not print”. Mark Boulton has a background from art- and design school, which he uses to explain the academics of typography, layout, colour theory and grids. For each theory he shows when and how this applies to the web, and even when to be crazy and break the rules to make it even better. Just make sure you learn the rules before you break them.

I really like this read since I’m already comfortable with the ins and outs of the typical front-end coding and web standards, but I have literately no education on the graphic design/art side of web design. I’ve leafed through a lot of books on the subject, even started reading a few, but none have had any connection to web design.

I recommend this book to anyone who touches any part of the design process. That includes you too, code-monkeys!

The funny thing is that there’s nothing new about CSS tables. I don’t know why I haven’t encountered them before, because they work fine in most browsers. Probably because the idea of tables and layout leaves a taste of sick in the back of most peoples mouth? This book proves me wrong, it explains with good examples how the CSS tables properties work, how they compare to the old ways of positioning and floating, and why it’s the next big thing.

The reason why the authors reckon it’ll be huge is the forthcoming release of IE8, which will be the first IE to support CSS tables. Obviously it’ll take some time before IE6 and 7 are gone, but that’s no reason not to play with our new developer toys!

The book finishes off by looking into the future (CSS3), showing examples of what CSS will look like when we get to use the Template Layout Module (formerly Advanced Layout Module), Grid Positioning Module and the Multi-column Layout module. The way of writing CSS using these differs radically from the usual floats and positioning, and using CSS tables seems like a good in between step to me. So if you’re serious about your CSS and want to avoid skill rot this book is an easy first step onwards.

I will post a review as soon as I get my hands on this.

(Through All That Malarkey)