(thx Tim)

(thanks, Tim)

For each and every PNG, GIF or JPG I sliced out of this beautiful design, Photoshop seemingly stripped the brightness and sharpness from the images. My template’s images looked perfect in Safari, Opera, and IE—even IE6!—but not in Firefox. Firefox, in which I do my initial development, is apparently the only browser in the market which acts this way: (I eventually learned) it cannot read color profiling embedded in images. Let me say that differently: Firefox 3 can read profiles, but they’re turned off and only available with an add-on or some configuration changes. I changed every possible setting in the Photoshop “Save for Web…” dialog with no success.

After further snooping and a little detective work in our design department, I learned my version of Photoshop was embedding a color profile—without my knowing—and this profile wasn’t “generic.” The generic profile means Photoshop won’t “color manage” your file and save it out to whichever format specified in true color. Interestingly enough, CS2 was making matters worse for me. I hadn’t yet upgraded to CS3 at work, so after doing just that, I followed these instructions—which should be set by default in Photoshop—and am feeling happy again.

In July we announced that we would be phasing out support for Internet Explorer 6 on August 15, 2008. To make the transition easier, we’ve extended that deadline to October 1, 2008. From now until October 1st, anyone using IE 6 to access Basecamp (or our other products) will receive a notice every 3 days letting them know they’ll need to upgrade their browser before October 1, 2008 in order to continue to use Basecamp. The notice will be displayed in the web browser and will include links to download a modern browser (IE 7, Firefox, or Safari). This notice will also be shown to your clients who use Basecamp. You may want to re-read the announcement so you are prepared for any questions they may have. If you have any questions please contact support. Thanks for your patience during the transition.

They’re leading the way — along with MobileMe — and I couldn’t be happier.

Computerworld is reporting that our friends in the UK have been frustrated by the iPhone 3G launch. It would seem that while the iPhone 3G is for sale in Apple Stores, the activation process isn’t working smoothly (sound familiar?). Why is that, you ask? Because O2, that’s the UK wireless company that has the iPhone, uses an activation system that only works with IE. Apple had to install Fusion on the Macs in the UK Apple Stores in order to activate iPhones on the spot, and it seems that the system isn’t working as smoothly as many would like.

via TUAW.

SWFObject is an easy-to-use and standards-friendly method to embed Flash content, which utilizes one small JavaScript file.

Version 2 — just released last month –offers the new express install from Adobe as well as whole new method for loading Flash files into your pages. The project’s home base is over at Google Code now, and there’s plenty of examples, help, and even a code generator (which is pretty slick).

The best news of all: upgrading to version 2.0 fixed a “wmode” transparency issue I was having in Firefox 3.

What is it about people still using IE6?

Now, my website is clearly not the most popular on the Internet, so I can’t assume 47% of everyone on the Web is using IE6. But I get a significant amount of traffic. From all over the globe. Lots of my site’s visitors might actually be looking for the Other Me (explanation), however, the fact remains: it’s a lot of traffic. Maybe it’s not as clean of a cross-section view as, say, CNN.com’s or NYTimes.com’s statistics might be, but it’s it’s good enough for me.

And, I’m not going to pretend IE7 is a great browser, but it’s a giant leap forward from IE6. Even my infrequently-booted Parallels-run copy of Windows XP has updated itself to IE7. Get with it people; do yourselves a favor and stop using the world’s shittiest browser.

Enter stage left: Douglas Bowman’s Sliding Doors of CSS courtesy of ALA.

I added two tabs to my new view, repositioned them on the right side — which took some fancy footwork because this awesome technique only demonstrated the tabs as left-justified — and started the browser testing. With some minor edits to the CSS, my new tabs worked perfectly in almost uniform fashion, except in IE7. The browser correctly interpreted both of these declarations, including the Holly Hack (a.k.a. the Be Nice to Opera rule), previously undetected by IE.

#tabbednav ul { margin: 0; }
html>body #tabbednav ul { margin-bottom: -10px; }

A post on Zeldman.com helped me figure this one out, and allowed me to specify rules using a modified Holly Hack. This declaration targets Opera and Mozilla browsers, but all versions of IE don’t see it, including IE7:

html>/**/body #tabbednav ul { margin-bottom: -10px; }

Thanks to Zeldman and donovan.

Update @ nearly 4PM:
After further testing, Safari picks up my modified Holly Hack and improperly renders my tabs. I guess I’m going back to the drawing board.

