Skip to main content

Kimberly Blessing

Want to become an expert? Study (web) history

5 min read

Lately I've been spending a lot of time thinking and talking about the past.

I'm at the airport awaiting a flight that will take me to the Line-Mode Browser Hack Days at CERN. CERN, perhaps presently most famous for being the home of the Large Hadron Collider, is also the birthplace of the World Wide Web. More on that in a moment.

Screen shotMy first personal web site, circa 1997

Twenty years ago -- What the hell? Where did the time go? -- I started college. I arrived at Bryn Mawr College a French major, soon to switch to Romance Languages. My Italian professor assigned us reading on a Web page. I was one of the few people in my dorm to have a computer (and modem! and laser printer!). I had email before I got to college, on both AOL and Prodigy. Bryn Mawr had a gopher space, but no web site -- in fact, there were only about 500 web servers up and running at the end of 1993. And yet, that seemingly meaningless introduction changed my life. I took computer science classes. I changed my major to computer science. I started building web sites -- heck, I designed and built the first web page to be hosted at For me, that was the start of it all.

And so here we are today. You, reading. Me awaiting my flight to Geneva. To CERN. Holy freaking crap! Understand that, for me, this is akin to visiting Mecca, except I am worshiping ideas, and code, and technology, and the propagation of all those things that has help fuel the evolution of our world into its presently hyper-connected state.

But I must admit that I was surprised, when telling some other web developers about my trip, that they didn't know about CERN's relevance to the web. The popular history of the Internet as an American creation dominates, and it has consumed the WWW creation story for some. So I educate and inform, to set things right, to help those whose careers are based on HTTP and HTML understand their domain's history.

Now, here's where I get preachy, because I run into scenarios like this -- where a web developer will make statements about web-related history that are completely wrong -- frequently. "Oh, IE doesn't support inline-block." Wrong, it has supported inline-block for a long time, but it couldn't just be assigned to any old element. (I've heard this one a lot lately -- perhaps because I'm interviewing and one of the coding problems I give can potentially be solved with inline-block.) "Old browsers don't support the HTML5 doctype," is another popular one. Misunderstanding the origin of CSS3 properties, incorrectly attributing computer accessibility to web accessibility, explaining IE compatibility mode based on one or two simple tests rather than reading the documentation -- even attesting to a lack of JSON support prior to 5 years ago (?!) -- are things I've encountered lately.

I admit that I am quite privileged to have, essentially, grown up with the web. I've been active with it, as a user and a developer, almost as long as it's been around. I do fondly remember using both Lynx and Mosaic to not just surf the web, but also test my own sites. I remember "playing around" with CSS to layer text, and trying to get it to work in both Netscape 4 and IE 3.

But I digress -- this isn't about me. This is about getting other web professionals to better understand our field. To be correct in what they say about the past, when trying to educate others. To not make false statements, based on lack of knowledge or direct experience, which lead to wrong assumptions and misinformed decisions about code and architectures.

I realize I sound like a crotchety old geek, complaining about the young whippersnappers who don't respect their elders. This isn't the case at all. I've had the pleasure of working with many younger people, or just less-experienced people, who have taken the time to learn about the web's history. (Admittedly, some of those people were required to, when they took my course on web app development.) And just knowing facts about history doesn't do much good, without analysis or thought of impact, for today or beyond.

Genuine curiosity and a desire to learn all that one can is ultimately what makes an expert. And, truth be told, any real "expert" will be the first to admit that they're hardly such -- they're still on the quest to become experts, themselves.

So, here I am, about to board my plane, hoping to enrich both my understanding of web history, and yours. Assuming I haven't entirely turned you off, I hope you'll follow my travels on Twitter.

Required Reading

Kimberly Blessing

WaSP's Work Is Done, But Mine (and Yours) Isn't

2 min read

Yesterday, on March 1, 2013, the Web Standards Project (aka WaSP) -- a small, grass-roots group of web standards advocates assembled nearly 15 years ago -- announced that it was formally wrapping up shop.

I was invited to join this small group of passionate and dedicated people almost nine years ago. My first email arrived on March 24, 2004 and, for the next few years, engaging with WaSP members and working on its projects were practically daily activities. Thinking I was a web standards "expert" when I started, I quickly learned that I had miles to go in terms of both technical knowledge and leadership growth. WaSP was a wonderful learning and growth experience for me.

