Authoring Strategies for Internet Explorer 4.0 and 3.0

Sue Ledoux and Anita Rowland
Microsoft Corporation

September 30, 1997

Contents
Introduction
   Compatibility Goals
General Authoring Philosophies
   Plan in Advance
   Test It!
   Browser Detection
HTML Parsing Differences
Table Rendering Issues
Object Model Differences
Scripting Differences
Controls
CSS Differences
Customizing Style Sheets
International Issues
Miscellaneous Differences
Conclusion

Introduction

Now that the final version of Microsoft® Internet Explorer 4.0

has been released, there are even more Web browsers available to the end-user. For Web authors to attract the largest viewership, they must author their Web pages such that they display reasonably well in all or most of these browsers. However, to distinguish a Web site by staying on the leading edge of Internet technology often requires making use of features that are not available (or not yet available) in all browsers.

This article discusses the differences between Internet Explorer versions 3.0 and 4.0. Its goal is to help in two authoring scenarios:

Authors who wish their pages to display correctly or degrade gracefully on both versions of Internet Explorer will learn about important differences that they can account for.
Authors who design exclusively for Internet Explorer (such as in intranet situations) will find the information useful in updating their Internet Explorer 3.0 pages to version 4.0.

Part of the content was taken from IECOMPAT.HTM, which provides a list of key differences between Internet Explorer 3.0 and 4.0. IECOMPAT.HTM is available in the Internet Client SDK and is a strict subset of this article. Additional differences came from "the trenches," from the experiences of developers currently upgrading their pages to work in Internet Explorer 4.0.

Compatibility Goals

Compatibility is a key priority for Internet Explorer 4.0. As much as possible, we want to ensure that users who upgrade from Internet Explorer 3.0 will not be adversely affected. Compatibility goals are based on the following considerations:

Compliance with existing World Wide Web Consortium (W3C) standards (e.g., CSS1, HTML 4.0) and other standards (e.g., ECMA). For example, the CSS standards have been expanded since the Internet Explorer 3.0 release, and Internet Explorer 4.0 takes advantage of this and complies with the current standards. Check out the Specs and Standards page for more information about current Internet-related standards.
Accurate rendering of existing Web content. Web site owners expect their pages to be rendered in Internet Explorer 4.0 as they were in Internet Explorer 3.0.

In essence, the primary goal for Internet Explorer 4.0 is to give users what they expect to be the right behavior, taking into account the above-mentioned factors. The combination of these factors and some bug fixes causes Internet Explorer 4.0 to render some pages differently from Internet Explorer 3.0. The Internet Explorer development team has kept these to a minimum, but they are unavoidable. This document will help Web authors identify key differences between Internet Explorer 3.0 and Internet Explorer 4.0. (For information about differences in Internet Explorer 4.0 on different platforms, check out the Internet Explorer 4.0 Cross Platform article by Nancy Winnick Cluts.)

General Authoring Philosophies

Plan in Advance

When you first begin to author your Web site, you'll have to decide which browsers you'll support. Before making this decision, it's important to carefully evaluate your target audience. You may be in a situation where you know exactly which platform your audience is using (for example, in an intranet situation where corporate policies dictate operating systems and browsers). Or, if you have a special-purpose Web site, you may be able to make some assumptions about the audience. (For example, for our own MSDN online site, we know that our audience consists of Web authors, developers, and Webmasters who are likely to have late-model computers running recent versions of browsers.) However, if you have a general-interest Web site, you may want to reach the greatest number of Internet-enabled users. In this case, you probably cannot afford to make assumptions about the capabilities and configuration of your users' computers.

The simplest way to reach the largest audience is to take the "lowest common denominator" approach, foregoing any of the latest improvements in Internet technology, which includes both standards updates and individual browser extensions. However, most authors would like to take advantage of many of these new standards and technologies to produce exciting, competitive Web sites.

Few organizations have the resources available to author a complete set of pages tailored to every browser out there. However, you will not win friends and gain influence by sticking to the lowest common denominator and authoring text-only pages, or by simply ignoring sections of your audience by relying exclusively on the newest technologies. A good compromise is to carefully choose the sections of your Web site that can most benefit from the newer or browser-specific features.

