12 Lessons for Those Afraid of CSS and Standards

When I first encountered Cascading Style Sheets in the autumn of 1998, I was trying to do cool stuff—make this stuff over here move, make that stuff over there change color—and it took another six months before I started using CSS to control presentation rather than behavior.

It took me two years to break out of the comfortable prison of layout tables, and another two years before I could use CSS to produce layouts that were originally intended for tables.

Even though I was forced during that time to deal with such anachronistic works of art as Netscape 4.0 and Internet Explorer 5.0 for Windows, the moral of the story should be clear:  it took me a long while to achieve genuine mastery of CSS.

There are plenty of excellent books and articles out there, including many written by the contributors to this publication.  While most of those works gracefully walk the inexperienced developer through challenging layouts and teach by literal example, few of them acknowledge that using CSS to create standards-friendly sites requires a mindset that is alien to many experienced developers.  This requirement hamstrings a lot of talented people, and for two years I’ve been looking for the words that will heal their pain.

The cries of frustration I hear from other developers about CSS are only an echo of the ones I made for years.  As a result I like to think that I can relate, and I’m writing to convey the most important lessons I’ve learned so far.

Lesson No. 1:  Everything you know is wrong… sort of#section2

Just so we’re on the same wavelength, I want to underscore the fact that if you’re starting to work with CSS, everything you’ve learned to this point probably feels useless, or worse than useless.  That’s a problem that needs to be dragged out into the open and shot with the utmost speed and mercy.

Unaffected is the body of wisdom you’ve acquired on subjects like design, optimization, user experience, programming, and project management.  However, the assumptions under which you’re accustomed to applying that knowledge change—sometimes drastically—when you switch to standards-friendly production techniques.

As a result, the best thing you can do is give yourself a clean slate.  Throw out your assumptions and expectations.  For that matter, throw out everyone’s assumptions and expectations.  Roll up your sleeves and learn something new.  When it comes to layout and production, resolve to remove “but” and “should” from your professional vocabulary for a while.  Replace them with “how” and “why”—and commit to meeting your project objectives.

At the implementation level, this lesson is about the differences between table markup and semantic markup:

Finally, don’t forget that there are things layout tables can do, and then there are things CSS can do. Some of these capabiities are mutually exclusive, and this doesn’t diminish the power of CSS.

Lesson No. 2:  It’s not going to look exactly the same everywhere unless you’re willing to face some grief… and possibly not even then#section3

There are an awful lot of differences between rendering engines, and the W3C specs sanction those differences.  You can adjust, tweak, hack, and waive, but if you want to preserve your social life, you will learn to let go of the small differences—and convince the stakeholders in your projects to do the same.

Lesson No. 3:  You will be forced to choose between the ideal and the practicable#section4

Life and work often become series of compromises, especially when things are in a state of transition.  The best thing you can do to ensure compromises in your favor is to plan effectively.

From time to time, though, you can expect to encounter situations where you will be forced to choose between the lesser of two evils, or perhaps even situations where you will be given no choice at all.  Sites that are incapable of passing accessibility or validity tests will result, and you will be forced to accept those outcomes even when your contrarian assertions are absolutely correct.

Appreciate the objectives of your projects.  Acknowledge workplace politics.  Decide what is most important to you as a professional.  Concede that the decisions of others made over your objections, much less those made without your input, do not reflect on your skill or integrity a jot (though they may reflect on the wisdom with which you choose your project sponsors).  Choose your ground, pick your battles… and fight the ones you can actually win.

Lesson No. 4 (with thanks to Antoine de Saint-Exupéry):  Perfection is not when there’s nothing to add, but when there’s nothing to take away#section5

When producing markup for a standards-friendly site, it’s all too easy to stick to the table-based way of doing things and create an over-abundance of container elements.  While at first it may seem like common sense to force the markup into the design, doing so misses the point of standards-friendly production.

Don’t force anything, and don’t add markup unless context encourages it.  Focus on the information first.  If you’ve got several instances of content that share the same purpose or classification, don’t be afraid to stick them inside divs or spans that share a class named in a way that describes that purpose or classification.  If you want to put body copy inside a container element that’s common to all of your pages, most people won’t fault you.

If instead you’re going crazy with divs because you need certain widgets to be present at particular layout coordinates (or have other seemingly unique presentation requirements), chances are you’re not thinking through your design completely.  As a consequence, your markup will be even harder to maintain than the table-based markup that you’re trying to replace.

Remove tags wherever possible… while keeping the next lesson in mind.

Lesson No. 5:  Some sites are steaming heaps of edge cases#section6

In many cases, the person responsible for a site’s graphic design is not responsible for any other aspects of site implementation.  When paired with a failure to create strict site- and section-wide wireframes, this lack of accountability results in unique comps for too many pages, and thus a lot more work for the stylist and producers.

It has been this writer’s experience that such an outcome is far more common during small projects than large ones, which leads to those small projects going egregiously over budget.  I invite the reader to consider the implications of that fact.

Whenever possible, encourage the graphic designers with whom you work to respect the imperative of consistency.  If your encouragement has no effect, make sure to stick a unique id on the body of every page of the site, and enjoy the bright side:  there’s no doubt that you’ve got a living.

Lesson No. 6:  Longer lead times are inevitable#section7

Browser vendors had five frenetic years to work out a uniform and reasonably stable approach to table rendering, and that task was made easier by the fact that until Gecko and KHTML were released, most rendering engines had a great deal in common—Mosaic begat Netscape but was also licensed to Microsoft.

