It has been more than 8 months since www.yola.com went live with a redesign, built and designed by a small team of people here in Cape Town.
Before we started the build (after months of design by committee), a simple decision was made: Let’s abandon Internet Explorer 6. This simple decision has had a significant impact on our development and design work at Yola, all for the better.

The effects of IE6 on a company

IE6 affects many areas of a web development company, not just its engineers. You’ll feel its cold, evil touch in:

• Product and Design
• Development / Engineering
• QA
• …and even Customer Support.

Let me explain…

The influence of IE6 on web design

Any good web designer will tell you how limiting it is having to design with IE6 in mind. IE6 feels boxy, slow and above all else: ancient. One of the single biggest limitations it has (from an aesthetics point-of-view) is the lack of native blended transparency support typically afforded by PNG-24.

IE6 adds obstacles to the QA cycle

Not only do your QA engineers have to have an additional IE6-ready VM (or physical machines if you’re kicking it old-school style) but so too do your developers.
IE6′s impressive list of 119 bugs are encountered any time you, for example, use a CSS float or influence an element’s box properties. Testing in IE6 is relatively easy, when it works, but debugging is another matter entirely.

IE6: the thorn in the side of every web developer

Microsoft created the Developer Toolbar for IE 6 and 7 (which feels archaic compared to Firebug). Without this toolbar, simple as it is, dev-life would be even harder working with IE.
If you work towards Standards-based HTML and CSS development, your handiwork will look great in Standards-compliant browsers, and then completely crap in IE6 – often causing a refactoring of the CSS and HTML so that sensible IE6 fixes can be applied.
To add to the frustration, the fixes for IE6 incompatibility are typically inconsistent and unreliable. Take our blended transparency issue above… Developers usually get around this IE6 limitation by using png-fixes – which lead to more headaches – try using a pngfix on a blended background image with an offset background-position!

Dealing with IE6 users

Bugs do sometimes slip through to production environments, and these bugs usually occur in IE. Those poor Customer Service people have to deal with IE6 too, but primarily through its frustrated users.

What did we gain by dropping IE6?

I think the primary benefit for me was the reduced frustration. IE6 is incredibly frustrating to develop for, which is a feeling so contradictory to the one accompanied by building a well-mannered website.

So, a rudimentary list of benefits in dropping IE6 support:

• Fewer design limitations allowing design work to push the envelope
• All supported browsers can now use blended transparency without the need for hacks / fixes
• Improved development turn-around times – less time wasted by testing and fixing IE6 bugs
• Fully native CSS1, greatly improved CSS2.1 and even improved native CSS3 selector support!
• Improved CSS selector support puts less strain on HTML development
• One less VM for QA peeps and Engineers
• One less browser officially supported by CS peeps
• …and less frustration!

Someday I’ll create a nice fat blog post on the CSS selector changes we saw. (It makes me giddy just thinking of the impact this has had on the CSS and markup development for yola.com)

To conclude

Some web developers will be locked into IE6 for good, others will find it worth the effort to develop for. All I can say now is that I’m glad we turned our back on IE6, in a way, we’re doing our part to make IE6 less of a necessity on the web.

CSS Reset

Eric Meyer is one of the original Web Standards Gurus. His work is good, and pure, and great time savers for us minions. Case in point: Eric’s work on reset.css.

What reset.css essentially does is set a common foundation in all browsers by removing the browser’s default rendering of HTML elements.  This makes it easier to author a web document so that it can look very similar in each separate browser.

The problem

I’ve been happily using reset.css on many projects, never noticing along the way the time I’ve spent on redefining margins on <ul> and <p> elements – time that could have been saved by defining a ‘Sensible Default‘.

Here’s an example…

ul {margin:0; padding:0; list-style:none; /*etc*/}

Reset.css would set all Unordered-Lists (<ul>) to have no margins, and no list-style.  This was great for defining semantic menus in the navigation and footer blocks, but…
the rule would cascade! (DUH!) and each time I wanted to have default rendering of a <ul> I’d have to define it explicitly. This situation would be exacerbated for each case when an <ul> needed to be displayed as expected, e.g. in a sidebar:

#sidebar ul {margin:1em 0 1em 2em; list-style:disc;}

The situation

I started working with Christo on a Django web-app, where I basically had to handle the templates, HTML and CSS + Supporting Images. I was using reset.css as normal.
Christo started voicing his frustrations with having to rely on me to define each and every case where a paragraph was needing margins, or an unordered-list was missing its bullets. It came down to a point where he asked me to remove reset.css. My Standards Zeal kicked in and I refused it, saying I’d have to create more exceptions than the rule by not using reset.css.
It ended up in a stalemate, so I thought I’d open up the dialogue to the StackOverflow audience. I put together a quick question and waited 24 hours for the answers to roll in.

Enter: Sensible Defaults

It turns out that the practice of defining Sensible Defaults is a common Programming tip. (This just goes to show my lack of formal programming experience!) Defaults can save a lot of headaches, and this situation of mine was no different.

The solution

Christo and I met half way by overriding the Reset rules just for the content area.

#content ul {margin:1em 0 1em 2em; list-style:disc;}
#content p {margin:1em 0;}
/* etc */

This way I could rely on Reset.css to ease the styling of header and footer elements, and then reset the reset by providing default styling to any content items such as paragraphs and unordered-lists.

TLDR? A warning as a conclusion

So, if you want to use reset.css then please, do The Right Thing™:

• Don’t be an idiot and implement something without understanding it
• Define sensible defaults for where they’re needed.

That is all.