To Be Clear (on Conditional Comments and Resets)

Published on August 24, 2008 (↻ February 5, 2024), filed under Development (RSS feed for all categories).

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

Jens Oliver Meiert, on November 9, 2024.

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, 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. (Please be critical, interpret charitably, and give feedback.)

Comments (Closed)

On August 24, 2008, 10:51 CEST, Louis said:
Very wise post Jens.

I wonder though about your opinion on Reset stylesheet. It’s not hard to imagine that in a close futur, we will be able to use automated tools to compress stylesheets by overwritting rules that has the same selector, the way the browsers do.

In that case, a reset stylesheet would not add any weight to the final file; it would only be a nice way to work truly from scratch, without having to remember the default stylesheet that comes with each and every browser, already on the market or to be released.

Also, event that at the present time, we have not such automated tool I describe, I can’t imagine myself styling a page without *{margin:0;padding:0}.

So here my point is that, talking of long run, wouldn’t it be necessary to consider the technical improvements the CSS world will probably go through?
On August 24, 2008, 10:55 CEST, Kroc Camen said:
A Reset is just an advanced
```
* {margin: 0; padding: 0; border: 0;}
```
except it works around <input>s.

It means you can code from 0 and know your browsers are going to be more alike and not have to deal with your ULs working in one browser, but not in others.

Sure, using them verbatim without knowing what you’re doing is ill-advised (Especially wasting a whole HTTP request just for that), but then no browser is perfect, so therefore neither can our code be.
On August 25, 2008, 12:21 CEST, Andrei said:
Why place the conditional comments in another stylesheet?

It’s quite simple to apply:
```
div#main {}
/* IE specific for div#main*/
div#IE6 div#main{}
div#IE7 div#main{}
/* end of IE specific div#main */
```
all in the same stylesheet.

Sometimes you really need to use specific targeting, and compromising your design for the sake of avoiding the use of conditional comments is the “lazy way out” IMHO.

If anything, Apple themselves use CC’s on their site. For a multi-billion dollar company that has a strong interest in the web to use them must speak volumes about their “maintenance”.
On August 25, 2008, 12:36 CEST, Andrei said:
I’ve also re-read the past article you referred to.

I still fail to see how conditional comments pose a maintenance problem. When IE8 is released, there is no need for you to update your past code. What for? If you specifically targeted IE6 and 7 (and did not use “gte” or “lte”), then there is no “maintenance” to speak of. If IE8 screws up your website, but your website works fine in FF and Opera, then conditional comments will actually save your life - because the update you would need to write would be for IE8, which is to be expected, given MS’s track record. Could you imagine having to rewrite ALL your code because of IE8? If you had CC’s there in the first place, the only adjustments you would have needed would be for IE8.

And please do not say “but if your code works on all browsers…” - that is a rubbish Utopian dream. Blogs are simple enough to work on all browsers, but when your website requires far more complex layouts (such as flexible containers, several z-levels, and absolutely positioned objects), there is no choice but to swallow the CC pill.
On August 25, 2008, 13:16 CEST, Jens Oliver Meiert said:
Louis, thanks; as for tools, well, I think that quite a few companies use some scripts to compress, merge, or do other things with their style sheets. Merging style sheets is not trivial though as this can very well mean layout issues due to its impact on the cascade, mostly due to changes in order.

Kroc, I guess there are several types of resets, e.g., the margin and padding reset, Eric’s reset, or resets probably yet to be created that reset all user agent styles. The reset type in use is interesting, but important is probably how it’s being used.

Andrei, how can’t you place CC in another style sheet? Your example doesn’t use them. And, going for a simple reply, font elements don’t need to mean a maintenance problem, either…
On August 25, 2008, 14:02 CEST, Rafael Madeira said:
Every time I see someone talking about how one of the downsides of doing this or that with the CSS is that they might have to *gasp* alter the HTML at some point in the future, I have to wonder if they’ve ever actually built a website.

