jrmehle.com

Safari's Top Sites

If you do more than a minimal amount of work on a number of Ruby web projects, you’ve more than likely sat down to figure out how to use Phusion Passenger in development. It makes switching between several projects a snap. Ruby and Rails developers have also been known to disproportionately favor Apple machines for their development workhorses. Continue reading if you fit the mold.With the release of Safari 4 came the nifty “wall of screens” feature known as Top Sites. This feature takes your most visited sites and displays them in a nice grid. It’s more pretty than useful, but I’d be lying if I didn’t use it at least once a day.

Lately, the combination of the previously described tools have been causing me pain. One of the things developers tend to do when developing sites is refresh them; A LOT! So typically there are at least a couple of my projects that wind up as Top Sites in Safari. The problem with this is Safari likes to go update those pretty looking screenshots every time you view the Top Sites screen (and randomly at other times). Because I have this set to display when a new tabs open, this is every time I open a blank tab. In other words, very often.

If you haven’t put two and two together by now, what happens when I open a tab is Passenger spawns processes to handle the requests Safari makes (just so it can update it’s screenshots). This ends up consuming several hundred megs of RAM and spikes the CPU load. If you happen to have a memory leak in your application, be prepared to launch Activity Monitor in a hurry to kill the ruby process that is spiraling out of control.

Delete/Pin Button

As a solution, you can easily hit the edit button and blacklist the worst offenders, but you have to do so for each unique URL. There is no way to say don’t ever list pages from “localproject.dev” or even “*.dev”. There is also a way to temporarily stop Safari from trying to update the images, ‘Command + .’

If you’ve been on Twitter over the past couple of weeks, you may have seen some tweets using the #fixoutlook hash tag. This is a reference to the Fix Outlook campaign headed up by the Email Standards Project. The group is trying to get Microsoft to stop using Word as the renderer for HTML email in Outlook.

Some backstory will make things clearer. Outlook 2000 (two versions previous to Outlook 2010) used Internet Explorer to render HTML inside of email. If you crafted some HTML for an email, you could expect it to look exactly the same in Outlook as it did in Internet Explorer. In 2006, Office 2007 was released and instead of using IE for rendering HTML inside of Outlook, Microsoft had changed to using Word. Word has a very very simple (and far from standards compliant) HTML rendering engine in it. So where your nicely crafted HTML email might look great in Outlook 2000, it now looked awful in Outlook 2007 due to Word’s poor HTML support.

Things of the Microsoft front have remained quiet until now. William Kennedy, Corporate Vice President, Office Communications and Forms Team (long enough title?), made a post the Office team’s blog explaining that there would be no change to Outlook 2010’s HTML rendering and some reasons why the team chose to stick with Word. It’s all a bunch of bullshit.

We’ve made the decision to continue to use Word for creating e-mail messages because we believe it’s the best e-mail authoring experience around, with rich tools that our Word customers have enjoyed for over 25 years.

Why is he bothering to trumpet authoring capabilities when what this is really about is rendering? People craft emails in a lot of different ways, both inside and outside of Outlook. Is it handy that I could type up a nice formatted document with graphics, paste it into Outlook, and have it look the same? Yes, of course. However if Microsoft made Outlook and Word render standards compliant HTML correctly, you could still do that.

Word has always done a great job of displaying the HTML which is commonly found in e-mails around the world. We have always made information available about what HTML we support in Outlook; for example, you can find our latest information for our Office 2007 products here. For e-mail viewing, Word also provides security benefits that are not available in a browser: Word cannot run web script or other active content that may threaten the security and safety of our customers.

This paragraph is wrapped in so much spin that I’m dizzy after reading it. What he’s basically saying is that Word can handle <b>, <i>, <center>, <table>, and that’s about it. Guess what? Standards compliant HTML renderers also do a great job of displaying HTML commonly found in email! Using Word is more secure because it doesn’t run scripts? Bullshit! Thunderbird, which uses the same rendering engine as Firefox, simply turns off scripting in email. Ditto for Apple Mail (uses Webkit). Why can’t you do this with Internet Explorer, Microsoft?

We are focused on creating a great e-mail experience for the end user, and we support any standard that makes this better. To that end, Microsoft welcomes the development of broadly-adopted e-mail standards. We understand that e-mail is about interoperability among various e-mail programs, and we believe that Outlook provides a good mix of a rich user experience and solid interoperability with a wide variety of other e-mail programs.

