A striking triplex penthouse apartment in a clock tower overlooking the Brooklyn Bridge and New York Harbor has gone on the market for $25 million. Photos.

Thx, Lex

Solitaire isn’t even installed by default on the new Microsoft OS. Here’s what I just had to do:

1. Start > Control Panel.
2. Windows Needs Your Permission. Do you want to allow that? Yes.
3. Turn On/Off Windows Features.
4. Windows Needs Your Permission. Do you want to allow that? Yes.
5. Turn on solitaire.
6. Windows Needs Your Permission. Do you want to allow that? Yes.
7. Please wait, this could take a few minutes. (It took four.)
8. Restart now.

Mark Needs Your Permission. Do you want to allow laughter? Yes.

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.