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.

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

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

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.

Well, Firefox is nearing 1.1 alpha, and among the new features is real support for outline. I figured I’d set up a test page and see what happened.

I set up two classes, one which applied an outline and one which applied a border, and just tried them on different objects. <p> only looked different in positioning (since border is just inside the edge, and outline is just outside), but <span> illustrated the difference clearly:

The first paragraph has some text with an outline. The second has text with a border. In both cases, the text wraps at the edge of the window, but while the border breaks and picks up again on the next line—as if the span had simply been chopped into pieces—the outline completely encloses each section on its own. This fits with its intended purpose, which is “to make [elements] stand out.”

Opera and Konqueror (and presumably Safari) seem to handle outline already, and display my test page the same way as Firefox 1.1.

First impressions: importing was clean and worked well. UI is a bit freaky, as things are spread all over the place—like the main menu, which is in the upper right and in line with the title bar instead of where the menus are on every other Windows application. The multiple toolbars seem confusing at first (it took a while to dig up my bookmark bar, for instance). Then I looked at the site trust/rendering choices, the big exciting feature of this release. And I’m not impressed. Or rather I am, but not favorably.

The current tab shows a shield icon indicating the trust level of the site: Green if it’s been verified by a “Netscape Security Partner,” yellow if not, and I would presume red if it’s a known phishing/virus/etc. site. There’s also an icon indicating the trust level: a check mark if it’s trusted, an ellipsis for “not sure” and an exclamation point for not trusted. Unverified sites are, by default, in the “not sure” category. So far this makes sense.

Clicking on the shield icon opens a site controls dialog box enabling you to choose to what extent you trust the website, and below that, whether to display the site using the Mozilla Netscape or Internet Explorer engine:

Imagine my surprise when I selected “I trust this site” and was greeted with a message saying “You have chosen to view this web site using the Internet Explorer display engine. Your setting will be remembered the next time you visit this site. Please be aware that there are known security vulnerabilities with the Internet Explorer display engine.” Of course, I had not made that choice.

It turns out that the default settings are as follows:

• Trusted: Display as IE with cookies, ActiveX, Java, and JavaScript.
• Not Sure: Display as Netscape with cookies, Java and JavaScript.
• Not Trusted: Display as Netscape, no cookies, Java or JavaScript.

It also reloads the page immediately—which kind of makes sense—but which forced me to start writing this post all over again when I decided to check a setting halfway through the second paragraph. They don’t seem to have worked out a way to get the IE and Netscape engines to share cookies, either, because I had to log in again after switching.

But what really bugs me is that it assumes with “trusted” sites that you’ll want to use the IE rendering. It may actually be true for a lot of people, but it undermines the effort to get sites to use browser-independent designs. It’s one thing to make it easy to switch into IE mode for sites that require it, but making it assume IE from the start leads to “why bother?” thinking. By default, on top-tier websites Netscape is no longer Netscape. If you look at Netscape.com, which is in the built-in trust list, you will view it as IE does. And of course, there’s a natural tendency to mark sites you trust, because it keeps reminding you that it doesn’t know whether you trust the site. So if you decide that you trust, say, meyerweb.com, and you mark it, you’re going to have problems with the examples on CSS/Edge.

You can set a trusted site to use Netscape rendering—this gives you a gear icon for “custom” settings, which looks like a slightly lumpy circle when shrunk down to the tab size. You can also change your own default settings, but given that as far as I can tell the only difference between Trusted and Not Sure is the rendering engine (and ActiveX), the only benefit I can see to doing this is for sites in Netscape’s own trust list.

In short, I don’t think Netscape 8 is going to pick up much of Firefox’s audience. On the other hand, I have to admit that there’s something strangely exciting about being able to load Windows Update in Netscape.

