Tag Archives: webdev

Browser Sniffing Strikes Again!

As the first major web browser to reach a double-digit version, Opera has been testing out alpha releases of version 10 for months now. One of the early problems they encountered was bad browser detection scripts that only looked at the first digit of a version number and decided that Opera 10 was actually Opera 1, and therefore too old to handle modern web pages.

After extensive testing, they’ve concluded that the best way to work around this is to pretend to be Version 9.80. From now on, all versions of Opera will identify themselves as “Opera/9.80” with the real version appearing later in the user-agent string.

For example:

Opera/9.80 (Macintosh; Intel Mac OS X; U; en) Presto/2.2.15 Version/10.00

This is similar to the way all Gecko-based browsers identify themselves as Mozilla/5.0, then list the real browser name and version number later on, which makes me wonder why they didn’t just stick with that increasingly irrelevant prefix — though I suppose any scripts looking specifically for Opera versions might have still picked up Opera/10 later on in the ID.

It’ll be some time before Firefox or Safari runs into this issue, but with Internet Explorer 8 in wide release, you have to wonder…what will Microsoft do when they get to IE 10?

Browser Bits

Opera.Firefox.Avenicus compares Firefox 3 beta 5 to Opera 9.50 beta 2 on performance and memory usage. The surprise: Firefox 3 uses less memory than Opera 9.50. Clearly all the work Mozilla has done on cleaning up memory usage has paid off.

Codedread comments on Apple’s Web Inventions.

Asa Dotzler counteracts FUD about the safety of Firefox, Safari, and other alternative browsers. His main point: the key measure of security is not the number of vulnerabilities, but the window of vulnerability: the time between a hole being discovered and the patch getting onto users’ systems. (In addition to a responsive security team, automatic updates really help here.)

In just over a week, Opera’s new developer toolset, code-named Opera Dragonfly, will be ready for an alpha release. This will be a welcome addition, not just for developers, but ultimately for Opera users as well. Obviously, it’ll make it easier for web developers to debug compatibility issues, leading to fewer sites breaking in Opera. But it could also bring more people in. Firefox’s growth got started with recommendations by techies. If Dragonfly proves to be as good or better than Firebug, developers will spend more time with Opera, which could lead to recommendations.

Opera on Acid3: 100% (and now WebKit too!)

Opera BrowserWe may soon have a winner! It looked like WebKit was going to be the first to pass the Acid3 test, passing 98 of 100 sub-tests earlier today, but internal builds of Opera pulled ahead, and have just reached 100/100!

This doesn’t constitute passing the full test, as the resulting page needs to look exactly like the reference image, but it means they’re very close.

These fixes won’t appear in the upcoming Opera 9.5, since it’s in the stabilization phase as it approaches release (just like any new Acid3-related changes in Firefox won’t make it into Firefox 3), but will probably find their way into the next major version.

We’re in the home stretch. Opera’s nearly there, but WebKit is close behind. WebKit could still catch up while Opera polishes off the rendering issues, in which case Safari would be the first browser to pass both Acid2 and Acid3.

Congratulations to the Opera team, and best of luck in the final lap of the race!

SafariUpdate: Just a few hours later, and WebKit has caught up, also passing 100/100. And as they point out, it’s a public build, one you can download and try out yourself! The race to pass is going to be very close. Though at this point, it’s almost certain that WebKit will be the first to be publicly accessible.

(via CSS3.info. More at OperaWatch and The Good Life.)

What’s Dynamic About It?

In my post on Webslices, I mentioned that the home page of my Flash site uses server-side includes instead of a static HTML file. But it doesn’t really update that often: maybe 3 or 4 times a month. Is it really worth building that file dynamically? Should I switch from SSI to something more powerful, like PHP, that will let me add headers so that repeat visitors won’t have to re-download the whole page except when it’s actually different? Or should I switch to a static file, with the same benefits but simpler? What am I actually building, anyway?

Looking through the code, I find:

Browser upgrade banners. People using old versions of Firefox (currently 1.5 or older) or Internet Explorer (currently 5.5 or older) get an “Upgrade to Firefox 2” banner instead of the thumbnail of the current issue of the comic. This is just as easily done with JavaScript—and is done with JS elsewhere on the site. (I used to make some minor adjustments for other versions of IE, but I converted them all to conditional comments a while back.)

Last-modified date in the footer, pulled from the actual file. I’ve already got a script to update this in the static files, so it’s just a matter of adding it to my general update script. A two-minute, one-time change and I’ll never notice the difference.

Latest posts from this blog. Probably better done with an iframe, or maybe using AJAX. Drawback: either method would mean an extra request from the client. On the plus side, repeat visitors would be able to re-use the rest of the page, and only download the 5-item list.

Unique-per-day spamtrap addresses, hidden where harvesters might pick them up. But only a few of them still accept mail and feed it to filters. Mostly, they just waste spammers’ resources. I could easily either get rid of them or change the script to generate a new address with each update instead of each day.

So really, there isn’t much stopping me from using a static file for the most-viewed page on the site, with all the attendant savings in system resources, bandwidth, etc.

On the other hand, I keep contemplating switching to a database-driven system for the whole thing, which would make any changes now meaningless. But since I’ve been thinking about that since around 2000 or so, and haven’t changed it yet, that’s not exactly a blocker!

Update (March 30): I’ve made the conversion to a static file. The blog posts and browser upgrade banners are now done client-side (and run after the rest of the page is loaded), the last-modified date is part of the pre-processing script, and I just removed the daily spamtrap addresses. Now to see whether it actually improves performance.