John discusses some new ECMAScript 5 features: strict mode and native JSON parsing. (It should be noted that IE8 is said to contain the latter already, though I haven't tested it yet so I can't say whether it adheres to the proposed implementation completely.)

Andy Clarke discusses possible solutions to the IE6 problem, and then highlights his own: create one Universal Internet Explorer 6 CSS file that will give any page a nice-but-basic typography and margins, but no layout or grid at all.

Interesting idea. We'll have to see what clients want (or whether they'll notice), but it sounds like an excellent intermediate solution between "don't bother with IE6" and "make IE6's rendering pixel-perfect".

Blackberry to support W3C Widgets in the future? Of course this article doesn't give technical details, but the inevitable figure with the boxes and arrows pointing anywhere does seem to sketch a widget context.

Initially he proposes reading out support for certain CSS declarations in JavaScript (i.e. if the browser supports element.style.marginLeft it supports margin-left). I disagree strongly: you're only testing whether a certain JavaScript object exists, and that does not necessarily say anything about CSS.

Fortunately Kangax is aware of this limitation:

A mere existence of a CSS property doesn’t tell us about an actual implementation and its conformance to a specification. A browser might have “borderRadius” property with a proper string value; it could allow to assign to that property and even set its value to a specified one after assignment; yet, it could never make borders rounded.

As far as I'm concerned this means that the testing method Kangax proposes is unusable in practice.

If you want to test border-radius or margin-left, create a CSS test case and look at it. You'll quickly see if it works or not. Don't try any automated testng, though. It's just not reliable enough. Ever.

This rule is especially important on mobile phones, where we can't be sure of anything. I will continue to test exclusively by hand.

Stefan Kolb, one of my co-workers at Vodafone, has conducted a selector performance test for seven JavaScript library versions in the Vodafone Widget Manager, which runs Opera Mobile, on ten different Symbian S60 phones.

For now it is clearly visible that some frameworks perform better than others in terms of DOM selection. By far the slowest framework in my tests across all devices was the YUI v2.7.0 framework. The fastest frameworks were the two version of the Dojo framework, with version 1.3.0 performing slightly better than version 1.2.3.

It is also clear from the results that the performance depends on the mobile device. The Nokia N73 was the slowest phone, no matter which framework was tested on that device. The fastest phone was the Nokia E66, closely followed by the Nokia N85.

Hopefully, the tested - well established - web frameworks will soon be optimized to perform better on mobile phones. After that, I am sure, they will be of great value for the mobile widget developer, just like they are for web developers today.

Obviously, we need many, many more performance tests before we can say which library is "best" on mobile phones. Still, today we've made a start.

Steve explains how script tags block other downloads in older browsers, although newer ones (IE8, Saf4 and Chrome2) do not block downloads, though they still may block rendering. Finally he gives a few possibilities for loading scripts in a non-blocking way.

Jeremy Keith is very upset about the slow and agonising death of Geocities.

You may not care about Geocities. Keep in mind that this is the same company that owns Flickr, Upcoming, Delicious and Fire Eagle. It is no longer clear to me why I should entrust my data to silos owned by a company behaving in such an irresponsible, callous, cold-hearted way.

Frankly, I think the fault wholly lies with people who put their data only on an external site. If the data is important to you, keep a local copy.

That's exactly what I do with my presentations. Although I recently joined SlideShare and will continue using it, the official, canonical PDFs of my slides are stored right here on QuirksMode.org. That automatically solves any future problem that might occur with SlideShare.

So I disagree with Jeremy here; if you don't want to lose your data, retain a local copy. Simple as that.

Jonathan admits he doesn't like the module pattern (use private variables and functions within a parent function, then return an object that contains public functions).

His main reason is that he wants to extend the modules later on, after the initialisation. Right now I'm wondering why we couldn't just add all functions we need to the initial function. As a reason, Jonathan quotes "Aspect-oriented Programming"", a technique I've never heard of.

For the moment I disagree with Jonathan, though that's partly because I don't have enough information.

Tim Cameron Ryan has written a script to work around the differences between an IE Text Range and a W3C Range. I applaud his courage; I once considered doing this but the incompatibilities were terrible and I decided I needed a little more practice; practice I never got because my career started moving away from production coding.

John Allsopp interviews Pete LePage; among other things about the IE8 compatibility modes.

EmulateIE7 is not truly equivalent to testing in IE7, but it’s pretty close. When building Internet Explorer 8, we were able to version the layout and rendering engine, but it was impractical to version the entire end-to-end system; for example the networking stack, parser, security fixes, HiRes layout, JavaScript engine, some DOM APIs, etc… In practice, though, we've found that IE8 Compatibility View works extremely well for most sites. For most cases, this should be enough, and for final verification, we provide the VPC images that you can download and test with a clean version of Internet Explorer 7.

Although this is probably not what web developers want to hear, I'd say let's give them a chance — until really, really serious incompatibilities between IE7 and IE8-as-IE7 are discovered.