One of my readers, René, asked me if my FlashScaler JavaScript class works with SWFObject 2. I’m happy to say that yes, it does. The demo and download on my original FlashScaler post now include working examples using SWFObject 2.1.

Recently I was developing a site for a client whose primary export market is in China. Needless to say I was a little alarmed when my client’s representatives in China reported that they couldn’t access their new website.

My client has reps in both Shanghai and Beijing, neither of who could see the website, so I knew it wasn’t a localized issue. My immediate suspicion was that the infamous “Great Firewall of China” was to blame. Thankfully I was able to take a few simple steps to diagnose the problem and get the site up and running.

It seems as if someone has finally cracked the problem of running multiple standalone versions of Internet Explorer under Vista.

In my last post I outlined some of the problems that might arise from the proposed version targeting changes to Internet Explorer 8. My major concern was that by removing the motivation for web authors to update legacy sites, version targeting might hamper the adoption of modern web development techniques. During the week I have given some more thought to this issue, and it occurred to me that in Adobe Flash we have a fantastic real-world test case from which we might learn if version targeting is a viable strategy for a web browser.

When Dean Hachamovitch demonstrated in December that the forthcoming Internet Explorer 8 browser passed the Acid2 test in standards mode, there were calls for Microsoft to clarify if “standards mode” was the default setting for IE8. Last week it was announced on A List Apart and the Internet Explorer blog that IE8 will render pages using an IE7-level rendering engine by default, and that web developers must opt-in to take advantage of the new Acid2-compliant rendering mode.

Basecamp is the grandaddy of online project management applications, but I recently discovered that its little brother Backpack can also hold its own as a project management tool.

If you’ve read any web design blogs during the past week you will no doubt be aware of the hornet’s nest that has been stirred up by Opera’s antitrust complaint against Microsoft. The issues at stake go well beyond Opera’s attempt to put a dent in Internet Explorer’s market share, and commentators have been quick to point out the ramifications for web standards, and the organizations that govern them.

Over at roScripts there is a nice tutorial explaining how to modify my FormBuilder PHP class so that validation is performed unobtrusively using AJAX. Check it out.

Reading though a preview of the HTML 5 specification over at A List Apart, I was somewhat surprised by the names chosen for two new HTML elements: header and footer. Like many other standards aware web designers I have worked hard to train myself out of the habit of naming divs non-semantically, only to discover that HTML 5 will undo all of my good work.

When I started out as a web designer, content management systems belonged strictly to the realm of big budget websites. For everyone else, it was perfectly normal for a web designer to manually update a site whenever a change needed to be made. Clients didn’t expect a CMS to be included with their website, and web designers didn’t offer the option. Times have certainly changed, and in an age of blogs, Facebook, and MySpace, clients expect to be able to take control of their website’s content.

For most web designers, especially those who work solo, a custom built content management system is still a tall order. Fortunately there are numerous commercial and open source content management systems available, which offer a practical and affordable means of wrangling content. However, a “one size fits all” content management system that doesn’t address a site’s specific content requirements can introduce as many problems as it solves.