Yesterday, on stage at An Event Apart Atlanta, I announced Pears: an open source WordPress theme for creating your own markup & style pattern library.
I wanted to create my own database repository of commonly used patterns and figured the tool might be useful for others as well. Breaking interfaces down into patterns has been immensely helpful in learning and re-evaluating the best possible code to implement them. I’ve just gotten started and will be adding more as I create them.
But Pears isn’t about how I code these patterns—it’s a tool for creating your own.
The theme is available on GitHub for those that want to chip in and make it even better. Admittedly, the code is a little rough here and there, but it works.
Looking forward to seeing others’ takes on the patterns that power flexible web interfaces.
Yesterday, a copy of my latest book arrived in the mail, the Third Edition of Bulletproof Web Design. The first edition came out back in 2005, and I’ve been revising it every few years. This latest edit was a bit larger than the 2nd because so much has changed. HTML5, CSS3, Responsive Web Design—all of these things dovetail nicely into the core bulletproof concepts from the original book.
If you have the 2nd edition, the new version is likely not a necessary upgrade (New Riders probably loves me for saying that). Meaning, the guidelines for building flexible websites are still there, but a lot of the code and some of the examples have been brought up to speed. I’m most happy that the book has been updated for those that haven’t read it before. And as always, I think it’s a great book for those getting started in building flexible websites with semantic markup and style.
The final chapter was rewritten from scratch to include a new fictional case study that follows a very simple example of Responsive Web Design, which I think is a natural extension of the previous chapters.
If you haven’t read the previous editions, I hope you enjoy it. It should be available by the end of the week.
Just like last time, each attendee will get a copy of the book (Video Edition including the DVD) and we’ll spend the day walking through much of its content and more. This event was a great success here in New England, and we’re thrilled to bring it to the UK. Thanks to Carson Workshops for making this happen!
So join us on November 23rd at Wallspace St Pancras in London. For more info on the event and to book a place (there’s a max of 70 spots), visit the Carson Workshops site.
It was a hot Summer Sunday afternoon. I’d just stepped off the Acela Express from Boston to New York City, and I was confused as ever about HTML5. I thought I was alone. Impossible in mid-town Manhatt– no, alone in being confused about the next chapter of markup specifications. I figured something was wrong with me. Was I not reading up enough about HTML5? Well no, wait, I’d been doing a fair amount of reading up about HTML5, yet there was still this partial confusion about a number of aspects of the proposed spec.
Thankfully, a few friends old and new got together at Happy Cog headquarters to walk through the spec, noting along the way the areas that seemed problematic, confusing or otherwise unsettling.
Personally, I came away from that day less confused, but more importantly feeling more positive about HTML5 in general. Along with this newfound positiveness, came some clarity in specific portions of the spec that seemed troublesome. The rest of the group (I can take zero credit for its publication) crafted a “guide to HTML5 hiccups” in the hopes that the powers that be would listen and healthy debate might begin on these specifics.
A few of those items that stood out for me were:
Offering an HTML5 syntax option when validating. This has nothing to do with HTML5 itself, but it’s important for the validator to simply and easily add an option for checking syntax that would help to foster good coding habits, avoid head-scratching rendering issues, etc. That’s why I choose to code XHTML today — it’s a personal preference that helps me maintain, optimize and troubleshoot code, and I’ll continue with that convention no matter the doctype.
HTML5 introduces a lot of new elements. All at once. Some of which seem unnecessary (e.g. article, hgroup).
While at first I was cringing at the idea of redefining the semantics of certain elements, it does start to make sense. Instead of introducing even more elements, HTML5 reuses and redefines. For example, the small element would now “represent side comments such as small print”, rather than a presentation instruction for font size.
The concept of “sectioning content” I didn’t quite get at first from the high level overviews I’d been reading, but seen in practice, it’s quite excellent (e.g. where the section dictates scope of the heading elements it contains).
That said, folks will use header and footer for exactly the areas that they’re now assigning IDs with those terms, while in HTML5 they can mean different things (header and footer of a section, for which there could be many on a page).
I still have an enormous amount to learn about HTML5, am still concerned about certain aspects of it, but overall optimistic about the future of markup.
Winner #1 is @wilto, waxing poetic about a place we’ve all been, surely:
IE6 lives on.
Box model—and heart—broken. position: fetal;
And Winner #2 is @squaregirl , who in three perfectly penned lines reminds us of the importance of validation during development:
Curly braces sound cute.
Until you leave one out. Oops!
I fracked my stylesheet.
Congrats to the winners! And thanks again to the fine folks at Campaign Monitor for sending them to the workshop. Which, by the way, is only a little over two weeks away. Spaces are being filled up, so grab a ticket and join us in Salem, won’t you?
You’ll get a copy of the book (the Video Edition, including the DVD), and we’ll present the content live, throughout four takeway-packed sessions, followed by Q&A. Breakfast, lunch and two snack breaks are also provided. And we’ll cap off the day with an after party at an awesome location to be determined.
The Hawthorne Hotel is located in downtown Salem, just 16 miles north of Boston. It’s also just a 10-minute walk from the MBTA Commuter Rail station which connects Salem to Boston in about 25 minutes.
This will be a unique opportunity to buy a book, then have the authors work through it live, with a chance to ask questions along the way. It’s sure to be a fun day — and we’re pretty damned excited about it.
Early-bird and student tickets are now available at a discounted price of $399 per person. Act quick! There’s limited seating for 100 fine people like you.
Oh, and interested in sponsoring the event? We’d love to hear from you.
I had help this time. The unstoppable Ethan Marcotte contributed an absolute gem of a chapter on the fluid grid. And I think it’s worth the cover price for the pages he authored alone. You might remember Ethan’s recent article on the subject over at A List Apart, and his chapter builds quite a bit on that, while tying it back into the book’s case study. And fellow beverage aficionado and bon vivant, Brian Warren, handled the technical editing.
The book is largely a culmination of the talks I’ve been giving around the world over the last year or so. In some ways, it’s a continuation of Bulletproof Web Design, in that it was convenient to be able to jump right into examples and the core of what I wanted to write about. There are a lot of CSS books out there, and the last thing I wanted to do was just write another general overview.
So this one gets specific rather quickly. And the timing seemed right. The browser landscape is changing rapidly. Browsers are implementing new and evolving standards faster. It’s an exciting time to be designing for the web. Firefox 3.5 has just been released, and with it came a goodie bag of CSS3 properties that can now be utilized between Mozilla and Webkit-based browsers (as well as Opera). I’m using the term “progressive enrichment” to describe advanced CSS and CSS3 properties that work in forward-thinking browsers today. And that’s a heavy focus of the book.
A single case study for the fictional “Tugboat Coffee Company” was used as a common thread throughout the entire book, where progressive enrichment, reevaluating past methods and best practices and flexible, bulletproof concepts are stressed. Part of being a craftsman of the web is paying attention to the details that matter most, and the book is an attempt to share a collection of those details using current methods.
In addition to the book, I also recorded a DVD. A video crew from Peachpit came and set up here at the BitCave in Salem, and the result is Handcrafted CSS: Bulletproof Essentials. It covers concepts from my previous book and the new one, while relating all of it to the Tugboat design. There was also a ukulele hanging around the office and I managed to put it to good use as a background score. The video acts as a unique bridge between the two books, and either comes bundled in a Video Edition of Handcrafted CSS or by itself.
More info can be found at the book + DVD’s companion website and Twitter account, where Ethan and I will be announcing another exciting aspect of this project in the next day or so. Stay tuned.
It’s been a long five years since it was orginally published, but last month month a new Web Standards Solutions, Special Edition was released by Friends of ED. Late last year, I gave the manuscript a little freshening up, mostly reviewing things in the crop of browsers that have been released since the initial version. I’ll stress that this was not a large overhaul of the book (hence Special Edition rather than Second Edition), so if you’ve already read the original, or own it, you’re better off spending your dime on another book.
But while it wasn’t a giant update, it was nice to give it some extra attention, and pass it through through tech editing, copy editing, compositing and proofreading cycles once again. In the end, I’m really happy it just made the book that much more solid for folks that haven’t read it—and hopefully still a good introduction for those getting started with semantic markup and CSS.
In other book news, I’ve been toiling away on something brand new, and look forward to sharing much more about that very soon.
Eight years ago (almost to the day), Jeffrey Zeldman wrote, To Hell With Bad Browsers, signaling the dawning of “The CSS Age”. Explaining how the use of @import for referencing stylesheets is ignored by Netscape 4, was an important step in shedding away the problems related to supporting an ancient browser. Eight. Years.
Completely ignoring a browser in terms of CSS is a wonderfully freeing thing. It certainly can’t be done on every site. The important thing to remember is that it’s a site’s statistics that should determine what level of support you decide to offer.
Later, IE5/Mac became a problem. I began giving it the same “talk to the hand” treatment that NN4 was receiving by using the backslash comment hack years ago:
/* import stylesheets and hide from ie/mac \*/
/* end import and hide */
Now, in 2009, IE6 has become the source of our frustrations — and for certain sites, giving it an unstyled, naked view is exactly what I want to do. Alpha-channel PNGs, min-width, max-width, rendering bugs galore — there are plenty of sites I’ve designed and maintain where the IE6 stats are low enough to drop the axe and move on. Now is the time!
So what’s the easiest solution? I was chatting with Ethan about using conditional comments to hide styles from IE6 only, and after a bit of Googling, we found Simon Clayson’s article, where he cleverly does the following:
This hides all styles (assuming they’re all contained within screen.css) from all versions of IE, but then re-applies them for IE versions 7 and greater. Lucky visitors that are using IE6 or lower will get an unstyled view of the site, just like the lucky visitors using NN4 have been getting for close to a decade.
What’s nice about this approach is that you’re not having IE6 import all your styles, having to worry about overriding them later. You could serve IE6 with a minimal stylesheet starting completely from scratch. Or none at all.
Is it a bit hacky? Sure. But in certain situations, not having the burden to worry about IE6 seems well worth it.
Have a better solution? Let us know in the comments.