I have as much dispute with IE6 as the next guy - there's no denying that it's holding us back and we'd be better off without it - and I fully support non-disruptive evangelism efforts that encourage IE6 users to upgrade to a modern and more secure browser. It's in their best interest after all.

But the notion that IE6 support should be discontinued, or that its users should be blocked, is dangerously misguided and missing the point. IE6 isn't your problem, and you shouldn't even maintain a list of supported browsers in the first place. If you think I'm talking to you, continue reading.

Via Inclusive Web Design For the Future (by Steven Champeon & Nick Finck):

The goal of Web design is not merely to dazzle, but to deliver information to the widest audience possible. Compromise is possible and desirable, but such compromise should not come at the expense of the user, but rather in terms of the native capabilities of the user's choice of device.

As someone that designs and develops online, one of my primary responsibilities is to deliver an accessible user experience. To my users, and not their choice of access. Their media device, operating system, browser, screen resolution or viewport - there's no denying that these factors should be considered when planning a new project, but they shouldn't ever be treated as constraints that place limitations on the interface or experience. They are merely variables that come together in any number of ways for any number of users. And although you can trend and analyse them today, they will undoubtedly change tomorrow, and next week, and month, and year... you get the picture.

If you think IE6 is today's problem, how will you deal with IE7, Firefox 2, Safari 3 or similar browser generations a year from now when they fail at rendering your standards-compliant CSS3? Cry foul like a stuck record from a bygone era and demand that your users upgrade once again to meet your standards? No, I didn't think so.

Then what's the alternative?

So glad you asked - progressive enhancement of course!

Before you point fingers, I'll be the first to admit that I'm not exactly a PE poster boy candidate. Using this site as a quick example - I built it with best intentions just under a year ago, and despite saying then that I'd adopted a PE strategy, there are so many things that I'd do differently today. But in my defence, that's the very nature of designing for the web: a continuous cycle of learning, adapting and growing.

So PE isn't new to me, but adopting it's methodologies into my workflow has taken longer than I'd like, only because it demands changing a system that I've spent a long time refining, and these changes demand free time that I generally don't have. But with every new project, I take another step closer towards PE utopia. I'd say I'm currently bordering on a solid progressive enhancement strategy, while some thinking around the defunct graceful degradation approach still remains.

See Understanding Progressive Enhancement by Aaron Gustafson for an overview of the subtle differences between the two concepts.

Both graceful degradation and progressive enhancement consider how well a site works in a variety of browsers on a variety of devices. The key is where they place their focus and how this affects workflow.

Although I don't appreciate the sweetness offered by the M&M anology, the article does a good job of introducing the two important follow-ups: Progressive Enhancement with CSS and Progressive Enhancement with JavaScript. Definitive reading!

