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.

It turns out that Buzz uses HTML5 features (specifically appcache, database and location) to store local data and to detect your physical location…and those capabilities were added in Android 2.0.

The support thread mentions that they are “working on another version that will make Buzz for mobile accessible on older Android OS versions (and some other smartphones as well).” The browser in Android 1.6 and below supports similar capabilities through Gears, so they may be planning a Gears-based workaround.

This would be a lot less of an issue if it weren’t for the fact that most of the Android phones out there still run 1.6 or even Android 1.5. IIRC only the Droid and Nexus One have officially been updated to 2.0 so far**, so unless you have one of those two models, you’re more likely to get Buzz to run on an iPhone than Android.

Funny, that.

*I’ve got a G1. It can only access Buzz through the updated Maps app, which brought up a bunch of people in nearby office parks posting things like “Testing Buzz” and “WTF is Google Buzz?”

**A few other phones have had updates announced, but I don’t think any have actually shipped yet. I could be wrong.

Political geekery; saw a bumper sticker reading </bush>. Only prob: tag should be <president name="bush">. Did I mention geekery? #

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.

The fact of the matter is, I’m not worried. I tested my personal sites and the sites I’d built for work months ago, using the IE7 betas, and more recently with RC1. I made a couple of minor changes to some stylesheets, but that was about it.

Why? I’ve been writing standards-based code for years. I validate it from time to time, and I test to make sure it works in the latest versions of Firefox, Opera and Safari as well as IE. So the code was already portable.

Plus, anything new I’ve built since January has been designed with IE7 in mind from the beginning.

Most of the changes were to workarounds for IE6. Either stopping them from running on IE7 (if the bug was fixed), or keeping them running on IE7 (if it was done using a CSS hack).

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.

One item I noticed was a copy of the Microsoft Technet Flash newsletter. I thought this was odd, since I’d gotten a copy of the same newsletter and it hadn’t been labeled. In fact, it turned out that my copy only scored 0.3 points, and the other hit 6.4! (5 points indicates probable spam.) What could explain such a disparity?

Answer: two very small differences.

First, it came through a half hour later, after the message had been reported to DCC. Since DCC is technically a list of bulk mail and not a list of spam, it’s theoretically not a false positive. That added 1 point.

Second: The text must have been slightly different, because the other copy triggered a rule that looks for the phrase “no cost” or “no charge.” That not only added 1.7 points, but altered the message enough that the Bayesian classifier was less certain it was legit – a shift from 0% to 1-9% likelihood of being spam. So instead of subtracting 4.9 points from the score, it only subtracted 1.5 — a net gain of 3.4 points.

Of course, these differences wouldn’t have been an issue if the message hadn’t been formatted in a very spam-like way. Before Bayes made its adjustments, the copy sent to me would have been 5.2 points — just over the threshold. Someone else seemed to be getting the text-only version (it didn’t trip any HTML rules) and the final score was -1!

It’s been tested so far on Mozilla, IE 6, Opera 7, and Konqueror 3.2. It doesn’t use anything more complicated than Fahrner Image Replacement, so it shouldn’t cause too many problems. I’ll try to test it in a bunch of other browsers at work tomorrow.

I consider this a first draft – among other things I figure on adding to the main title banner – but it’s something a bit more distinctive than the out-of-the-box layout we ended up with after the upgrade to 1.0.

Updated Feb. 12 and Feb. 13 to describe testing in more browsers and the interesting saga of tracking down a bug in Internet Explorer 5.0:

Update Feb. 12 @ 10:45. Well, I’ve successfully tested Opera back to 4.0, Mozilla back to 1.0, Netscape back to 6.2 and IE back to 5.5. I still need to check Safari and Mac IE 5, since Katie had turned her computer off by the time I was finished last night. (Gecko browsers are pretty consistent across platforms, so all I really need to check on Mac Mozilla is that the fonts are readable.)

So far, every browser that can be expected to handle the layout has shown it fully or reasonably, except one: IE 5.0 for Windows:

It looks like it’s treating the bottom margin of each post as padding, without moving anything out of the way. (Padding is inside the box, margins are outside.) It should be placing a blank line between the bottom of a post and the next item, but instead it’s extending the box down, causing an overlap with whatever comes next.

This reminds me of the margin problems IE 6 had with my software page layout – but this time IE 6 is fine. It’s only IE 5.0 that’s having problems, and the tweaks I allowed myself time to make haven’t been enough to solve them.

Well, if stats are to be believed, there aren’t too many of you out there still using IE 5.0. I’ll try to figure out a workaround, but for those of you still using IE 5, isn’t it time to think about either upgrading to IE 6 or switching to something better?

Update Feb. 13 @ 16:30. I took a quick look at the resulting HTML code, and suddenly it was obvious: every post on the main page, where comments aren’t visible, had the following code at the end: <div class="storycomment"></div>. It’s perfectly valid, and most browsers just ignored the empty element. If IE 5.0 had just added the blank space, it would have been okay, but it somehow added the space when displaying the surrounding block, but not when figuring out where to put the next block.

Anyway, I moved the <div> tags into the comment loop, so they’re only present when comments are actually shown. The IE 5 display problem is fixed!