The newer features available fall into two categories:

Features that are supported only by certain browsers, and that do not function in any other browser.
Features that are supported only by certain browsers, but that "degrade gracefully" in others (meaning that the page is still completely functional and lacks only some esoteric embellishments). Many dynamic features can be included without harming the low-end browser view if thought out carefully.

For the parts of your page that you have decided to take advantage of browser-specific features, using features that gracefully degrade where possible will further reduce the effort required to create and maintain the pages. However, don't be afraid use non-standard embellishments; these provide your site with the latest in functionality and will greatly enhance the user experience and your competitive edge (although it's important to honestly assess whether a planned embellishment actually does enhance the user experience, and doesn't just excite you personally!). The key is keep these enhancements to a manageable number, giving careful consideration to the future maintenance and upkeep requirements of the site. Nancy Winnick Cluts gives some great pointers about technology tradeoffs in her Tradeoffs article.

Test It!

No matter how carefully you plan and code your pages, of course there is no substitute for looking at your pages in both Internet Explorer 3.0 and 4.0, and any other browsers that you have selected as your target. There is a tendency in the fast-paced world of Internet publishing to skimp on this phase, with the rationalization that "we can always fix it tomorrow." But your audience may not return tomorrow to see the updates.

It is helpful if you test your site at many steps along the way during development, not just once at the very end. A useful technique is to prototype all of the complex or newer functionality first, and then test it on all target platforms. Once you have determined that the feature is functional or has a workable alternative on all browsers, you can go ahead and design the rest of the site. This can save a lot of time by catching any incorrect assumptions early, and can possibly prevent you from having to completely redesign your site from scratch.

When defining your target audience and creating your test plan, don't forget to include hardware requirements. It's a good idea to set up machines with all of your target platforms before you even begin, to ensure that you have an adequate testing environment for each platform, before authoring specifically for that platform. In the case of Internet Explorer, you'll need two separate machines to test under versions 3.0 and 4.0. You may want to set up a version of Internet Explorer 3.0 on an older 486 or even a 386 system. This setup will help you fully understand what the low-end audience will experience, and has the added benefit of reducing your testing costs.

Browser Detection

For some features, you will be able to use a single implementation that will either work in all browsers, or degrade gracefully in some. For other functionality, however, you may want to check the version of the client browser so you can provide an alternate implementation if the browser does not support the specific features you would like to use.

There are several techniques that can be used to determine the browser vendor and version:

Client Side

You can check the browser version on the client side (meaning the script is executed on the client side only and no information exchange takes place with the server) by using the navigator.userAgent object. An easy way to identify whether the browser is Internet Explorer and determine its version number is to use the following JScript function:

function msieversion()
// return Microsoft Internet Explorer (major)
// version number, or 0 for others.
// This function works by finding the "MSIE "
// string and extracting the version number
// following the space, up to the decimal point
// for the minor version, which is ignored.
{
var ua = window.navigator.userAgent
var msie = ua.indexOf ( "MSIE " )
if ( msie > 0 )      // is Microsoft Internet Explorer; return version number
   return parseInt ( ua.substring ( msie+5, ua.indexOf ( ".", msie ) ) )
else
   return 0          // is other browser
}

This function runs on the large majority of browsers and returns the major version number for any Microsoft Internet Explorer browser, or zero for all other browsers. Use of this function assures that the script will be compatible with future versions of Internet Explorer.

Scripts should always check version numbers "greater than or equal to" rather than just "equal to" to be compatible with future versions of the browser. Existing scripts that check for userAgent equal to "MSIE 3" should be changed to check the version correctly so that these scripts will recognize Internet Explorer 4.0.

The following example shows how to correctly check the client browser version:

if ( msieversion() >= 4 ) {
   [code for Internet Explorer 4.0 browsers]
}
else if ( msieversion() <= 3 ) {
   [code for other IE browsers]
}
else {
   [code for other browsers]
}

Server Side

You can also detect the browser on the server side, using Active Server Pages (ASP), CGI, or some other server-side solution, and send the client entirely different content based on the browser version. The following example demonstrates this technique using ASP:

<%
set bc = Server.CreateObject("MSWC.BrowserType")

