Archive for ‘standards’ category

Pears

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.

Bulletproof Web Design, Third Edition

book

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.

Adapted

There’s no doubt that employing a mobile first, responsive design approach to a new project is a wonderful way forward for many sites. I think the most exciting thing about seeing these best practices develop over the last few years is that it finally feels like web design. Finally. That we’re not designing sheets of paper that happen to be on screen.

So yes, for new projects under the right circumstances a responsive plan is often the ideal. But what about existing sites? The ones that were designed before browsers supported media queries and before smart people started stitching things together into cohesive battle plans for building flexible websites? Ideally, the move to responsive design with device-agnostic-layout-hotness is one that starts from scratch. That is, it’s likely best to rethink it all.

For existing sites (particularly ones that are also businesses) teams don’t always have the luxury of tossing everything aside and building anew. We found ourselves in this position with Dribbble, a bootstrapped operation still run by 1.5 people (Rich Thornett and half of myself, plus wonderkid intern Bruce Spang).

Up until now we haven’t had an official offering that made the experience of using Dribbble bearable on small screens. If time was plentiful, we’d have a few options:

  • We could’ve created a separate mobile version of the site. This would’ve been a lot of work up front, and even more work to maintain. Not to mention loss of full functionality. There are times when I welcome a stripped-down UI for quick tasks, but more often than not, I’m missing the features found in the “full” versions of sites when I’m browsing on the phone.
  • We could’ve tossed everything aside and redesigned the entire app with responsive design in mind. Fun! But with a growing to-do list, the day-to-day work of managing a large, thriving community, and the business of generating enough money so that everything can keep humming along, it wasn’t an option for us right now.

That left a third option, and it was after a few (decaf) lattes and advice from Ethan, that I decided the best thing to do was compromise for now. Let’s keep the same content and code that’s been powering the large-screened version that Dribbble has always been, and then let’s do something adaptive to it—using media queries to effectively make the site fluid and as vertical as possible when rendered at 480px wide and smaller. In other words, let’s take a step towards a responsive design by crafting an adaptive stylesheet that overrides the master to make things usable and readable on phones and small-screened things. Our tiny team can continue to maintain just one codebase.

Dribbble on the iPhone

And so that’s what we did. Baby steps.

The process in making this a reality turned out to be very interesting. Much is written and talked about in terms of ideals when it comes to designing for any-and-all screen sizes, but not a lot is talked about in regards to the decisions one has to make when retro-fitting existing fixed-width sites. Sites with loads of interaction elements that need to adapt when it’s squeezed down skinny.

What happens to wide, horizontal navigation? Does search have to take up all that room? What about our form patterns? Where does advertising fit? How can we avoid modifying the markup for this section? I did my best to avoid using display: none; to simply hide things that didn’t quite fit. And not much is hidden, thankfully. But you do need to get creative in terms of how certain UI patterns are handled. Items that were previously rendered horizontally may possibly be stacked vertically. Items that were stacked vertically in tight spaces (short tag names) may be set side-by-side in columns to save vertical space (CSS3′s mutli-column layout proves very useful for spreading out lists of short links). We’re all still figuring this stuff out of course, and there’s so much more I want to write and talk about regarding these (sometimes) ad-hoc solutions. More soon, hopefully.

For now, I’m happy with this initial stab at a small screen experience for Dribbble. When time, resources and funds are more abundant, I’d love us to rethink things in a more holistic manner, but for now incremental improvements will keep us moving. And that’s the priority.

Handcrafted CSS Nashville

I’m pleased to announce Ethan and I are bringing the Handcrafted CSS workshop to Nashville! We’ll reprise of the one-day course we organized last September here in Salem, Massachusetts and again last November in London with Carsonified.

As always, each attendee will get a copy of the book (Handcrafted CSS: 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 in New England and Old England, and we’re thrilled to bring it south, to Tennessee.

So join us on June 21st at the historic Hermitage Hotel right smack in downtown Nashville (steps away from the famed Ryman Auditorium and other sights). For more info on the event and to book a place (there’s a max of 100 spots), visit the Handcrafted CSS Workshop site.

Regarding HTML5

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.

Handcrafted Haiku Winners Announced

Well, we loved them all, and agonized over choosing two winners to receive a ticket to next month’s Handcrafted CSS workshop. But decide we did!

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?

Handcrafted CSS: The Workshop

Now that we’ve announced the book, we can also announce another exciting thing: Handcrafted CSS: A Day of Markup & Style will be a unique, one-day workshop presented by Ethan Marcotte and myself on September 14, 2009 at the Hawthorne Hotel here in Salem, Massachusetts.

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.

Web Standards Solutions, Special Edition

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.
book coverLate 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.

How I Might Deal with IE6

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 \*/
@import url("screen.css");
/* 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:


<!--[if !IE]><!-->
  <link rel="stylesheet" type="text/css" media="screen, projection" href="screen.css" />
<!--<![endif]-->

<!--[if gte IE 7]>
  <link rel="stylesheet" type="text/css" media="screen, projection" href="screen.css" />
<![endif]-->

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.

Simon’s method also serves up a bare-bones CSS file specifically for IE6, but I think that’s being too polite :) Another real-world example of this method in practice, is The Rissington Podcast, which cleverly serves an IE6 stylesheet complete with Comic Sans.

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.

Update: Commenter Daniel James might’ve simplified things down to a single conditional comment, like so:


<!--[if gte IE 7]><!-->
  <link rel="stylesheet" type="text/css" media="screen, projection" href="screen.css" />
<!--<![endif]-->

I’ve tested in Mac: Safari, FF3, Opera and PC: IE6, IE7, IE8beta, FF2. More testing required, but this looks very promising.