When I published that article last year, the words and advice contained within were welcomed warmly by large numbers of people. The article was translated into at least eight different languages, and continues to be referenced in other writings and in academic curricula. On the flip side, the same article was also the cause of flaming, accusations of ignorance, and general vitriol thrown my way, claiming I was over-hyping CSS and deceiving the multitudes of its capabilities. Those claims were voiced more loudly when readers couldn’t find any proving example code whatsoever. Those who refused to let go of their old ways assumed that I fabricated the entire case study.

I still stand behind that article. And I promise the example code is real, and still resides in the same location where it has been for the past year. You just had to know where to look for it.

I intentionally omitted any links or references to my working code examples in that article because the point was not to get hung up on details or to demonstrate the methods used. I wanted to step back and look at the overall picture. After experience with recoding Yahoo Search, I no longer believe in reworking (in CSS) some other organization’s site, then publicly rubbing anyone’s nose in it by posting the code for all to see. I wasn’t trying to target Microsoft for bad CSS support in IE, nor make a fool of its home page code. Rather, last year’s home page of Microsoft.com was chosen as an example because it was a high-profile representation of a very common design model used on thousands of sites: header across the top, three columns of content, and footer across the bottom. If a site doesn’t use a three-column content model, it may simplify the same model down to two columns:

I gave this presentation for the first time in Seattle, right around the corner from Redmond. So I thought the selection of reworking Microsoft would turn a few more heads. Those who attended my talk at Digital Design World had full access to the Microsoft example code during and after my presentation. It was never hidden from them, because it was used as a tool to aid in learning the methods and benefits of tableless design.

In an odd bundle of circumstances, Microsoft ended up redesigning its home page just one month after my Seattle presentation, significantly reducing the file size of its code. The design was simplified and the amount of text on the page was significantly reduced as well, so this wasn’t solely a reduction due to leaner code. However, all spacer gifs seem to be gone from the markup, and only eight tables remain in the current version, so that points to progress from last year’s 40-table version.

Fast-forward to today

Now that a full year has passed since the article was published, and because Microsoft no longer uses the design I made an example, I also moved on and now use another design for my tableless presentations. Because of these factors, it now seems appropriate to share more broadly the final example code I used, and the full set of slides I used during my Seattle presentation to cover the reworking of Microsoft.com.

• Example code: 2004 Microsoft home page using CSS
• Seattle presentation: No More Tables

The portion covering the recoding of Microsoft.com doesn’t start until somewhere around page 32 of the presentation. Once the presentation gets to Step #3, small links at the bottom of the page point to in-progress files representing the work done up to that step.

By sharing even more information surrounding this case study, I hope having everything in context to this case study helps enlighten others to the means and the power in using CSS to implement and control layout and all other details of design.

Now, bear in mind, (in my opinion) the new visual design of MSN is quite uninspired. It’s drab and boxy. (No offense to the designer, if there even was one.) Looks like it may have gone directly from a Product Manager’s sketch to the developer who coded it. The design certainly offers nothing new or innovative, and looks like it’s following Google and Yahoo, obviously trying to play catch-up. (Perhaps some would say the MSN design, particularly the very top portion of the page, is a little too inspired. Looking like a confused mix of Yahoo’s pointy tabs combined with a poor Google-simplicity imitation.) The search page’s simplicity is so simple, it looks unfinished.

Despite a lack of interest in the visual design, I see several interesting things going on here worthy of mention, and to which we should pay attention:

XHTML 1.0 Strict

Not only do the new MSN pages unashamedly boast the XHTML 1.0 Strict doctype, the home page comes through with — at the time of this writing — only 28 validation errors, and the search page comes through with only 1 error. Not perfect, but so much closer than many other high-profile sites that have launched in the past couple years. Most of the validation errors are simple, easily fixable problems. The iframe for the ads will be a problem though: it’s not allowed in XHTML 1.0 Strict.

CSS for layout; improved semantics

The new site is also significant for its use of CSS for page layout and improved semantics. Lots of headings and unordered lists. A table used appropriately for the stock market summary; another probably part of a legacy ad system.

Upgrade message

A somewhat fair-minded (read: not entirely IE-centric) interestingly-worded upgrade message is displayed at the top of the home page when CSS is toggled off:

Why does MSN look like this?
Your browser cannot find our style and presentation information. You’re welcome to use the page as is, or upgrade your browser to its latest version. If you’re using Microsoft Internet Explorer, go to the Microsoft Internet Explorer website to install the latest version. If you are using another browser, see your browser’s website for more information.

