CSS: On Risk-Taking, Mirroring, Layouts, Resets, and Hacks

Jens O. Meiert, August 24, 2011 / December 14, 2011.

This entry is filed under Web Development.

A collection of CSS-related posts I published on Google+. I don’t exactly know how to deal with those yet.

Risk-Taking

It’s not possible to exercise proper code hygiene and maintain good code health without keeping house, and keeping house means taking risks.

This is particularly true for CSS in complex environments (several sites, several locales, several templates, several developers, several variables) in which you know but one thing, namely that you have no clue: how are your style sheets really used (and where, and by who, and, sometimes, why)?

Contrary to what feels like the next logical step the biggest mistake then is to shy away from proper maintenance. There is nothing more threatening to code efficiency, hygiene, and health than a complex environment (well, or a fearful lead developer).

It is important to take risks. You have to probe projects and check what is really needed. Don’t be afraid of breaking things if it can be for the long-term benefit of the project (remember it’s easy to roll back a CSS change). Just getting the job done may make you a good subordinate but not a good web developer.

What you get when you don’t take risks are higher level problems like poor performance and manageability, then hacks like versioned style sheets, and sometimes, in disguise, stuff like user agent and feature detection or “compiler” tools (they can but sometimes only appear to be BFFs).

What you can do when you do take risks is focusing on mitigation: Make sure the HTML is right in the first place (ground rule). Keep at least one communication channel open to inform about and clarify on CSS updates in advance (it’s a whole different story then if nobody listened). Offer fellow developers time and tools to test, and also a way out for exceptions (isolate those, don’t have them drag you down in your core style sheets).

Mirroring

A quick tip on managing major updates in heterogenous, complex environments.

Test, normalize, and QA your CSS update. (As we know, and always do.)
Take a diff and “mirror” the changes to come up with old.css and new.css (these style sheets only reflect differences). Mirroring means that both style sheets use exactly the same properties: for something you removed you simply set a declaration that uses the expected, now possibly inherited value.
Pre-launch: use new.css to, for example, create a bookmarklet—you read about that already—to then propagate for testing.
Post-launch: use old.css to create an emergency escape in case things go wrong (typically because of however motivated style sheet overwrites or use on pages that better applied a custom style sheet) and can’t be fixed immediately. That style sheet is your trump card. Again, only for emergencies and for temporary “local” use.

This is obviously the short story. The approach has been proven invaluable in a number of complex projects: you don’t need it in single project, single locale, single player mode.

Layouts

For what feels like 20 years have we managed to create page layouts with positioning and floating alone. In the near future will we have 20 different ways to do so.

There’s quite something to add about how CSS 3 addresses design and development needs however for a good taste of how much abundance the future will offer see e.g. Mr Gasston’s article on CSS layouts.

The number of options may get limited again to reduce redundancy but look forward to a lot of debates around what template/layout/grid approach to use when. I will not spare you from those either (but obviously with more detail in this brief update).

Resets

It’s no news that I’m a critic and consider them utter nonsense: see outdated Why “Reset” Style Sheets Are Bad and also my Reset Style Sheet Exposer extension. However, if you absolutely, definitely, undoubtedly want to use a reset then rather consider writing a new and true one from scratch than using an existing one as no known reset appears to be complete.

For the purpose of writing a true reset I suggest to normalize all the user agent style sheets out there—mmh, no overview but that UA style sheet article—and “reset” everything these style sheets do.

Don’t do it though. It’s not worth it.

Hacks

We all know it’s tempting to address styling differences over user agent detection or special CSS filters, workarounds, and “hacks.” Both detection and hacks should always be considered last resort though in order to achieve and maintain an efficient and manageable code base.

Avoid giving detection and hacks any kind of free pass as they hurt projects in the long run as projects tend to take the way of least resistance. That is, allowing and making it easy to use detection and hacks means using detection and hacks more frequently. More frequently is too frequently.

What to do instead? Always look for alternative styling solutions. More often than enough there are several ways to do something in CSS.

As I said in one of these posts, there is a whole lot more to add: this is what makes web development so exciting. Don’t we love it.

Enjoy the most popular posts, possibly including:

Comments

On August 25, 2011, 17:20 CEST, Bruno said:

Hi Jens,

What do you think about the normalize project? Seems that you prefer “normalization” instead of the “reset all” approach, so do you think that this a good starting point?

Best,
B.
On August 30, 2011, 1:13 CEST, Jens O. Meiert said:

Late: when talking about “normalizing” I only refer to normalizing all the different default styles. Paul pointed me to normalize.css but it did not change my take on “reset” style sheets. I can see a point in “neutralizing” styles inherited from other sources but that’s a different animal (with a different, “!important”-heavy solution).

Unfortunately, comments are closed.

Jens Meiert