IE Conditional Comments: Where Have They Been?

by Destry Wion  ::  published 19 April 06    

Introduction

I’m sure there’s a small army of folks out there who have been using Conditional Comments (CCs) for Internet Explorer (IE) since they first made the scene in IE 5.0 back in March 1999, but judging from my look around there isn’t much to read about them until fairly recently in time. Granted they don’t represent the complexity of nuclear fission, but considering how effective they are (and yes, valid too) you have to wonder why there was not more attention given to CCs years ago.

In the next section I’ll present a little article research I conducted that more clearly elucidates the lack of articles I’m referring to. In later sections I’ll address some reoccuring arguments that seem to plague CCs. By looking at these arguments closer, I hope to give CCs a little boost of positivity, but even more, to simply put some light on a topic where it has been lacking for quite some time.

Quick and Dirty Google Research

My objective was to simply collect a reference list of CC articles that have been available since 1999 (when CCs were first available for use); however, the research was not intended to be exhaustive, but rather a representative concentration of CC articles/per date as they might be found by anyone making a half-hearted attempt using Google and a few keywords. I figured this was about as realistic as it would get with anyone else.

Following are a few more specifics about the non-scientific process:

1. I stopped hunting for articles on 13 April 2006, so anything published after that date would naturally not be reflected.
2. I used Google and the following three strings of Boolean logic:
   1. conditional comments
   2. conditional comments AND hacks
   3. conditional comments AND 1999
3. I tried to focus only on Weblog articles (or basic Web pages), but I did add a few forum topics to the list, as well as references to certain comments/replies of articles/topics.
4. There was a lot of overlap between the returns of each logical search, naturally, and for each search event I limited cursory scanning to the first five pages of results, as by that time the same articles from earlier pages started reappearing in the returns. Evidence suggests most internauts (Web users) stop at page three anyway so I’d say I went a reasonable extra distance.
5. In a few cases, I didn’t find articles by returns, but by following links in other returned articles.
6. Not all references had a clearly indicated publication date. (Why do people not date their articles?) In some cases I was able to pull the publication year from the reference’s URL. If a reference had no date at all, it wasn’t used in the tally, but I may have kept it in the reference list at the end of this article for your perusal.

The collected references were tabulated and grouped by date (Table 1), and represented in a histogram for additional impact (Figure 1).

Table 1: Relative concentration (counts/year) of conditional comment articles published since 1999.

Years Available	Concentration
19981	1
1999	3
2000	0
2001	0
2002	2
2003	1
2004	5
2005	17
2006 (to April)	7

¹The 1998 article seemingly represents only the second time CCs had been announced to the world; more than a year before IE 5.0’s official release.

Observations

There are some interesting things revealed in the table and graph worth noting:

1. Overall count of published articles on the topic of CCs is very small. I don’t claim to have listed every single article that exists (and in fact I knowingly skipped a few of the more recent, bandwagon publications), but one would think there would have been at least a few dozen articles on the topic in the near eight years CCs have been around.
2. Hardly anything about CCs was published in the first several years, when in fact this is where you would expect to see the majority of articles. When a new technological ability is released, people generally write about it; why not here?
3. The big surge in chatter over CCs happens a mere 7 months ago, right after Microsoft’s call to action last October.
4. Articles for 2006 are less than 2005, but since we are only 4 months into 2006, it’s very likely publications will surpass the 2005 numbers by the end of the year, if not much sooner.

All this strongly suggests that not many people who advertise themselves as designers or developers were savvy of CCs until very recently, and if you follow up with reading the articles in my reference list—as well as the follow up comments to those articles—you’ll see people admitting as much. I don’t mind saying that I’m one of the 2005 statistics in that graph; seemingly learning about CCs when and how most everyone else did. In all likelyhood, there are still many more folks out there who don’t know what conditional comments are.

I think this lack of dialog about CCs over the years is a bit curious, if not downright unfortunate. In retrospect, I can’t help but think there’s been a lot of wasted effort on hack management that might have been offset to a large degree had discussion of CCs been more ubiquitous earlier on. I’m not saying we could have done without Tantek Çelik’s pass filters to handle browsers besides IE (we certainly needed pass filters during those awkward, teenage browser periods), but perhaps between the pass filters and CCs there might have been more constructive handling of—and less whining about—IE’s inconsistencies. Curious pondering indeed.

