It isn’t often that I run across a Firefox Add-on which just blows my mind and makes me want to sing the praises of the developer, but Better Gmail 2.0.5.2 is one such add-on. This week we converted the office away from Microsoft Exchange server and onto the Google Mail App instead. I won’t go into the reasons why in this post, but after I made the switch I was somewhat disappointed with the interface of Gmail and it’s inability to allow me to customize it.

Here were just a handful of my gripes.

• I can’t resize the width of the left side menu bar
• Why does Gmail feel the need to “label” my messages rather then using the conventional folder system?
• Shouldn’t I be able to modify the color scheme to my liking. There is only so much pastel I can take
• When writing messages the REPLY, FORWARD and DELETE aren’t in the most obvious or intuitive locations

I don’t want to continue on bitching about Google, because aside from the interface the Gmail App kicks ass and checks SPAM well. It is reliable and it allows me to IMAP my mail to desktop clients. In light of my situation I looked for some way to relieve my disdain for the default interface.

Better Gmail 2 makes the entire mail experience much more enjoyable and easy on the eyes.
Google Talk actually looks like an IM client

Labels are converted into operating like folders.

A handy keyboard shortcut menu

All in all, this add-on has made the jump from Exchange to Gmail VERY enjoyable! I highly suggest Better Gmail 2.

This past week while working on a project I ran into the most frustrating IE7 bug I’ve encountered to date. I have tried to recreate it in separate environments from the site I was developing but up to now have been unable to do so. However, in hopes of helping someone tortured by this bug down the road I will give my best guess as to what is causing it and explain how I fixed it.

First off, the bug looks like this:

Alright, the first thing is that this bug comes into play only in IE7 (IE6 works fine). Second, it seems to occur only when there are html elements nested inside an anchor tag and these elements are told to change their background properties on the :hover phase of a parent element. This most often happens with nested list drop down menus like the example above. Third, the elements that act buggy are positioned absolutely within the :hover(ed) parent element. Once again this only really occurs with drop down menus.

In the code below the element that gets the bug is the anchor element within the nested list items.

<div id="navigation"><ul id="nav">
<li><a href="" title=""><span>Solutions</span></a></li>
<li><a href="" title=""><span>Investors</span></a><ul>
	<li><a href="" title="">Buggy nav item 1</a></li>
	<li><a href="" title="">Buggy nav item 2</a></li>
	<li><a href="" title="">Buggy nav item 3</a></li>
</ul></li>
</ul></div>

What happens is that when a top level navigation item is hovered over the drop down appears, however, because a top level nested element had a background image change on the :hover state the drop down list loses its padding. In essence, the ul > li > ul > li > a element will lose its padding and end up looking like the buggy menu above. Although once the user rolls over this anchor element it will once again regain its padding and jump back into place.

When would this occur?

Good question. The most likely occurrence of this would be if you had a navigation menu that required a lot of imagery. For example, a menu with which you were forced to use a span tag to get one extra background image. And then on the hover you wanted the span background image to change, perhaps to point an arrow downward instead of sideways. Therefore the user would know which top level item they had hovered over even if the mouse was placed on the nested sub-menu below. In this case you’d probably have some CSS like this.

#header ul#nav li.active a span,
#header ul#nav li:hover a span {
   color: #fff;
   background: url(/images/icons/downward-arrow.gif)
   no-repeat 15px 50%;
}

Alright, so basically you decide to help the viewer see what nav menu they’re on by changing the span background property to have a down arrow. Unfortunately all you end up with is a buggy IE7 drop down menu. What’s the best fix? In this case the best fix is the apply that downward arrow to the li background and just have the span item go transparent instead of change the image on the fly. One added bonus to this method is that you won’t have to load that image on the hover state. Still, this means that if you’re using the li background already you will be forced to find another way to highlight the top-level navigation item.

What’s really going on here?

Apparently when IE7 tries to re-render a background image on the :hover state, nested absolutely positioned elements are reset to their default value causing them to lose padding, etc. Hence, the best option is to avoid making IE7 redraw background images when there are absolutely positioned nested elements. Instead, rely on background colors or transparency for effect, or apply the effect to the li background.

Recently an article was published on A List Apart talking about the future of the DOCTYPE element and how browsers will render it in relation to web standards. In essence, the article discussed how developers have become used to certain browser rendering habits, and although they work within a standard framework, have not accounted for browsers in the future to display their websites correctly. Therefore, WASP suggests these browsers should continue to render like their previous counterparts unless specifically targeted to utilize current day standards.

First off, this line of thought is completely ignorant. The whole concept of web standards is to create a guideline that all developers can follow when producing websites. If developers stick to this guideline the consensus is that the browser (any version) should render pages correctly. Granted, some browsers (IE6/IE7/Safari1.2) have various issues rendering standard compliant code, but, in these cases, developers have found ways to target individual browsers and versions to make them work. For instance, utilizing conditional comments to target IE. The rest of the browsers: Firefox, Opera, Safari 2&3, Konquerer, etc. that actually follow web standards tend to look and act the same. There may be slight text rendering differences, or slight pixel variations, but for the most part functionality works and the website looks good.

The point is, standards work. So why in the world would we change the paradigm of how we implement them? It makes no sense to have a browser render pages like the previous version unless otherwise told.

The solution is simple. Target the browsers that have standards problems and apply hacks as needed. Otherwise, assume the “standard” will work and fully embrace it. If websites from the late 90’s break, so be it, you can’t impliment a standard without having non-standardized things stop working perfectly.

It’s like anything, if you want it to get better, you have to make a few sacrifices. If those sacrifices entail non-standards websites, then it’s time for that to happen. The web will be a better place. We have to stop placating people and force change for the better.

I love Chris Pederick’s developer toolbar for Firefox. It is user friendly has a ton of useful features – my favorites are CSS editing and the ability to display on-screen element information. Microsoft Internet Explorer (IE) also has a developer toolbar, straight from Microsoft – but how does it stack up against Chris Pederick’s creation?

Despite the inherent disadvantage of being part of the standards-shy IE*, the Internet Explorer Developer Toolbar does have some helpful features. Like Pederick’s toolbar it features validation of various document types through the W3C and has a helpful “View DOM” feature that breaks down the DOM of the page, promoting easier JavaScript and DOM scripting development. An interesting “Show Ruler” function also allows users to measure distances on screen, but I’m skeptical of its real-world value. The Internet Explorer Developer Toolbar has fewer features than Pederick’s Firefox version.

Although the Internet Explorer Developer Toolbar tries to elevate IE’s status as a developer’s browser, it actually does very little encourage its use as a serious development tool. I’ve learned that standards compliance the most important factor when choosing a browser for development – so that’s why I’ll continue to primarily use Firefox for development and IE for compatibility testing.

*I’m referring to IE version 6 and lower. I have not yet tested IE7 extensively.