High Performance CSS code design

In the last few years much emphasis has been placed on web performance issues. Browser vendors have optimized JavaScript engines, JavaScript libraries have been honed, and content delivery has been improved. Unfortunately, CSS has received less attention. Developers have been advised how to optimally transfer CSS files, and instructed to use CSS shorthand, but very little has targeted CSS code itself.

Ms. Nicole Sullivan is among those looking to improve CSS code. She has been promoting “OOCSS,” or “Object Oriented CSS,” her methodology for how to design and refactor CSS 1. She has collected a number of best practices for architecting a CSS framework. The benefits are simple: CSS will perform better, become more modular, as well as being grounded with a consistent API, making it easier to learn and use. This is accomplished by reducing the file size and complexity of our CSS.

While many of these techniques can be considered common practice for experienced CSS programmers, implementing them can be difficult. The art is in analyzing trade-offs and picking the optimal path. That said, these rules are not for everyone, or every site. It all boils down to deciding if the site’s performance gain is greater than the time it takes to learn and use the techniques.

Useful for sites with

• Many pages
• A common visual and structural design
• Critical performance requirements

Less useful for sites with

• A few pages or just one page
• Varying design (possibly “portfolio” or design sites)
• Few performance concerns

So how do we get started? We go hunting for bad code smells. In Chapter 3 of Refactoring: Improving the Design of Existing Code, Martin Fowler and Kent Beck coin the phrase “code smell,” meaning “structures in the code that suggest the possibility of refactoring.” Simply put, we go looking for chunks of code that our intuition tells us could be cleaned. In the chapter heading, Grandma Beck is quoted (then talking about child-rearing), “If it stinks, change it.” We’ll take a more formal approach to finding these code smells, going from easy to difficult. First, we’ll sniff around the CSS selectors, and then move onto the CSS properties. Finally we’ll look for visual design patterns that can direct the structure of our CSS.

Selectors

Selectors are both the easiest place to find code smells in CSS and the easiest to correct. Three big code smells tend to stink up CSS selectors; unused selectors, location-based selectors, and overly specific selectors. Each contributes significantly to increased CSS file size.

Using the label element for form accessibility

I’ve always been a fan of the <label> element. It’s an incredibly simple way to make a form more accessible. It does two things:

• It explicitly associates text with a form element, so a screenreader doesn’t have to guess what text goes with what form element.
• For checkboxes/radio buttons, it gives the user a larger click area, which is useful for people with limited vision (or me, since I always end up missing them!)

You can find a number of simple usage examples on the W3C’s WCAG Techniques page for labels.

I recently discovered something new about the <label> element (new to me). I hadn’t realized that you can associate multiple labels to one form element. This is useful because it allows you to associate even more information with a form element. With it, I could write something like this:

<label for="box">1. </label>

<input type="checkbox" id="box"/>

<label for="box">This is some text with a 

<abbr title="full title name">shrt. title</abbr> other stuff inside.</label>

This isn’t the most useful example, but I think it demonstrates the general idea. [Note: normally, I wouldn’t write out an explicit number, I would use an unordered list. But without major support for CSS counters, I find myself between a rock and a hard place.] My optimism was quickly quashed though, because, as Roger Johansson mentions, screenreaders tend to ignore two labels. I will have to do some of my own testing to find out more, but I find this very disappointing.

Another interesting application is to include labels for screenreaders, while using CSS to hide them from visual users. Just make your label a block element, give it a 0 width (to remove the width it would have taken in the document flow), and move it off-screen. You cannot simply display: none the label, as that usually hides it from screenreaders. I would like to look further into the end result using current technology (hoping for improved results since 2004), but I certainly believe this leaves no excuse for anyone NOT including labels in their forms.

Back to using one label again, I ran into a Firefox Bug where a link is included in a label element. When a link is clicked inside a label element that is associated with a checkbox, the checkbox becomes checked! Hit the back button, and the item will still be checked, with the visual check the only evidence anything happened. You can see how this would not be friendly to a screenreader (not to mention visual users!) IE and Opera both behave without checking the box. If you have a moment, please vote for this bug and help me get it fixed.

Big release day on the webbernet

So I guess it’s simply the time of year. Many big releases today… software, APIs, and more!

