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.

I usually use the WDG Offline Validator as a first line, but the W3C’s tools are incredibly useful. #

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.

Now the first IE8 beta supports Webslices. They’re similar in concept, but can include formatted data (not just plain text) and use microformat-like markup on the web page instead of a <link> element in the head.

I figured with two browsers supporting the concept, I’d give it a shot. I adapted the script I use to generate the RSS feed so that it will also take everything on the most recent day and generate a text file, which is used for the Microsummary title. For the Webslice, to start with I just marked up the “Latest Updates” section of the home page. Since I haven’t installed IE8b1 at home, I’m using Daniel Glazman’s experimental Webchunks extension for Firefox to try it out. Unfortunately the extension doesn’t seem to resolve relative links in its current state.

The real question, of course, is whether either technology offers anything better than what feeds can do now.

I think I’ll end up going the external-feed route for the Webslice as well, since it’ll use a lot less bandwidth than having a bunch of IE installations pulling the entire home page once a day. Plus since I’m using SSI on that page, it doesn’t take advantage of conditional requests and caching, and a static file will. But that’ll have to wait. Lost is on in 2 minutes, and after getting up earlier than usual this morning, I’ll probably be going to bed right after the show.

Update: I checked in IE8, and the webslice does work as expected. A few minor differences: Webchunks pulls in external styles, like the background and colors, while IE8b1 only uses styles in the chunk itself. Interesting bit: I’m marking up list items as entries, and IE8 is actually displaying them as a bulleted list, while Webchunks is simply showing the content.

So it at least works. Maybe tonight or Sunday I’ll see if I can refine it a bit.

Way back when, I put a simple app on my Flash site: a team-name generator for teams of speedsters. It randomly generated a name from two lists, and provided a button to generate another one. I originally wrote it in PHP.

The funny thing was that it was the most-hit page on the site, because people would sit there and hit the button to generate a new name half a dozen times before moving on. And because it was a sever-side script, that meant not just another HTTP hit, but re-downloading the entire web page with only 2 words being different.

Eventually I realized it was much better suited to a client-side app. I rewrote the whole thing in JavaScript, using DOM functions to replace the name on the current page instead of reloading. I left the hooks to the PHP in place, so that it would still work for clients with JavaScript disabled.

• It was much faster — practically instantaneous, in fact.
• It used a lot less bandwidth — 40 KB (5 KB × 8 ) vs. 6 KB (5 KB + 1 KB) for a typical 8-name* scenario.
• Traffic stats more accurately reflected the page’s popularity, as it dropped from #1 to around #30–50.

* Based on a drop from 32,000 hits/month in July 2006 to 4,000 hits/month in September, with the rest of the site staying about the same, it seems people were hitting reload 7 times.

Over the last year or so, WordPress and A List Apart have converted me from “stick with the lowest common denominator” to “let’s show real typography.” Since the days of the Demoroniser, Unicode has become a standard part of HTML, so modern browsers* can either display a full range of characters or convert them to something they can display. You probably won’t be able to see Chinese text in Lynx, but a properly encoded curly quote—“ or ”—will show up as a plain old ".

For one thing, real typography looks much nicer. An actual “—” looks more professional than “--” does. Curly quotes are also more readable than straight quotes. Take this series of titles, first with curly quotes and next with straight quotes. With curly quotes, it’s easier to tell which pieces of text are inside the quotes and which are outside:

“Blah blah one,” “Another title,” and “Yada yada.”
"Blah blah one," "Another title," and "Yada yada."

Indispensable resources: Commonly Confused Characters and The Trouble with EM ’n EN are great for figuring out just which dash to use where, and also to get the codes right (if your authoring tool doesn’t take care of it for you). Evolt’s Character Entity Chart is helpful for looking up codes and for checking just how much your browser can (or can’t) handle.

So, reminded of the existence of the Demoroniser, I looked for a Unicode-aware update. The original script remains ASCII-only, but I did find the Unmoroniser, a modified version that converts the problem characters to the proper HTML entities instead. Accompanying the script is a rather long but nonetheless amusing rant on why this change is a good thing.

*In this case IE 5+, Mozilla/Firefox/Netscape 6+/etc., Opera 6+, Konqueror 3+ & Safari should have no problems. Netscape 4 manages the basics, but many characters only show up on Windows or don’t work at all.