HTML5 For Web Designers by Jeremy Keith, CSS3 For Web Designers by Dan Cederholm

HTML5 For Web Designers by Jeremy Keith and CSS3 For Web Designers by Dan Cederholm are both A Book Apart books.  Even though I just recently read Introducing HTML5 and The Book of CSS3, I wanted to see how HTML5 and CSS3 would be presented “for web designers”.  Introducing HTML5 and The Book of CSS3 go through many new aspects of HTML5 and CSS3, both usable and not quite ready, and they are both really helpful in getting a good grasp of the big picture for both of them.  They both go through different categories of new features, with explanations and some basic examples for each.  They read a bit like textbooks to me, though.

HTML5 For Web Designers and CSS3 For Web Designers take more practical, use-right-now approaches.  They don’t necessarily try to thoroughly cover all the new features, but present the ones that are stable enough for you to use right now.  And both books are so short!  They were easy reads and the authors have really friendly tones.  I’m hoping the other A Book Apart books are similar!

HTML5 For Web Designers starts off with “A Brief History of Markup”.  Some of it is similar to what Introducing HTML5 mentions, but I also learned new things.  It takes a very humorous tone – I liked the following:

After HTML 4.01, the next revision to the language was called XHTML 1.0.  The X stood for “eXtreme” and web developers were required to cross their arms in an X shape when speaking the letter.

No, not really.  The X stood for “eXtensible” and arm crossing was entirely optional. (page 2)

The chapter “The Design of HTML5” was interesting to me, because it gives a background that is more that just historical facts – it gives  a glimpse into the reasoning and principles behind people’s thoughts.  For instance, it talks about some of the WHATWG’s design principles used to guide the development of HTML5.  One that caught my interest was “Priority of constituencies”, which, according to the book, says: “In case of conflict, consider users over authors over implementers over specifiers over theoretical purity” (page 10).  So apparently HTML5 is, at the core, designed for the users.  I often assume this is true for many things, when in fact they are not at all… It’s nice to know HTML5 really is designed that way!

In talking about the very loose syntax of HTML5, I came across this paragraph:

If you’re looking for a cheap evening’s entertainment, get an array of programmers into the same room and utter the words “significant white space.”  You can then spend hours warming yourself by the ensuing flame war. (jpage 15)

First of all, I probably enjoyed the phrase “array of programmers” too much.  Second, it made me try to clarify my own thoughts on white space.  I haven’t yet seriously used a language in which white space is significant (such as Python), so I can’t clearly say what I think about that, but I do know that I really like patterns and structures – any time I code, I try to make my style as consistent as possible everywhere.  I feel like theoretically I would enjoy the strictness of significant white space, but in reality I would probably get pissed off that my code broke due to something tiny I didn’t feel was important at all.

One thing I thought was interesting is the author’s approach to canvas.  I’ve seen people all over the internet so excited about it, treating it like the best thing ever… but this author is not quite as enamored with it, due to its lack of accessibility (page 27).  It’s interesting that he considers that more important than all the “cool stuff” canvas can do.

Another thing I found interesting is when the author is discussing calendar widgets.  He says, “…calendar widgets all do the same thing, but you’ll find that they’re implemented slightly differently on each site.  A native calendar widget would smooth away the inconsistencies and reduce cognitive load during the date-picking process” (page 51).  To me though, I feel like it would be weird because a native widget would be styled by the browser, and may not fit with the overall design of a site.  Which is “better”?  It seems like something would be inconsistent for the user either way, so is there really a “better” way, or is it okay either way?

I actually enjoyed CSS3 For Web Designers more than HTML5 For Web Designers.  The tone is also friendly and humorous, but the approach the author takes to examples is a lot easier to relate to and more interesting.  Also, he (Dan Cederholm) apparently coined the term “bulletproof web design” and created Dribbble (foreword)!

I like his humor a lot – “We created support groups for designers emotionally scarred by inexplicable Internet Explorer bug” (page 2).  He also has an interesting take on the critical and non-critical aspects of a site’s visual experience.  According to him, branding, usability, accessibility, and layout are critical, while interaction, visual rewards, feedback, and movement are non-critical (page 5).  I had never though of splitting aspects of a site in those ways, but with his categorizations, his critical and non-critical aspects mostly make sense to me.  I am surprised that branding is critical (though perhaps he is talking about business sites, while I mostly think of personal sites), and feedback is non-critical (I had figured that would be part of usability).