Change is Happening

Despite what the observations might indicate, crying over spilled milk is pointless, and perhaps now is simply the better time for CCs to make their big impression. The playing field is changing, and the rules of the game will likely change with it. Consider the following milestones:

• near complete disappearance of Netscape 4.x
• the demise of IE 5 for Mac,
• the liberation of Opera,
• timely releases—and incremental improvements—of other standards-compliant browsers like our ever-loving Firefox and Safari,
• the announcement of a new IE browser, seven (IE 7), with improved standards support,
• and the newfound ability to test conditional comments across multiple IE Standalones (a huge plus for development).

Now that IE 7 is upon us, and older browsers are on their way out, conditional comments should prove to extremely useful for handling the stragglers—IE 5, 5.5, and eventually 6.

What are Conditional Comments?

Keeping it short, CCs are a kind of comment-based syntax that only versions of Internet Explorer for Windows (IE 5.0 and later) can understand. CCs are used in the markup of a Web page (they cannot be used in CSS files), and when used correctly they can direct IE browsers to do—or not do—something with respect to processing Web page markup. That’s it, and it’s incredibly useful. Not only that, but CCs validate too because they’re simply based on HTML comment syntax.

I won’t be giving you syntactic examples of CCs; there’s already good efforts of that elsewhere. I recommend the following two references to get started, especially the first one:

1. Manfred Staudinger‘s extremely bountiful article, Taming Your Multiple IE Standalones. Not only does Manfred explain how to maintain use of CCs across multiple installations of IE versions, but he provides an extremely useful breakdown of all the possible evaluations that can be gained from CCs; see section titled A Technical Discussion About CCs. (I really wish Manfred had made each section of this article linkable, because the main title itself does not do justice to all the great information it contains…maybe he’ll fix that).
2. Microsoft’s less-than-palatable, but authoritative page, About Conditional Comments.

After that you can follow up with items in my list of references at the end of this article (both references above are included in the list).

Hacks or Not?

It seems hard to get a clear bead on whether or not CCs are hacks, and the confusion may be one reason why CCs have not seen much limelight.

Peter-Paul Koch has a worthwhile page, Conditional comments, and offers that although CCs are rather unique, they are nevertheless hacks…

“...since they can serve to give special style instructions to some browsers.”

On the other hand, the definition of a hack by Molly Holzshlag in her article Integrated Web Design: Strategies for Long-Term CSS Hack Management would suggest something different:

“...a hack occurs any time we use an element, property, or other syntax within a language for a purpose other than its intended application.”

Molly’s definition of a hack, if I’m not mistaken, would not qualify CCs as hacks because when CCs are used they are indeed being used for the purpose they were intended; to communicate special instructions to IE browsers that have need of those instructions.

In the rest of this article, I’m going to take the position that CCs are not hacks, but rather valid, proprietary markup that is used as it was intended to be used, and against which all other browser types are immune. However, in another one of Peter’s pages, CSS Hacks, he points out that of all the hacks that exist, there are only three that qualify as safe (hacks that are sure to work unfailingly over time), and CCs are one of the three.

Regardless of what a person’s stance is on the matter, here is the real point: CCs seem much more utilitarian than other modes of hack management that became more popular in years past. Even now, with IE 7 looming in the horizon, many of the bandwagon Web standards advocates would still choose to use hacks to address IE bugs. Such thinking would suggest that people still don’t undestand that CCs are a much more isolated and elegant way to handle IE problems.

Why are Conditional Comments Good, and How are They Used?

Besides being an effective way of dealing with IE bugs without influencing other standards-compliant browsers, CCs are a great way to help keep a site’s main CSS file light, clean and valid, which is simplified further now that other browsers like Netscape 4.x and IE 5 for Mac are dead (if you subscribe to that notion).

CCs can be used in a couple of ways. One way is to add modified markup or style rules into the CCs themselves wherever alternate markup is needed in a given Web template. However, for those people who bother to use CCs at this point, this method is not very popular (particularly with purists). The main gripe being that it creates extra markup in the template, even though it validates just fine.

The other way to use CCs, and certainly destined to be the most popular way, is in the template head section to insert external links to alternate IE style sheet rules. The CCs can be cascaded so that rules can be written as concisely as possible. Make no mistake, this is a good use of CCs indeed, and it’s hard to believe this methodology has not gained more notariety in years past.