if bc.browser="IE" then
   if bc.majorver="4" then
      [code for Internet Explorer 4.0 browsers]
   else
      [code for other Internet Explorer browsers]
else
   [code for other browsers]
end if
%>

For this solution, your pages will need to be hosted on a server that supports ASP.

The rest of this article describes the key differences between Internet Explorer version 3.0 and 4.0.

HTML Parsing Differences

FRAMESET inside a BODY is ignored

Reason for change: Compliance with HTML 4.0 DTD (Document Type Definition)

The <FRAMESET> and <BODY> tags are mutually exclusive for Internet Explorer 4.0; you must use either one or the other but not both. If you use both, the second one will be ignored.

If you were using the <BODY> tag to set attributes for the contents of the <FRAMESET>, move these attributes to the <FRAMESET>. The only place you need a <BODY> on a <FRAMESET> page is within the <NOFRAMES> section.

Any <SCRIPT> or <OBJECT> tags used in a <FRAMESET> definition document should be defined in the <HEAD> section of the document; otherwise, they will imply a <BODY> element, and the <FRAMESET> will be ignored. In addition, there are other tags which, when used, also imply a <BODY> (such as <IMG>, <P>, or even straight text), and will result in the subsequent <FRAMESET> being ignored.

Table Rendering Issues

Improved table width algorithm

Reason for change: Better compatibility with real-world pages

If the combined widths of the cells in a table exceed the width set for the table, Internet Explorer 4.0 uses the cumulative width of the cells to override the width set for the table. (Internet Explorer 3.0 would have adjusted the widths of the cells to fit the width of the table.)

Rendering order of <THEAD>, <TBODY>, and <TFOOT>

Reason for change: Spec compliance

According to W3C specifications, the order of these table elements should not matter. Internet Explorer 4.0 matches the spec. For example, even if a <TFOOT> appears first in the source order, Internet Explorer 4.0 will still render the contents of the <TFOOT> at the end of the table.

Object Model Differences

Removal of frames.count property

Reason for change: Redundant property

Internet Explorer 3.0 supported both frames.count and frames.length. Because these two properties are functionally equivalent, Internet Explorer 4.0 supports only frames.length.

Accessing X-object properties for ActiveX controls

Reason for change: Enhancement

X-object properties are properties that are exposed by the Internet Explorer 4.0 container on all objects in Internet Explorer 4.0. If an object has a property or method that conflicts with an X-object property/method, the object's property/method should be accessed explicitly as item.object.property, instead of item.property.

Unknown attributes are exposed as implicitly declared properties

Reason for change: Enhancement; better compatibility with real-world pages

Any unknown attribute on an element is exposed as an implicitly declared property on the element. This enables authors to specify initial values for implicitly declared properties in their HTML pages.

Scripting Differences

Case sensitivity in JavaScript

Reason for change: JavaScript compatibility and ECMA standard

JavaScript is now case-sensitive in Internet Explorer 4.0. Some real-world pages rely on capitalization in the definition of different variables. Case insensitivity was breaking those scripts.

Case sensitivity in entities

Reason for change: Microsoft applications read and generate case-sensitive HTML entities

Entities are case-sensitive in Internet Explorer 4.0. They were not in Internet Explorer 3.0, except where case sensitivity was meaningful. For example,   works in both 3.0 and 4.0, but &NBSP; will work only in Internet Explorer 3.0.

Doc objects

Internet Explorer 4.0 does not support window.navigate or window.location.href if the window has a non-HTML doc object (such as a Microsoft Word 7.0 document) loaded. As a result, once you have loaded a foreign page, you cannot control your frame or window content through script.

Interpretation of time values

Reason for change: Better compatibility with real-world pages and ECMA spec

getTimezoneOffset is defined to return the difference between local time and UTC time in minutes. If you want to test for a time behind GMT, you have to test for a positive number. A time zone ahead of GMT is a negative number.

Accessing collections in an OBJECT

Reason for change: ECMAScript compatibility

Internet Explorer 4.0 conforms to the ECMAScript language definition, whereby object.N = object["N"] = object[N]. Therefore, object[N] requests the property named N from the object. To access an object's collection explicitly, use the item method on the collection:

object.collection.item(N)

where collection is the name of the collection property.

Mouse* events renamed

Reason for change: ECMAScript compatibility

The previous naming convention for the mouse* events (mouseover, etc.) was non-standard. The names of these events have been changed to onmouse*.

Controls

Every ActiveX™ control should be a well-behaved control. Control developers should be sure to check out the Component Development section of the MSDN Online Web Workshop for information about control development.

Printing of pages containing ActiveX controls

Reason for change: Enhancement

One of the main goals for printing from Internet Explorer 4.0 is the ability to print in the background and to print links that have not yet been activated (for example, printing recursively, printing through the right-click menu, printing by dragging an HTML link to the printer, and so on).

To provide this functionality, a print spooler was created that runs in a separate thread inside Internet Explorer 4.0. This spooler takes URLs, downloads them, instantiates the associated application (in other words, this is not restricted to HTML documents), and instructs the application to print/render the data.

As a result of these changes, controls must to be able to save their data during run time, must not assume a screen DC, and must not expect to be UIActivate'd. (For details, see the Component Development section of the MSDN Online Web Workshop.)

HTML Layout Control

If you have any content that makes use of the HTML Layout Control, we encourage you to serve a separate page for Internet Explorer 4.0 based on the new CSS Positioning syntax. Because CSS Positioning support is now native in Internet Explorer 4.0, it is more efficient than using the HTML Layout Control. If it is not feasible to move to the CSS Positioning syntax in the immediate future, we encourage you test your page using Internet Explorer 4.0 and recommend that users add the site to a security zone with a level set to "low".

For additional information, see the HTML Layout Control pages on this site.

CSS Differences

Internet Explorer 3.0 introduced Cascading Style Sheets (CSS) to Windows-based browsers, with the first implementation of a working draft from the W3C. Since this time, the W3C Style Sheets working group has published the final Cascading Style Sheets, level 1 (CSS1) W3C Recommendation

. Internet Explorer 4.0's implementation of CSS is based on the final CSS recommendation. What this means for Web authors is that the CSS implementation is a richer, complete implementation that also includes bug fixes, and reflects any specification changes made from earlier drafts. The following is a list of issues that may affect authors who have authored pages using CSS in Internet Explorer 3.0. Changes include bug fixes as well as spec changes or clarifications.

In some cases, authors may choose to use separate style sheets for Internet Explorer 3.0 and Internet Explorer 4.0. See the Customizing Style Sheets for Internet Explorer 3.0 and 4.0 section of this document for ideas on how to use separate style sheets for each browser. You can also find more examples and information in George Young's Cascading Style Sheets in Internet Explorer 4.0 article.

HTML vs. CSS inheritance

Reason for change: Spec compliance

Internet Explorer 4.0 now implements correct inheritance when style properties are mixed with HTML properties. In Internet Explorer 3.0, style properties always override any non-stylesheet rendering properties. Examples include the following:

In Internet Explorer 3.0, if text-decoration is set to none on the <HTML> tag, <A> tags would not be underlined. This behavior is not correct.. In Internet Explorer 4.0, underlining is removed only if text-decoration is set to none on all <A> tags, not the <HTML> tag.
Internet Explorer 3.0 would set margins on the <BODY> relative to the default <BODY> margins, or to the margins set with the TOPMARGIN and LEFTMARGIN attributes. Internet Explorer 4.0 correctly overrides HTML settings with CSS, so these attributes (as well as the default margin settings) are overridden with a CSS margin attribute on the <BODY>.

CSS inheritance in tables

In Internet Explorer 3.0, <TABLE>, <TR>, <TD> were treated like any other element, and CSS inheritance rules applied as they would to any other element. Internet Explorer 4.0 now treats CSS formatting for tables in the same manner as HTML formatting elements. Precedence for HTML formatting attributes dictates that table formatting does not inherit from previous content. Therefore, CSS attributes are not inherited by table elements either.

Note: The defaults for these formatting elements can be set by the <BODY>, and do not necessarily default to their initial values.

<HR> no longer inherits color property from the <BODY>

Reason for change: Spec compliance

In Internet Explorer 3.0, setting the color property for the <BODY> affected the color of an <HR>. Internet Explorer 4.0 does not pick up the color from the <BODY>.