Activity within the group slowed in more recent years, in part due to individuals moving on in their lives and not having as much time to dedicate to the mission, and in part due to the industry changing and naturally embracing what WaSP had advocated for so long: that implementing and following the specifications would make the web a better place for everyone. So, while the group exits the stage quietly, it's not without having had a tremendous impact. And so, to my cohorts, I say congratulations on a job well done.

The final WaSP blog post closes by entrusting the ongoing WaSP mission to the reader. Don't think you can change your team, your company, your country? WaSP's legacy proves true the old adage: "Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has." So go on, now -- go change the world.

Kimberly Blessing

I should've bet money (on using paragraphs in forms)

2 min read

For years and years, I have coded HTML forms with paragraphs. I would tell people that an input field and its label, plus any associated data (help text, error messaging, whatever), should be wrapped by a paragraph. To me, the contents are semantically and syntactically related; and much like any other written document, each form label-field pair is a distinct topic requiring separation from others. I think there's also precedence in the print world for this, as well as examples from early HTML work, but let's just leave my argument at that.

I believed in paragraphs in forms so much that I even made this the rule in PayPal's coding standards. And because of this, I have had a very long-standing argument with colleagues and friends, like Steve Ganz. (Mark Trammell, Shimone Samuel, and Jeff Harrell come to mind, too.)

I've been working on a writing assignment with Christopher Schmitt (a chapter on HTML5 forms for the upcoming HTML5 Cookbook) and he suggested that I include an explanation as to why I'm using paragraphs in my form examples, because, as Christopher said, "You know someone's going to be coming out for us on that one."

So, direct from the HTML5 spec, here's my new justification for using paragraphs in forms [Emphasis mine.]:

Any form starts with a form element, inside which are placed the controls. Most controls are represented by the input element, which by default provides a one-line text field. To label a control, the label element is used; the label text and the control itself go inside the label element. Each part of a form is considered a paragraph, and is typically separated from other parts using p elements.

There you go. I was right all along. I should've bet money on it.

Kimberly Blessing

Review of HTML & CSS: The Good Parts

3 min read

HTML & CSS: The Good Parts

O'Reilly's HTML & CSS: The Good Parts by Ben Henick is a new book to educate and aid web professionals in building quality web experiences. A quick disclaimer about this review: I worked on this book as a technical reviewer and the author is a colleague and friend.

This book is primarily for those who have some experience with HTML and CSS and want to refine their skills -- but even front-end code ninjas will find some valuable reference material in this book. While the title implies a focus on HTML and CSS, Ben takes the time to touch on a number of related topics, such as the client-server model, creating usable interfaces, image optimization, and web typography -- thus giving the reader greater insight on the wider range of knowledge and skills it takes to build a quality web site.

One of my favorite sections of the book is chapter 4, "Developing a Healthy Relationship with Standards." Ben gives an excellent explanation of the history and benefits of standards adoption and then wraps it up with 10 rules for "standards-friendly" development. If you're still trying to make the case for adopting standards where you work, definitely check out this chapter.

If you've read any of the "Good Parts" books then you know that these books also highlight the "bad parts" and "awful parts" of the subject matter. While Ben gives a good overview of the browser wars as context, he spends a number of pages calling out the various issues with Internet Explorer. (I like to think that I helped tone down some of the harsh criticism he originally wrote by reminding him of how advanced IE6 was at the time of its release.) He goes on to explain the concept of graded browser support (something near and dear to my heart) and hits on a number of seemingly nit-picky but important concepts which standardistas care about.

