Skip to main content

Kimberly Blessing

Kimberly Blessing

Mandatory Reading for Evangelists

1 min read

Whether you're advocating for Web standards, design patterns, social media, or any other cause or group of people, certain basic principles apply. I think these two resources should be considered mandatory reading for evangelists of all sorts:

  • The Developer Evangelist Handbook by Chris Heilmann explains what a developer evangelist does (definition could apply to evangelists in other technical arenas) and provides instruction and recommendations how to best fulfill this role.
  • For when times are tough, also read 5 Tips for Stranded Evangelists. The recommendations here will help you work your way out of difficult scenarios when it seems that you're alone or everyone is against you.

Read any other good evangelism resources lately? Mention them here!

Kimberly Blessing

How do you define/defy "best practice"?

1 min read

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?

Kimberly Blessing

CSS & Troubleshooting IE6

3 min read

This past Saturday I gave my CSS Summit presentation on CSS & Troubleshooting IE6. Feel free to download the presentation slides to check out what I covered!

In the chat room, a number of questions and comments came up regarding the use of CSS hacks to address IE. I don't know how many people were in the camp of "all hacks are bad, all CSS must validate!" versus "who cares, use all the hacks you want", but I was put on the spot and asked for my two cents. I said something to the effect of, "Aiming to write CSS which validates is a great goal and perfectly achievable on your personal site, but when putting together a site for work or for a client, especially a large site, you may find that using hacks is easier to write and read, and will scale better over time -- so long as you plan a way out." I think that resonated with some of the folks in attendance, who have always felt that to honor the Web Standards cause, a developer always had to follow the best practices and have valid code at all times.

So, just to reiterate, no, you don't have to have valid markup and style sheets all of the time. In fact, there are times where you'll intentionally code something not valid -- whether it's the use of the target attribute for an anchor to make sure a link opens in a new tab/window, or whether it's the application of a hack in your CSS, so a future developer doesn't have to look through multiple CSS files to figure out what you did. I think this is perfectly acceptable, provided you execute the hack consciously. At almost all of the large companies where I've worked*, we've had to use hacks or deliver non-valid code. It's just a fact of life. It's what you know about your non-validating code, what you plan for**, that matters.

*At PayPal, we attempted to maintain separate IE6 and IE7 style sheets, called with conditional comments; this caused developers to have to write additional CSS in many cases, as the CSS architecture included a global CSS file, one or more product/flow/page-specific CSS files, and then these IE-specific CSS files. Due to the cascade, overwriting one style in the IE-specific CSS file sometimes meant writing additional lines of CSS to restore a style -- unless you could ensure that tweaking selectors in the other CSS files to make them more specific would be a better fix, without breaking any other pages... perhaps you see where I'm going with this? With over 100 developers potentially working on a bit of code, decoupling IE-specific styles created a nightmare situation, which inline hacks would have solved in a way that would have been easier to read and easier to maintain.

**On the other hand, at CIM, we have no coding standards (yet), so each developer appears to be addressing browser-specific issues in whatever way they want. I've seen multiple hacks used in our code and backing them out later is going to be a major challenge. When you do use hacks, make sure everyone on the project/working on the site uses the same ones!

So, with that, you have my permission to use hacks and write non-validating code -- just make sure you have a good reason for doing so, in case someone comes asking why you did it. 'Cause I won't back you up if you don't have solid justification!

Kimberly Blessing

NYPL Style Guide

1 min read

More tutorial than strict style guide, the New York Public Library Online Style Guide contains information on XHTML and CSS for those developing pages that are part of the library system. Although written in 2001 (with the help of Carrie Bickner-Zeldman), all of the information is still relevant today.

NYPL continues to refine their best practices and processes, of course, and you can follow their progress on the NYPL Labs blog.

Kimberly Blessing

Hypertext Style Guide

1 min read

Started in the "early days of the web (1992)", Tim BL's Style Guide for online hypertext is still a great resource.

Some of my favorite bits:

  • "If you are a person responsible for managing the information provided by your organization, you have to balance the advantages of a 'house style' with the advantages of giving each group or author free rein. If you end up with decisions in this area, it is as well to write them down (not to mention put them on the web)."
  • "Always use heading levels in order, with one heading level 1 at the top of the document, and if necessary several level 2 headings, and then if necessary several level 3 headings under each level 2 heading. If you don't like the way heading level 2 is formatted, fix it on your client, don't just skip to heading level 3."
  • "Have fun with style sheets. Also, within a company or a series of publications, use them to establish conventions which tie a given look to documents of a given status."

Kimberly Blessing

Working with the Not-So-Tech-Savvy

2 min read

Maybe it's the co-worker who sits next to you, or perhaps it's your boss. It could be a new client. And, invariably, someone in your family qualifies. That's right, they're the not-so-tech-savvy you have to deal with. How do you get them to understand you so that you can communicate and work together effectively?

Web Worker Daily provides 10 tips for working with the computer-illiterate, ranging from the obvious (avoid jargon and be patient) to smart strategies you may not have figured out yet (introduce new technologies gradually, talk results instead of process).

Two things that aren't mentioned in the article but deserve emphasis:

  1. Don't talk down to the person or treat them like an idiot. First of all, no one deserves being talked down to. Doing so is going to make you look bad and it will make future communications even more difficult. The person you're talking to could have a Ph.D. in some other field and simply may not have the background or experience to understand you without more explanation or context.
  2. Take the time to educate. I had a boss who was very results-oriented. When I was able to demonstrate the ROI of Web Standards in an effective way, he wanted to understand more. Over the course of a few months, I helped him learn some HTML and CSS, introduced him to our publishing tools, and gave him a copy of Zeldman's Designing with Web Standards, which we discussed at length. Didn't my boss turn around and become my biggest supporter and advocate to more senior management? And all it took was my investing in his education. Think of what educating a co-worker or client could do for you -- relieve you of that constant headache from one-off questions? Stop you from rolling your eyes after every interaction? Maybe the payoff seems small, but the mutual growth is worth it.

Kimberly Blessing

Coding HTML Emails

1 min read

Coding HTML emails is rarely regarded as a fun task, but these articles may help take some of the guesswork out of the task.

Sitepoint author Tim Slavin offers four steps (each with many details) to coding a better solution in How to Code HTML Email Newsletters.

Campaign Monitor provides an updated Guide to CSS Support in Email Clients for 2008. Their matrices thoroughly detail CSS support in both desktop and web clients, 21 in total.

Kimberly Blessing

Standards Suck

1 min read

Standards Suckis a podcast show/blog by Anne van Kesteren, Marcos Caceres, and Lachlan Hunt.

So far, the topics covered include WCAG 2.0, the Selectors API, and ARIA in HTML5. However, they haven't explained why they think that standards suck. I guess we're supposed to gather that from the complexities of what's discussed.

Kimberly Blessing

CSS Selector Performance

1 min read

Jon Sykes has investigated the performance of child selectors in a series of tests. Read Part 1, Part 2, and Part 3.

While his findings show that type and class selectors are rendered more rapidly than descendant and child selectors, the example files are (necessarily) exaggerated in order to demonstrate the performance impact.

I'd like to see a well-coded, real-world example (one which balances type, class, and ID selectors with descendant and child selectors) vs. an example that exploits the use of class selectors (and is probably less efficient over all due to excess code) -- I would guess that they'd perform about the same. And, as pointed out elsewhere, the well-coded solution will be easier to maintain in the long run, which would well be worth the extra milliseconds on the client.