Tag Archives: webdev

Recent Links: Geography, Internet and Comics

A few interesting links that I’ve been meaning to post for a while now.

Geography and History

Using and Building the Internet

  • Warren Ellis has given up on Facebook and Google+ because it’s just so hard to reliably reach or listen to people. Think of how many posts in your news feed you miss each day just by not being online at the right time, never mind the pre-filtering Facebook does to the firehose.
  • Page Weight Matters – an engineer at Google led an effort to cut Youtube’s bandwidth requirements by a factor of ten. Strangely enough, when they started a live test, average page load time went up. It turned out that people on low-speed connections had found out about it and started using it even though it took two minutes to load where they were…because even that was still better than the 20 minutes they’d been stuck with before. (Via Raymond Camden)
  • If you run an email newsletter, keep in mind that many of your readers will try to read it on a phone. Keep that in mind when designing your format. Giant images with no text aren’t going to be too helpful.
  • How to keep electronics going when you lose power for days: Generators, batteries, car chargers, solar or kinetic chargers, etc.

Comics

  • Some of the earliest UNIX daemon art was drawn by none other than Phil Foglio of Girl Genius fame.
  • Saturday Morning in Front of La Salle De Justice is a painting by Rey Taira in DC Comics’ gallery show, inspired by Seurat’s famous painting Sunday Afternoon on the Island of La Grande Jatte (the painting at the center of Sondheim’s Sunday in the Park with George), but recast with the Justice League and other DC Comics heroes. It’s making the rounds again now, but I first saw it on Firestorm Fan a few months back.

Webkit display:table-cell Problem

I recently tried to retrofit a mobile layout onto an old table-based site using CSS. It was a fairly simple layout: A banner across the top, two columns, and a footer. I figured I’d use CSS to “unwrap” the table and make the sidebar and main content area into full-width sections instead of side-by-side columns.

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.

Comic-Con Hotels 2010: Reviewing the Reservation Form

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.

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?