As explained in the mouseover text, the title refers to the idea that because animals have different senses, each animal effectively inhabits a different reality. This can philosophically be extended to human perceptions.

Keeping that in mind, make sure you read it in a few different web browsers (both desktop and mobile!) for the full effect (JavaScript required). And try resizing the window.

As an art project, it’s the best use of browser-sniffing I’ve ever seen.

• SMBC: Where does the time go when you play online games?
• XKCD: Server Attention Span
• The Joy of Tech: The Internet is running out of tubes. (via @brionv)
• Classic Spamusement: They hold a whole lot of it. I had no idea….
• Bizarro on Facebook slacktivism (at Failblog).

Sci-fi and fantasy:

• Keeping Up With the Cardassians. For months, this is what I heard every time someone mentioned the Kardashians. (What can I say? My brain is more attuned to Star Trek than to reality TV.)
• Author Robert J. Sawyer answers pointed questions about Flashforward and the TV adaptation, including what went wrong. I have to agree that it was really hurt by focusing too heavily on the conspiracy arc.

Coolness!

• Discovery spacewalk seen from the ground (Thierry Legault, of course!)
• Majestic Snow Batman towers over Vermont
• Ultra hi-res moon. The full-sized image is 24,000 x 24,000 pixels and half a gigabyte!
• Flash Coffee is a product tie-in just waiting to happen! (That F’ing Monkey). It would fit right in with the Central City Track Team shirt.

Tech stuff:

• Gmail accidentally reset thousands of accounts last month. (They got it back — this is Google after all.) I’ve come to rely heavily on Gmail, but I still keep a local copy of all my email in case something like this happens. (Engadget, via @pobox)
• 6 ways to use public Wi-Fi hot spots safely (C|NET).
• Mobile Content Is Twice as Difficult (Jakob Nielsen’s Alertbox)
• Map of smartphone marketshare by OS & manufacturer. It’s a 3-way split between iPhone, Android and Blackberry. iPhone & Blackberry are of course one manufactuer, while Android is divided mainly among HTC, Samsung and Motorola. (via @androidandme)
• Things Real People Don’t Say About Your App or website (via @brionv)

Somewhere along the line, I revisited the same CSS techniques, but used the “max-width” media query to change the layout on smaller screens. This seemed even better in the long run, since screen size matters more than whether a device is a desktop computer or a handheld computer. (The iPad was nothing but a long-standing rumor in those days, but demonstrates this clearly.)

The raw screenshots (click to view) are slightly larger, but since mobile devices often have denser screens, if you’re reading this on a desktop, it’s probably about the same physical size.

That worked great on the iPhone, and on the G1, which I updated through Android 1.6. I stopped testing it after a while, and no one commented on it, so I figured it was still working. (Reminder to self: that’s always a mistake.)

Last week I got a G2, which came with Android 2.2. Last night I visited one of my websites, and was presented with this shrunken, unreadable mess…because Android doesn’t actually use the real screen size anymore. It pretends it has a bigger screen so that it can present a desktop-like view and then let the user zoom around. Mobile Firefox does the same thing.

<rant>Why is it that every time I find a clean technique to use the same markup on both desktop and mobile devices, some browser manufacturer decides to bypass it in favor of giving the user a clunky imitation desktop view instead of one optimized for their experience?</rant>

*ahem*

Anyway, it turns out it’s possible to fix this problem with the <meta viewport tag> as shown here:

<meta name="viewport" content="width=device-width">

So I can provide nice, clean small-screen layouts again…after I add extra markup to every single page that uses these stylesheets.

Problem solved!

Well, almost. It fixes the layout…but it also prevents the user from zooming out for quick scrolling, which can be awfully useful on a long page.

Screenshots of the Barry Allen Flash profile, taken using the Android SDK emulator with stock Donut and Froyo images.

Oddly, it was just fine in the last IE9 preview. Even stranger, the sample 2010 page looks just fine. It’s not my customizations, though. I’ve checked on two other locally-installed WP sites.

There’s a short discussion thread at the WordPress forums, and a bug report. As of today, it’s marked as fixed, but here’s the question:

Is it worth fixing in WordPress?

I haven’t found any indication as to whether this is a bug in the IE9 beta or a deliberate change. If it’s a deliberate change, it’s an odd one, because it takes behavior that used to be the same as every other web browser out there and changes it to something different. If it’s a bug in IE, though, that’s where it should be reported and fixed, not in just one of the sites affected.

That said, I’m probably going to try the workaround on at least one of my sites the next time I get on a machine with IE9.

In theory this should be simple: CSS handles tables by using the display property and assigning it table, table-row and table-cell for the <table>, <tr> and <td> elements. You can assign these properties to other elements and make them act as tables, or you can assign block or inline to these elements and make the table act like a series of paragraphs.

Initial testing worked perfectly in Firefox 3.6 and Opera 10.5x. Internet Explorer 8, as expected, ignored the changes entirely. Chrome, however, did something very strange, and Safari reacted the same way: The banner shrank, and the columns changed from a narrow sidebar to a 50/50 split…making it actually worse for small screens.

Clearly WebKit didn’t like something I was doing. Unfortunately, WebKit powers the exact platforms I was targeting: the iPhone and Android!

I dug around with the developer tools a bit to see if I could figure out what was going on. Was the browser not applying the property? Were the table cells inheriting the “original” property from somewhere else? Did I need to change properties on thead and tbody as well?

What I found was that WebKit did recognize the display:block I had added, but somehow the computed style was reverting to display:table-cell. This only applied to table and td, though. Table rows actually did what I told them to, which was why the result ended up looking bizarre.

If it hadn’t changed anything, I probably would have chalked it up to the capability just not being implemented yet. But since it worked on table rows, but not on cells, I decided to treat it as a bug in WebKit and went looking for the best way to report it. I ended up creating a WebKit Bugzilla account and reporting it as bug 38527.

Check out the testcase in Firefox 3.6 or Opera 10.5 to see what it should look like, then take a look in Chrome 4 or 5 or Safari 4.

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.

Yes, guestbooks and counters. For WebRing.

The 1990s really are back!