In close to 10 years working in the field, I’ve never worked on (or even seen) a case where the site in need of an “aesthetic” redesign didn’t also call for a complete structural overhaul, save in cases of personal websites where the designer just feels like updating occasionally and, more frequently, is up for a challenge.

In the particular case of Conditional Comments that you’re arguing, the damage can be as overwhelming as running the risk of changing a whopping one line of code sometime in the future. Surely there has to be a better way.

Unfortunately, separation of content and presentation is, at this point, still a myth (look that up). You must know, not fear that you will need to modify your HTML countless times while creating or updating the templates, and that you are very likely to get back to it for minor, unexpected edits some time after you’re “done”.

And those who have to crank out websites on a frequent basis know better than to sweat over the “ethics” of it, if you will. They know it is a part of life. Instead, they create practices to simplify their workflow. Practices such as CSS Frameworks, CSS Resets and Conditional Comments.

“What then makes me recommend not to use them at all – precisely, ‘a novice should not use them, an expert would not use them’”

The first reset to be made popular and shine light on the subject was devised—and just recently updated—by a person who can safely be considered an expert.

“… once you have to customize a reset, there might be no real advantage anymore; the time spent can be used to go for the “real” style sheet instead”

Unless you’re revisiting a reset because you realized that your actual usage doesn’t really reflect what’s there, and you intend to make permanent changes that will save time or mental load down the line, “customizing” a reset is missing the point entirely.

Using a reset is creating a blank canvas that you can then build on top of. If your reset says “border=0″ but for this particular job you need “border=1″, you don’t edit the reset. You create a new rule and overwrite the reset. You spend time on the real stylesheet instead.

And for those who go “well, then what’s the point of writing something you’re just gonna overwrite anyway”, the point is that, more often than not, you don’t overwrite the whole thing. But, most important, it’s one more step towards cross-browser consistency. You can just write CSS and later check in a lot of browsers and everything is pretty much the same, the inconsistencies much easier to pick out.

Which, although possibly OCD (but designers are frequently neat-freaks anyway), feels much better than coding primarily for one or two browsers, and then checking it on 4 or more when you’re done only to find that somewhere down the line things started going wrong for one or three of them, and you’re not sure where to start.

So I’m sorry, and it’s nothing personal, but I can only fathom criticisms like this (and you’re not the only one making them, Jens, so it’s really not personal) from people who match the following criteria:

1. Don’t need to deliver coded, functional websites on a frequent basis;

2. Have way too much time to spend on nothing interesting at all;

3. Has a very high tolerance for mindless, repetitive manual labor;

4. Have poor interns doing the actual manual labor for them, so they can brag on the internet about how you don’t see any need for it;

5. Are even more of a neat-control-freak than people who employ these time-saving, mind-relieving methods, having an unshakable need to code it all by hand;

6. Are letting some ideology get in the way of reality (and productivity);

7. Any combination of the above.
On August 25, 2008, 14:25 CEST, Jens Oliver Meiert said:
Rafael,

In close to 10 years working in the field, I’ve never worked on (or even seen) a case where the site in need of an “aesthetic” redesign didn’t also call for a complete structural overhaul,

and, nothing personal, either, that seems characteristic for people who may miss the vision behind separation of document structure and presentation.

There’s nothing mystical about separation of structure and presentation, and it works (a larger commercial example I can think of is German test.de, CSS-redesigned in April). Apparently only experience can debunk this myth though—which is not possible when sticking with “excuses” or other people’s views, on why all the presentational stuff is still necessary or must stay within the HTML as is.

Great stuff. Thanks for sharing your point of view!
On August 25, 2008, 15:19 CEST, Nacho said:
Although I find Eric Meyer’s Reset Styles cool and helpful, I actually feel that the vertical-align:bottom;
used in the reset actually gives mor problems than the one it solves.

Is actually necessary that atribute?
On August 25, 2008, 18:09 CEST, Duluoz said:
As someone who obviously can not be an expert, cause I’ve only been developing websites for a few years, I find it extremely troubling that I have no issues separating presentational and structural code. Maybe if I were an expert I would see my naivety and mix the two with ease? Maybe I live in Utopia Land? 😉