Ultimately, you will need to take the basic principles and adapt them as best you can into your workflow, all within context of course (if you exclusively develop intranets for IE6 then don't bother). For example, the biggest changes that I've made include:

• Adopting a JavaScript library - together with behavioural separation, jQuery provides me with powerful, unobtrusive and accessible methods for manipulating style and content. I swear by it, but I'm careful to not rely on it.
• Resetting my CSS: see Eric Meyer's Reset Reloaded (and Again) as a starting point, or A Killer Collection of Global CSS Reset Styles if you have the time.
• Sizing my layouts and typography using ems - How to Size Text in CSS (by Richard Rutter) is invaluable.
• Using conditional comments to target IE6 and IE7-specific CSS for style compatibility. Familiarise yourself with IE's hasLayout too - adding one simple rule to your conditional CSS will save you a lot of trouble and time.
• DD_belatedPNG - Medicine for your IE6/PNG headache! - the holy grail of PNG support in IE6
• Being comfortable with the idea that despite the above points, my interface designs are secondary to the content that they deliver. They will never render consistently for all users - but then, they won't know the difference anyway.

And there you have it! No more reason to blame IE6 for your laziness or reluctance to adapt. If you're not convinced, have your say in a comment. I'd also love to hear if and how you're using PE in your own work, or any experiences worth sharing.

More reading:

• Pragmatic progressive enhancement  - why you should bother with it (by Christian Heilmann)
• Creating gracefully degrading javascript and enabling progressive enhancement (via Mark Story)
• Progressive enhancement in action (via Nvision)

h1 { display: inline; }

Brilliant, I can't believe I'd overlooked that.

I've used the word 'viewport' in the context of the browser size and not screen resolution.

If you can't figure out the rendering differences between the techniques, you may want to try each at different viewport sizes (increase your screen resolution and/or browser width) and at different browser text sizes. Use this bookmarklet (drag it onto your Bookmarks Toolbar or into your Favourites) to easily resize your browser width.

I'd like to keep this list fresh, factual and unbiased - please comment or drop me an e-mail if you have something to contribute. And no debates over personal preference, please.

1. Fixed: layout is determined by absolute dimensions, typically to fit a viewport with a width of around 800 pixels. With 1024x768 resolutions gaining popularity, there is a growing trend to design exclusively for this size.
   
   Pros: Easy to implement.
   Cons: Supports single scenario only. Typically breaks when browser text size is adjusted.
   Examples: news.com (800), download.com (1024), theonion.com (1024), macromedia.com (800), 24sata.hr (1024), bmw.com (1024)
2. Liquid (aka. Fluid): layout is determined by relative dimensions, typically percentage values to fit 100% of the viewport.
   
   Pros: Accommodates all viewports. Larger volume of content is viewable without scrolling. Scalable and flexible for forward-compatibility.
   Cons: On wide viewports, readibility suffers from long lines of text.
   Examples: wired.com, sercotransarctic.com
3. Resolution dependent (by Cameron Adams): varying layout according to viewport width. When the width is adjusted, the layout is dynamically adjusted accordingly. JavaScript required, but degrades gracefully.
   
   Pros: Full control over how changes in the viewport have an effect on the content. Flexible.
   Cons: Time-consuming, more maintenance required.
   Examples: Author's demo, rammstein.com, smh.com.au, microsoft.com (last two require browser reload).
4. Elastic (by Patrick Griffiths and more recently, Roger Johansson, and again by Douglas Bowman): resizes to browser font size. Similar to Opera's zoom function.
   
   Pros: Takes the user's preference into account. Flexible. Accessible.
   Cons: Time-consuming, more maintenance required. Difficult to make images scale.
   Examples: mozilla.org, yahoo.com, aol.com, Elastic Lawn (CSS Zen Garden)
5. Jello (by Michael Purvis): a combination of Fixed and Liquid.
   
   Pros: Scalable and flexible for forward-compatibility.
   Cons: Steep learning curve.
   Example: Author's demo.
6. Progressive (by Alessandro Fulciniti): a combination of Fixed and Liquid. A Fixed layout under and over certain pixel widths, while Liquid inbetween. JavaScript required, but degrades gracefully.
   
   Pros: Scalable and flexible for forward-compatibility.
   Cons: Steep learning curve.
   Example: Author's demo.
7. Constrained (aka. Untitled): Liquid layout up to a maximum pixel width.
   
   Pros: Scalable and flexible for forward-compatibility.
   Cons: uses IE's proprietary CSS rule to emulate max-width property.
   Example: This site.

I've added my RSS feed buttons to my home page, and having said that, there's a new feed for my weblob. The protocol for my feed links is 'feed://' - should I change this to 'http://' instead?

I've really taken a liking to RSS since switching to Thunderbird, because I don't need to run a feed reader in addition to everything else.

I'm playing with the CSS3 opacity property in places - for example in the nav menu, and the blog pic image (camera icon) above - if you mouseover either they'll change from being semi-transparent to fully opaque. This property is supported in Mozilla 1.7+ and Firefox 0.9+, I'm not sure about other browsers.

The search form on my home page has moved higher up the page for more prominance, and now includes the option to search my links. I'm using a cookie with the search now to work around a problem with losing the POST variables when the page is automatically reloaded.

I'll try explain. My search forms submit to '/search'. To include the search term in the results page URL, I reload the result page if the term isn't already included in the path, to make it for example: '/search/design'. This means I lose the POST variable storing the type of search, ie. either 'blog' or 'links'. The cookie expires 5 minutes later. I'm open to suggestions for improvement.

I've also added a full calendar to my archive page. I still need to make the calendar on my blog page more dynamic.

Before you click anywhere, pick apart my code or run it through any validators, you should know that this is something of a beta version. I've done almost no cross-browser testing (I'm aware of some behavioural glitches & twitches) or any other form of QA. What I have done however is completely overhaul the backend, improve functionality, add features and finish my portfolio!

You'll also notice the new "projects" menu item. There are a couple of things I'll be adding to this section in due time, but for now it's empty. My weblog now has it's own home - http://coda.co.za/blog - where you can view the latest 10 posts, or search the archives (although the calendar feature doesn't work yet). Otherwise the structure has remained completely intact.

My intention with this home page, as mentioned previously, is to place a stronger emphasis on my portfolio, photography and projects. Also, the introduction copy is permanently visible unlike this design's predecessor. The image between the menu and intro copy will change over time. I might even integrate a user upload function.

Also worth noting: I've added an e-mail form to my contact page, search keyword(s) on the result page are now highlighted, and my portfolio is now partly database-driven which will allow for more flexibility in the future.

Design Notes
I've changed fonts: I'm using Lucida Sans Unicode for body text, Century Gothic in my logo-line and page headings, and Georgia for blockquotes.

The width of this site does not exceed 980px - I've used the max-width CSS property for browsers that support it, and for IE I've used a proprietary expression to achieve the same effect. My primary reason for taking this approach is that users with resolutions of 1024x768 or larger will view my site at the maximum width, while at smaller resolutions, 800x600 for example, it will downsize reasonably well. In some places, text and images pushed beyond their boundaries will obtain a scrollbar.

Therefore a liquid layout to a certain extent, and a definite improvement on the fixed 800x600 width or smaller designs you see on almost every blog these days, including my previous design. This layout I believe is a much better use of space considering the default dimensions of a web browser.