A Closer Look

Let’s consider it from another angle, the angle that seemed to have ruled everyone’s attention for so long (you can again refer to Molly’s article mentioned earlier for reference). The method considered to be the most prudent for hack management was to begin with your main style sheet file and import the necessary hacks into it using a combination of the @import attribute and one or more of Tantek Çelik’s pass filters, both of which are certainly hacks by Molly’s defintion as they represent kinds of syntax being used for something other than what they were intended for.

In any case, these hacks were acceptable (eventually even validating in the W3C’s CSS validator) as they enabled designers to separate the main styles from the non-validating hacks stored in other style sheet files. What people liked about this approach is that it made it easy to add and drop support of certain hacks as needed by adding/dropping as many @imports as necessary in the main CSS.

The method above was not bad for the most part, certainly better than cramming all the non-valid hacks with the standard rules in a single CSS file (an option many people oddly seem to favor), but it still wasn’t perfect; a person still had to tolerate the @import attributes and pass filters, which themselves were hacks in the otherwise clean stylesheet files.

By using CCs, one can achieve the same end result while completely eliminating the hacks (including the validating band pass hacks) from the main CSS altogether. The targeted rule filtering that the pass filters provided is now provided by the CCs, but instead of filtering rules from inside the main CSS file, rules are effectively filtered from the head of the page template, from within the CCs themselves. As a result, the main style sheet file is not only compliant but perfectly clean too, and just like before the designer can easily excise the hacks for the decrepit browsers (like when the time comes for IE 5, 5.5, etc.) by simply removing the associated conditional comment from the template header. No fuss, no muss.

The Arguments

While reading up on CCs in preparation of this article, I noticed that CCs have their share of naysayers, who generally expressed themselves in the comments of articles of other authors.

As I kept reading article after article and their associated comments I began to see that detractors generally didn’t have a full grasp of the situation (like me perhaps). I got the feeling people had just become comfortable with their newly acquired star hack skills, or whatever, and figured they had reached utopia. The following sections look at some of the more prevailing arguments against conditional comments.

Argument 1: One Style Sheet File to Rule Them All

There are many people out there who prefer to manage Web presentation from a single style sheet file. The desire for this is seemingly much stronger than having at least one main CSS file that contains nothing but valid CSS. Anyone can understand the advantages that single style sheet file management would provide (easier maintenance), but apparently that’s where the understanding stops for a lot of folks who would rather mix both hacks and valid rules to keep there one-file quota. The problem, I suppose, is that because such cheats as star hacks pass the CSS validator check, people think it’s good enough to stick with them.

Seems to me that even in a perfect world, where it was possible to manage site presentation with a single, valid CSS file across every imaginable browser, there would still be instances where having multiple style sheet files would be desired, like when a site is quite large and has differing themes, for example. Hence, this really isn’t an argument against CCs at all, it’s just an issue of personal preference. Nevertheless, I think most purists would agree, as long as any hacks are needed, a single style sheet file is simply a bad idea.

Argument 2: Can’t Use Conditional Comments in the CSS

A second argument that comes up a lot is that one can not use CCs inside the style sheet files themselves (which is true), that they have to be added to each XHTML template that needs the alternate CSS rules. Similar to the first argument, this argument comes up because people want a low-maintenance way to manage their content. Apparently the thinking is if CCs have to be added to each template, then that’s multiple instances of change whenever an edit is needed. This is a very reasonable consideration, but again, if one’s objective is to have clean CSS then I’m not sure it’s an argument. There’s a couple things to consider in the other direction.

First, remember what was covered in the earlier section, A Closer Look, which focused on moving away from adulterating CSS files, as opposed maintaining the same habit of clogging them up with hacks and filters. Apparently, people have become so entrenched in using band pass filters in the CSS that they still want to pursue that course of action, but in this case switching out pass filters for CCs. Although adding CCs to style sheet files might make your site management activities a tiny bit easier (and I emphasize tiny bit), it’s the wrong idea in the long run.

Second, it doesn’t hurt to consider that fewer and fewer sites are being developed as static anymore, and static sites are where this might even be a problem at all. In fact, the opposite is true, more and more sites are being developed on top of content publishing systems, and for the most part these systems provide the ability to recycle content from one region of the site to another, kind of like single-sourcing. For example, Textpattern utilizes a building block called a Form, which is very convenient and easy to use feature that inserts snippets of Web page code (such as conditional comments) into a page template. The markup is written once, stored in a custom Form, and added to as many page templates as needed by using another Textpattern building block called a Tag. Simple and powerful. Other publishing systems, if they are any good, use similar single-sourcing methods.

