Tag Archives: css

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.

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.

Webbish Links

The WaSP Buzz recently posted several links to CSS resources, including a rather thorough CSS Reference at SitePoint.

The ISC reminds us that IE7 will be pushed out to WSUS next week, which should help get rid of IE6. Yeah, I’d rather more people switched to Firefox or Opera, but I’m at the point where I’d love to be able to stop worrying about IE6’s shortcomings when trying to build sites. IE7’s shortcomings are much easier to work around. (Sorry to keep harping on this!)

The inventor of Norton Antivirus talks about computer security and has some rather interesting ideas on what policies are worth pursuing…and what policies aren’t. Long passwords? Great for protecting a stand-alone machine, but on a 10,000 machine network, they only need to crack one. Patch everything? Not every vulnerability gets exploited. I’ll have to read the Slashdot thread when I have time; that should be really *ahem* interesting.

Advantages of standards-based design: Compatibility

Microsoft is really pushing for people to make sure their websites and apps are compatible with IE7. Apparently this is a real concern for a lot of people who relied on certain proprietary features, bugs, and quirks in IE6. I guess they figured they wouldn’t have to worry about future versions. (Hmm… I wonder where they got that idea?)

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).

Corporate Acid

The big news in web browsers this week is the formation of the Mozilla Corporation, a wholly-owned subsidiary of the Mozilla Foundation. So far it looks mainly like an accounting change so that they can work more easily with businesses that aren’t quite sure how to deal with non-profit partner. Firefox, Thunderbird, etc. will of course remain free and open-source. I’m optimistic about the change—being a for-profit company doesn’t seem to have hurt Opera much.

Speaking of Opera, they’re close to passing Acid2 in-house. They seem likely to be the next browser to pass (after Safari, iCab, and Konqueror). The next question is: Who will be the first to release a final version that passes the test? Safari and Konqueror still only pass on the development branches, and iCab’s still in beta.