Update @ just a bit before 4PM:
Ok, final update. I promise. In the end, I was able to make some modifications to one other rule and didn’t end up needing the negative margin. If anyone knows more about this “/**/” hack, ping me, I’m curious now.

If you have ever tried to send an (X)HTML email from your web apps, you and I both have a lot more to ask for.

I’m currently writing an application for a client of mine that’s rich in user interaction. In part, users can create accounts, verify email addresses, forget passwords, and more of the standard account-related functions. Needless to say, without any unnecessary overkill, we will be sending a good amount of emails to my client’s user base. I could have easily opted to send text-only messages, but the requirement included displaying a logo, bolding text, and other graphical presentations otherwise not available in text-only. So, without much hesitation, I charged ahead. Whip up some clean (and strict) XHTML, use loads of my already-fine-tuned CSS rules, pump in some content and we’re off!

Wrong. And this was just the beginning.

I use my Gmail account for testing — it’s convenient because all the messages get lumped into one conversation for easy review, not to mention the huge disk space and (my favorite) delete button closely within reach. But for all of Gmail’s successes, it sure wreaked havoc on my nicely-formatted XHTML messages. Evidently, Gmail strips every shred of code out of your email, and rebuilds it in its entirety before spitting it back into it’s wonderfully successful conversation view. Those unique div, span and other IDs? Gone. The short and sweet CSS rules? Gone, and definitely not working. Hell, even my one-line footer wrapped in a small tag didn’t render properly. I now know why I can’t read my itinerary confirmations from the airlines in Gmail.

To make sure I wasn’t out of my mind, I changed my testing email address to an account I manage with Outlook on Windows and Mail on the Mac. Naturally, the message came through looking as perfect as I could have ever imagined. I repeated this process with Mozilla’s Thunderbird and then webmail at Yahoo!, Hotmail, and AOL — all succeeded, but in different ways. Microsoft’s widely-used Outlook client performed the best (same goes for Outlook Web Access), followed closely by OS X’s Mail. Neither re-wrote my code. Yahoo! did better than Hotmail, but Hotmail’s new interface liked the HTML and CSS hybrid a little more than the old but it still wasn’t perfect.

I am fighting an in-browser application war! Here we have browser-based applications developed by the world’s largest software manufacturers performing the same basic functions displaying standard XHTML and CSS content from the same source — and it just doesn’t work. Grrr. In the end, it’s Gmail that is causing the biggest headaches.

Yesterday, I finished restructuring the code following tips I read about on this highly-useful Interweb (I love that old Verizon DSL commercial). Here are a few that helped me get going again:

• Don’t put anything in the head of your email template.
• Forget the love you have for your fine-tuned CSS document; there’s no hope of using it (as an externally linked file). You’ll have to drop all your classes and ids replacing them with hideous inline styles. If your email’s recipients use Gmail, you’ll need to do this one.
• If all else fails, especially with AOL, use a table to position your goodies. I can’t believe I typed that, but when it comes to this and saving time, it works.
• Have patience. I nearly tossed my lappie out the window on more than one occasion.

As of yesterday, my client’s customers are ready to receive fancy-schmancy emails. No matter which mail client, web-based or desktop, Mac or Windows, they’ll all see the same content — as it was intended by this designer. Now that it’s done and I’m filling out my time sheet, I find myself having a hard time justifying the large chunks of time spent formatting arbitrary (yet critical) emails when there’s plenty of other work that needs doing. It seems funny to me but after all these messages, like them or not, are part of your app and, more importantly, your client’s outward-facing marketing.

Poor XSL
One of the reasons I’m discontent with the three biggies — Safari, IE7, and Firefox 2 — is their apparent blatant disregard for a designer’s freedom to exercise his or her right to a custom XSL—styled XML feed. I don’t normally spend too much time writing XSL documents, but for one client’s particular requirement, they wanted a custom XML feed page. The client’s user base, we anticipated, was not RSS-savvy and we’d hoped to ease them into the process for consuming news, regular updates, and more. So, enter a fairly simple XSL style sheet and the über—friendly appearance of styled XML. Not so in the latest versions of these browsers.

It’s possible that I haven’t yet found the setting in the browser preferences or the line of code that fixes it, but the aforementioned Big Three are overriding my XSL! (Opera handles the XML as intended.) They favor their own display of RSS feeds and bully mine out of the way. (See theirs. See mine.)

I’m not even going to try to explain why the software makers decided on this, so if you know of a fix, let me know.