Style switcher

A fairly prominent use of a simple client-side style switcher on the home page, allowing the user to toggle between blue and white body backgrounds.

Handheld media type

Look through the imported style sheet on the home page, and you’ll see several uses of @media handheld {} to target certain rules for handheld devices. Rules like this:

@media handheld {
  #sitenav,#content1,#content2,... {float:none;}
}

which turn off many of the floats. It’s encouraging to see a large site like this finally thinking about the handheld media type. Makes sense, with platforms like the PocketPC gaining popularity. Hope this is a sign that the PocketPC team is solidly behind the handheld media type.

However, I note lots of individual uses of @media handheld {}, containing only one rule each, rather than one use which groups and contains all handheld rules. Odd. See next point.

Dynamic style sheets

The use of query strings to point to their style sheets obviously indicates dynamic scripting is in play here. One of the byproducts of dynamically-assembled CSS is the ability to eliminate almost all whitespace in the style sheet. This makes it difficult for us to read, but easy for them to update (and possibly alter based on variable factors like browser). This potentially explains why the @media container wraps around single rules. Rules are probably flagged as being for a particular media type, and there’s currently no logic in the style sheet that groups rules together based on shared media types.

Input button outlines

Don’t assume all browsers allow full manipulation of input buttons. If you do, and I’ve been bitten by this one before, your buttons could end up looking like this (taken from Safari):

IE5/Mac left in the dust

I’m not sure what MSN.com looks like in the updated and much improved MSN for Mac browser (only available to MSN subscribers) that Tantek helped complete while he was still at Microsoft. But take one look at the new MSN home page in IE5/Mac, and one thing is clear: Microsoft seemingly paid no attention at all to what the new MSN site looked like in IE5/Mac. Ouch.

Microsoft links to an explanation of benefits of the new MSN where they list the top (first) feature as being “Faster load time“. Not sure what the old HTML file size was, but it would be interesting to have as a comparison.

Update: Some of you may be interested to know that folks from the MSN team have definitely seen this page, and are aware of the feedback, compliments, and criticism. See Venkat’s comment below for more info, and a link to a new MSDN blog where Venkat provides a few thoughts and asks for feedback.

A huge drop in the number of tables used to lay out the page (my count is seven tables — that’s down from 40 tables previously), not a spacer gif in sight, all the proprietary attributes and identifiers in the links are gone, most of the bulky JavaScript the previous home page used is stripped out, and the HTML now weighs in at a lean 11 KB.

I don’t see any browser sniffing going on, thus, we can assume Microsoft is now only serving one version of the home page, rather than the two separate versions maintained before. The team even used proper alt text for the large image map front and center.

Whoah! Can this really be Microsoft I’m writing about?

While this step represents a huge leap forward for Microsoft toward leaner, more efficient tableless layout that uses much more CSS for design details, it’s not all the way there yet. There are a few critical things Microsoft is still missing, even by HTML 4 standards. Small mistakes such as placing <p> tags inside link anchors, use of individual divs for bulleted list items rather than using unordered lists, overuse of classes and extraneous elements, and the obvious continued use of several remaining tables to lay out the page. There are a few rendering issues in various browsers that could be worked out, but at least only one version is served to everyone now.

The heartening thing for me about this whole design transformation is the potential of what Microsoft could achieve if they kept pushing forward. The current code isn’t that far off from a completely standards-compliant, accessible, semantically rich home page.

They still haven’t placed a doctype at the top of their HTML. But even forcing the page to validate as HTML 4.01 Strict, (at the time of this writing) the W3C validator only throws 64 errors! That’s nothing. Especially when you look through the errors and see most of them are redundant, like the paragraphs inside anchor tags, and repeated use of <nobr> and the non-standard <wbr> tag for allowing soft line-breaks. Fix all that stuff, and they’re looking at maybe 20-25 remaining errors. The CSS isn’t in that bad of shape either. A couple proprietary properties and a few syntax mistakes.

Whether someone at Microsoft was listening or not, these changes are outstanding to see. Hopefully, this is just a start of what’s to come. The home page team should certainly get recognition for the progress they’ve made so far.

Nice work Microsoft. Please… just don’t stop here.

Thanks to Beto for the tip!

Turns out I underestimated. By just a little.

Olivier Vanbiervliet pointed me to a public Microsoft page titled “Inside Microsoft“. The page provides a bit of “backstage” information about microsoft.com, including some detailed stats for the month of May 2004.