Also, it should not be forgotten that when a content publishing system is overkill for a given site, one can still single-source a chunk of markup by using a server-side script to do the same thing. A person merely needs to add the markup to an external script file and insert it where needed (as needed) via a little script magic (PHP, ASP, ColdFusion, or whatever the server needs are). This technique would also allow one to manage all instancs of CC use from one location (assuming the CCs were consistent from template to template).

Intentionally or not, Microsoft has perhaps done us all a favor by forcing use of CCs in the templates themselves, and if future versions of IE continue to improve like IE 7 has done then even use of CCs will become unnecessary with a little more time. Furthermore, by using CCs now, it’s only that much easier later to to drop them when the time comes: 1) Remove the CC from the template header. 2) Delete the associated hack file from the server. Time for completion, two minutes tops.

Argument 3: Other Browsers Need Hacks Besides IE

I’ve seen this argument brought up a number of times, and it seems centered around the fact that CCs are proprietary Microsoft and work only for IE Win browsers; or to put it another way, Web browsers other than IE don’t have something similar, which might otherwise make handling their particular bugs just as easy. The intentions of people using this argument seem good; they seem to be speaking from an analytical standpoint, thinking about CC applications on a wider scale. Again, however, I think it’s misdirected thinking for a couple of reasons.

First, having different browser types with differing, proprietary functionality for handling bugs would do nothing to support Web standards. Such a reality would only encourage people to slip backwards into lazy development since there would be safety nets for sloppy coding. The effort for cross-browser compliancy would be that much more difficult. At any rate, it’s very unlikely that other browsers besides IE will ever implement conditional handling features.

The second reason I think having conditional capabilities in other browsers is misguided is because there really isn’t a need for them anyway. We should all agree that backwards compatibility is a good and necessary thing, that’s certainly my stance; however, too many people are clinging too far back. I also think people put too much emphasis on the breadth of browser types, and not on those that actually represent high percentage of use (i.e., not every single instance of use). Yes, we all know there are other browsers besides IE, but in todays climate, and with respect to browser bug management, what browsers are really worth worrying about anymore? Internet Explorer 5, 5.5 and 6 for Windows, that’s pretty much it.

Let’s walk through the quick reduction. First, let’s exclude worrying about Firefox, Opera, Safari, and perhaps Camino and Konqueror too, particularly previous versions of these browsers. Why? Very simple, because users of these browsers are a different breed; they generally understand the significance of upgrading and therefore keep their versions current. This group is not a problem. (If you happen to be in this group, then ask yourself, are you a problem? If so, then update your damn browser already!)

That leaves IE 5 for Mac, Netscape 4.x, and a whole slough of other no-name browsers that are not much more than browser museum fodder. As alluded to earlier, IE 5 for Mac and Netscape 4.x browsers are dead. The graveyard pits are already dug and waiting. Let’s lower the caskets and start shoveling.

Don’t get me wrong, if you need to keep coddling IE for Mac and Netscape 4.x (and I realize there are times when it’s necessary), fine, use the safe @import and commented backslash hacks and tuck them away. The point here is that using CCs to specifically handle IE’s bugs isn’t any harder or different, but unlike other kinds of hack use CCs allow you to keep your main styles pure (has that been said enough yet?).

Argument 4: Yet Another IE Browser We Have To Cater To

Whether it’s because of years of frustration with IE browsers or simply a deep dislike of the Microsoft empire, there are a lot of expressed feelings that IE 7 is just going to be another version of IE that Web designers and developers will have to nurse. The assumption seems to be that while accommodating the new browser, the older versions will remain problematic for a long time to come. Parallel to this argument, people would rather see Microsoft make IE 6 standards-compliant than worry about releasing something new.

I don’t see it as another browser added to the list; I see it as a newer, better browser bumping a couple of old ones out of the picture. I think the introduction of IE 7 means a quicker burial of at least IE 5 and 5.5. Don’t underestimate Microsoft’s ability to take care of it’s own (the IE user base). Think about it: Microsoft is releasing a new browser along with a new operating system, Vista, later this year (according to Gate’s keynote at Mix06). A new browser and OS combination is not something Microsoft has done in a while, and the aim will be to get this one hooked deep in the gills of existing IE users. Marketing? Oh yeah, baby; it won’t take too long for IE 7 to cover the bases.