My new logo, if you hadn't figured it out by now, is a broken "c" - it's that simple.

So this is it. I'll be playing around with a couple of things over the next few months, inbetween backpacking. I'm not sure how closely a redesign of digicam.coza will match this one, but for consistency-sake I'll most likely keep it identical. For now I'd love to hear your initial feedback. Leave a comment or e-mail me with your thoughts.

"It doesn’t help anyone, we’re all aware of our defficiencies [sic], and could probably point 100 more out on top of the 10 you point out. Not only that, but you have no idea what kind of conditions we’re working in, or what else we’re trying to do (or the fact that we’re building a whole new standards compliant, CSS based site behind the scenes, but Rome wasn’t built in a day…at least it wasn’t built properly in a day)."

- more at The Standards Police will get you! by Brian D. Garside.

And my own two cents. Running a website through validation tools and then complaining that they're not standard-compliant is like failing a student in an exam for using green ink.

All of my sites are standard compliant. They might not meet all the validator requirements (due to a few markup errors) but they still work. They're usable, they're accessible, and they're cross-browser/platform compatible. Furthermore I consider the V&A Waterfront project, designed in 2002, as the first major corporate South African website to adopt a standard-compliant design.

Also another CSS site list launched: CssBeauty, which to my delight featured the Serco TransArctic Expedition as their first showcase piece. Thanks Alex!

I'm making progress on my own redesign, which since starting a few weeks ago has subsequently grown into a complete backend overhaul. My goals are best put by the Daft Punk boys: Harder, Better, Faster, Stronger. I've decided to place less emphasis on my blog and more on my projects, portfolio and photography this time around, while improving user interactivity and general IA.

I've wanted to link the following site into a post for a while now: Jeedoubleu, by Greg Washington, is one of the smartest flash portfolios I've ever seen. If only he could lose the "Think outside the box" cliché.

Malaysian Andy Lim has some sweet underwater photography - check out his Sanctuary Under the Sea.

Lastly, some photos I took this morning after 3am, shortly before sunrise. I first assumed they were strange cloud formations but concluded they're airplane exhaust trails - they stretched from one end right across the sky to the other, in perfect parallels. I could be wrong; you decide. Excuse the poor thumbnail quality, I can't figure out why that's suddenly happening.

Apart from the V&A Waterfront which I built the previous year with an HTML 4.01 DOCTYPE and which uses a single table for the site-wide, fixed 2-column layout (although the entire presentation layer is styled with CSS), the Teamscience site was my first step up in pushing ahead from HTML to XHTML and using only CSS for layout. Looking back at it now, the markup could be improved so that it degrades in older browsers better and embedded Flash tags updated so that the pages validate as strict XHTML 1.0 - but considering the number of sites that had switched over at that stage I'm still happy with the result.

Be sure to check out dezwozhere.com's list of CSS, Accessibility and Standards links for some great resources, while his blog is worth a read over too.

And a great site I've failed to mention in the past which has become the largest advocate for CSS-based layouts is the css Zen Garden - "A demonstration of what can be accomplished visually through CSS–based design". One in particular - Gemination - caught my eye: load it up in any standards-compliant web browser, and then load it up in Internet Explorer. As extreme as this example might be to showcase the real advantages of the technique, MOSe is really worth investigating.

Anyway, this week I've re-discovered probably one of the most under utilized features of the Mozilla browsers, despite having mentioned it here before: Ad Blocking.

There's nothing more annoying that a flashing banner ad placed smack-bam!! right in the middle of an article you were trying to read. Nobody likes banner ads. So having applied the multiple ad-blocking techniques described by Blogzilla, I've decided to provide the following quick demonstration: a before and after scenario of a randomnly-chosen *wink* MTV.com article page.

Gaming site IGN.com is also notoriously bad for it's ads - you have to see a huge ad even before entering the site (it will cost you to disable it), while upon entering you're faced with a horde of ads and popup windows. See the before and after.

It works just as well on other sites: CNN.com before and after if you're still not convinced.

Using a personalised userContent.css file (based on this one) and by enabling the other ad-blocking preferences, Mozilla successfully hides all banner ads from displaying.

It's ridiculous that websites offer it's users, who unfortunately don't know any better, the chance to remove banner ads as an incentive to subscribe to their services, when Mozilla does just that at no cost: it gives it's end-users the power and control to personalize how they experience the web.

You can compare the two versions here: Original (69 kb) vs Standards-based (43 kb).
The standards-based page validates as compliant HTML 4.01 Strict and CSS2.

That they look identical is simple proof that tables are not necessary for site layout.

The idea with this case study is to prove that using standards-based markup, IOL could effectively reduce each of their pages by 26 kb or more - and considering they are one of South Africa's highest ranked websites in terms of visitorship, the amount of money they would save on bandwidth could add up to be quite a suprising figure.

MACCAWS have just published an inspiring list of high-profile Standards Sites, definately worth checking out if you're still unconvinced that standards are the way forward.