Their published traffic numbers actually state that microsoft.com got 1.2 billion page views in May 2004. Divide that by 31, and we’re not just looking at 1 million page views per day, but more like 38.7 million page views per day.

Which, if you do the math, with a potential average savings of 25 KB per page, works out to numbers a little higher that what I originally projected. More accurate savings could actually be closer to:

924 GB per day.

329 terabytes per year.

I updated the article to reflect these more accurate projections.

Half way through the presentation, I switched gears and announced we’d be converting a real-world example from tables and spacer gifs to a pure CSS layout. I could have created a fictitious example to work with in the presentation. But that idea would have seemed too contrived. If I created my own example, it would have been nice and tidy. Everything would have rendered exactly as I wanted it to, staying free and clear of any “trouble spots” I already knew to avoid.

Fictitious wasn’t good enough. I wanted a real challenge. So I chose the site of a small, local-to-the-Seattle-area company I thought a few of the attendees in the audience might be familiar with: Microsoft

Ok, maybe more than just a few attendees were familiar with this not-so-small company. Many users arrive at Microsoft’s home page every day. Microsoft’s literal home page may or may not be as well-known and oft-used as search giants Google and Yahoo! But microsoft.com in general gets tons of traffic, and the people which pass through its domain every day quite likely number in the millions.

The shame is that Microsoft’s site isn’t as optimized as it could be. They haven’t taken the plunge yet. Users download unnecessarily larger pages, and servers waste extra bandwidth to keep up. At 40 KB, the HTML for Microsoft’s home page is not exactly a bloated beast. But it is burdened with inaccessible, kludgy, table-based markup filled with proprietary attributes and some awkward JavaScript. Notice I didn’t mention whether it was valid markup or not. Despite using the flavor of XHTML, Microsoft omits the doctype on their home page.

Why Microsoft?

Is this just another “pick on Microsoft” thing?

Bluntly and honestly… no.

I didn’t choose Microsoft to jump on the bashing bandwagon, or to toss a few more pot shots at a company some people in our industry love to hate. (I didn’t pass up any opportunities to question certain decisions they’ve made, but I avoided passing judgment.)

I admit that I purposely chose and targeted a high-profile company. It’s my nature to go after the top guns. But it’s also an example with which almost everyone is already familiar. Microsoft.com was (and is) a perfect candidate for a standards-compliant CSS makeover.

Here’s why…

Reason #1

Because of the inefficient use of an abundance of tables and spacer gifs used to layout the page. Pages are more locked down when their content is laid out using tables, and can often be less accessible as a result. Microsoft is not alone here. An overwhelming majority of sites on the Web today still use lots of tables for page layout and other purely visual purposes. I chose Microsoft because it could serve as a well-known example (and eventually a model) that relates to the same issues many sites still need to address.

Reason #2

Because the basic structure of Microsoft’s current design is a model that thousands of websites use for their own site design: Header + 3 columns + Footer. Specifically: a Header that spans all the way across the top of the page, a Left column containing mostly navigation, a Main column for content, a Right column for extra “stuff”, and a Footer that sits below all three columns and also spans the entire width of the page. If it’s not a 3-column layout, many sites might use a 2-column variation of this same basic structure with a Sidebar to the left or right of the Main column:

Reason #3

Because Microsoft’s home page uses CSS for little more than FAC (fonts and color). I’d love to see the company that basically invented the concept of style sheets in an application environment, lean more heavily on CSS, and less on old-school methods.

Reason #4

Because Microsoft is currently serving a different version of their home page depending on which browser is used to view it. One version for Internet Explorer for Windows (v5.5 and above). Another somewhat “dumbed-down” version for all other browsers (including IE/Mac) that omits some of the imagery and all product logos. The non-IE/Win version leaves out some of the functionality (e.g. fly-out menus) and renders page elements with different techniques. If you have IE/Win 5.5 or higher, plus another browser available, you can check for yourself. If not, here’s a screenshot of the two versions, with differences circled in red:

The non-IE/Win version is noticeably more anemic than the full version served to IE/Win. We all know it doesn’t need to be this way. If you’re wondering, it’s not just sloppy coding that works in some browsers and not in others. Microsoft intentionally does a JavaScript browser detect, and redirects the browser to a different file if the browser is IE5.5 or higher. Instead, Microsoft could just maintain one version that works in all browsers.

