It was fast. Anticlimactic, really. It took a few reloads to get the Comic-Con International home page up, but once I could click on the reservation link, everything went smoothly. I was done by 9:05.

The reservation page was actually optimized!

  • Just one image: a banner across the top.
  • Everything was on one page, including the list of hotels, the personal info, and the hotel choices.
  • Hotel selection was done by client-side scripting, so there was no wait for processing between selections (and no risk of typos confusing their processing system later today).

This is a huge deal, especially compared to Travel Planners’ horribly overdesigned 2008 forms — yes, forms, plural — that kept bogging down. (I never even saw last year’s, though I tried for an hour and a half to get in.)

On the downside, that one page does load a half-dozen script files, but that doesn’t seem to have slowed it down much.

In case none of your 12 choices were available, they asked for a maximum price you’d be willing to pay for another hotel that’s not on your list. I vaguely recall this being a feature of the old fax forms, but I don’t remember being asked this on the phone last year.

I was surprised to find that they didn’t want credit card info immediately, but that’s good from a streamlining perspective as well. The hotel choices, room type, and contact info are critical in order to make the reservation in the first place. Payment can be done later, so in a rushed situation like this, it’s better to handle it later. Plus, not asking for credit card information means that they could run the site without encryption, speeding things up a bit more.

I would have liked to have gotten a confirmation number for the request, or an email, just so that I could be sure that I was in their queue. And to be sure that I entered the right email address. And the right start and end dates. And…well, you get the idea. I’m a little paranoid about the process at the moment.

Here’s hoping that the back end of the process, and sending out confirmations, goes as smoothly as the front end did.

Update: Short answer: it didn’t. Long answer: I’ve written up what went wrong, at least from the guests’ point of view.

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?

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 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.)