Again, Mr. Kennedy seems to be focused on the authoring experience when this is more about rendering. On top of that, it assumes that everyone uses Microsoft products inside of a Microsoft environment. News flash; even people who live exclusively inside the Microsoft universe of products often interact with people who don’t. The words above are trying to say different, but they really aren’t saying anything.

There is no widely-recognized consensus in the industry about what subset of HTML is appropriate for use in e-mail for interoperability.

Why do we need a consensus specifically for HTML email? HTML already has a standard! Use that! If Mr. Kennedy welcomes these standards, why don’t they try to be proactive about it instead of giving their customers what amounts to a downgrade? Contact this Email Standards Project and strive for a more (for lack of a better term) bi-partisan effort.

The biggest problem here with Outlook using Word’s rendering engine is for people authoring email that is viewed in Outlook. Anyone who is in charge of their company’s email campaigns can attest to the frustration of trying to craft a message that looks good in the most commonly used email clients (it’s not possible to please everyone). It’s especially punctuated by the fact that Microsoft seems to be one of the only ones lagging behind. Thunderbird, Apple Mail, and most webmail clients support much more HTML and CSS in a more standards compliant way than Outlook does. On top of that, Microsoft seems to be denying that there is a problem in the first place. If the thousands of tweets are any indication, there is a problem Microsoft. Step up and join the conversation, work with not only the Email Standards Project, but also others in forming a standard.

This post was inspired by a blog post from: Ben Ward. Some of the arguments he makes I’ve reused here.

I have some work to do.

Last week, Microsoft officially lifted the covers off of Internet Explorer 8.0 and deemed it ready for public consumption. According to a post on Neowin.net, the browser will be available via Windows Update as early as April 13th and as an Automatic Update as early as April 27th. Of course, you could also grab it right now if you wanted.

One of the key features that had developers like myself salivating was better standards compliance. Specifically with the CSS standard. The closer we can get all browsers to following standards, the easier it gets to create a website that looks right in all browsers without resorting to hacks and tricks. Unfortunately even the tried and true methods of targeting IE browsers in the past was made more difficult by a new feature, Compatibility View.

Windows Internet Explorer 8 improves browser interoperability and advances the Web by delivering a better implementation of web standards. Although this is a move in the right direction, you might encounter compatibility issues with some sites that still rely on the behavior of earlier versions of Internet Explorer. Common symptoms of site compatibility problems are out-of-place menus, images, or text.

Compatibility View resolves most site compatibility issues and makes websites that are designed for older browsers look better.
From: Release Notes for Internet Explorer 8

If you’d read only that, you’d think that Microsoft is doing the right thing. They’re helping website developers out by supporting more standards and they’re helping out “Joe the Computer User” with this Compatibility View feature. However, the devil is in the details.

Compatibilitiy View

The way Compatibility View works is like this. By default, IE8 will render in standards mode. This is good because as I said, it lets website developers code to the standards and not worry about whether or not things will work. They just do. If a consumer comes to a site that they don’t feel looks like it was intended, they can toggle Compatibility View for that site. What Compatibility View is actually doing is using a non-standards compliant rendering engine that is similar to IE7 to render the page instead. I say similar because it’s not the same as viewing a page in IE7 (yet another headache for developers). Furthermore, if a sufficient number of people use Compatibility View on a site, it will be added to an internal list on a server somewhere at Microsoft.

There are several problems with this. First of all, the fact that Compatibility View renders things almost like IE7, but not quite is a real problem. As far as I know, there is no way to query which mode the browser is in. Conditional comments targeted at IE7 won’t be picked up with Compatibility Mode.

Worse yet, a site that gets on the Compatibility View list has no way of taking themselves off the list. You are forever cast off into non-standards land for any Internet Explorer 8 user. If you update your site to fix whatever rendering issues there were formerly in IE8, there is no way to tell Microsoft that. Until Microsoft comes up with a way for site owners to have their site taken off the list, your site will be broken in IE8 (should you eventually update it).

In all likelihood, we developers have a few months before IE8 starts to gain any sort of market share. If you haven’t at least got a test box or VM with IE8 installed on it yet, then it’s time to get going. With any luck, some smart people will figure out how to deal with a lot of the mess IE8 has introduced and the web will move along. From a consumer point of view, IE8 is a welcome upgrade to IE7 touting better security and faster rendering. It’s too bad it has to make so many of us lose our hair. All the more reason to Bring Down IE6.