At least Microsoft serves a version of its page to non-IE/Win browsers. Some developers may not even go that far. The frequent reason we hear cited for dropping support for other browsers is that MSIE/Win is THE browser used by a MAJORITY of people, and that it takes TOO LONG to develop for (and render properly in) any other browsers. Others complain that development for browsers other than IE/Win is TOO EXPENSIVE. Both the too long and too expensive claims are false.

Many developers believe these claims because they start by developing for — and checking in — IE. Then they view it in another browser and become frustrated when they see all kinds of supposed “bugs” they think they’ll have to fix.

IE interprets CSS more loosely than other browsers that have been iterating versions over the last couple years (Mozilla, Firefox, Safari, Opera…). Starting with IE means fewer problems with development work will be detected early on. Developing for IE initially, then trying to retrofit for other browsers will increase time and cost in the long run. But there’s a better way to approach development that’s faster and less costly.

Start with the stricter, more compliant browsers that (usually) render things how they’re supposed to render. Get everything working there. Then, double back and create a few “patches” for IE. Development is much faster this way. It may be counter-intuitive to initially avoid the browser that represents the majority of your traffic. But the process is much more fluid and efficient if you don’t become accustomed to — or depend on — IE’s relaxed rendering behavior. Start with IE, and you may start with bad code that takes much longer to fix for other stricter browsers.

Going this route, we still have the IE Factor to contend with. However, as we gain more experience with IE’s CSS misbehavior, the IE Factor eventually starts to minimize. There is hope.

Just the Facts, Please

For the second half of the presentation, we stepped through the entire process of converting Microsoft’s table-based spacer-gif-laden page to a more accessible, purely CSS-driven version that works in all browsers. This is not new. Others have re-coded microsoft.com before. Many regular readers of this site have been creating tableless designs for a year or more by now. But we don’t see everyone else jumping into the water yet, despite the water being fairly thoroughly tested by now. Thus, the presentation at Digital Design World, and this follow-up article.

Continuing the presentation, we broke down each stage of the process into manageable chunks. I highlighted each of the major steps of the process, including the dumping of tables, conversion to more semantic markup, and the CSS techniques used to faithfully reproduce each portion of Microsoft’s home page design.

Throughout the presentation, we examined lots of visuals (diagrams, screenshots, and pictograms) that aided in understanding the techniques used to render each section. I also had the code saved out as separate “pre-baked” files I could refer to for each stage of the process.

One of the reasons for writing this follow-up article is to publish the final results of the Microsoft.com makeover, which are kind of hard to ignore:

Going Further

The numbers get even more interesting when we start doing Meyer/Davidson ESPN-style estimates and projections. According to a public Microsoft page titled “Inside Microsoft“, Microsoft’s published traffic numbers state that microsoft.com got 1.2 billion page views during the month of May 2004. In this presentation, I showed how to decrease the markup from one page by 62%, or 25 KB. I also predicted that about 25 KB is a fair savings estimate per page if Microsoft was to get more aggressive about using CSS site-wide. If multiplied out by an average of 38.7 million page views per day, that 25 KB savings per page could add up to about 924 GB in bandwidth savings per day, or 329 terabytes per year.

These numbers alone should be enough to turn a few heads.

Now, toss in the fact that the makeover is just one version, and supports Microsoft’s more “advanced” design, (as currently seen in IE/Win) and does so in many more modern browsers.

Companies like Microsoft may or may not want to maintain just one version of their home page that works in more browsers, loads faster, and is more accessible to all kinds of users and devices. Regardless, I thought it was worth pointing out that it’s now very possible to demonstrate and walk through how they — or any company — could create one super-powered version that uses leaner markup, works in more browsers, and increases accessibility. All demonstrated within the time span of an hour or two…

Additional Points and Caveats

