Adapting to the brave new world of Internet Explorer 7
Published: April 27, 2006
By Sandi Hardmeier
Every time a new release of Internet Explorer hits the streets, there will be some users who experience problems. In the 'old days' (yes, I know, I’m showing my age) the most common problems were video driver related. We were forever telling people to update their video drivers and reduce hardware acceleration in an attempt to solve failure-to-respond problems involving kernel32.dll. Or, if the user had left their antivirus program running, we would advise a reinstallation of Windows (boring side note: I first became involved with the Microsoft online community after I was silly enough to leave my antivirus protection running during the installation of Outlook 95).
Over time, things have improved so much that problems with video drivers are a rarity. Antivirus programs as a whole also seem to be behaving better, although there are a couple of antivirus programs that may still cause serious problems on your system if you leave them running when installing Internet Explorer.
Internet Explorer 7 introduces some unique challenges and shows us that some lessons from the past have still not been learned by Web site developers.
User-agent-string detection
Whenever we visit a Web page, our Web browser will transmit basic information about itself and the operating system we are using.
Internet Explorer 7 has a new user-agent string (UAS): "Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)". "Mozilla" is the application-name portion of the UAS. 4.0 is the version. MSIE 7.0b is the Version Token. Windows NT 6.0 is the Platform Token. The "b" in the UAS signifies that the version of Internet Explorer is a beta.
Tip: You’ll note that Internet Explorer reports that it is "Mozilla." This report is because Internet Explorer and Mozilla actually have a common lineage. My earlier article, "The History of Internet Explorer," discusses this point.
Web sites sometimes use the information provided by the UAS to control the content displayed to visitors. Some Web sites will display sites differently according to the Web browser and browser version. Some Web sites will completely block Web browser versions they are not coded to recognize. I have even encountered Web sites that bar access to Internet Explorer users no matter what version they use, simply because the site’s owners don’t like Internet Explorer, or Microsoft.
Web sites that detect "up to a particular browser version" instead of "supported browser version or higher" (a subtle, but important, distinction) are very widespread. Realistically, there is often no technical reason for the wholesale blocking of a new version of Internet Explorer, and some Web developers break their sites unnecessarily. Sometimes, if a site will not recognize Internet Explorer 7 because the site uses "up to a particular browser version" protocols, the Web site developer will apply a style sheet that is incompatible with Internet Explorer 7 when, in fact, the style sheet the developer used for IE6 would have worked quite well. Style sheets are used to manage many parts of a Web page, including position, size, and behavior of columns, font size, font, background colors, and other page features.
For example, my Frequent Flyer Web site blocked Internet Explorer 7 Beta 1 completely because it did could not recognize it (it used an "up to a particular browser version" detection protocol). Another Web site for a large international corporation did not block Internet Explorer 7 but instead served a style sheet that forced the font size on their Web page to an unreadably small size. When I tricked both these Web sites into thinking that I was using Internet Explorer 6, both sites worked perfectly.
"How did you trick the sites into thinking you are using IE6?" I hear you ask. I edited my computer’s Registry to override the UAS.
The Windows Registry can be a frightening place, and I strongly recommend that you do not try to edit the Windows Registry by hand unless you are very experienced in, and familiar with, the areas of the Registry that you are working in. For example, I am quite comfortable with editing areas of the Registry that relate directly to Internet Explorer, but I will not touch other areas without research and guidance. That being said, UAS related problems are common enough that there are a few sites that now provide importable Registry files that will do the job for you. The most popular site is http://www.fiddlertool.com/useragent.aspx, which hosts an IE6 file and various IE7 files. Run the IE6 file to fool sites into thinking you are running IE6, and then run the correct file for your version of IE7 to change things back again.
CSS fixes
Microsoft has taken some very brave steps with their changes concerning how Internet Explorer treats CSS. The CSS fixes being implemented in Internet Explorer 7 will result in some common CSS workarounds (commonly called hacks) no longer working-they will either be ignored, or the effect will be different to what had been the previous case. Because of this change, Web pages may display incorrectly. Two examples are shown below:
In the example above you can see some of the text is missing.
This is an extreme example of what can go wrong when CSS hacks break.
It is beyond the scope of this article to advise Web developers about how to fix the display issues that we see above (and to be honest, I’m not good enough at CSS to consider myself the best source of advice). It is also doubtful that breaks such as these will be fixed by the UAS trick mentioned above.
I strongly recommend that Web developers take advantage of two resources when working on CSS issues on their sites. First, the IE team blog is an excellent source of information. Second, Markus Mielke and Dave Massy, two program managers, have written an excellent starting-point article about the changes to CSS that may cause issues with Web sites (see Related Links).
What can we, as casual Web surfers, do when we are confronted by such display problems and the UAS workaround does not help? Well, not that much. We can contact the owners of Web sites and advise them of the problem, or, if we understand CSS, we can apply our own style sheet to a site (click on Tools, then Internet Options, and then Accessibility. Enable the option to Format documents using my Style Sheet, and then navigate to the CSS sheet on your PC that you wish to use). Sometimes an affected site will also have a Web feed. Invariably the feed will work and you will be able to read the text and view the graphics on the affected page that way. Of course, we can also use an alternative Web browser until the site owner is able to review and rewrite his CSS.
Tip: Advanced users only: By viewing the source code of a page we can work out what style sheet has been applied, its document path, download the style sheet code, edit it to remove the problem hacks, save to our system, and apply the updated CSS to a problem site using the steps described above.
The Internet Explorer team has released builds of Internet Explorer 7 via MSDN and Technet, as well as via the Internet Explorer home site, to give Web developers and IT Professionals every opportunity to test their sites and applications in the new environment of Internet Explorer 7. But, there will still be some pain while we wait for various Web sites to rewrite user-agent-string protocols to suit Internet Explorer 7 and as developers discover that the CSS workarounds originally implemented to address deficiencies in the way older versions of Internet Explorer handled CSS are now broken. The most important thing to remember if you come across issues such as those described in this article is that your computer is not broken. Reinstalling Internet Explorer 7 won’t help. Reformatting your machine won’t help. Writing to site owners, alerting them to issues and referring them to related Blogs and MSDN articles will help.
