In the Beginning

When I first started using Mac OS X in college I fell in love with the Safari web browser. It was light weight, sexy, and fast. Unfortunately, the more I ramped into complex web development the more I realized Safari’s severe developer limitations. Back then developers had to enter terminal commands to even gain access to Safari’s developer menu. And, once turned on, the developer menu lacked the oomph of Firefox’s flourishing Firebug and Web Developer Toolbar extensions.

Since that day I’ve been using Firefox heavily for development and only occasionally jumping into Safari to test site feel and functionality.

Then, about a year ago, Safari started making real steps to support web developers. The release of Safari 4 earlier this year capitalized a nice upswing in Safari developer improvements. But, unfortunately, Safari still lacks some of the most basic development capability.

In my opinion, if Safari doesn’t address the following three issues, it will never become a viable competitor to Firefox for developers.

Source View Made for the 80’s

Any time your browser’s source code view renders like Internet Explorer’s you really need to sit down think things over. Is this acceptable, am I being an asshole? The answer, obviously, is yes.

Let Me View Background Images!

The web is no longer a mass of tables and img tags. Thanks to CSS we’ve started abstracting background effects from real content. Knowing this, there is absolutely no reason why Safari shouldn’t have a view background image option. Safari, do you really expect me to right click, inspect element, and then track down the CSS that links to that background image? Give me a break.

Target HTML Elements Faster

The best thing about the Web Developer Toolbar extension for Firefox is that you can hit cmd-shift-y and instantly view HTML elements. This is perfect if you’re trying to track down a styling issue or remember an ID name. It’s fast, easy, and accurate. Safari’s right click > inspect element isn’t even in the same ballpark as this. And, as hard as I’ve tried, there’s no way to reassign the Inspect Element shortcut in OS X.

Conclusion

Safari, you’re a great consumer browser. And yes, WebKit is a phenomenal web rendering engine. Hell, even Google loves you. Please, just fix these small problems and I’ll switch to you full-time, I promise! Until then, I’m going to continue buying FireFox t-shirts.

We’re happy to formally announce the launch of Support Details, our first planned public product. This is one of those ideas which was in the works here at Imulus far longer then need be. In fact the idea was discussed in ’03 and sadly it fell off the radar until this year. Support Details is an attempt to add clarification to browser related issues between non-technical web visitors and their clients & customers.

This idea started as way to save time. To solve odd browser issues our team was always asking the clients questions like:

“What browser are you using?”, “Which version of Flash is installed?”,”Do you have cookies enabled?” “What is your screen size?”

You get the point.

We simply were losing too much time to explaining the “how to” aspect; hence Support Details.

To be useful the product had to determine what browser a customer was using, along with any other configuration data which could be detected. Then, it needed a reliable way for capturing and sending the data over to the person who was working on the problem.

The concept is simple. That is part of the reason we believe it works so well. Yet, we’re always open to good suggestions for improvement and we’re eager to hear your feedback.

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.