• If you’re curious, and like to be thorough, the CSS only increased from 3 KB and 5 KB (IE/Win and non-IE/Win versions, respectively) to 8 KB for the makeover version.
• The fly-out menus seen in IE/Win’s version for two options in the left-side navigation are possible to reproduce as well. All done with pure CSS and simple, semantic, accessible markup. The makeover uses the :hover pseudo-class to toggle on/off a nested unordered list when mousing over the parent list item. One consideration: IE doesn’t support :hover on list items, so the JavaScript method Microsoft is already using would still be necessary to support fly-out menus in that browser. Or something like Suckerfish Dropdowns could be used to keep the same semantic nested-list markup the makeover version uses.
• The hefty jump in number of image tags for Microsoft’s current non-IE/Win version is due to heavier spacer-gif usage. The non-IE/Win version also calls every bullet image individually, rather than via one CSS declaration, as the IE/Win and makeover versions do.
• All of the JavaScript found in Microsoft’s markup was removed. As were hundreds of proprietary attributes in anchor elements that were/are apparently used for click-tracking purposes. Microsoft would likely want to add some of this layer back in — though hopefully through a valid means of doing so.
• As mentioned above, the point of this article is to publish the potential results and benefits of using CSS and simpler, more semantic markup to build pages. It merely uses Microsoft as a well-known example. This article intentionally omits linking to the final makeover code. I understand that many people could learn from the work done for this presentation, without seeing the presentation, by studying the changes made to the HTML and CSS. However, I do not want to downplay anyone’s role at Microsoft by publicly releasing modifications to their source code before having a chance to present them directly to Microsoft, and discuss the changes and techniques with appropriate team members, if they ever wish to do so.

Translations

This article is translated into the following languages:

• Brazilian Portuguese: Jogando as Tabelas Pela Janela by Humberto Oliveira
• Simplified Chinese: Throwing Tables Out the Window by Gregory Song
• Dutch: Tabellen uit het raam gooien by Nick Verstappen
• French: Passer les tableaux par la fenêtre by Benjamin David
• German: Tabellen aus dem Fenster werfen by Eric Eggert
• Italian: Gettare le tabelle fuori dalla finestra by Giuseppe Di Carlo
• Japanese: Throwing Tables Out the Window by Kohei Yoshino
• Polish: Wyrzucanie tabel przez okno by Pawel Grzesiak
• Spanish: Tirando las tablas por la ventana by Hermann Kaser
• Turkish: Tablolari Pencereden Disari Atmak by Mehmet Dogan

Update: As of 27 July 2005, the example code and corresponding presentation slides were released and made available to everyone. See Still throwing tables for background information and links to the code and presentation referenced in this article.

Tweaks that should have worked had no effect, prompting me to try things that made absolutely no sense to try.

This bug was no exception. It took a lot of isolating and trying remote possibilities to come up with the solution that fixed it. I also mentioned different combinations of IE’s can drive a CSS author mad. This bug shows up in IE5.5, but not in IE5.0 (Win). IE5.5 certainly renders CSS a little better than its predecessor, but with IE5.5′s release and improvements, new bugs — which did not previously exist in IE5.0 — suddenly appeared. Some of those same bugs were carried into IE6.0.

The problem: A simple series of content boxes (I call them “modules”) appearing in succession within a 200-pixel wide sidebar. Nothing out of the ordinary, certainly nothing complex. Each module started with a title marked up with the <h2> tag. Each module’s title was followed by two generic paragraphs of text.

The example file I’ll provide is stripped down, with almost all design details removed. Titles were given a bit of style to reduce font size and top and bottom margins. For what I was creating, borders for each module only existed on the sides. I’ve exaggerated them to make this bug more obvious. To see it misbehaving, view this example of the bug in IE5.5 or IE6.0, then view it in any other browser to see the correct behavior. For those not fortunate enough to have either of those two Windows browsers, here’s a screenshot of the first and last modules, as rendered by IE6.0:

Notice how the text gradually slips further to the left for each module. The bug only begins to appear in the second module, then gets progressively worse for each module below. Until the last module’s text slips so far to the left, it gets clipped by the module’s container. The problem gets infinitely worse as more modules are added. No other browsers have problems rendering the text correctly.

Obviously, this problem wasn’t acceptable. I had no idea how many modules the client might need to stack together in the sidebar. I tried every trick in the book I knew to prevent the text from slowly slipping over. The problem was seemingly incomprehensible, as each module was completely independent of the next. The code was completely valid, and no containers overlapped each other. I tried it with the 200-pixel sidebar, and without. I removed padding, applied margins, removed the titles. No luck.

I walked away, went to lunch, then came back to find the root of the problem. I discovered the text was slipping to the left by four pixels from one module to the next. At the time, each of my side borders were only 2-pixels wide. So the text slippage between each module was equivalent to the width of left and right borders combined. I removed the side borders, the bug disappeared. (See example)

Ok, so it was the border. But the effect I was going for required the side borders. At one point I tried adding top and bottom borders to the module: Bam! problem solved. Turns out it’s actually the presence of a bottom border (any width) which fixes the bug. It makes no sense why a missing bottom border on one element would affect another element on the page. But in IE5.5/6.0, it does.

