To Be Clear (on Conditional Comments and Resets)

Published on Aug 24, 2008 (updated Feb 5, 2024), filed under development (feed). (Share this on Mastodon or Bluesky?)

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

My articles on Conditional Comments and “reset” style sheets belong to the most popular articles on the respective topics not just on this site, but apparently on the Web. I appreciate the discussion, led with so much passion.

Now, it looks like I could still clarify my standpoint, so allow me to summarize my main concerns, starting with a request to take the post titles with a grain of salt: Both Why “Conditional Comments” Are Bad and Why “Reset” Style Sheets Are Bad are intentionally provocative.

Conditional Comments

The main problem with Conditional Comments is their impact on maintainability. By their very definition you have to link at least one additional style sheet from your HTML, unless, even worse, CSS rules are added within the document. For the same reasons that we avoid using font elements because they’re presentational and mean HTML changes once we want to change the layout (which means a maintenance problem), we should avoid Conditional Comments as once we want to change (or even keep) the layout when a new version of Internet Explorer ships or an old version goes, we face a good likelihood to change the HTML, which translates to an unnecessary maintenance issue as well. Using templates or “search and replace” is a weak counter-argument; one could apply it to font, center, align, and other presentational elements and attributes as well, claiming that they were not a maintenance problem, either.

There are implications for collaboration as well, and we can observe them in practice: Since CC style sheets don’t necessarily use different selectors than the “regular” style sheets, developers either have to look for the same selector in at least two style sheets, which slows them down (even when compared to “hacks,” which usually are close to related rules), or they overlook them, implement another solution, eventually run into unexpected layout problems (because the CC style sheet overrides something or does something unexpected), and maybe even introduce other code that is unnecessary. That is just a logical problem, and it’s, to come back to my “socks” question, similar to putting one sock in one and the other in another place. This doesn’t make it easier to get to work in the morning because you end up needlessly looking for one or just go for another pair, basically rendering the one you previously chose useless.

As we haven’t even talked about issues around standardization and compatibility, I hope this clarifies further. Looking for solutions that neither rely on CC nor “hacks” is best, but at least do “hacks” within style sheets, despite the implicit risks that hacks targeting “living” user agents bear, not mean HTML changes. That’s an advantage.

Reset Style Sheets

My criticism regarding resets mainly focuses on the situation when they’re used without modification (something that Eric does explicitly ask for), causing unnecessary since overwritten or redundant code. In fact, observing use of resets in the wild confirms that this criticism is just, as resets are often and actually used without edits (they’re sometimes explicitly used as a standalone, “don’t touch” style sheets).

What then makes me recommend not to use them at all—precisely, “a novice should not use them, an expert would not use them”—is that once you have to customize a reset, there is barely an advantage in using them anymore; the time spent can be used on the “real” style sheet instead, one that deserves the attention to make it as elegant and efficient as possible. This should be motivation for more than perfectionists.

(Of later reset critiques a Google+ post probably sums it up best. If you’re looking to learn when a website uses a reset, check out the Reset Style Sheet Highlighter Chrome extension.)

When Conditional Comments And Resets Are Not Bad

Conditional Comments and resets are less “bad” when they work for you. And with “work for you” I don’t just mean today, but I hope tomorrow, at the end of 2009, and at the end of 2020.

❧ When being passionate about something, I may get carried. I care, and it’s important to me to have conversations about maintainable, quality code, even if arguing for the different positions proves challenging.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve worked as a technical lead and engineering manager for small and large enterprises, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)