Over the last few weeks, I built a PHP application that overlays Approve 71 banners on profile pictures. The actual application is hosted in an iframe and lives on a server in a different domain, eq.dm, than the main server at approvereferendum71.org.

This works fine in most browsers. Then we started getting reports that it wasn't working in IE8 on Win7 RC1. The iframe content was blank.

Poking around, I found the problem with the Fiddler proxy. The landing page on eq.dm was supposed to stick some information into the PHP session, then redirect to a second page at the same site. The second page was in an endless loop, redirecting to itself. In Fiddler, I saw a different PHPSESSID cookie on each response, and no cookie in the requests.

After reading IE 8 only has access to session cookies, I told IE8 to Accept All Cookies and the iframe content appeared. That fixed it for me, but we could hardly ask people to lower their security sessions.

I created a P3P file for the second domain, using the IBM P3P Policy Editor. (KB 323752 has more background on P3P and third-party cookies.)

IE now worked at its default security level. Problem solved! Or so I thought.

A day later, we got reports of similar problems with Safari 4 on Mac OS X.

I sniffed the traffic with Wireshark. Same problem: the “third-party“ cookie wasn't being accepted by Safari.

Unfortunately, Setting cross-domain cookies in Safari indicated that there was no reasonable workaround.

We overcame the issue up playing some DNS games, which was only possible because we control both servers. The second server is now also acting as a subdomain of the first, at dev.approvereferendum71.org. We used ini_set("session.cookie_domain",".approvereferendum71.org") to scope the iframe cookies. I've tried it in a variety of Windows, Mac, and Linux browsers, and it works in all of them.

Google finally released the much-anticipated Chrome preview for Mac and Linux yesterday. I've tried it on my OS 10.5 MacBook and my Ubuntu Jaunty Netbook Remix netbook.

Chrome works fairly well, so far. It seems slow at resolving hostnames, but otherwise downloads pages quickly. Rendering speed is good. Gmail comes up in an amazingly short time, as in Windows Chrome. It uses less CPU than Safari or Camino.

Favicons are not showing up in tabs on Mac. Fonts are not antialiased on Linux.

As a user, I'm happy to see that there is real competition between the browsers after the stagnation in the first half of this decade, when IE6 ruled. As a web developer, it's a pain to have so many browsers to test.

In the late 90s when I worked on the classic Active Server Pages dev team, I tried to convince one of the Program Managers that we should make regular updates to browscap.ini, the file that described browser capabilities. He wanted no part of it.

I was pleasantly surprised to learn via Hanselminutes that Microsoft has stepped up to its responsibilities and is now shipping the Mobile Device Browser File on CodePlex. Over 400 mobile devices are defined, with 67 distinct capabilities.

The Hanselminutes podcast is an interesting discussion of the Mobile Web and designing a different experience for mobile browsers. There's more to it than the small screen. You want to think about the scenarios in which the site is likely to be used. The user is probably traveling: give directions. Make phone numbers dialable by using the tel: scheme. Think about server round trips.

I spent part of my day fighting with CSS for an email template. CSS support is poor in both desktop and web clients, and much worse than in current browsers.

Gmail, for example, does not support <style> in either the head or the body of HTML email. You have to explicitly set style attributes on individual nodes. You might as well be using <font> tags!

You can't assume that images will be downloaded, so the mail has to make sense without them. And forget iframes.

CampaignMonitor seems to have the definitive guide to CSS support.

One thing that's been bugging me since I started using Opera is that bold and italic text was showing as normal text in my personal blog. Yet other browsers were correctly displaying bold and italic on my blog.

I'm still not entirely sure why Mac Opera had a problem with it, but I fixed it by using the Lucida Hybrid stylesheet tweak.

I adjusted a few other things while I was at it. The most obvious is that the font size is larger.

Most RSS readers won't pick up the stylesheet, so take a look at the actual blog.

Over at Cozi, we've started a new technical blog. I just put my first post up, describing a nasty problem we had late last year.

Here's the summary:

Internet Explorer 6 does not support transparency in PNG images. The best-known solution is to use the DirectX AlphaImageLoader CSS filter. It's less well known that using AlphaImageLoader sometimes leads to a deadlock in IE6. There are two workarounds. Either wait until after the image has been downloaded to apply the filter to the image's style, or use the little-known transparent PNG8 format instead of the filter.

More here.

Title: Defensive Design for the Web
Author: 37 Signals
Rating: 3.5 stars out of 5
Publisher: New Riders
Copyright: 2004
ISBN: 073571410X
Pages: 246
Keywords: programming, web
Reading period: 23 December, 2007 - 9 January, 2008

This book contains 40 usability guidelines for websites, ranging from Eliminate the Reset button and disable the Submit button after it's clicked to Give an error message that's noticeable at a glance to Be upfront about item unavailabiity. The topics include error messages, clear instructions, friendly forms, overcoming missing pages, helpful help, obstacles to conversion, and search.

When I state them that baldly, they sound obvious. But they're not. The 37 Signals guys have amply illustrated each guideline with examples of sites that violated the guideline, and sites that exemplify the guideline. The examples are well chosen and bolster their points.

The book feels padded, however. They could easily have reduced the page count by two-thirds. Indeed, an earlier version of this book is available as a 17-page whitepaper. It was certainly worth the $6 that I paid for it at Half-Price Books, but I think I'd feel cheated if I had spent $25 on it.

The book refers to a companion website, DesignNotFound.com. This site is no longer available, which I find unforgivable. It's such a complete contradiction of the principles they advocate. The Wayback Machine reveals the original site.

Title: Bulletproof Web Design, second edition
Author: Dan Cederholm
Rating: 4.5 stars out of 5
Publisher: New Riders
Copyright: 2007
ISBN: 0321509021
Pages: 312
Keywords: css, web
Reading period: 10-29 October, 2007

Cederholm clearly explains the CSS techniques required to build a "bulletproof" website: one that is robust in the face of text resizing, window resizing, disabled images, etc, with minimal, semantically correct markup that works across all the major browsers.

Anyone who's serious about building a modern website should read this book.

Cederholm builds up his examples, one step at a time, in a clear manner. For the shorter examples, he tends to show the entire CSS or XHTML again and again, with the latest changes highlighted in orange. I would have preferred him to strip out the unneccessary repetitive material. Otherwise, great book.