One could speculate that a lot of Windows users won’t be buying Vista right away, and therefore won’t be getting the instant IE 7 fix. That will certainly be a factor, but I don’t think it will be as big or long-lasting of a factor as proponents might make it out to be. Enough IE user house-shaking has taken place in recent years to at least make John and Jane Doe reasonably aware that browser upgrades are not only possible, but sensible too. Combine that with Microsoft’s marketing engine and we’ll see the likes of IE 5 and 5.5 flatline in relatively short order. If it’s not IE 7 that kills the vermin, then it will certainly be IE 8 (2008?). If I’m wrong, no big deal, we have CCs to easily slip alternate rules where they are needed, but now I’m repeating myself.

Closing

The hack management paradigm is changing, and IE 7 is making it happen, a major eye-opener. People like Eric Meyer, Dave Shea, and Andy Clarke have already given warnings about it and we better head the call (see right here, respectively). As for myself, these little gems called conditional comments make perfect sense; I wish I had known about them all along. I hope to see many more publications about CCs. Perhaps that would help to enlighten people and make life a bit easier. I intend to use them from hereon out for old versions of IE, keeping my main style sheets clean as can be. Starting right here.

References

1. Anonymous. (1999, 26 July). “DHTML Tip: Conditional comments Part I“ [section in “Dynamic Drive DHTML Newsletter”]. Dynamic Drive. www.dynamicdrive.com/newsletter/issue8.htm#2. Accessed 13 April 2006.
2. Anonymous. (1999, 17 August). “DHTML Tip #1: Conditional comments Part II“ [section in “Dynamic Drive DHTML Newsletter”]. Dynamic Drive. www.dynamicdrive.com/newsletter/issue9.htm#2. Accessed 13 April 2006.
3. Anonymous. (2006, 5 February). “Conditional Comments are your friends.” Kick Ass Web Design. kickasswebdesign.com/wordpress/2006/02/conditional-comments-are-your-friends/. Accessed 13 April 2006.
4. Anonymous. (2005, 12 October). “Call to action: the demise of CSS hacks and broken pages.” IEBlog. blogs.msdn.com/ie/archive/2005/10/12/480242.aspx. Accessed 28 March 2006.
5. Anonymous. (n.d.). “Conditional Comments of IE.” JavaScript Kit. www.javascriptkit.com/howto/cc.shtml. Accessed 28 March 2006.
6. Bersvendsen, Arve. (n.d.). “Hack-free CSS for IE.” arvebersvendsen. virtuelvis.com/archives/2004/02/css-ie-only. Accessed 8 April 2006.
7. Boodman, Aaron. (2004, 9 May). “Newsflash: IE Conditional Comments.” youngpup.net. youngpup.net/2004/condcomm. Accessed 8 April 2006.
8. Clarke, Andy. (2006, 9 February). “And All That (Conditional Comment) Malarkey.” And All That Malarkey. www.stuffandnonsense.co.uk/archives/and_all_that_conditional_comment_malarkey.html. Accessed 28 March 2006.
9. Cook, Craig (n.d.). “Swearing Off Hacks with Conditional Comments.” Focal Curve. geek.focalcurve.com/archive/2005/09/swearing-off-hacks/. Accessed 8 April 2006.
10. Drake, Ted. (2005, 29 September). “Preparing for IE7 – Hacks and Conditional Comments.” Post-Next. www.tdrake.net/preparing-for-ie7-hacks-and-conditional-comments/. Accessed 9 April 2006.
11. Dugonjic, Marko. (2005, 16 June). “Essentials of CSS Hacking for Internet Explorer.” maratz.com. www.maratz.com/blog/archives/2005/06/16/essentials-of-css-hacking-for-internet-explorer/. Accessed 8 April 2006.
12. Edwards, Michael D. (1999, April). “Handling and Avoiding Web Page Errors Part 3: An Ounce of Prevention.” MSDN. msdn.microsoft.com/library/default.asp?url=/library/en-us/dnscrpt/html/weberrors3.asp. Accessed 13 April 2006.
13. Fitzsimons, Nick (2006, 22 March). “I second Richard@Home on the use of conditional comments.“ [comment to “New Clearing Method Needed for IE7”]. 456 Berea Street. www.456bereastreet.com/archive/200603/new_clearing_method_needed_for_ie7/#comment33. Accessed 7 April, 2006.
14. Hupp, Michael (2004, 26 April). “IE Comments“ [comment to “CSS Drop Shadows II: Fuzzy Shadows”]. A List Apart. www.alistapart.com/comments/cssdrop2?page=4#34. Accessed 28 March 2006. (See also the poignant replies to this comment: 35 and 38.)
15. Johansson, Roger. (n.d.). “Stop using CSS hacks now.” 456 Berea Street. www.456bereastreet.com/archive/200510/stop_using_css_hacks_now/. Accessed 9 April, 2006.
16. Johansson, Roger. (n.d.). “Valid downlevel-revealed conditional comments.” 456 Berea Street. www.456bereastreet.com/archive/200511/valid_downlevelrevealed_conditional_comments/. Accessed 9 April 2006.
17. Kaminski “setmajer,” Chris. (2002, 15 November). “Another Possibility“ [comment to “Flash Satay: Embedding Flash While Supporting Web Standards”]. A List Apart. www.alistapart.com/comments/flashsatay?page=10#91. Accessed 28 March 2006.
18. Koch, Peter-Paul. (2005, 6 September). “CSS hacks are starting to break.” QuirksMode. www.quirksmode.org/blog/archives/2005/09/css_hacks_are_s_1.html. Accessed 9 April 2006.
19. Koch, Peter-Paul. (n.d.). “Conditional Comments.” QuirksMode. www.quirksmode.org/css/condcom.html. Accessed 28 March 2006.
20. Koch, Peter-Paul. (n.d.). “CSS Hacks.” QuirksMode. www.quirksmode.org/css/csshacks.html. Accessed 28 March 2006.
21. Lawson, Bruce. (n.d.). “Future-proof Your CSS with Conditional Comments.” Bruce Lawson. www.brucelawson.co.uk/index.php/2005/future-proof-your-css-with-conditional-comments/. Accessed 8 April 2006.
22. Meyer, Eric A. (2005, 13 February). “Conditional comments are one tool in the (now quite large) toolbox of ways to work around problems in IE/Win.“ [listserv reply to “Conditional Comments & CSS”]. Incution. archivist.incutio.com/viewlist/css-discuss/52323. Accessed 9 April 2006.
23. Mischook, Stefan. (2006, 23 March). “IE Conditional Comments Video.” killersites.com. www.killersites.com/blog/2006/ie-conditional-comments-video/. Accessed 13 April 2006.
24. Mischook, Stephan. (2004, 25 October). “Solving the IE7 CSS problem – IE conditional comments are probably your best bet“ [Forum Topic]. killersites.com. www.killersites.com/mvnforum/mvnforum/viewthread?thread=3151. Accessed 9 April 2006.
25. Osola, Bob. (2006, January). “The PNG problem in Windows Internet Explorer.” (untitled site). homepage.ntlworld.com/bobosola/. Accessed 11 April 2006.
26. Perkins, Justin. (2006, 31 January). “Conditional Comments, Where Art Thou?“ [comment to “In Search of the Holy Grail”]. A List Apart. www.alistapart.com/comments/holygrail?page=6#55. Accessed 28 March 2006.
27. Pilgrim, Mark. (2003, 2 July). “The Vanishing Image: XHTML 2 Migration Issues.” O’Reilly xml.com. www.xml.com/pub/a/2003/07/02/dive.html. Accessed 15 April 2006.
28. Puente, Hefte. (2005, 8 August). “IE’s Conditional Comment.” Jefte.net. jefte.net/design/internet-explorers-conditional-comment/. Accessed 9 April 2006.
29. Rougeux, Nicholas. (2005, 17 October). “On one condition.” C82. www.c82.net/article.php?ID=24. Accessed 9 April 2006.
30. Sebastian. (2005, 17 December). “_A hack is a hack…” [reply to Avoiding CSS Hacks for Internet Explorer]. 24 Ways. 24ways.org/advent/avoiding-css-hacks-for-internet-explorer#c000400. Accessed 11 April 2006.
31. Shea, Dave. (2005, 13 October). “Bye Bye Tan Hack.” mezzoblue. mezzoblue.com/archives/2005/10/13/bye_bye_tan_/. Accessed 8 April 2006.
32. Shea, Dave. (2005, 3 November). “IE7 Conditional Comments.” mezzoblue. www.mezzoblue.com/archives/2005/11/03/ie7_conditio/. Accessed 8 April 2006.
33. Shea, Dave. (2006, 3 April). “Taming the Browsers: CSS Hacks.” informit.com. www.informit.com/guides/content.asp?g=webdesign&seqNum=249. Accessed 9 April 2006.
34. Staudinger, Manfred. (2005, 4 February). “Taming Your Multiple IE Standalones.” Position is Everything. www.positioniseverything.net/articles/multiIE.html. Accessed 28 March 2006.
35. “stylo.” (2002, 23 December). “An Example“ [comment to “Cross-Browser Variable Opacity with PNG: A Real Solution”]. www.alistapart.com/comments/pngopacity?page=#10. Accessed 28 March 2006.
36. Silvester, Dave. (2004, 29 July). [listserv reply to “CSS Underscore Hack”]. Incutio Archivist. archivist.incutio.com/viewlist/css-discuss/42077. Accessed 9 April 2006.
37. Tony. (2005, 16 October). “Conditional Comments“ [Forum Topic]. CSS Forum. www.csscreator.com/css-forum/ftopic13341. Accessed 11 April 2006.
38. Wallant, Michael. (1998, 17 July). “Conditional Comments, Radio Buttons.” MSDN. msdn.microsoft.com/library/default.asp?url=/library/en-us/dndude/html/dude071798.asp. Accessed 13 April 2006.
39. Yank, Kevin. (2005, 13 October). “Microsoft says: de-hack your CSS.” sitepoint. www.sitepoint.com/blogs/2005/10/13/microsoft-says-de-hack-your-css/. Accessed 13 April 2006.