So the bug could ultimately be described as this: If left and right borders are applied to one container element without a bottom border, the side borders on the first container will adversely affect the text position in the next successive container element.

To fix my instance of the problem, I added a 1-pixel bottom border for each module, making it the same color as the module background to keep it mostly invisible. (In the example, background and bottom border are white.) Since the border isn’t necessary in all other browsers, I really didn’t want it there when it wasn’t needed. So I added one more rule to turn off the bottom border for them:

.module {
  margin:0 0 15px;
  border:4px solid #666;
  border-width:0 4px;
  border-bottom:1px solid #fff;
  padding:2px 10px;
  }
html>body .module {
  border-bottom-width:0;
  }

By using a child selector, that final zero-width border rule is hidden from all versions of IE/Win. (View the final solution) I also discovered that applying a width to each module also solves the text-slippage problem. But IE5/Win’s broken box model needs to be dealt with if the modules use left or right padding. And widths should not be necessary for individual modules, given that a width is already specified for the parent #sidebar. So I stuck with the add/remove bottom border trick to avoid the need to re-specify module widths.

This is just one example of the inexplicable bugs which caused delay for my latest project. If anyone else encounters the same bug, hopefully this example will save some of their hair, and prevent them from facing the same frustration.

Such is often the case when designing with CSS. When working with semi-complex layouts, I frequently encounter challenges that end up slowing me down. I’m getting familiar with these road blocks, and can often predict where I’ll find them. Having patience, or knowing what to try to get around them prevents head from going through monitor.

Without a doubt, the biggest challenge I encounter each time is in wrangling Microsoft’s Internet Explorer browser. This devil does not play fair. It often follows no rules, and its behavior defies all common logic. It will double margins for no apparent reason. Borders disappear, 62 pixels magically turn into 143 pixels. It dodges left when other browsers go right. I’ve decided to call this phenomenon “the IE Factor“. (Those familiar with authoring DHTML four or five years ago already know where I’m headed with this.)

While working on the final stretch of a client project last week, I got stuck in a patch of quicksand. Design was finalized long ago. The bulk of CSS was authored over the holidays. Mozilla, Firebird, Safari, and Opera were all rendering the design beautifully, give or take a few small hiccups. But the design still had a few major quirks in IE (both Windows and Mac versions). “Ok, no problem — I need to spend an hour or so squashing bugs in IE.” That hour turned into two full days. Days filled with head-scratching and mind-numbing deconstruction and isolation of declaration blocks and properties. Progress came to a screeching halt while I tried every trick in my book. Solving one problem revealed another. Making a fix for IE would throw off the other browsers. Tweaks that should have worked had no effect, prompting me to try things that made absolutely no sense to try. And lucky me, IE/Win and IE/Mac have completely different bugs.

To be fair, IE/Mac has a predictable set of bugs which have known workarounds. But as I stated above, IE/Win will defy all common logic. Which makes it such a difficult browser to troubleshoot. I don’t dwell on the box model problems in version 5.x. Those can be dealt with. It’s the idiosyncrasies of IE5.0, IE5.5, and IE6.0 together (or in different combinations) that will drive a CSS author mad.

At times, I thought about writing every one of my style sheet rules using child selectors, filtering IE/Win out completely and serving it the same unstyled version as Netscape 4. But of course, IE possesses too much market share to turn off a design for every person using it. My client couldn’t — and wouldn’t — agree with that type of decision. So I had to compromise on each bug. If I couldn’t find an acceptable solution, or beat IE into submission, I’d decide to turn off that feature or design attribute just for IE/Win. Nice hover effects over those icons? Sorry IE, you won’t get them. A nice little bottom border on this box, like EVERY OTHER BROWSER renders correctly without going into convulsions? Sorry IE, you don’t get that either. You’re too fragile for a simple border. What kills me is the extra markup I’ll sometimes give in and add, just to get IE to render a critical part of the design correctly.

On numerous occasions, I’ve been bogged down by Internet Explorer’s incomplete support of CSS. I spent an extra 2 weeks trying to figure out why IE was bungling the Wired News layout. I should have known that I’d encounter difficulty with my project last week. But those two days of lost time hit me hard. I was over-confident that I could catch anything IE threw at me, thinking I could solve it quickly and easily. Silly rabbit. In reality, I’ve now calculated the IE Factor can add upwards of an additional 10% in time and cost for each project, distorting the estimating process if it’s not figured in.

