Building on the momentum from my last post, it's a perfect time to talk about when it's okay for web designers to drop support for IE6. Of course WE want it, but I don't believe designers and developers get to make this call when they choose. Lots of prominent designers disagree with me, but I don't think it's up to us to decide.

Fact is, studies show that most people still using IE6 don't have a choice to upgrade. As of May 2009, 60% of companies still use IE6 as their default browser. That's something we are compelled to take into account.

In recent memory we've seen popular web apps like 37signals apps, Apple's MobileMe, Google Apps and YouTube stop support for this browser. Since these apps cater to a more computer savvy audience, I believe it's makes complete sense for them. However, it doesn't provide just cause for people that build public websites to stop supporting it without more research. I don't believe Apple.com will stop optimizing for IE6 anytime soon if it means they can sell more Macs.

I did a quick survey of a bunch of our clients. I saw anywhere from 5-15% of users to our client websites are still using IE6. That's too high for me, so we're going to keep supporting it. Until that percentage creeps to roughly 3% or lower, I believe it's our obligation to make sure it works.

"Making it work" can mean a number of things. I don't think websites have to look exactly the same in IE6 as they do in modern web browsers. We geeks call this progressive enhancement, but as long as the website is still functional and degrades gracefully I have no issue with it.

A slightly more aggressive approach is being taken by the creators of IE6nomore.com, which I find pretty interesting. They have created some really simple code people can add to their website, which shows a banner like this to any IE6 visitors:

That's a pretty cool idea!

No matter what, if you do choose to drop support for IE6 make sure you are doing it for the right reasons. Doing it out of frustration, laziness or indifference isn't the best way to communicate expertise to clients and potential clients.

By far the most difficult thing to master when learning to code with web standards is browser optimization. It seems like every layout presents a different challenge than the last one. It's taken me years to figure out pretty much every bug Internet Explorer can throw my way, but I still struggle from time to time.

Part of coping with Internet Explorer (versions 6 and 7 in particular) means having some nifty tricks that can help you in a pinch. Some of my tricks aren't very well publicized, so I'm posting them here in hopes of saving at least one person from taking their frustration out on their innocent laptop, wife or dog.

Target IE6 or IE7 with a single character

A quick way to set a specific style that applies only to IE6 or IE7 without the use of conditional comments or javascript is to try the following simple syntax in your stylesheet. Just add a simple asterisk or underscore before the property:

#someElement {     
	background: red; /* modern browsers */     
	*background: green; /* IE 7 and below */     
	_background: yellow; /* IE6 exclusively */  
}  

Credit: NetTuts.com- http://bit.ly/8TIJSs

Using text-indent on an input in IE6

If you use image sprites (which I highly recommend), you are likely to run into this problem. The text-indent property does not work on an input. So you may get an image that looks like this:

Instead of hiding the text and replacing it with an image, both show up in IE6. The following three lines must be added to your IE stylesheet for the input in question to fix the problem:

display:block;
font-size: 0px;
line-height: 0px;

Usually the display:block property is unnecessary if you are using a sprite or image replacement technique to replace the text (because it's already a block level element).

Credit: ProductiveDreams.com- http://bit.ly/12YKXi

IE8 Rendering Modes

In typical Microsoft fashion, they actually present you with a bunch of rendering mode options in Internet Explorer 8 instead of just doing it the right way all of the time. So if you write code properly and it validates, you will want to add the following meta tag to the <head> ALL of your layouts moving forward:

<meta http-equiv="X-UA-Compatible" content="IE=8" />	

This tag enables the IE8 standards compliance mode on your website, which you would think should be active all the time.

Credit: Zurb.com- http://bit.ly/4RGzk

CSS Browser Selector

When all else fails, I use an amazing 1.1k javascript file called CSS browser selector. This script lets you code styles for tons of different technical configurations. You can set attributes by operating system, browser and browser version. It also cleverly adds a "js" class when javascript is enabled so that you can set styles up for when it is disabled. Pure awesomeness ...

Credit: http://rafael.adm.br/css_browser_selector/

The Alpha-transparent PNG Paradox

One super-annoying issue with IE6 is that it doesn't know how to read alpha-transparent images properly. So if you have an image with a shadow over a transparent background or something with an opacity less than 100%, chances are it won't look so hot in IE6.

This isn't an easy fix. There are a number of recipes that cover different situations. Frankly, we try to avoid all of them if we can and simply use different images in IE6 that don't have alpha-transparency. It doesn't look as cool, but that's what they get for using a crappy browser. Here are the best solutions I know about:

• Unit PNG Fix (lightweight, my favorite right now)
• Supersleight (doesn't work for background images)
• DD_belatedPNG (I haven't used before, but it seems very solid)

A few weeks ago, the Google Analytics team released some fantastic updates to their software. Of particular interest to me was enhanced mobile tracking and reporting capabilities.

The first thing to understand about mobile website reporting is that it works differently than regular websites. Many mobile browsers do not yet support javascript, the language that platforms like Analytics depend on to track website stats. Instead of the browser doing the work, mobile tracking leans on some server-side code to track visitors properly.

Don't be intimidated by all the geek-speak though. It's not rocket science to implement analytics on your mobile site. If you've got five minutes, know how to use FTP and don't mind copy/pasting some code, you can do this!

1. Add a new profile

From your Google Analytics account, add your mobile site as a new domain.

2. Get advanced tracking code

Once your site is added, Analytics will give you a Web Property ID like normal. Keep this around for future reference. In the example below, the Property ID is highlighted.

Click on the "Advanced" tab under the instructions heading. Then click on the radio button to select "A site built for a mobile phone". Finally, select the server-side language. I will be using PHP for this example.

3. Insert the snippets

There are two snippets of code that you must copy/paste onto each page of your mobile website. One goes at the top of each page, right after the <html> tag. The other goes at the bottom of each page, prior to the </body> tag.

Note that the third line of the top snippet includes your Web Property ID. This varies for each domain, so be sure to change it if you ever re-use this code.

4. Upload the file

Lastly, you have to download this file called "ga.php" and upload it to the root directory your domain. This means if your domain is m.yourdomain.com, this file needs to be at m.yourdomain.com/ga.php.

5. Test and Celebrate!

Give it a few minutes and refresh the tracking status in Google Analytics. Assuming you followed the directions, you should be in great shape.

Known Limitations

Lastly, it's important to familiarize yourself with the currently known issues, published by Google in the sample code instructions:

• Multiple instances- you can't run multiple copies of the script on your website, or use it in conjunction with the standard javascript tracking code.
• Inaccurate locations- Since Google determines users' location using their IP address, tracking this from a mobile device is not as accurate.
• Server load- Due to the additional code required to track visitors properly, additional server load may be possible.