Calculation of font-size as a percentage

Reason for change: Bug fix

In Internet Explorer 3.0, the font size was calculated as a percentage of the element's default/initial font size. Internet Explorer 4.0 calculates the font size as a percentage of the parent element's font size.

For example, if you set a font-size style for <H1> to 85%, the font will be 85% of normal <H1> font size in Internet Explorer 3.0, but it will be 85% of normal text font size in Internet Explorer 4.0.

There are a few ways you can resolve this incompatibility between Internet Explorer 3.0 and Internet Explorer 4.0:

You can use <DIV> with a class identifier instead of a heading tag, since both versions default to normal font size for <DIV>. However, you will lose the spacing that heading tags insert above and below. The spacing above can be added with margin-top, but margin-bottom is not supported in Internet Explorer 3.0.
You can use absolute font sizes (such as 30pt, 50px, etc.) or one of the following CSS1 keywords: xx-small, x-small, small, medium, large, x-large, or xx-large.

Use of quotes in font-family

When font-family is specified with a comma-delimited list, the list needs to be enclosed in quotes in Internet Explorer 3.0. If it's not enclosed in quotes, the style following the font-family (in this case, font-size) is not recognized.

Internet Explorer 4.0 parses font-family with or without the quotes. If your code needs to work in both Internet Explorer 3.0 and Internet Explorer 4.0, you can enclose the font-family list in quotes and both browsers will behave the same.

In the following code, font-size is ignored in Internet Explorer 3.0:

font-family: verdana, arial, serif;
font-size:65%

With the quotes, however, both Internet Explorer 3.0 and Internet Explorer 4.0 recognize font-size:

font-family: "verdana, arial, serif";
font-size:65%

Composite background property

Internet Explorer 4.0 follows the CSS specification with respect to the background property. The CSS specification explicitly states that all individual background properties not set by the composite background property should be set to their initial values (for example, in the case of background-image, that initial value is none). In other words, the line:

background: white

is identical to:

background: white none repeat scroll 0% 0%

In addition to setting the background color, both code lines will clear any previously set background-image, background-repeat, background-attachment, or background-position.

To set only a sub-property, use the individual background properties. For example, to set the background color to white while leaving the other background properties alone, use this line:

background-color: white

Extent of background color on block level elements

Reason for change: Spec compliance

When using the background-color attribute on block-level elements (<DIV>, <P>, <H1>, <H2>, <H3>, <H4>, <H5>, <H6>, and other blocks that force a line feed), Internet Explorer 3.0 fills color only around text, leaving areas to the right and on the last line without background color. Internet Explorer 4.0 fills the complete rectangle to the left and right margins of the parent element (unless the width is set for <DIV>).

Note: Because the <SPAN> element doesn't force a line feed, background color is displayed in the same way in both browser versions, filling only around the text. If you want Internet Explorer 3.0 to fill the whole box the way Internet Explorer 4.0 does, you can use a table.

In Internet Explorer 3.0, the background would not extend to the complete width of the element. In Internet Explorer 4.0, it does.

For example, in Internet Explorer 3.0, only the text contained in a <DIV> would have a background color. In Internet Explorer 4.0, the entire rectangle for the <DIV> gets the background setting.

Vertical margins between paragraphs

Reason for change: Spec compliance

Internet Explorer 4.0 correctly implements vertical-margin (top and bottom) collapsing, whereas Internet Explorer 3.0 inserted margins that couldn't be overridden between paragraph elements. Internet Explorer 4.0 collapses vertical margins together, per specifications, and vertical paragraph margins are overridden by any top- and bottom-margins on the paragraphs.

Internet Explorer 4.0 replaces margin values, whereas Internet Explorer 3.0 added the margin value to the default margin value.

Using margins with <BODY>

In Internet Explorer 3.0, margins are relative to the HTML <BODY> margin (either the default value or the value set using the TOPMARGIN and LEFTMARGIN attributes). In Internet Explorer 4.0, the margins are relative to the edges of the page.