So, you could say I’m becoming familiar with the route. I’m learning the best paths to tread when constructing designs with CSS. I know the interesting segments, the boring stretches. Most importantly, I’ve started to recognize patterns, and can predict the areas that will slow me down. Specifically, I know about the IE Factor. I don’t like it one bit, but at least I can prepare, and expect to encounter it for each project. And I’m building up an arsenal of weapons for use against IE when it misbehaves in the future.

The browser wars are supposedly over. We’re supposed to be at peace now. Everyone is supposedly cooperating. We’re supposed to be living in an era where we don’t need to alter code and make unique design decisions for each browser. We’re close, but I don’t think we’re there yet.

Update: See one example of a bug which contributes to the IE Factor, described in detail in this entry.

Adobe’s decision to partner with Opera is an important one. It’s one more step in proving that IE is not — and does not need to be — the browser to which everyone defaults. In addition to clamoring from the development community, it will take major tool and application vendors to help step up the call for Microsoft to pay attention to these demands. The article featured a disappointing quote from Windows product manager, Greg Sullivan:

“While it is true that our implementation is not fully, 100 percent W3C-compliant, our development investments are driven by our customer requirements and not necessarily by standards, [...] We balance feedback from all our customers and make our development decisions based on meeting the requirements of all of our customers, not just a few of them.”

By using this explanation, Microsoft could try to slant what they call “customer requirements”, or even project their own requirements based on features the company wants — or doesn’t want — to build into the browser. But growing pressure applied by larger organizations and demanding groups of customers may eventually become a voice Microsoft can no longer ignore. The more fires lit under Microsoft, the less likely they’ll be able to shield themselves from the firestorm developing around them.

I was a die-hard Mac fanatic. One of those arrogant designers who shrugged off Microsoft’s market share and expected 76% of the computing world to revolve around my operating system of choice. If you weren’t on Mac, you didn’t matter.

The legacy goes back to a 1 Mhz Apple II+ that my Dad bought while I was still in junior high. Apple introduced me to the digital world of green monochrome screens, BASIC, and the creation of horrible continuous-paper banners created with PrintShop and a dot matrix printer. I began working with an 8Mhz/1MB RAM Mac Classic made publicly available in a student government office my freshman year of college. I plunked down my own chunk of change on a Mac Centris 610 two years later, which quickly paid for itself with freelance design work.

Wired bought a small group of PowerBook G3s for us at the end of 1997, and I fell in love with the Mac design aesthetic. A sleek black notebook with subtle curves, and one of the first working portable DVD drives. It was a beautiful machine worthy of showing off everywhere I went. Six months later, I upgraded my outdated Centris for a beige PowerMac G3 desktop, two months before the bondi-blue G3′s came out.

Downfall

My Mac idolatry began to wane the following year. My days were filled with system crashes, extension conflicts, frozen applications just before saving, and font manager nightmares. Wired MIS began to drop support for Macs, so designers were left to fix their own problems. Lycos had swallowed up Wired by that time, and everyone back in Boston was using Windows. It was too painful to share files or communicate cross-country with a company who knew nothing but 95 and NT.

In August of 1999, I stepped out into the streets and bought my first dose of the dark side. Well, sort of. The cool part of the dark side. If any designer ever owns a Windows machine, it’s at least partially understandable when the dealer is Sony and the vice is Vaio. Such was my case, but this purchase was a bad hit — this super-slim Vaio Z505 ran Windows 98. A horrible introduction to a recreational use of Windows. I could suddenly share files and what not with my Boston colleagues, but I was greeted on a daily basis with the BSoD, and could never successfully enter standby or hibernation modes. I’m sure both Sony and Microsoft share the blame for that one.

The following year, I eBayed my original Vaio in exchange for higher grade stuff. A newly redesigned dockable Vaio R505 in the same series, this time running Win2000. And this is where my addiction grew. I finally learned what Windows was all about. Why it was used. Why Microsoft had such high market share. Win2k was stable.

I never crashed when using it.

My fonts loaded correctly every time. I could reliably collaborate with teams in Boston via NetMeeting. I studied the OS inside and out, and learned how to make it mine. I could push pixels around in Photoshop and have the power of IIS under the hood on the same machine.

Slippery Slope

ASP was a welcome addition to the tired HTML and SSI tricks of this designer. I could suddenly create dynamic pages and serve them directly from my laptop. Entire design prototypes could be built using one or two templates. I learned Windows server administration, and took over the job of managing a machine for our User Experience group back in Boston through terminal services. I built a custom CMS to manage the Lycos Style Guide, and learned how to make connections with databases to power portions of the site.