I liked the way he presented examples, and he takes a very practical, learn-by-trying approach.  For instance, when talking about timing functions in transitions, he says, “If you slept through geometry in high school like I did, don’t worry.  I recommend simply plugging in each of these timing function values to see how they differ” (page 20).  The examples were really fun to follow and made a lot of sense, because he related them all to a fictional case study (page 29).  In fact, he made the fake site available: Things We Left On The Moon.

The author brings up a good question – do websites need to be experienced exactly the same way in every browser (page 35)?  His answer is no.  From what I understand, he believes that the most basic functionality should work in every browser, but extras on top of that are not required, and you should design your site so that it degrades gracefully.  For example, if a browser can’t display the transition of text from one color to another, fine!  Just have it change color – the transition is not so important.   I think that I agree with him, although I may not agree with which exactly what aspects he thinks are important.

Also, fun fact I learned from the book – parallax scrolling originated in an arcade game (page 84)!

It may seem like I recommend every book I read ever, but that might also be because I give up and don’t finish books I wouldn’t recommend.  I definitely recommend these two books.  Originally I had been debating whether I should purchase them or not, since I already had the other books about HTML5 and CSS3.  I’m glad I did though, because although a lot of topics discussed were similar, they were approached in very different ways and I definitely learned new things.  I really like the short and quick “learn what you can use now” approach that A Book Apart books seem to take.  I’ll probably end up getting more of them (I already have Responsive Web Design!)

Introducing HTML5 by Bruce Lawson and Remy Sharp, The Book of CSS3 by Peter Gasston

Due to procrastination I am writing about two books at once again!

In planning out my Node.js experiment, I realized that to really learn Node.js, I would need to learn JavaScript for real – and to learn JavaScript for real, I would need to go back and re-learn HTML and CSS.  In re-learning HTML and CSS, I discovered I was stuck in the past and really needed to catch up to HTML5 and CSS3, which led to the purchase of these two books.

To learn about all the cool new stuff in HTML5, I decided on Introducing HTML5 by Bruce Lawson and Remy Sharp.  This book was perfect for me – it describes the cool new features of HTML5 (plus some extras) in enough detail to allow the reader to use them, assuming you are already familiar with HTML, but leaves the really in-depth information for your own further exploration.

The book includes a short history of HTML5, which was really fascinating to me.  I never realized there was so much drama and conflict behind it all – the W3C deciding to freeze HTML at 4.01 and move to XHTML 1.0 in 1998, people from Opera and Mozilla disagreeing with work on a new XHTML 2.0 specification and creating the WHATWG to create their own specification, the W3C deciding they may have been wrong and starting to use the WHATWG’s specification as the basis of a new version of HTML, the W3C finally dropping XHTML 2.0 and moving to HTML5, the tension between the W3C and the WHATWG (pages xi-xiii)… It’s like high school drama!

I also never knew how haphazardly new features get implemented in browsers, and how much competition there is among browsers.  The example the book gave is XMLHttpRequest (page xiv).  It was created by Microsoft, and to implement something similar the other browsers had to reverse-engineer it, so there was never any standard.  Browsers all implement things in such different ways – it’s so interesting how there has to be a delicate balance between specifying how browsers should handle things (such as invalid markup or errors) and browser individuality (or else all browsers would be the same and there would be no competition!).

The biggest thing I learned in reading this book is HTML’s emphasis on accessibility.  When I taught myself way back when, I had no idea – I just used it to make my page look how I wanted.  I never realized that specific HTML tags are so important, not just for accessibility, but also for search engines.  I feel like this as been increasingly emphasized recently, hence the very strong opinion these days that HTML should purely be for structure and CSS should do all the styling.  Also, apparently there are laws about a website’s accessibility?!  The book says that some old screen readers don’t handle the specification correctly, so it’s not your fault if they can’t deal with your content, but “it’s your responsibility to know your users and the law in  your area” (page 53).  It didn’t go into any further detail – does anyone know anything about that?

I also learned some interesting fact tidbits.  Apparently the HTML5 shiv was named by John Resig, but later realized he used the wrong word and really meant shim.  The name stuck, however, so now it’s known as the HTML5 shiv (page 276).  Also, apparently “even today Microsoft Internet Explorer claims to be a Mozilla browser” (page 281).  Learning more about browsers’ history really makes me understand people’s disdain towards IE!

My favorite part is the tone of this book.  Both authors use a very colloquial writing style, and there are so many little pokes and teases at each other.  Here are some of my favorite text selections:

New browser features are very exciting and some people have made websites that claim to test browsers’ HTML5 support.  Most of them wildly pick and mix specs, checking for HTML5, related WHATWG-derived specifications such as Web Workers and then, drunk and giddy with buzzwords, throw in WebGL, SVG, the W3C File API, Media Queries, and some Apple proprietary whizbangs before hyperventilating and going to bed for a lie-down. (page xvi)

HTML5 browsers must still render these dear departed elements, of course, as there are plenty of them still out there in the wild.  But you must avoid them as if they were tarantulas, zombies, man-eating tigers, plutonium sandwiches, or Celine Dion songs. (page 70)

You don’t need us to explain what our old chum id is.  But now you can begin the value of id with a digit, just like you always have been able to do with class.  Yay to the max, that’s phat, as people a quarter of my age probably say. (page 74)

Say for instance you had created a real-time charting application that tracked every time Bruce mentions his favourite pink cuddly toy on Twitter.  This charting app will plot Bruce’s sentiment against the current time – so you know if he’s happy with the colour, texture, and general feel of the thing or not. (page 270, obviously written by Remy)

To catch up on CSS3, I picked The Book of CSS3 by Peter Gasston.  To be honest I was pretty skeptical about the book at first.  The cover has a robot mannequin on it, being measured by smaller robots… what in the world does that have to do with CSS3?!  I never found out, but the book was very useful, so I guess it’s good I didn’t judge it by its cover!  This book is similar to the last – it assumes you’re familiar with CSS, and teaches you enough about the new CSS3 features to be able to use them, but doesn’t throw extraneous details at you.

I was very surprised to learn that CSS2 isn’t even an official W3C recommendation yet, and that work began on CSS3 way back in 1998 (page 2).  These things take so long!  It’s understandable though, I guess, since so many people give their opinions and they all have to agree in the end.  I wonder why CSS3 popped up as such a popular topic recently, though?  Same with HTML5, actually – at what point did they all of a sudden gain visibility?  Is it because browsers now have implemented so much of them that we can use them even if they’re not finalized?

I never realized the recommendation process was so complicated.  Working Draft, Last Call, Candidate Recommendation, Proposed Recommendation, and finally Recomendation (page 3).  I wonder what the average length of time it is for a module to make it through all the stages?  Years, probably!

I was pretty impressed with how much research seemed to have been done by the author in terms of browser support.  At the end of every chapter, there is a table listing the features discussed in that chapter and which browsers (among WebKit, FireFox, Opera, and IE) support it, which support it with browser prefixes, and which are expected to support it in a future version.  The examples in the chapters also include browser prefixes, so you know exactly which features are support in what way.

Something that made me think was the following sentence, which is related to something I mentioned earlier:

We think of web pages as having three layers: content (HTML), presentation (CSS), and behavior (JavaScript), and it’s generally understood that these layers should all be kept absolutely separate – we don’t use presentational or behavioral rules in the content layer (in other words, no CSS or JavaScript inline in the markup). (page 163)

I wonder when this shift came about?  From what I’ve understood after reading around, people make a big emphasis on separating layers precisely because people never used to do that.  Even I remember using <font> and style=”position:absolute” in my HTML.  What was it that caused this shift?  I personally do believe it’s easier to understand and maintain if everything is split.  However now the Transitions and Animations modules kind of take a step back – they add animation, which is usually seen as behavior.  I wonder how things will change now?

The book also went into some proposed CSS3 that may or may not ever come to reality.  One interesting one is the CSS Haptics proposed by Nokia (page 248).  I can’t really wrap my head around the fact that they are simultaneously filling in the gaps of features web developers wanted long, long ago and had to implement with workarounds (such as rounded corners done with images), and thinking way far ahead to propose CSS that defines the haptic feedback of a touchscreen.  The example was “haptic-tap-type: latched-button-down”.  Will a touchscreen one day really be able to make me feel like a physically pushed a button down?!  I still can’t get my brain around it.

Fun fact – to get around a certain @font-face drawback, you need to add a “null” value which only needs to be a single character.  It’s become convention to use a smiley face! (page 55)

These two books were awesome, and I definitely learned a lot.  I’ve now already started on my next set of books (which will most likely be written about together, since I’ve already finished one of them but don’t feel like writing about it yet…) to continue my learning for the Node.js project.  I’m also working on a separate “project” at the same time though – getting through Seven Languages in Seven Weeks by Bruce Tate.  All this stuff is so exciting!