Bloggerrific

It is time for the web design community to take a stand and stop supporting Microsoft Internet Explorer 6! That’s right, I said it, as many have said before me, and yet somehow, most web designers still cross-browser test in IE6. Well, guess what, I’ve stopped. Okay, not completely. With my freelance clients, I will probably still check IE6, because truthfully, many of my clients themselves still run IE6. However, at my fulltime job as the web designer for College Prowler we have officially stopped supporting IE6! So why did I push for this, and how are we handling it?

So, some quick stats on Microsoft Internet Explorer 6. IE6 was launched by Microsoft in 2001. Though it has had some minor updates since it’s initial launch, you know that doesn’t change anything, especially because some people out there are still using that first launched version! IE6 came standard on every Windows machine since then until IE7 was launched in 2006. Now last time I checked (aka when this post was written) it was late 2009. IE6 has been out of date since it’s inception, but has definitely been out of date since it was replaced by IE7 over 3 years ago. So how it is that still approximately 5% of internet users still use IE6? Well sadly, Microsoft does not require, or even really push users to update, especially in the olden days. I grabbed that 5% estimate off of Google Analytics for my own site, College Prowler, and a few of my freelance clients. Though the percent is slowly falling, it will be around for a while I’m sure. So, based off of the small percentage, which is slowly falling, and the fact that cross-browser testing IE6 occupies at least 50% of my cross-browser testing time

The irony of it all is that even Microsoft is desperate for users to upgrade off of IE6 to IE7 or IE8. This of course begs the question, how stupid do you have to be to still run IE6!?! At least 90% of the display bugs I’m aware of are solely IE6 problems. Entire blog articles are devoted to listing bug fixes for IE6. Well, based off of all of those stats, our company finally let me move away from IE6. We put up a warning (only visible to IE6 users) that we don’t support IE6. We even included a link to download IE8, but somehow I don’t think that’s gonna do anything. I’m just glad to be done with it!

So if you know what’s good for you as a web designer, forget IE6! The more people that stop supporting it, the faster people will switch off of it, and the faster we’ll be rid of that evil browser that has trouble outputting today’s beautiful websites. Of course, if you are still making websites with red text on a blue background, maybe you should still be testing in IE6…

IE6, has for quite some time, been the bane of my existence. It has a deluge of bugs, but it also has some easy fixes for it. Below I have a small list of some of those bugs which don’t have easy and simple solutions but that you should still be aware of.

1. PNG transparency fix link bug:
In my last IE6 bugs and hacks post, I wrote about the common PNG transparency issue. The common javascript fix that is used for this actually causes a problem if you use png images inside of a link. I use this a lot for custom-made rollover buttons (which I implement using a great CSS trick). If a PNG image with transparency is placed inside of an <a> tag with the javascript fix enabled, then IE6 won’t recognize it as a link. Luckily, this actually has a fix! Simply add a "position: relative;" to the image CSS definition and you are good to go!

2. Absence of min-height/min-width:
IE6 does not understand min-height or min-width style definitions for objects. These definitions are often very helpful with dynamic content. There is sadly no fix for this problem. Luckily, this usually won’t cause big problems with your layout. The best you can do is try to avoid the need to use these definitions and you should be fine.

3. :hover only works on a tags with an href
Unfortunately, IE6 decided that the pseudo-class :hover wasn’t useful enough for anything other than links. Obviously, that isn’t always the case. You may want to use it for divs, spans, paragraphs, or any number of other objects. There is no fix for this problem, you’ll just have to live with your hover not working in IE6 and below.

4. Divs won’t maintain a small defined height

This is a really strange one. It seems that if you define a div with a height of anywhere below about 10 pixels, IE6 will force it to 10px (or whatever it magically seems to have selected). This is most likely because it is making room for overflow. There are three fixes that I’ve heard of:

• Apply a “font-size: 0px;” to the div (which can be a problem if you have copy in the div).
• Apply a “line-height: 0px;” to the div (which can also be a problem for the same reason above).
• Apply a “overflow: hidden;” to the div which should remove the overflow problem.

Now that all of that is over, Internet Explorer 8 has just been released post Beta. This couldn’t be more frustrating for me seeing as right now there are 3 active version of IE out there. Last time I checked IE has about 50% of the browser market, and within that, IE6 had about 20%, IE7 about 70%, and IE8 the remaining 10%. Slowly this will all shift, but it’ll be at least another year before I’d even consider not testing in IE6 anymore. Sadly that means for at least a year I’ll be testing three frickin versions of Internet Explorer. FRICK! Good luck to you all .

The float property in CSS is a blessing if you ask me. I use it almost exclusively for layout, with occasional tables or absolute/relative positioning. The float property leaves your layout incredibly fluid so that you can change it very easily. However, there are some difficulties that are easy to run into when using the float property.

What float essentially does is force block level elements to not actually take up space in the document. Only floating elements will move around other floating elements, but you might find that sometimes your elements overlap or float around another when you just don’t want it. This happens very commonly when you define the height of an object such as a div, and float elements inside of it which actually will exceed the height of that div. Some browsers will not expand the containing div automatically. Other times, you might have a div floating left, and another immediately after that, but you don’t want them next to each other horizontally. For all of these problems, there is one simple and easy solution:

The “clear: both” property: Think of the clear property as a horizontal line that forces everything written after it in markup to appear below it (within the containing div). The most common implementation I’ve ever seen is a div solely created to contain this property. I’ve seen this all over the web, and I use it all the time, without any hesitation. Make a CSS declaration like this:

div.clear{
   clear: both;
}

And the HTML:

Putting this div below another other set of divs will essentially create a forced break between everything written above it in the HTML, and everything written below it. This is limited to the containing div though. I personally can only think of a single situation when you wouldn’t want it limited to the containing div (if you wanted to force a two column layout to be the same height, but you just can’t do that). So yeah, stick to this… you won’t regret it!

If you are making a website, you absolutely need to test it across browsers. This need increases even more when you use CSS heavily for your layout and other styling. Why you ask? Well, different browsers read CSS differently. In particular, Internet Explorer (IE) is awful because Microsoft doesn’t feel the need to ascribe to web standards. So here are some suggestions to get your started with your cross-browser testing:

1. Download every major browser to test your site in. Essentially, you should be working with Firefox, Internet Explorer, Safari, Chrome, and Opera. Opera is used by about 3% of internet users, and is the least common of the five mentioned here. There are also other browsers, but usually you need to stop somewhere, and I think Opera is a good place to end.

It might help to set yourself up with Google Analytics so you can know what percentage of your users are using what browsers. It will even break it down further into what version your users have, which brings me to my next point.

2. Make sure to test both IE7 and IE6. Internet explorer 6 and 7 are vastly different. Soon, IE8 will be out of beta testing and will be yet another version that needs to be tested. This is the biggest pain you’ll encounter. IE7 is actually pretty good at complying with web standards, but IE6 is like a death trap. The problem here is obviously you are only allowed to have one version of Internet Explorer on your browser at any given time. So, either install a virtual machine (much to techie for myself) or keep setup files for both IE6 and IE7 around, and just uninstall and reinstall (which is annoying, but it does the trick). Why must we go through such painful agony just to make sure our site looks good? Well, sadly, too many PC users don’t let Windows automatically update for them, leaving about 25% of IE users still with version 6. This is of course sensitive to the date of this post and will slowly decrease. Overall, in the past 6 months, I’ve found users of my company’s website go from about 18% IE6 users to 14%, which isn’t even statistically significant. Bottom line, test in both because they are vastly different!