Latest Ten Articles

• Finally Pro-MacBooked 6 April 07

  Six months later than expected, and on the eve of the new Apple Leopards, I am nevertheless a happy owner of the MacBook Pro, and it feels good.

• What Makes a Good Web Accessibility Guide for the Business? 2 April 07

  With pressure mounting on web developers and companies alike to provide quality eAccessibility products and services, it makes good business sense for companies to have their own eAccessibility guidelines to help ensure development objectives are being met in efficient and cost-effective ways. However, just knowing guidelines are needed is one thing, producing and integrating them into a development workflow is something else. What breadth and depth of information should they cover? How should they be written and structured for maximum understanding? What format provides the best utility? Seemingly, the preparation of eAccessibility guidelines is not a fundamental task, the considerations are many.

• Main Points Delivered at the First European eAccessibility Forum14 March 07

  I’m not exactly punctual on this one, but making a long story short, here are the main points as I took them from the eAccessibility Forum held in Paris nearly 6 weeks ago…already.

• In Paris for the First European eAccessibility Forum27 January 07

  It’s going to be a whirlwind trip on the train, but should be interesting nonetheless.

• Lose Readers by Moving Themes?14 January 07

  We hear about free Weblog themes all the time, and see the same ones all over the Web, but it’s not often you read about someone moving a personal theme from one self-owned domain to another, or the implications of doing so.

• Book Reviews Coming to Wion18 November 06

  Reading and writing is my kind of chocolate, and when it comes to book reviews, everybody wins. I hope you’ll find them helpful. Stay tuned.

• A Core Textpattern Technique Addressing Internationalization Interests14 November 06

  This article presents a core Txp technique for managing internationalization efforts, and three methods of use are described: 1) multilingual publishing within site, 2) collaborative international publishing between individuals, and 3) an alternate approach to #2 that essentially takes a community slant.

• Textpattern Building Block Mechanics30 May 06

  Here is the second article in a two-article series about Textpattern building blocks. If you missed the first article, Understanding Textpattern Building Blocks, you might check it out too.

• Heatmap Presentation of Eye-tracking Data17 May 06

  Isotopic heatmaps of eye-tracking sessions are easier too see and understand; hence, great slide material for stakeholder presentations (management, clients, and so forth).

• IE Conditional Comments: Where Have They Been?19 April 06

  Conditional comments have been with us for years and largely unknown, but with the coming of IE 7 they may be the swan song that’s about to go platinum.