Tagged: IE

Recently, a developer sent me the following link pointing out gleefully the downward trend in IE 6.0 usage. http://marketshare.hitslink.com/report.aspx?qprid=3. Though I do not think anyone will be sorry to see the end of IE 6.0, as developers we need to understand the end use of our code.

The following link http://en.wikipedia.org/wiki/Usage_share_of_web_browsers compares many different sources for getting a good handle of what is being used in the market (and trends).

Though these stats vary greatly, IE is still generally 70%- 80% in most of the stats I see. Firefox is around 15-30%+ depending on which source you look at. For example, http://www.w3schools.com/browsers/browsers_stats.asp is much more FF friendly in it’s stats, but I suspect they are based on their traffic, not overall web traffic. Their traffic is more web developer oriented.

What can we learn from this? Developers like Fire Fox more than the general public does. No surprise here. We like the add ons, the stricter adherence to standards, etc. BUT the client is not generally a developer. Neither are the people looking at sites.

To sum it all up. As a developer at SolutionSet or elsewhere feel free to use whatever tools you like. But the most important browser to look at your work in is still IE. It is the “standard” out there that all your code should conform too. Too often, developers deliver great work in Firefox, that is untested in IE. I encourage all developers to regularly review all work in IE and actually use is at the primary way to “view” the work currently being worked on.

Over at ryanbrill.com, I’ve previously written about the multiple class bug in IE6. Today, we’re going to look at another similar IE6 bug: the ID-Class bug.

It seems that IE6 chokes when you have an element with an ID and several different class states. A common example is when you add a page class to your #content div. Take this example:

Home page:

<div id="content" class="home">
	<p>Home page</p>
</div>

About page:

<div id="content" class="about">
	<p>About page</p>
</div>

CSS:

#content.home {
	background: blue;
}
#content.about {
	background: red;
}

Given that code, IE will only ever add the styles to the #content.home div. #content.about or any subsequent styles following the #id.class paradigm will not get applied. Note that the order of the classes in the CSS is key here. If you move the #content.about rule above the #content.home rule, then the #content.home rule will no longer work.

So, how to fix this?

There are two options. The easiest one is to simply remove #content from the selectors, leaving you with:

.home {
	background: blue;
}
.about {
	background: red;
}

This may not necessarily be the best solution, as now you have generic classes that could be applied elsewhere (for instance, <a href="index.html" class="home">).

That brings us to another key part of this bug. This is only relevant if the #id.class is the last item in the selector. So, another option is to move the class higher up in the source, perhaps to a #container div:

#container.home #content {
	background: blue;
}
#container.about #content {
	background: red;
}

That will work fine, as the #id.class is no longer last in the selector. This is the solution I recommend, as you won’t have to worry about a generic class being added to un-intended elements.