I've noticed that text becomes difficult to read when I apply opacity or a drop shadow using a filter in IE7. Here's an image of a menu without opacity applied in IE7.

Notice that because of clear type, the text is nicely rounded and readable. Here's an image of the same menu with opacity applied in IE7.

You can see that the text is pixilated and less easy to read. It seems that if an opacity filter is applied to an element, the element's text is not displayed using clear type, even if the OS is set to use clear type. Here's an image of a div with a drop shadow applied.

The OS is set to use clear type and has been tuned. Firefox on the left uses the OS settings to display the text, yet with IE7 on the right, the the text is very hard to read. IE6 with all its problems at least doesn't mess up text when a filter is applied to an element. I have an open ticket with Microsoft and the support person sent me an email message that told me the way to fix the problem is to not use the drop shadow filter. I don't believe that's a good solution. Has anyone else had problems with filters in IE7?

Update 18 Aug 2008: Added an openTabOfElement method and now check for the hash of the url and open the tab that contains the hash item. Try opening the Contact tab. This also works for form validation routines when you want to set focus back to a field that contains an error. If the tab is closed you will get an error. To open the tab pass the element to the tabs.openTabOfElement method before setting focus to the form element.

I liked the tabs created in Sliding Doors of CSS, Part II by Douglas Bowman. Please read the article so that you will understand how to modify the CSS of the tabs. The tabs are very nice for site navigation, but I wanted to use it in a tabbed interface within a page so that a user could click on each tab without reloading the page. First I started with the markup for the tabs.

Continue Reading "Tabbed Interface..."

I know it's a couple of days early to go Pink for October, but I don't have time to convert this weekend. Please take the time to donate to a breast cancer organization of your choice.

Thank you

Tanny

Update 15 Sep 2006: Added check to see if target element is contained in the li before removing the sfhover class to avoid flickering over select elements with a size greater then one.

I've modified iehover-fix.js to use DOM methods to create the iframe shim instead of innerHTML. When using innerHTML the iframe, menus and sub menus were added, which in cases with a large menu tree could take some time. I usually use innerHTML to add a number of elements to the DOM because it is faster. In this case using DOM methods should improve performance since we are only adding one element for each dropdown or flyout menu and not recreating the menu list. I've also added code suggested by Alistair Potts that should work with https pages.

Continue Reading "Select tag overlap in IE, Part III..."

Update: Added conditional comment so that IE 7 is bypassed.

Only ten months late, but here is how to use iehover-fix.js. First a little history. Some have used the Suckerfish dropdowns menu written at A LIST apart way back in November 07, 2003. The dropdowns work great until select elements (dropdown list boxes) are added to a form. The menus go under the select elements when viewed in IE. Several years ago I found a fix for this problem and wrote about it in my Select tag overlap in IE article. Since then things have changed and multi-nested menus are now supported which you can read about in the excellent Son of Suckerfish Dropdowns article written by Patrick Griffiths and Dan Webb.

Using the iframe technique, Ilya I. Gerasimenko wrote the Cascading Menu: Vertical (IE <select> bug fix) solution. The only problem is that it didn't work with the Son of Suckerfish Dropdowns and didn't take IE 5.0 into account. IE 5.0 doesn't support the iframe method.

Taking Ilya's solution, I modified iehover-fix.js to support IE 5.0 and Son of Suckerfish Dropdowns.

Continue Reading "Select tag overlap in IE, Part II..."