I was hooked on a drug from Redmond.

My Wired G3 PowerBrick sat in a file cabinet drawer while I fell further down the rabbit hole. The G3 was a cinder block by today’s laptop standards. I didn’t want to lug around an 8-pound back-breaker. It couldn’t even handle the newfound tasks that my made life so much easier. My shiny bluish-silver Vaio was barely over 4 lbs., and it tagged along with me everywhere I went. When it came time to upgrade software, the Windows versions got the attention, while my collection of Mac-based software continued to grow sorely outdated, further taking away any remaining rationale to break my current habit.

Loss of Hope

Toward the end of 2001, I desperately wanted to replace my G3 desktop. The big box generated an unbearably loud hum, and it took up way too much real estate beneath my desk. I debated giving up Mac entirely in exchange for my new addiction. But I couldn’t bear the thought of completely abandoning my previous life. I purchased a gorgeous new PowerBook G4 at wholesale cost from a counselor at CompUSA. I suppose it was an attempt at salvaging my sense of loyalty which was gasping for air. The G4 booted OS 9 by default. But it also had this new thing called OS X that I wasn’t so sure about.

I had long fallen out of Mac circles, and knew nothing about OS X, other than what I had seen at MacWorld. The major OS rebuild seemed rather disappointing to me. All I could think was that it looked a little too sugar-coated for a professional designer. And the screen type was so big. Was Apple compensating for poor anti-aliasing? I didn’t understand all the changes in OS X, and hadn’t yet taken much time to learn my way around a Unix file system.

The darkness was closing in.

Sadly, the G4 saw very little light of day once it was purchased. It sat conveniently out of the way inside a hall closet. I pulled it out now and then to cross-check my stylesheet hacks on Wired News prototypes over the summer. Hardly the full potential of a 667 Mhz G4 processor. But what else did I need it for?

Denial

Around March of 2002, I upgraded to Windows XP Pro. The deal with the dark side was sealed. Finally a stable operating system from Microsoft that possessed plenty of eye appeal. Many of the new features of XP made so much logical sense. Grouping of taskbar buttons, hiding inactive system tray icons, built in support for wireless networking, and common tasks based on folder type. It proved to me that Microsoft had been conducting a lot of user testing and was paying attention to the resulting feedback.

The pusher got smarter.

XP was fast and slick. It made me feel good. It stole some of the UI philosophy from Apple, but didn’t go overboard with decoration. Put XP beside OS X, and purely based on the visuals, I’d pick the former any day, especially considering smaller screens. XP didn’t abuse the screen real estate that OS X carelessly occupied. I could customize the interface in XP by turning off any of the visual effects I found overly gratuitous. I missed that level of control in OS X.

Whenever I pulled the G4 out of the closet, it felt like the OS just got in my way. It didn’t allow me to accomplish a task without concentrating on the awkwardness of the OS itself. By this time, I knew Windows inside and out — how to manipulate it and make it work for me. In OS X, it seemed I was always scrolling to find something. Nothing ever fit on the screen, even though the PowerBook screen was 3 inches larger (and 128 pixels wider) than my Vaio. I had no reason to go back. I was completely comfortable with Windows.

Admission

At what point did I realize the problem? This required admitting a problem might actually exist. Was there one? After enough friends and colleagues expressed their surprise and dismay in the depth of my dependency on the Windows environment, I started to wonder.

The first step toward recovery is admitting the problem.

Could such a reliance be harmful? Had I gotten sucked too deep down the hole? It was time to step back and start evaluating. Time to consciously reconsider my dependency and take another look from the outside. I’ve always had intrigue with the new Mac OS, and a fascination that Apple chose to base its underpinnings on open source software. But I hadn’t taken the time to give up what I used to know so well about OS 9.

Last weekend, I took my first two steps and reopened my mind to other possibilities. I bit the bullet and upgraded the G4′s OS to version 10.2. I also picked up a copy of David Pogue’s Mac OS X, The Missing Manual. It’s taking me time to relearn something so entirely foreign. But I’m quickly discovering the reasons behind the changes, and the advantages and power of this new OS.

As I acknowledge the problem with one drug, I’m only attempting to replace it with another. I’m learning how Apple can help temper my dependency on Windows. But I won’t ever be able to escape Windows entirely. It’s ubiquitous. No matter when, or how much I turn back to Mac, I’ll always be a recovering Windows user.