Slashdot Mirror
Book Review: HTML5 Developer's Cookbook
stoolpigeon writes "HTML5 is the latest version of HTML. In fact, it is still under development — but HTML5 brings so many highly-desired capabilities that browsers have begun to implement it and many projects already take advantage of it. Often an HTML5 project employs more technology than just HTML, and the label has come to include the use of CSS3 and JavaScript as well. There are a number of resources out there to help one use HTML5 and recently I've been using the HTML5 Developer's Cookbook by Chuck Hudson and Tom Leadbetter." Read on for the rest of stoolpigeon's review.
HTML5 Developer's Cookbook
author
Chuck Hudson, Tom Leadbetter
pages
480
publisher
Addison-Wesley Professional
rating
9/10
reviewer
stoolpigeon
ISBN
978-0-321-76938-1
summary
HTML5 Developer's Cookbook
I like the cookbook format myself in situations like this. I'm already familiar with HTML but I want to learn about the new features that exist in HTML5. This means I'm not nearly as interested in explanations, especially in the basics, as I am in getting a big diff on the languages with lots of examples and only as much explanation as necessary. Though the trick for authors is to walk the fine line between too much explanation and not enough. If they get too wordy, it really isn't a cook book any more. Not enough explanation and it can become difficult to understand all the issues that come to bear with an example. This is especially true when dealing with something that is new and still in development.
HTM5 Developer's Cookbook walks this line well. Hudson and Leadbetter have organized the recipes into various categories and further labeled them with a level of difficulty. Recipes are marked as beginner, intermediate and advanced. I found the labels helpful because while I've mucked about with HTML and its corresponding tech, I felt more comfortable easing in on the beginner end first. If I were working with someone who was a true beginner to working with any kind of development, I would probably not start them off with a cook-book. I think that is especially the case here because so much of HTML is not covered. This is not an exhaustive resource on HTML but rather a set of explanations and examples on what is new or different in this latest version of HTML.
The book itself begins with a quick review of how we got to where we are, a bit of HTML history. The chapters follow this pattern, starting with some history where needed and an explanation of the new technology driving the examples that are to follow. Then there are the recipes themselves, followed up by any helpful information and a summary. There's more prose than I've seen in many other cook-books but in this case I didn't see it as a negative. The authors assume that readers are familiar with the old approach and they need to explain how the new approach is different. In some cases tags have changed meaning, this needs to be spelled out.
Hudson and Leadbetter deal with handling how various browsers support (or don't) the various aspects of HTML5 that they highlight. This is especially important as everything is still in flux. Though if past history is any indicator, even if the spec were completely nailed down, there would still be differences between browsers. This does bring up an important question though. This book has a definite shelf life. As HTML5 continues to develop there are many parts that may become inaccurate. This is true of most tech books, but doubly so in this case. If someone is looking for a timeless tome on the topic, this wouldn't be it. In my case, it's a timely resource to get up to speed quickly, from a single source that I trust. I can search the web and find a mixed bag or turn to this one spot to get quickly up to speed.
I had an electronic version of the book made available from the publisher for this review. I've found that format to be very helpful in this case. It keeps me from feeling at all guilty about buying a book with such a narrow window of usefulness. I also really enjoy being able to jump straight to recipes. There is a list of just the recipes at the end of the book that are linked directly to each that make this especially easy. I'm rapidly moving away from dead tree books, and I didn't feel any reason here to miss that format. (On a side note, I got the page count above from Amazon. I wonder what metric we'll be using to judge book size in the future? Word count?)
All of the chapter titles and recipes are available on line. From new structural elements to integrating with devices, there are plenty of practical and useful examples. I couldn't find a clear statement in the text of the book on readers being given the freedom to use the recipes directly in code. This surprised me so I checked with the publisher and they told me that all code is free to use. Maybe that is not necessary here because everything shown is just an example of following the specification, but given the current climate with regards to intellectual property I wanted to be sure.
I've rated the book 9 out of 10 due to the fact that I think the authors do a great job of not wasting my time but instead quickly deliver what I need. If you want to get a feel for what is up with HTML5 yourself, I recommend this as a great option. If you are interested in a more comprehensive review of HTML in general or how to create web pages, I would find something more suited to providing an introduction to web programming.
You can purchase HTML5 Developer's Cookbook from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
HTM5 Developer's Cookbook walks this line well. Hudson and Leadbetter have organized the recipes into various categories and further labeled them with a level of difficulty. Recipes are marked as beginner, intermediate and advanced. I found the labels helpful because while I've mucked about with HTML and its corresponding tech, I felt more comfortable easing in on the beginner end first. If I were working with someone who was a true beginner to working with any kind of development, I would probably not start them off with a cook-book. I think that is especially the case here because so much of HTML is not covered. This is not an exhaustive resource on HTML but rather a set of explanations and examples on what is new or different in this latest version of HTML.
The book itself begins with a quick review of how we got to where we are, a bit of HTML history. The chapters follow this pattern, starting with some history where needed and an explanation of the new technology driving the examples that are to follow. Then there are the recipes themselves, followed up by any helpful information and a summary. There's more prose than I've seen in many other cook-books but in this case I didn't see it as a negative. The authors assume that readers are familiar with the old approach and they need to explain how the new approach is different. In some cases tags have changed meaning, this needs to be spelled out.
Hudson and Leadbetter deal with handling how various browsers support (or don't) the various aspects of HTML5 that they highlight. This is especially important as everything is still in flux. Though if past history is any indicator, even if the spec were completely nailed down, there would still be differences between browsers. This does bring up an important question though. This book has a definite shelf life. As HTML5 continues to develop there are many parts that may become inaccurate. This is true of most tech books, but doubly so in this case. If someone is looking for a timeless tome on the topic, this wouldn't be it. In my case, it's a timely resource to get up to speed quickly, from a single source that I trust. I can search the web and find a mixed bag or turn to this one spot to get quickly up to speed.
I had an electronic version of the book made available from the publisher for this review. I've found that format to be very helpful in this case. It keeps me from feeling at all guilty about buying a book with such a narrow window of usefulness. I also really enjoy being able to jump straight to recipes. There is a list of just the recipes at the end of the book that are linked directly to each that make this especially easy. I'm rapidly moving away from dead tree books, and I didn't feel any reason here to miss that format. (On a side note, I got the page count above from Amazon. I wonder what metric we'll be using to judge book size in the future? Word count?)
All of the chapter titles and recipes are available on line. From new structural elements to integrating with devices, there are plenty of practical and useful examples. I couldn't find a clear statement in the text of the book on readers being given the freedom to use the recipes directly in code. This surprised me so I checked with the publisher and they told me that all code is free to use. Maybe that is not necessary here because everything shown is just an example of following the specification, but given the current climate with regards to intellectual property I wanted to be sure.
I've rated the book 9 out of 10 due to the fact that I think the authors do a great job of not wasting my time but instead quickly deliver what I need. If you want to get a feel for what is up with HTML5 yourself, I recommend this as a great option. If you are interested in a more comprehensive review of HTML in general or how to create web pages, I would find something more suited to providing an introduction to web programming.
You can purchase HTML5 Developer's Cookbook from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
What sections of the book did you find the most useful in the book? Why were they the most useful for you?
Android has terrible HTML5 support in the default browser and Chrome for Android isn't much better. Also WHATWG was founded by members of Apple, Mozilla and Opera. Google didn't join until later when Hickson went to Google. And they didn't fight against H.264 otherwise they would have removed support for it from Chrome like they said they would but didn't. But hey, I'm sure they paid well for this shilling so congrats.
The book isn't uploaded to the pirate bay yet...
The best part of the summary is that the first anchor isn't even a link, has no name, title, alt, or class attributes.
Please tell me this is not what HTML5 will bring us going forward.
blog
Mod up. Oompoopoo with the Poonity interface is teh pwnage.
I actually like Google, but you make the MS shills look reasonable. A lot of companies have done a lot for HTML5, Google is but one of them, and certainly not anyone's savior. h.264 isn't going anywhere, WebM at this point appears to be DOA and might be just as patent encumbered as h.264. Meanwhile Android's HTML5 support is shit, which would be more annoying if everyone's HTML5 support wasn't shit right now. NaCl might be cool, but so far it's just another browser specific tech, which makes it both useless and contrary to the ideals you claim to support. Google is not HTML5's savior. Neither is Apple, Mozilla, Microsoft or anyone else, because HTML5 doesn't have a savior. If someone had saved it, it wouldn't be such a steaming pile of shit right now.
It's easy enough to say that these companies should just be left to rot, since they do not appear willing to evolve, but that attitude ignores the fact that the commodities that these companies offer might still be heavily in demand, even if their business model is not.
And in the end, attitudes aren't going to changed by evolving technology, evolving technology will instead only get held back by these unchanging attitudes.
"Often an HTML5 project employs more technology than just HTML, and the label has come to include the use of CSS3 and JavaScript as well."
No, it hasn't. HTML5 is HTML5, CSS is CSS, and JavaScript is JavaScript.
As a comparison, programming in Rails today includes knowledge of Ruby, JavaScript, CoffeeScript, CSS, and SCSS, and even more... yet nobody confuses any of those with Rails.
Just as nobody I know has confused CSS or JavaScript with HTML5.
...some recruiter has called be wanting to know if I have at least three years "in depth" experience with HTML 5
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
Technically, HTML (Living Standard) is the latest version.
If they plan to renege on their announcement about H.264 in Chrome, it would seem that acquiring VP8 was an awful waste of money.
It might be that they're trying to plan a successful transition rather than a pointlessly principled one. It's worked so well for Mozilla that they're about to renege on their principles.
Yeah, we should all read up on HTML5, because 2022 will be here before you know it.
HTML5 is another name for "quirks mode," a standards-agnostic (because standards-ignorant) approach to web design. What makes me say that? There is no doctype declaration for HTML5, hence no way for any browser to implement standards compliance.
HTML5 exists, in its own way, as a cluster of proposed new HTML elements, vaporware specifications and proposed features. Presumably, when enough browsers support enough features of this non-Standard to make it worthwhile, a new version number of XHTML will be created, incorporating the most widely and consistently implemented "HTML5" feaures into XHTML 1.0. At most it will deserve a 1.1 version number.
Oh please, it's been 15 months since they claimed they were going to remove support. If they couldn't do something in 15 months, they're incompetent. That or it was just chest thumping that they couldn't back up.
Or they're trying to plan a successful transition rather than a pointlessly principled one. Removing H.264 is a simple task, but it won't make the video files on the 'net magically come down the pipe in WebM format. Last I heard, YouTube is still in the process of converting existing content to WebM. You don't think they're going to just drop support for the biggest video site on principle are they? Like I said, even Mozilla is retreating here.
I'd much rather they take the time to get it right than not. If they switch now, WebM is almost certainly dead, and HTML5 video with it.
YouTube did a full transition a year ago and has transcoded all new uploads to WebM since last April. No, the real reason they never dropped support is that their chest thumping only got yawns from the industry and no one cared. You can make all the excuses you want but they could have long since switched if they had really wanted to. Besides, On2 only cost them $144 million which is Only .5% of their yearly revenue do hardly much of an expense. Sometimes gambles just don't pay off.
Okay so then WebM is dead in the water, so what would dropping H.264 accomplish other than make Chrome a less capable browser?
Don't get me wrong. I'd rather HTML5 video be royalty-free, and want Google to use their influence to help that happen. I just don't see how limiting Chrome's functionality in the present gets us there.
If your problem is that Google said one thing and (apparently) did another, I guess I couldn't care less given the details. If your problem is that Google is insufficiently supporting royalty-free HTML5 video, your work is still ahead of you in demonstrating that their commitment to drop H.264 would further that goal.
sfp cable
Instead of talking in abstact terms, why not name some companies which rely on flash and are indispensable? I haven't had flash installed for a year or two, and have very rarely come across a site which does not offer an alternative video format. All the mainstream players like BBC, YouTube, Vimeo etc have already moved and you can bet the others are already preparing to do so, given the number of ios devices. In the end attitudes will be changed by the reality of what customers/readers demand, not what is convenient for site owners - websites are pointless without readers after all.
Google fights for our privacy and rights
This requires either an "unintentionally hilarious" or "bitterly ironic" mod option.
To have a right to do a thing is not at all the same as to be right in doing it
CTV, CBC, Globaltv... just to name three that my family and I use regularly. Alternatives exist, but they require a paid subscribition or other paid services... such as downloading tv episodes via itunes, or netflix, whereas simply watching their shows on their website is completely free, as long as the viewer is willing to put up with 4 or 5 commercial interruptions per hour that last about a minute or two each. Not a big deal, in my opinion. It is fairly easy to ensure that a viewer cannot skip commercials with flash. It's not at all trivial with javascript and html5 video, since the client actually gets to see the source code, and it's much easier for a person to modify or customize it so that they can ignore commercials than it would be for them to change a flash app to accomplish the same thing (although I know the latter isn't impossible either, it has the trait of being at least a considerably larger technical challenge than modifying source code).