First, the biggest. IE8 has been released in initial beta. The release was also included a general overview of IE8’s new features and fixes. It’s actually quite a lot of information to absorb all at once. I’ve skimmed a number of the IE8 whitepapers, and feel the biggest changes are W3C’s WIA-ARIA support, Acid2 compliance, the javascript selectors api, and their assertion of achieving CSS 2.1 compliance. Of course, the devil is in the details, and there is no company for which that statement is more true. They have a lot of work ahead, and we know they talk a good game. The big upside, however, is that they are actually talking about it. Out in the open. Big step, and I applaud them for that.

The other biggest buzz of the day was from Yahoo, in announcing the beta of their Fire Eagle service, an API for broadcasting your physical location to the web. I wouldn’t call it earth-shattering, but I think that there’s a good chance a number of cool things are built with it. Watch the video of it’s introduction, and then take a look here to quickly get an idea of the details. It would appear from the details that it was written in a highly usable way.

Of more direct importance to me, Google has announced their Contacts API. I despise when sites ask me to enter my username/password for other sites. The most offensive request is for Gmail. I don’t have any interesting emails, let me tell you… but I certainly don’t want to let others read them. The Contacts API is a safe way for distribution and use of your Gmail contacts, without threatening the security of your Gmail account or your other Google-stored information. With this, I should be able to sync my Gmail contacts with my desktop mail contacts. I’m very happy about that.

Heading up the long-since-overdue category, AOL has announced they’ve opened their Instant Messenger Protocol, OpenAIM. Finally. I remember ages ago when… well, it’s all in the past now. That’s one big wall that has been broken down between protocols, and hopefully Yahoo and Microsoft will fall in line. It will be great if other apps can finally use the features that have been limited to the AIM client for all this time. I use Adium and Pidgin most of the time (Adium, I believe uses Pidgin’s core), and look forward to seeing what they do with the new open protocol. (On a personal note, hopefully this doesn’t spell any negative news for my friends who work on AIM.)

IE8, Doctype and potentially broken default behavior

I woke up this morning and read the A List Apart articles (that I defered reading until this a.m.). The powers that be have decided that IE will now use a metatag to decide what rendering type (ie6, ie7, ie9, etc.) to use. This allows for backwards compatibility. Supposedly.

First, I don’t really care about the meta. It’s fine… it is just one more trick to add to the pile. Generally, I agree with Eric Meyer’s points, that it’s better than browser switching. And it is. It’s also better than conditional CSS comments.

There are a few problems that I see, however. The first one was actually thrown into my lap as a twitter discussion between Jeremy Keith (down-to-earth web guy) and Chris Wilson (works on IE). Following the twitter-timeline, first, second, third. Apparently the default behavior for rendering a document with a HTML 4.01 doctype will be IE7. That’s right, it doesn’t fall through, it will be stuck on IE7. That is just wrong. Hopefully, both Jeremy and Chris and the other powers that be work that detail out further before Microsoft proceeds.

My second worry is the case of “edge.” Edge, as far as I am concerned, stands for bleeding edge, and that implies an experimental version, where results will be unpredictable. (I infer that definition based on every other software release that I’ve heard of.) Hopefully that’s not the case, but there sure as heck better be a concrete definition of what they consider “edge”. Hopefully they’ll throw a “current major version” in there as well. Who knows.

The third, and probably largest concern that I have, is that we are now relying on Microsoft to include past browser rendering attributes into current browsers. So IE8 should be able to render all of IE7’s quirks, as well as IE6’s quirks. Based on the fact that Microsoft had a hard time fully flushing out all of the CSS standards for so long, whats to say that that they’ll accomplish this in full. Additionally, there are the worries that including past rendering attribues will yeild the “bloatware” that Eric mentioned.

And finally (at least for today) there’s the mess of doctype and meta. Now you get to define things in both places. It’s just sortof kludgy. One more thing that I have to memorize, and I hate memorizing things.

Anyway, it’s Day one of this stuff, and there will be much discussion to come, and I’m guessing a lot of other stuff as well.

Another design tweak

As you might have noticed, I’ve been a bit pre-occupied recently. And likely will be so in the future. So a design for this site has once again been placed on the back burner. I am good for a tweak-ing, however.

Looks fine in Firefox 2 for mac/pc. Opera, has a small problem, I think due to a varied em interpretation (it’s different on each platform). I tried IE6, and of course, things were missing, but the design as a whole stood up. So a few “non-lazy” changes should do the trick. Having only spent 30 minutes and using :before and :after pseudo attributes, I was surprised IE didn’t send my PC up in flames.

It just occurs to me, it would be nice if I could add a little javascript (for fun, not practical usage). Not sure what I would add it to, however. Oh well, placed on my to-do list after the real design.