Category Archives: Web Design

Recent Links: Comic Strips, Moon, Hotspot Safety, Flash Forward and More

Comic strips and art:

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!

Tech stuff:

Mobile Web Layouts vs. the Viewport

A few years ago, I tried to give some of my most-used websites a nice, clean look on mobile browsers by adding a stylesheeet with the “handheld” type. Then the iPhone came out and ignored them, and everyone copied that behavior, making it useless.

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.

IE9 vs. WordPress’ Twenty-Ten

As usual, the first thing I tried after installing the Internet Explorer 9 beta last week was to see how it handled all of my websites. It does just fine with everything except this one. It shifts the header image off to the right. This is particularly odd because it’s just the standard Twenty-Ten theme that’s the default for WordPress 3, customized with one of my own photos.

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.

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.