It's really amazing how much information Ben packed into this 352-page book -- far too much for me to address here. Besides touching on HTML5, there's a helpful glossary and numerous reference tables. As I'm writing this review, in fact, I'm sticky-noting the book so I can easily find reference information that will help me in my day-to-day work. That said, you can also sit down and read the book cover-to-cover. (Ben's an incredible writer.)

If you're looking to enhance your skills, improve the quality of your work, find a better job, or even if you just want to have a backup brain handy, I recommend HTML & CSS: The Good Parts.

HTML & CSS: The Good Parts
  • HTML & CSS: The Good Parts
  • by Ben Henick
  • Published by O'Reilly Media, ISBN-13: 978-0596157609
  • Companion web site
  • Buy it from Amazon

Kimberly Blessing

The Problem Isn't IE6 -- It's You

5 min read

This post is going to upset a lot of people, I'm sure, but what I have to say needs to be said, if only to remind members of our community to behave themselves.

Is Internet Explorer 6 an old, outdated, hanger-on of a browser? Yes, absolutely. Does it require the use code hacks in order to achieve semi-parity with more modern browsers? Yes, it does. Should this be such a problem for web professionals? No, it shouldn't.

IE6 Cartoon Thanks, Tracy Apps!

For a moment, forget about all of IE6's issues, security, how much you dislike Microsoft, or whatever baggage you're carrying around. Instead, think about IE6 as an unknown browser -- perhaps as a random blip in your browser stats, or maybe as an interesting piece of tech you've seen on a blog or at a conference. You don't know much about that browser or how your site is going to work on it, so what do you? You code it using web standards goodness: you create a base with semantic markup (and any server-side tech for forms), add on design via CSS, then layer on client-side interactivity with JavaScript and Ajax-y goodness -- et voilà, you have a lovely, robust web experience.

Now, with some new or unknown browser, you hope for the best. But with IE6, we know what the issues are. If you're using PNGs with alpha-transparency in your design, you'll need an alternate solution. If you're adding horizontal margins to floats, you know you'll run in to a double-margin bug. If you're trying to clear floats within a parent, you know you need to set height. You'll need to plan for handling unsupported CSS selectors. And when it comes to JavaScript, you may not even know what to plan for (unless you spend most of your days working with JS).

But again, you're a web professional. You know your craft. You know this platform and its issues. (If you don't, you need to know your craft better. No, I don't buy "newness" to the field as an excuse -- this is still a present concern, so you need to understand it! Why not start with my CSS tips for IE6.) While some venting may be in order, I find the outright hatred for this browser (and other versions of IE, also bashed on a regular basis) to be downright unprofessional. Here's why:

  1. IE is still #1. While recent reports cite that its market share is shrinking, IE (all versions combined) is still the number one browser in use worldwide. The snide comments I've seen people make about IE (which I won't link to) often extend to remarks about IE users, which is just about the uncoolest thing I've witnessed. Respect the user, regardless of browser!
  2. IE6 use is shrinking. With the growing number of sites proactively messaging that support is being discontinued for IE6, its share should continue to shrink, which will lessen your burden over time. (You do have an actively managed browser support policy, to help you identify when you don't have to support it any longer, right?) Celebrate that people are upgrading instead of harping on the stragglers.
  3. Promote the best experience. Instead of complaining about having to make a fancy widget work perfectly on IE6, engage with the client/product/design team to explain how you can deliver the best possible experience to every user by honoring only what each browser is truly capable of, rather than let one browser hold you back. You now have plenty of real world examples (Google Apps, Digg, Facebook, YouTube, etc.) to back you up on this!
  4. Help prepare for the future. Remind those in decision-making roles that the more time you spend looking backwards at the old, the less time you have to prepare for the new. Since I haven't met a business owner (small, corporate, or otherwise) who doesn't like "new", this should snap them back to their primary focus of strategies that save money and provide for the future.
  5. Don't make yourself look like an ass. If I'm one of those poor souls still stuck supporting (or, perhaps worse, using) IE6 and I'm trying to hire someone, do you think I'm going to hire the person who's been hating on that browser all over the interwebs? Umm, no.

I know folks are going to jump in with all sorts of comments about me not thinking about Ajax-y web apps or super beautiful design-y sites. The thing is, I do work on and continue to lead a team which works on these types of sites and apps, and yes, we're supporting IE6 in all cases. No, it's not to pixel perfection. No, the functionality we build for a new browser isn't 100% replicated. But these sites aren't as far off as you might think* -- and in the cases where I'm using hacks or JS shims to get IE6 into compliance, I also have easy code management techniques for dropping support.

*In fact, very recently, after preparing business and design teams to accept far less functionality in IE6, my team delivered a cool animated design-y thing that worked perfectly in that browser! (It's not live yet, but I'll update this when it is.)

So take the time to inform and to educate about browser differences and support strategies. Enthusiastically suggest alternatives to your team. Track your browser metrics and get happy about those numbers changing. Say a small thank you to those at Microsoft who are working to improve IE. Get inside the IE6 user's head and present their story, not your own tale of woe. If you need help, ask for it.

Seriously, it'll save you from looking like an ass.

Kimberly Blessing

How to Improve Page Load Times

1 min read

My latest article for Peachpit is on one of my favorite topics: web site optimization and improving page load times. This article is a review of the basics, which I hope will be helpful to those of you wondering where to start with optimization.

As a next step, you may be interested in my 2008 presentation from WebVisions: Optimize Your Site in Seven Easy Steps. This repeats a few tips but also provides some additional steps to improve page load times.

These resources just scratch the surface of the topic, but they're important fundamentals. If you want to optimize your site, you need to do it at every step -- in your code, with the use of graphics and other assets, at the server. Building a site and trying to retrofit for optimization may help, but it doesn't pack the same punch. (The same thing holds true for accessibility. And, like accessibility, creating an optimized site isn't terribly difficult when planned for from the start!)

If you have any questions about Easy Steps to Improve Page Load Times, please ask and I'll answer in another article or post!

Kimberly Blessing

In Control Orlando

1 min read

In Control OrlandoIf you're planning which conferences you'll attend next year, be sure to look in to In Control Orlando, a Web Design Workshop Conference, being held February 22-23 in Orlando, Florida!

I presented at In Control Cincinnati this year and thought it was great. As a presenter, having only 60 minutes to relay your information and message can cause you to rush -- but the workshop format lengthens each talk to an hour and 45 minutes so there's plenty of time for taking it easy, giving demos, and answering questions. I think that makes for a much better experience for attendees, too -- no more furious note-taking without ideas sinking in!

As for the presenters, you'll be learning from some industry leaders: Jared Spool, Ethan Marcotte, Kelly Goto, Stephanie Sullivan, and Christopher Schmitt. (Nope, sorry, I won't be there... and I'm kinda jealous, because I'd really like to see these folks speak!)

Interested? Want to get $50 off the registration price? Use this discount code: INCKIMB

Kimberly Blessing

Planning for and Managing Browser Support

1 min read

With a flurry of new browsers hitting users’ computers and mobile devices this year, everyone involved with the Web has had to scramble to ensure that their sites are compatible with the latest and greatest. This has left many Web professionals and business teams wondering, “What browsers should my site support?” Kimberly Blessing helps you answer that question.

Read my article at Peachpit and let me know what you think! And stay tuned for my next article on optimization...

Kimberly Blessing

Craftmanship can change the world

2 min read

Most mornings, I hit the Starbucks near work for a double tall non-fat no-whip cinnamon dolce latte. Yes, it's a mouthful to say. And apparently it's a really tough drink to get right... at least for the morning crew at this particular Starbucks. Despite seeing the same crew regularly, I almost always have to correct them on some aspect of my drink that they've screwed up (espresso shots sat too long, wrong milk, wrong size drink, scorched milk, etc.). When I do point something out, rather than get an apology, I'm usually given some excuse as to why it's not right. I'm starting to suspect that either they're making my drink wrong on purpose or they just don't care about their craft -- but in either case, they send a clear signal: a job's a job, and they don't care about theirs all that much.

Web developers can't have this attitude. We absolutely must care about our craft and continually ensure that our work is demonstrative of best practices (both industry and our own signature practices). Sloppy execution of our work leads to cross-browser problems, inaccessible features, confusing user interactions, and time lost refactoring code in the future. We don't get to give excuses to our customers -- if it doesn't work, end users don't use the site, and clients don't pay. Messy code shows that we don't care about leaving something our fellow developers can learn from, and it demonstrates that we don't care to take the time get our code right.

I shudder to think about the kind of code the baristas at the local Starbucks would write, were they developers. If only they could be more like so many of the awesome developers/craftspeople I know... then I'd be happily caffeinated each morning. And if fewer developers wrote code the way those baristas make drinks? Well, the Web might just explode from all that awesomeness.

Kimberly Blessing

How do you define/defy "best practice"?

1 min read

Cross-posted from The Circle of Standards:

Since the practice of setting and managing standards is as much a management concern as it is a technical concern, I spend time reading a number of business blogs. The HBR Voices blog is full of important management insights.

A recent blog post, How Are You Defying "Best Practice"?, was particularly insightful. Although the article was referring to business and management best practices, it just as easily could have been about design and code best practices.

The only difference is that, while the business world has well-documented and well-established best practices (most commonly taught in MBA programs worldwide), the Web design and development world doesn't yet have that common set of agreed-upon best practices. What one designer or developer considers a best practice may be contrary to what another one believes.

This leads me to the question of how do you define what is an industry best practice? And, how do you defy those best practices, if at all?

Add your two cents