3. Try out some of the free cross-browser compatibility testing tools out there. There are a lot of them, but most just want your money, and most aren’t very great if they are free. Short of shelling out some money, your best bet is probably browsershots.org. However, last I checked they limit you to one page (with every browser imaginable though). However, this requires you to have your site live when you test, whereas installing the browsers on your computer allows you to test offline.

4. Keep an eye out for common errors with specific browsers. The more you test, the better feel you’ll get for the flaws of different browsers. You’ll learn that the default margin on paragraph tags is different in IE than it is in other browsers. You’ll learn that min-height and min-width attributes do not function on IE6. As you come to figure out these flaws, you’ll be able to preempt them by writing clean and efficient CSS. This doesn’t completely eliminate the need to cross-browser test, but it certainly will make the process go a lot quicker.

When I was studying at CMU, I learned the mantra of usability research, “The user is not like me”. It is so true that it’s cliche, but it also applies to web design. You just can’t assume that your users see the same thing as what you see unless you go about finding out how they see it! Different browsers display code differently. Account for all your users or suffer the consequence and lose some of them to layout bugs…

When I started my job as a fulltime web designer, I discovered that my boss used tables for everything. This wasn’t that surprising considering he is a back end developer as opposed to a front end designer. I of course yelled at him (in my mind so as not to get fired) about how horrible tables are. Since then, I’ve settled more in the middle, and I figured I should offer my two cents on the debate of Tables Versus CSS for layout purposes.

First let’s take a look at the oh-so-obvious faults of tables, and why these cons are such an issue.

Con 1. Tables are incredibly rigid. Short of moving the content from one cell to another, changing the layout of anything within your table is incredibly difficult. Especially since you won’t want your layout to look like it uses a table, you’ll end up with rowspans and colspans everywhere.

Con 2. Table code can get messy. If you use tables for all your layout, then you’ll end up with nested tables all over the place. The code becomes hard to read, and almost impossible to edit.

Con 3. Tables have different default settings in different browsers. If you want your site to look the same no matter what browser your user is viewing it through, then you’ll have to go through at set padding, margin, border, et cetera to the values you want them to be. This is a hassle because of all the tags associated with tables. You’ve got table, tr, th, and td. Mind you, even if you don’t use tables, you should be setting default CSS values anyway to avoid cross-browser issues.

Con 4. Tables increase the size of your files. That’s right. Tables just often require more code. Even though the difference in load time for most people is negligable, it is still something to consider.

Alright, and now the benefits of tables, and why it is important to set aside your bias against tables and accept these pros.

Pro 1. Tables can be very helpful for certain design elements. Take rounded corners of any box for example. Though you’ll need anywhere between 1 and 8 images to make a rounded corner box (1 if the box does not need to expand, 3 if it expands in one direction, and 8 if it expands in two), tables will make the implementation of this a lot easier. Of course, you can use divs for this, but you won’t need to edit this table, just the content and images inside. Divs can float incorrectly in different browsers, ruining your rounded corner box, but the table won’t break.

Pro 2. Tables are great when you need to show… tables. That’s right, sometimes the best way to display information is in a table, and obviously the best way to implement that in the web is using… you guessed it, a table!

Pro 3. Tables make certain difficult CSS issues much easier. With tables, you can easily vertically center text, or ensure that two separate sentences of text will always appear next to each other horizontally. Obviously, there are tricks in CSS around this anyway. To vertically center a line of text, you can set the line-height to the same pixel height as the div it is in. So clearly, there is always a way around this problem.

When it comes down to it, every pro or con you find for tables doesn’t really matter. For every pro, using a little CSS magic, you can work around it. For every con, using a little effort or time can work around it too.

In the end, using floating divs is a much safer route to go for your layout. You can change the location of content very easily, your code will be cleaner, and make more sense logically when reading through it. But don’t knock down tables. Use tables for your overarching page layout (header, body, footer for example). These things won’t change as much, so tables are a clean and safe solution. Basically, tables aren’t 100% evil or amazing. Use them when appropriate, and don’t overdo it, and you’ll be just fine.