After installing Snow Leopard on my 15″ MacBook Pro a few days ago I noticed that fonts, specifically at low sizes, looked terrible. Edges where overly rugged and text seemed dim. In essence, it seemed as if every font had decreased an entire weight.

With further research I discovered that this is a problem with 3rd party (non-apple) monitors and their default status in 10.6. Previously in 10.5’s System Preferences users where able to alter Font Smoothing with one of several options:

Yet, in 10.6 the option has been replaced with a simple Use LCD Font Smoothing When Available dialogue. The problem is OS X 10.6 detects some 3rd party monitors (Dell, Samsung, Lenovo, etc.) as CRTs and doesn’t allow them to utilize font smoothing. Here’s an example side by side of font non-smoothing vs. smoothing on Snow Leopard.

Fortunately there is a way to force font smoothing via terminal, simply paste the following text and hit enter:

defaults -currentHost write -globalDomain AppleFontSmoothing -int 2

• 0 – is the setting for CRT rendering (looks horrible on LCD)
• 1 – is the setting for Light
• 2 – is the setting for Medium (Best for Flat Panel)
• 3 – is the setting for Strong

Once you’ve set this you will want to log out and back into OS X. At this point all the fonts should look as they did before your upgrade to 10.6. Hoorah!

Update: Added another example from iTunes music selection that highlights this issue a bit more. Also, updated a grammar fix thanks to Reddit user guriboysf.

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.

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.