Facebook really loves to play Popularity Police. If you don’t like enough of a Page’s posts, they stop showing in […]
Book Review:
CSS Cookbook by C. Schmitt
April 5th, 2010
I was recently wandering the aisle of a bookstore when I came across the CSS Cookbook, 3rd Ed by Christopher Schmitt, published by the wonderful O’Reilly Media. Something about O’Reilly books always appeals to me; the detailed pen drawings of various animals and flat, solid colors always catch my inner designer and make me wonder what’s inside, even when the topic is some outlandish programming language I’ll never use.
What’s inside? I’ll never know.
I picked up the CSS Cookbook and started thumbing through it to get a feel for the format. Every method had a problem (such as “You want to use multiple PNGs with alpha transparency”) a solution detailing the code, and a discussion explaining why and how the code works. Pleased with the overall layout, I flipped back to the beginning to have a look at the massive, seven page beast of a table of contents.
The book is laid out into logical sections (Web Typography, Images, Lists, Forms, etc.). In each of those sections I found CSS problem/solution pairs ranging from the very basic to the very advanced. It starts right out with “Picking a Text Editor” and “Coding a Basic HTML Page” on through “Applying Basic CSS Rules to a Web Page” and “Determining When to Use Class and ID Selectors,” but it doesn’t stop with the basics. Later on comes “Inserting Reflections on Images Automatically,” “Using Image Sprites,” “Creating Breadcrumb Navigation,” and “Styling a Screenplay with the HTML5 dialog Element.” Scanning the rest of the contents, I found myself growing excited to see things listed I wouldn’t have even thought to create with CSS. Of course I brought it home.
Most people would probably think of this book as a reference, though a Google search often reveals the answer faster than flipping through a book. Instead of putting it on my shelf waiting for me to question it, I decided to spend a few evenings reading through it. I skimmed the things I knew and bookmarked the things I didn’t, and I was reminded just how powerful a markup CSS can be with the right knowledge. The format is clear, the methods reliable, and the reasoning well-explained. I recommend it to anyone looking for a deeper understanding of CSS and how to leverage it to its full potential.
One thing I love about this profession is that there is always something new to learn. Whether a strengthening of the basics of principles and languages already known, a completely new technology, or something in between, there is always room for and push towards growth. What books have you found to aid you along your journey?
0 Comments - Be the First! »
MIX10 HTML5 Workshop
March 15th, 2010
Today was Day 0 of the Microsoft MIX10 conference in Las Vegas, NV, called Day 0 because today was optional workshops only with Sessions starting tomorrow. First let me mention that apparently in conference-speak, “workshop” means “lecture.” It was a great lecture, but “workshop” is a misnomer. Anyway, I went to an all day, two-part workshop on HTML5 hosted by Molly Holzschlag of Opera. She filled us in on the current state of the language, its potential, and what we can do with it today.
Molly spent a good portion of the morning bringing us up to speed on the colorful past of markup spec and browser implementation. The long and short of it is this: HTML was sloppy and hard to scale. XHTML came along and cleaned it up, introducing “rigor” to Web development, aka enforced consistency of markup. It also introduced the “separation of concerns,” wherein we began splitting our content apart from our design (via CSS) to improve scalability and maintainability. XHTML was supposed to be the transition from HTML to pure XML – but that didn’t exactly stick to the wall. Years later, we are still using XHTML as a preferred markup. However, as of December 2009, XHTML’s working group charter expired and will not be renewed, meaning that the W3C is officially retiring XHTML from its further attentions.
So if XHTML has worked so well for so many years, why retire it, and why switch to HTML5? The short answer is, that’s the nature of the Internet and the nature of technology in general. XHTML is not broken, per say, but it does not address all the needs of today’s Web. HTML5 seeks to add additional features and functionality, thereby improving the job of the Web developer and the experience of the end user.
Rather than continuing to build on a platform originally designed as a segue to turn the entire Web into XML, a few “cowboys” (as Molly called them) decided to go back to HTML and improve it. So was born the Web Hypertext Application Technology Working Group, or WHATWG for short. WHATWG started it, then W3C got a hold of it, and now both groups are working independently on standardizing it (Molly recommends following W3C for various reasons which I won’t detail here).
One important note (and one thing I, personally, am not too thrilled about), is that HTML5 drops the rigor introduced by XHTML in an attempt to allow browsers to be more forgiving in their displays if coding mistakes are made. It’s perfectly valid to define attributes without quotes and mix upper and lower case in the markup. I’m sure this will result in a lot more sloppy code, though I hope professionals will continue to take pride in clean markup for readability and maintainability.
The most exciting thing about HTML5 – and the reason everyone in the industry must take notice of it – is the collaboration by all major browsers. All five major browsers are talking about and working together on implementing this; even now in its earliest, still amorphous stages, these browsers are pushing out support for various HTML5 features.
You may be thinking that this is all well and good, but HTML5 standards aren’t supposed to be complete for years. Doesn’t this mean we can ignore it until then? Well bite on this and chew it for a minute: the CSS 2.1 spec still isn’t complete, something we’ve been using for years, and we’re already moving on to CSS3! The Web is arguably the fastest-moving platform for technology ever developed, and it’s also the most amorphous. Developers can’t afford to wait for Web technologies to be nailed down to a science before we start paying attention to them. If it works with relative reliability and interoperability, people will use it. As Molly repeatedly pointed out, “implementation trumps standards.”
So what does HTML5 actually have to offer? In a nutshell, it seeks to solve existing problems through evolution of existing markup. A big part of the HTML5 spec is error handling, so that errors in coding are displayed consistently across browsers (something they very much are not today). It adds markup elements to replace commonly used ids and classes, such as header, article, nav, and footer. It seeks to find a native solution for video and audio embedding (once they finally nail down a codec). It adds basic form validation and new form element attributes to simplify form coding. In addition, it includes the following APIs:
- offline Web applications, “ApplicationCache”
- client-side data storage, per-session via sessionStorage, persistently across sessions via localStorage and client-side SQL database storage
- postMessage() for cross document messaging
- native drag and drop without script
- native getElementsByClassName
- accesskey API (assign a keystroke combination for a given element – in the past: not normalized/standardized, no visible clue that it exists) and spellcheck
- keygen element
- how to handle SVG in text/html (SVG has full 3D support)
Other APIs which you may hear in conjunction with HTML5 but which are not strictly a part of the language are:
- geolocation – allowing script access to geolocation data
- native JSON support
- XLHttpRequest (level 1 and 2)
- Device-related APIs (such as remaining battery power, realtime bandwidth, processor speed, talking to webcams, etc)
- multi-touch
The potential of this plethora of new technologies is immense and is why so many designers and developers are getting excited about HTML5. With every major browser working to responsibly implement it, I hope to see browsers better able to differentiate themselves by their UI features rather than their display methods. (Can you imagine if televisions tried to differentiate by whether you could see or understand the programs instead of by higher level User Experience features?)
As I mentioned above, some HTML5 can already be used, if tentatively. Molly suggested that we could start using the new markup elements right away as long as we declare them in our CSS as block level elements. For video, simply add fallback to other codecs. Form elements with the new attributes will degrade gracefully into text inputs.
To learn more about the specifics of HTML5, check out The HTML5 Doctor. Molly also mentioned that she is very impressed with the currency and accuracy of the relevant Wikipedia articles.