Note: Internet Explorer 3.0 and 4.0 are almost compatible if you set the TOPMARGIN and LEFTMARGIN attributes to zero in the <BODY> tag. Note the use of the word "almost"; Internet Explorer 3.0 may not set the right margin exactly at zero in this case, and some content may extend too far to the right.

Using vertical margins with <P>, <H1>, <H2>, <H3>, <H4>, <H5>, <H6>

In Internet Explorer 3.0, margins on these elements were relative to HTML default margins for the element. In Internet Explorer 4.0, they are relative to margins of the parent element. In other words, zero now truly means zero. Many authors have used negative margin settings to tighten up spacing around <P> elements, headings, etc. in Internet Explorer 3.0. These negative margin settings will result in overlapping text in Internet Explorer 4.0.

Note: You can use <DIV> with a class identifier in your HTML document to resolve this incompatibility between Internet Explorer 3.0 and Internet Explorer 4.0, since both versions default to zero margins for <DIV>. Keep in mind, however, that Internet Explorer 3.0 does not support margin-bottom, so you will always want to use margin-top in the lower of two elements to set the vertical spacing between them.

Using left margins with <OL> and <UL>

Margins for list items are relative to the HTML default left margin in Internet Explorer 3.0. In Internet Explorer 4.0, they are relative to the left margin of the parent element. Again, negative left margins were commonly used to bring the list close to the margin in Internet Explorer 3.0, but in Internet Explorer 4.0 this will make part of the text go off the page.

Note: The result in Internet Explorer 4.0 depends on whether list-style-position is set to inside or outside. A setting of inside puts the list markers inside the margin, while a setting of outside puts the markers outside the margin, with the left edge of the text flush with the margin. Use the following settings if you want the markers flush with the left margin in Internet Explorer 4.0:

ol {margin-left: 0pt; list-style-position: inside}
ul {margin-left: 0pt; list-style-position: inside}

This will result in HTML default list margins in Internet Explorer 3.0, which isn't too much of a sacrifice.

Better CSS support for line-height

Reason for change: Spec compliance

The first draft of the CSS specification, which was current when Internet Explorer 3.0 shipped, said that line-height should be measured between baselines. The current version of the specification now dictates that line-height should be calculated as the "line-box" (which includes leading for ascenders and decenders) and that the balance of space is split between the top and bottom of the line. Internet Explorer 4.0 supports this change.

Comments in style sheets

Reason for change: Spec compliance

Internet Explorer 3.0 supported C++ style comments in style sheets. Internet Explorer 4.0 does not.

BODY and LINKed style sheets

Reason for change: Bug fix

Internet Explorer 3.0 didn't handle background images and <BODY> properties set through linked style sheets. Internet Explorer 4.0 does.

Error handling of missing linked style sheets

Reason for change: Better user experience

Internet Explorer 3.0 would report errors if a linked style sheet was missing or corrupt. Internet Explorer 4.0 will fail silently.

Multiple style sheets

Reason for change: Better CSS support

Internet Explorer 3.0 applied only one (the last) style sheet for a page. Internet Explorer 4.0 supports multiple style sheets per page -- including multiple linked and imported style sheets.

Customizing Style Sheets for Internet Explorer 3.0 and 4.0

You can use several techniques to tailor your page for Internet Explorer 3.0 and Internet Explorer 4.0 using cascading style sheets. This section describes some of these techniques:

Using multiple style sheets

To use this technique, note that Internet Explorer 3.0:

Supports only a single style sheet
Does not support the disabled attribute

Define multiple style sheets using the <STYLE> or <LINK> elements within a document. Add Internet Explorer 3.0-specific style information to the last style sheet defined in the document. Internet Explorer 3.0 uses the last style sheet it encounters. To prevent Internet Explorer 4.0 from using the style sheet, add the disabled attribute.

For example, given the following style sheet:

<STYLE TITLE=css_ie4>
   body   {font-weight:bold}
</STYLE>
<STYLE TITLE=css_ie3 DISABLED>
   body   {font-style:italic} 
</STYLE>

Internet Explorer 4.0 will set the content within the body of the document to bold, but Internet Explorer 3.0 will italicize that same content.

Use @import

Internet Explorer 3.0 does not support @import, so define Internet Explorer 4.0-specific styles in a separate file, and use @import to import them.