I am of the same opinion as you Jens when it comes to both resets and conditional comments as you well know from previous comments.

I also I do not buy the argument that one must use a framework to get work completed more quickly either. As someone who is constantly creating new sites both large and small, I’ve yet to say to myself, “I sure wish I had a framework and reset so I could spend time customizing it to fit my needs”. Whatever works for you though is great. But while you’re wasting time customizing, I wrote a custom style sheet, finished my work, and am outside playing. 😊

Call me a perfectionist, but to me, do it right (with the obvious caveats), or don’t do it at all. On the other hand, I’m glad there are people out there not willing to put in the work to create quality, highly maintainable websites, to keep others who will in business.
On August 25, 2008, 23:31 CEST, Andrei said:
Jens, to answer your question:
(pardon the bad syntax - I didn’t want to lose anything, and I don’t have much time atm).

I don’t use conditional comments in this sense:
```
[target IE CC]
   [new IE specific stylesheet]
[/close IE CC]
```
You can, in fact, approach it like this: (which is what I use)
```
[html body element tag]
[target IE 6 CC]
   [div id="IE6"]
[/CC]
[target IE7 CC]
   [div id="IE7"]
[/CC]
     regular content
[close IE CC]
   [/div]
[CC]
[/html body element tag]
```
What this does is basically create a new parent container div depending on which IE you wish to target. So, for example, your CSS only needs tweaks for IE6, only the IE6 parent div loads, and you can target IE6 in the same stylesheet, as such:
```
/* normal div */
div#main {}

/*IE6*/
div#IE6 div#main{}
```
and because all the other browsers ignore the divs that are inside the IE CC’s, there’s no need to readjust anything for the working browsers and thus, you only use one style sheet.

Anyway, my explanation is rubbish, so here is a link to a much clearer one.
On August 26, 2008, 6:37 CEST, Evan said:
I typically use a less than IE7 Conditional Comment to include IE6 png Javascript fixes. I agree with you on the point that you shouldn’t necessarily deliver a separate IE stylesheet, but feel like using conditional comments to fix transparency issues for IE6 is a rather needed practice due to the poor support.

Also agreed, is that you should almost always customize a CSS reset and not just include it untouched. Overwriting the default browser CSS, and then resetting the CSS, and then adding CSS to format elements the way you want them is a terrible practice.
On August 26, 2008, 12:06 CEST, Louis said:
Andrei’s technique is really interesting. Using CC on the body element in particular would allow to distinguish a page loaded in IE6 from a page loaded in FF.

That’s very clever. I wonder what Jens think about it.
On August 27, 2008, 10:32 CEST, Jens Oliver Meiert said:
Nacho, it appears Eric is using the declaration vertical-align: baseline;, which should work fine; however, personally, I often use vertical-align: top; when dealing with tables—something that may help in your case, too?

David, glad to hear that, not just that we talk the same language 😊

Andrei, okay, got it. The issue remains though, or let me ask how that does not affect maintainability in terms of avoiding HTML changes? How would you deal with Internet Explorer 8, or with the situation when IE 6 disappears? Wouldn’t that require HTML changes? Apart from that, talking ID/class semantics, is that document then an “IE6”/“IE7”/“IE8” document, changing its supposed meaning without changing its function or content? I hope you know what I mean, I just don’t recommend keeping user agent information out of the document but rather focus on bringing the probability and necessity of HTML changes down to an absolute, the unavoidable minimum.

Evan, thanks for dropping by; as for the PNG issues, well, I did use child selectors in the first, 2005 edition of my CSS book (released before IE 7) to address this problem (using GIF background images as the default, and offering PNGs for browsers that happen to support both PNG and child selectors), see e.g. the first photo gallery (and its tape-style stickers). This is considered a “hack” (even though it’s perfectly valid CSS), yes, however, once there are problems you can easily change the style sheet.