• Judge slams SCO’s lack of evidence against IBM. Also Groklaw’s take. After all the wild claims they’ve made without providing evidence, it’s nice to see even the judge is getting sick of it.
• Coke may try out coffee cola – Yeah, it’s a month old, but it’s news to me. (Incidentally, I hate CNN’s practice of deleting stories from their website. That’s where I read about this earlier this week, and I had to go hunting for an article that was still up.) [Note: I've had to track down a third copy of the article.]
• MP3tunes.com shuns DRM – former MP3.com founder starts a new legal download service, and sticks with unencumbered MP3s instead of messing around with ultimately-flawed digital rights management. I’m reminded of Cory Doctorow’s famous talk on why DRM is bad for everyone.
• Beware the unexpected attack vector – Your enemy may not come at you from the direction you expect. Set up sentries around the beach, they’ll get you through the ocean. Set up a firewall, they’ll get you through web browsers. It’s mainly about computer/network security, but it has an interesting story explaining why there’s only one major newspaper in Los Angeles.
• CSS Zen Garden parody: Geocities 1996 – I’ve been meaning to post a link to this for over a month. It’s fully valid code, and manages to bring back the worst of 1990s web design.

After a while I came back to it, and started with very simple buttons like this:

Your browser shows this as:

Valid XHTML XFN Friendly

Here’s the CSS and HTML used for this version:

a.w3c, a.nw3 {font: 9pt Arial, Helvetica, sans-serif; border: 1px #000 solid; padding: 2pt; text-decoration: none;}
a.w3c:link, a.w3c:visited {color: #000; background: #fc6;}
a.w3c:hover, a.w3c:active {background: #fec;}
a.nw3:link, a.nw3:visited {color: #000; background: #adb;}
a.nw3:hover, a.nw3:active {background: #cfe;}

<a class="w3c" href="#">Valid XHTML</a> <a class="nw3" href="#">XFN Friendly</a>

Of course, Netscape 4 had problems with this, because it dislikes putting borders or padding on inline elements — like links. Not only does it push them onto separate lines, but they’re no longer clickable! What I ended up doing was separating out the border and padding rules and putting them in an @media screen section to hide them. So on Netscape 4 it looked like this:

Earlier this month, I found Eric Meyer’s take on the same problem: using CSS to imitate those buttons so that visitors don’t have to download an extra 15 images just for footnotes. He was trying for as exact a match as possible, and the result looks great – in Mozilla, Opera, Safari or Konqueror. But the margins aren’t quite right in IE, and unlike Eric, my site isn’t a showcase of what CSS can do.

I ended up using his idea of putting a single <span> tag inside the link — that’s all you really need to divide it into two regions — and using two classes to simplify using the same styles for different types of buttons. Since I’d already abandoned the idea of an exact match, I didn’t worry about getting the fonts and spacing exactly right, and since I was using these in a horizontal row, I didn’t have to worry about specifying widths. It looked pretty good, at least on MOS:

I still had problems in Internet Explorer, though. It adds the padding together, even though it shouldn’t mess with the line height on an inline element, so it ended up with an extra line of background color around the left section:

Since I wasn’t trying to match exactly, I decided to just remove all the vertical padding, leaving something much narrower than the originals, but much cleaner than what I could get otherwise:

Your browser shows:
W3C Valid XHTML XFN Friendly

<a class="btn w3c" href="#"><span>W3C</span> Valid XHTML</a> <a class="btn fea" href="#"><span>XFN</span> Friendly</a>

a.btn {font: 8pt Arial, Helvetica, sans-serif; padding: 0 .5em 0 0; border: 1px #000 solid; text-decoration: none;}
a.btn span {border-right: 1px solid #000; margin: 0 0.1em 0 0; padding: 0 0.5em;}
a.w3c:link, a.w3c:visited {color: #000; background: #fc6;}
a.w3c:hover, a.w3c:active {background: #fec;}
a.w3c span {background: #fff; color: #06c;}
a.fea:link, a.fea:visited {color: #000; background: #ccc;}
a.fea:hover, a.fea:active {background: #bed;}
a.fea span {background: #093; color: #fff;}

This works well in modern versions of IE, Mozilla, Netscape, Opera, Safari and Konqueror. IE5 gets the colors right, but doesn’t show the borders. Netscape 4, interestingly, doesn’t recognize multiple classes. It thinks “btn w3c” is a single class with a space in the middle, so its freak-out over borders and padding is no longer a problem. It just ends up looking like a normal text link. It’s not great, but at least it works, and at this point that’s all I want for NS4.

There’s one more problem, and that’s one of accessibility. The WAI and Section 508 guidelines both suggest you avoid putting links next to each other with no separation, because a screen reader might not make it clear to a blind web surfer that the links are separate. I haven’t come to a final decision on this one, but what I’ve got on some pages is just separating them with ordinary bullets:

W3C Valid XHTML · XFN Friendly

The first thing I realized was that the technique isn’t suitable for large, arbitrarily-sized regions, because you need to have a background image as large as or larger than the area being given the shadow. When you’re trying to apply it to most of the page, you need a multi-thousand pixel image. That’s not only hard to work with, but even if it compresses well it’s still going to take up a lot of unnecessary room in the browser’s memory.

I wanted to keep the markup simple, so I shopped around a bit more and came across a CSS drop shadow example at W3C which was very simple: all you do is put a shadow-colored div behind the area and mess with margins.

Well, that worked great in Mozilla, Opera, Konqueror and Safari. Then, the dreaded Internet Explorer test.

No dice. IE on Windows has a problem dealing with negative margins (which explains why it thrashes the layout on my software page). It shrank the containing div down to one line, but spread its background all the way down, and duplicated the top of the inner div so that there were two borders. (Note that IE for Mac worked fine.)

So I thought, how about using positioning instead of margins? That actually worked, keeping margins intact and everything. So I had a simple drop shadow that worked in all the major modern browsers! Next step: What would it do in Netscape 4?

I’m at the point where I don’t worry about design appearing right in Netscape 4, I just worry about the content being visible and clickable. If things don’t line up, or the background is missing, I don’t mind, but if you can’t read it, or you can’t follow navigation, I try to fix it. Well, Netscape 4 is picky about applying background colors, and it had decided to show only the shadow’s background color — which, of course, was black, the same color as my text! Fortunately, there is a very simple, validating hack to hide CSS rules from Netscape 4, so I used the Caio Hack to hide the background color for the shadow div.

So now I’ve got a test page that looks good in all major modern browsers, and is at least usable in Netscape 4 (for the die-hards who won’t or can’t upgrade to Netscape 7.1 or Mozilla). I proceed to update all my pages to add the nested div. Story done, right?

Of course not! The first problem was with IE, which took some files – but only some – and actually double-layered the text! After a bit of experimenting I realized it was only doing it to the largest files, and it seemed to be wrapping the text around from the bottom to the top as if it had some sort of maximum length on nested and/or relatively-positioned blocks. It looked just like a sheet of paper that’s been run through the printer twice. By this time I wasn’t really interested in starting over with a new design, so I just added another class and reverted those pages back to a shadowless layout.

So was I finished now?

No, Netscape 4 – despite being fine with the page I had used for testing – was royally messing up the rest of the pages, somehow deciding that a negative position for the left edge of the inside block should be measured against the right edge of the container instead of the left. And once you move something in NS4, chances are the links either haven’t moved or have moved somewhere else. So I had unclickable menus off at the right edge of the page instead of the middle, and poems you couldn’t see without scrolling to the right. Very much not in the mood to fsck around with this, I just moved all the positioning inside the Caio hack.

Done?

Nope! A few pages have images floated off to the right. IE/Win would flash the image briefly, then paint the background over it. Really. On the one page where the image matters, I just resorted to a table. A table inside an otherwise CSS-based layout, just because one browser is too buggy to display floated images right.

Now, let’s go back to the beginning. Remember, I wasn’t trying to do anything complicated. The HTML change consisted of going from <div>...</div> to <div><div>...</div></div> — that’s all — and the CSS change consisted of (first try) setting margins or (second try) setting positioning. Mozilla, Opera, Safari and Konqueror all got it right the first time. Not once did I have to tweak anything. But IE/Win and NS4 both exploded, repeatedly.

Microsoft, unfortunately, has the browser market sewn up and has gotten lazy. I wouldn’t mind so much if they were willing to fix their bugs, but they aren’t. These aren’t new or advanced standards I’m working with here, these are basic features that have been around for 7 years. I can understand Netscape 4 screwing up — it’s old, and the only reason I’m even bothering is that so many people were scared off of upgrading by the crap that was Netscape 6 or the hardware/OS requirements for the much-better Netscape 7 and Mozilla. But IE 6 is supposedly current (even if they haven’t done much with it but plug security holes for the last few years). It ought to be able to handle this stuff.

This minor site upgrade should have been a half-hour project at most, instead of using up an entire evening and prompting me to write several pages detailing the experience.