When Internet Explorer 4.0 loads a document containing the following HTML code, it will import and use the style sheet information included in the file "ie4specfic.css". Because the <LINK> element includes the disabled attribute, Internet Explorer 4.0 will not apply the styles. On the other hand, Internet Explorer 3.0 will use the styles defined in the file "ie3specific.css" because:

It is the last style sheet encountered
The disabled attribute is ignored.

<STYLE>
   @import url(ie4specific.css);
</STYLE>
<LINK disabled REL="stylesheet" HREF ="ie3specific.css">

In the following example, Internet Explorer 4.0 uses the styles contained within "ie4specific.css" as well as the styles defined directly within the <STYLE> tag. Internet Explorer 3.0 applies only the <H1> and <H2> styles.

<STYLE>
   @import url(ie4specific.css);
   h1  {color:green}
   h2  {font-style:italic}
</STYLE>

Using the Document Object Model to manipulate style sheets

Internet Explorer 4.0 exposes styles and style sheets through the Document Object Model. Styles and style sheets can be added, styles can be removed, and style sheets can be disabled using any installed scripting language. To use this technique,

Check for Internet Explorer 4.0 or greater at document load time.
Disable the first style sheet in the style sheets collection.
Add a new style sheet.

The following code can be associated with the onload event of the body.

<SCRIPT>
function HandleOnLoad()
{
   cUA = window.navigator.userAgent;
   if (parseInt(cUA.substring(cUA.indexOf("MSIE ")+5, 
      cUA.indexOf( ".", cUA.indexOf ( "MSIE " ) ))) >= 4)
   {
      document.styleSheets[0].disabled = true;
      document.createStyleSheet("ie4specific.css");
   }
}
</SCRIPT>

Use browser sniffing and disable Internet Explorer 3.0 style sheet in Internet Explorer 4.0

Another technique relies on browser sniffing. Like our previous examples, this technique also relies on the fact that Internet Explorer 3.0 supported only one style sheet per page, and the last style sheet in source order is the one that would be applied.

Set up your page so that the Internet Explorer 3.0-preferred style sheet is the last one defined, and check for the UA string. (For further information, check the Browser Detection section). Note that you can combine <LINK> and <STYLE> elements for this technique; a style sheet object for Internet Explorer 4.0 is an instance of either a <LINK>- or a <STYLE>-defined style sheet.

If the UA string indicates Internet Explorer 3.0, do nothing. The Internet Explorer 4.0-specific style sheet will never be applied.

If the UA string indicates Internet Explorer 4.0, use the style sheets collection on the document to disable the Internet Explorer 3.0 style sheet, and only the other style sheet(s) defined for the page will be applied:

document.styleSheets[1].disabled = true;

This one line of script disables the second style sheet so that it is not applied to the document.

Use browser sniffing and separate linked style sheets

Also using browser sniffing, you can use separate linked style sheets. Using your favorite browser-sniffing code, just link the appropriate style sheet as demonstrated in the following pseudo-code:

if we're on Internet Explorer 4.0 then
   document.writeln('<link rel="stylesheet" type="text/css" 
                      href="IE4.css">');
else if we're on Internet Explorer 3.0 then
   document.writeln('<link rel="stylesheet" type="text/css" 
                      href="IE3.css">');
else if we're on navigator then
   document.writeln('<link rel="stylesheet" type="text/css" 
                      href="NAV.css">');
else
   document.writeln('<link rel="stylesheet" type="text/css" 
                      href="other.css">');
endif

International Issues

One NCR represents one character

Reason for change: Bug fix

Under DBCS languages, such as Japanese, Chinese, and Korean, a pair of NCRs (Numeric Character References) are treated as one double-byte character in Internet Explorer 3.0. For instance,  is rendered as Chinese character U+4e9c (Unicode codepoint) in Internet Explorer 3.0 with charset=Shift_JIS. In Internet Explorer 4.0, the same pair is displayed as two high-ANSI characters.

Line spacing

Reason for change: Enhancement

For FE fonts where leading is not 0, Internet Explorer 4.0 increases the font height by 1/8 for better readability of ascenders and decenders.

Font linking

Reason for change: Enhancement

Font linking enables display characters that are not supported by the specified font.

<FONT FACE=Arial>some double byte characters here</FONT>.

For Internet Explorer 3.0, non ASCII characters enclosed by a <FONT> element are displayed in default glyphs (looks like garbage to the end user). For the same scenario, Internet Explorer 4.0 font linking picks up an appropriate font if Internet Explorer 4.0 can find one. Internet Explorer 4.0 uses the information you provide under View, Options, Fonts. You can use the multi-language support offered on the Internet Explorer 4.0 download site or shipped with Windows NT™ 4.0 to add fonts for languages that are not native to your system.

Express Unicode values directly.

Reason for change: Better compatibility with existing pages

Internet Explorer 3.0 interpreted NCRs (&#nnn) as bytes within the system's active code page. Internet Explorer 4.0 interprets the NCRs as Unicode code points. This breaks compatibility with pages authored for Internet Explorer 3.0 using NCRs and designed for character sets other than Latin1. (Internet Explorer 4.0 treats less than 256 as Latin1, and greater than 256 as Unicode.)

Carriage return is treated as white space

Reason for change: Enhancement

In Internet Explorer 3.0, carriage returns (white space) in the source of FE characters result in a single space regardless of the contents. Internet Explorer 4.0 collapses the space if the carriage return is between FE characters in source.

FORM posting

Reason for change: Bug fix

Internet Explorer 3.0 submits a <FORM> using the Windows character set of the local machine. Internet Explorer 4.0 submits form data using the character set that the <FORM> element is embedded in.

Miscellaneous Differences

Page caching

Reason for change: Better support for dynamic pages and existing content

Internet Explorer 3.0 kept the last four pages in memory as they were rendered. When the user hit the back arrow, Internet Explorer 3.0 pulled the page straight from the cache to the screen. This caused some subtle problems: For instance, the onload event was not fired and therefore initialization scripts were not rerun, and dynamically generated content (such as a script generating the local time) was not up-to-date. Furthermore, this mechanism used a lot of memory.

Internet Explorer 4.0 implements a history mechanism that stores the URL of a page (or the URL list of a frameset) and associates a "history stream" with the URL . When the user navigates away from a page, the document and the objects living in the document get a chance to save their state. Things that are saved as part of the history of the document include the document's vertical scroll position, form values, and information from controls that specifically implement the IPersistHistory interface.

Caching pages containing forms

Reason for change: Bug fix

Internet Explorer 3.0 doesn't always retrieve a page from the cache for a repeat visit to a page with a form. Internet Explorer 4.0 now always pulls from the cache if using HTTP (although it won't pull from cache for HTTPs).

For a consistent experience, between the two browsers, put the following in the <META> tag in the <HEAD> of the document:

Use system's window color for background

Reason for change: Consistency with other Microsoft applications

If a document does not have its own BGCOLOR specified, Internet Explorer 4.0 now sets the background color to be the system's window color (the color used in the client area of a window), whereas Internet Explorer 3.0 set the window background to the system's default button-face color.

Form submission with a GET method

Reason for change: Better compatibility with existing content

<FORM METHOD=get ACTION="http://www.Microsoft.com?value1=boo">

For the above HTML, Internet Explorer 3.0 would submit the name/value pair "value1=boo" to the server. Internet Explorer 4.0 ignores the part of the action after the "?" and forms the submit string based on the contents of the form.

Conclusion

Now that Internet Explorer 4.0 is released, there will be an inevitable transition period during which Web pages will be accessed by both Internet Explorer 3.0 and Internet Explorer 4.0. While the overwhelming majority of Internet Explorer 3.0 features are upwardly compatible with Internet Explorer 4.0, as with all product upgrades there is a small set of changes implemented as a result of enhancements, bug fixes, and compliance with newly emerging standards. By using this article as a guideline and by testing under both Internet Explorer 3.0 and Internet Explorer 4.0, you can ensure that your Web site will be correctly displayed when viewed using either version of Internet Explorer.

Sue Ledoux is a writer for the MSDN Online Web site.

Anita Rowland is a member of the Internet Explorer 4.0 program management team. She also creates and maintains the Seattle Cacophony Society Web site (http://www.halcyon.com/anitar/cacoph.html ).