Louis, I hope I shared my thoughts in an appropriate way, cheers 😊
On August 30, 2008, 0:36 CEST, Rodrigo said:
I use Meyer`s reset and it saves me a LOT of time and kills most of the pain in handling cross-browser issues. I could say that I can`t live without it 😁

For CCs, I have a single rule for the entire website. I define a stylesheet for IE 6 and place it in my master template, so there`s no problem to mantain it.

I don`t like IE hacks at all. I hate them. I prefer using another stylesheet just for the IE 6.
On my last project, the IE6 SS had only 5 selectors, in order to fix some positioning.

I think the point is whether you can develop your SS efficiently, so you don`t have to add workarounds for odd behavior.
On May 27, 2009, 0:21 CEST, Olev said:
I think using hacks is a bad idea. If a new Internet Explorer version comes out, then the hack might not work anymore and you would have to invent a new hack (for all of the sites and perhaps really fast!). That might not be possible, especially if you used several different hacks. This is what I would call a maintenance nightmare. On the other hand, CCs would target the correct versions (and using ‘lte’ syntax, perhaps if the new IE version is better at CSS support, you wouldn’t have to change anything at all). CCs are usually in the template or header/footer, so it’s easy to change the code - it is included from1 source. So I don’t agree with you about the maintenance issue.

Also, I think you’re talking about minor cosmetical redesign when you say there should be no need for changing the (X)HTML code. Bigger redesigns usually include changing the structure also. The separation of structural and presentational layers doesn’t suggest you shouldn’t change one if you change the other. And redesigning a site doesn’t mean that you’re redesigning only presentational layer (perhaps you don’t need some section of the site anymore or need some additional elements).
On November 6, 2009, 13:15 CET, Jacob Rask said:
In a new redesign/-code, we are considering using a conditional comment for IE6, loading a specific style sheet. Then in a year or two, we will hopefully be able to remove that entirely without doing any extra changes to any code.

@Andrei: That is an interesting approach. Quite often IE might need an extra wrapper anyway.

However, I sometimes find myself having to use non-standard CSS like zoom: 1; in IE stylesheets. I accept using non-validating CSS in ie.css but not in my main CSS files.
On January 27, 2010, 10:05 CET, kristof vandommele said:
I’ve been using a system comparable to Andrei’s since early 2008.
I found that maintaining add-on css-files for IE wasn’t very productive, so I rethought the way I used to target different IE-versions.

After the body-tag, I include a couple of cc-spans with the respective IE-version as an ID. These spans get closed right before the /body.
```
{body}
    {if IE 6}{span id='IE6'}{endif}
    {if IE 7}{span id='IE7'}{endif}
    {if IE 8}{span id='IE8'}{endif}
....
   {if IE}{/span}{endif}
{/body}
```
In my CSS-files, I can now keep all rules together, which is a lot more comfortable when developing and testing.

Example:
```
#header{margin-top: 5px}
      #IE6 #header{margin-top: 7px}
      #IE7 #header{margin-top: 6px}
```
With this system, I don’t need to rely on hacks anymore for any IE-version (e.g. !important).
When revising stylesheets months or years later, I can quickly see where and what I fixed for which IE-version.

I would have liked to make the body-tag conditionnal, but it gets messy sometimes working with content management systems, so I never bothered.

I’m actually surprised that in 2010 a lot of developpers still work with separate cc-served stylesheets.
On May 13, 2012, 11:09 CEST, scutterman said:
I came here after searching for opinions on whether it’s a good idea to use CC stylesheets, and I believe that the way I’m using them isn’t completely against what is said here.

I am currently working on a template for a site, and I needed to add in some hacks for inline-block for IE 7. I decided to add these hacks into a second stylesheet so that the compliant browsers wouldn’t have to deal with them, and also so that they don’t have to deal with the extra bytes in the file that they completely ignore.

I will still have the problem that, if I decide to change the inline-block status of the selectors using it, I’ll have to make the changes in the CC sheet as well, but this seems like a minor price for not introducing hacks unless they are explicitly needed.