The state of CSS rendering technology is comparable to the state of table rendering technology in early 1998… so give it time, and test your layouts diligently in the meantime.

The good news is that the time needed to test and debug your layouts is repaid after launch by the reduced time spent on maintenance, extensions, and revisions.

Lesson No. 7:  Coherent and sensible source order is the best of Good Things#section8

If you deliver work that reads properly when styles are removed, your thoughtfulness will repay you many times over.  Such a practice carries many benefits, including:

  
• A site-wide print stylesheet replaces separate print-only pages.

  

• Stylesheets are easier to document, normalize, and maintain.

  

• Interspersal of markup and scripting on site templates decreases.

  

• Keyboard navigation of the site becomes considerably less painful.

  

• When the site is redesigned, there’s no need to rearrange the content all over again.

Lesson No. 8:  Descendant selectors are the beginning and end of genuinely powerful CSS rules#section9

When you begin the transition from table-based layout to standards-friendly production, it’s tempting not only to go crazy with container elements, but also to stick classes and ids all over the place.

Of course, you usually don’t need to.  For an example, consider an element intended to contain navigation links.  A common beginner’s mistake is to build the whole thing with divs, which offends purists because doing so makes things more difficult for users of screen readers.

Since divs aren’t the ideal solution, we can use unordered lists instead.  Screen readers accept commands to skip those. Thus, a “good” navigation element is an unordered list of links.  A conscientious developer might put an id on the list for the sake of positioning, and classes on the links, so that they can be distinguished from all of the other links in the document.

However, in this scenario, only the id is necessary.  The trimming in question is made possible by a descendant selector:

#nav a {
  color: red;
}

In English, this selector says “all links within #nav should be made red.”

Here’s a more complicated example:

#bodycopy blockquote.critical {
  float: right;
  width: 30%;
  padding: .5em;
  margin: .5em;
}

The attributes in that rule would be applied to blockquotes assigned to the class critical, but which also appear within #bodycopy.  This allows both plain blockquotes in #bodycopy and similar blockquotes in #sidebar to be styled differently, while minimizing the number of classes and ids that need to be used.

In effect, descendant selectors allow you to reduce the number of classes and ids in the markup and to keep a keener eye on context than is possible without these selectors.

When used in combination with background images and layout properties, descendant selectors make possible effects that tables can’t even begin to duplicate.

Lesson No. 9:  In the real world, stylesheet hacks will get your project across the finish line#section10

Yes, stylesheet hacks are mildly disrespectful to the intentions behind the underlying technology.  Yes, stylesheet hacks introduce the possibility of nightmares in the wake of a major change…such as the one that will take place when Internet Explorer 7 is released.  Yes, the whole subject is an uproar waiting to happen.

This writer takes an unambiguous attitude on the subject.  Given a choice between making excuses to a client about why something looks lousy in their browser or just fixing it, the latter decision settles up a pending invoice with far less pain and delay.  When used wisely and with the appropriate caveats, stylesheet hacks make life a lot easier!

Lesson No. 10:  Working around rendering bugs is like playing Whack-a-Mole#section11

By this, I mean that when a rendering bug in one browser is worked around successfully, it often results in the exposure of another rendering bug in another browser (or a different version of the same browser).  When this happens, you can expect to step back and re-examine your entire ruleset… if not your entire stylesheet collection.

The good news is that there’s usually a way out of these apparent no-win situations, most of which can be found by a properly-tuned web search.  Positioniseverything.net is an especially valuable resource in these cases.

Lesson No. 11:  When you’re drowning in CSS layout problems, make sure of the width and height of the water, float without putting up a struggle, and get clear of the problems#section12

When you’re working with columnar layouts, unpleasant surprises are common.  The best way to achieve an aesthetically pleasing columnar layout and sensible source order is to use the CSS float attribute.  However, in order for this to work well, all of your columns need to have defined widths and, in some circumstances, defined heights as well.  Without those widths and heights, the layout is rendered willy-nilly.

Additionally, you may find yourself ignoring Lesson No. 4 above in order to create the layout successfully.  However, that’s one of the compromises I mentioned—a compromise hopefully made only after you’ve tried your best to do it some other way.

Lesson No. 12:  Background images will make the difference between the plain and the tastefully embellished#section13

Thanks to the vagaries of the CSS box model, mixing proportional and fixed dimensions within a layout—in other words, attempting an elastic layout with lots of borders—is a sure way to disaster (or at least considerable grief).  However, you can create the illusion of that mixture by creating well-composed background images and referencing them properly in your stylesheets.  Self-directed experimentation is recommended, particularly with regard to the behavior of borders.

Another common task for which I believe background images are appropriate is the replacement of headings with bitmapped type.  Though arguably contoversial, the practice of combining the background-position and text-indent CSS properties makes it possible to give search engines and screen readers what they need, while also providing the high-quality visual experience for which most graphic designers strive.

For the record, naysayers should know that I’ve yet to encounter any personal computer users who routinely browse the web with stylesheets enabled and images disabled.  While that scenario leads to an intriguing intellectual exercise, I’m presently confident that it bears little relationship to the way people habitually browse the web in the real world.

In Conclusion#section14

The buzz about Web 2.0, CSS, and myriad other subjects of the bleeding edge can become a dull roar to those left ill-equipped for industry changes because of work habits adopted in good faith years before. It is my hope that the experience I’ve shared will help some folks to find a way back to the top of the heap—which is where the web needs you.