Migrating from Internet Explorer 3.0 to Internet Explorer 4.0 and Later

ARCHIVED CONTENT: Compatibility is a key priority for Microsoft Internet Explorer 4.0 and later. As much as possible, we want to ensure that users who upgrade from Internet Explorer 3.0 will not be affected adversely. Goals for compatibility are:

  • Compliance with existing World Wide Web Consortium (W3C) standards—Cascading Style Sheets (CSS), Level 1 (CSS1), HTML 4.0, and so on.
  • Accurate rendering of content on the Web. Web site authors expect Internet Explorer 4.0 and later to render their pages as they designed them.

Users should experience the behavior they expect, and Windows Internet Explorer achieves this within the boundaries of the aforementioned goals. The combination of these factors and some bug fixes causes Internet Explorer 4.0 and later to render some pages differently from Internet Explorer 3.0. While we have kept these differences to a minimum, some issues are unavoidable.

The following sections outline the most salient differences that authors will encounter.

  • General Authoring Issues 
  • CSS Compatibility with Internet Explorer 3.0 
  • Using Different Style Sheets 
    • Using Multiple Style Sheets 
    • Using @import 
    • Using the Document Object Model to Manipulate Style Sheets 
  • International Issues 

General Authoring Issues

Summary or Symptom in Internet Explorer 4.0 and later Description Reason
frameSet inside a BODY is ignored frameSet and BODY are mutually exclusive tags for Internet Explorer 4.0 and later. Use one or the other. If you use both, the second one will be ignored.

If you are using the BODY element to set attributes for the contents of the frameSet, move these attributes to the frameSet.

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.

Compliance with HTML 4.0 Document Type Definition (DTD)
Improved table width algorithm Internet Explorer 4.0 and later calculates the width of a table more accurately than Internet Explorer 3.0 and consequently matches the way many Web sites were designed. For example, if the combined widths of the cells in a table exceed the width set for the table, Internet Explorer 4.0 and later uses the cumulative width of the cells to override the width set for table. Internet Explorer 3.0 would have adjusted the widths of the cells to fit the width of the table.

tFoot, tBody, tHead were rendered in source order for Internet Explorer 3.0. According to W3C specifications, the order of these table elements should not matter. Internet Explorer 4.0 and later matches the spec. For example, if a tFoot appears first in source order, Internet Explorer 4.0 and later will still render the contents of the tFoot at the end of the table.

Better compatibility with real-world pages.
Case sensitivity Microsoft JScript is case sensitive in Internet Explorer 4.0 and later. Some real-world pages rely on capitalization to result in different variables being defined. Case insensitivity was breaking those scripts.

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

JScript compatibility.

Microsoft applications read and generate case-sensitive HTML entities.

Use system's window color If a document does not have its own BGCOLOR specified, Internet Explorer 4.0 and later sets the background color based on the system's window color, whereas Internet Explorer 3.0 set the window background to the system's default button-face color. Consistency with other Microsoft applications.
mouse* events renamed mouse* events are nonstandard. They are now onmouse*. JScript compatibility.
Unknown attributes are exposed as implicitly declared variables ("expando feature") 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. This is also known as the "expando" feature. Enhancement—better compatibility with real-world pages.
Accessing X-object properties for Microsoft ActiveX Controls X-object properties are properties that are exposed by the Internet Explorer 4.0 container on all objects in Internet Explorer 4.0 and later. 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. Enhancement
Page cache (1) Internet Explorer 3.0 kept the last four pages in memory as they were rendered. When the user clicked the Back button, Internet Explorer 3.0 pulled the page straight from cache to the screen. This caused some subtle problems. For instance, scripts were not rerun (for example, the onload event was not fired), dynamically generated content was not up to date (such as a script generating the local time), and this mechanism used a lot of memory.

Internet Explorer 4.0 and later implements a history mechanism, which 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, which specifically implement the IPersistHistory interface. Controls that want to persist their state must support IPersistHistory.

Better support for dynamic pages and existing content
Page caching (2) Internet Explorer 3.0—doesn't always pull from the cache for a repeat visit to a page with a form.

Internet Explorer 4.0 —always pulls from the cache if HTTP (won't pull from cache for HTTPs).

Solution:

Put the following META tag in the HEAD of the document:

<META HTTP-EQUIV="expires" CONTENT="0">
Bug fix
Form submission with a GET method
<FORM METHOD="get" ACTION="https://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 and later ignores the part of the action after the "?" and forms the submit string based on the contents of the form.

Better compatibility with existing content.

CSS Compatibility with Internet Explorer 3.0

Internet Explorer 3.0 introduced CSS to the Web with the first implementation of a working draft from the W3C. Since this time, the W3CCSS working group has published a CSS recommendation. The Internet Explorer 4.0 and later implementation of style sheets is based on the final CSS recommendation. What this means for 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 might affect authors who have authored pages using CSS in Internet Explorer 3.0. In some cases, we've fixed bugs, and in other cases there have been specification changes or clarifications.

Authors might choose to use separate style sheets for Internet Explorer 3.0 and Internet Explorer 4.0 and later. See the section following the table for ideas on how to use separate style sheets for each browser.

Summary or Symptom in Internet Explorer 4.0 and later Description Reason
Multiple stylesheets Internet Explorer 3.0 applied only one (the last) style sheet for a page. Internet Explorer 4.0 and later supports multiple style sheets per page—including multiple linked and imported style sheets. Better CSS support
HTML versus CSS inheritance Correct inheritance when style properties are mixed with HTML properties. In Internet Explorer 3.0, style properties always override any non-style-sheet rendering properties. For example, if text-decoration is set to none on the HTML tag, A tags would not be underlined (this is incorrect). In Internet Explorer 4.0 and later, underlining is removed only if is set to none on all A tags, not the HTML tag.

Another example: Internet Explorer 3.0 would set margins on the BODY relative to the default BODY margins or the margins set with the TOPMARGIN and LEFTMARGIN attributes. Internet Explorer 4.0 and later correctly overrides HTML settings with CSS, so these attributes (as well as the default margin settings) are overridden with a CSS margin set for the BODY.

Spec Compliance
Better CSS support—margins Internet Explorer 4.0 and later correctly implements vertical margin (top and bottom) collapsing; inserted non-overridable margins between paragraph elements. Internet Explorer 4.0 and later collapses vertical margins together, as per specifications, and vertical paragraph margins are overridden by any TOPMARGIN and BOTTOMMARGIN attributes set on the paragraphs.

Internet Explorer 4.0 and later replaces margin values, where Internet Explorer 3.0 would add the margin value to the default margin value.

Spec Compliance
Better CSS support—line height An earlier working draft of the CSS specification said that line height should be measured between baselines. The CSS Recommendation states that line height is calculated as the "line-box" (includes leading for ascenders and descenders) and that the balance of space is split between the top and bottom of the line. Spec Compliance
CSS inheritance in tables IE3.0—table, TR, TD were treated as any other element, and CSS inheritance rules applied as they would to any other element.

Internet Explorer 4.0 and later—treats CSS formatting for tables the same as HTML formatting elements. Precedence forHTML formatting attributes dictate 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.
 
BODY and linked style sheets Internet Explorer 3.0 didn't handle background images and body properties set through linked style sheets. Internet Explorer 4.0 and later does. Bug fix
Comments Internet Explorer 3.0 supported C++ style comments; Internet Explorer 4.0 and later does not Spec compliance
HR inherits color property from the BODY Setting the color property for the BODY would affect the color of an HR. Internet Explorer 4.0 and later does not pick up the color from the BODY. Spec Compliance
Background on block level elements In Internet Explorer 3.0, the background would not extend to the complete width of the element. In Internet Explorer 4.0 and later, 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 and later, the entire rectangle for the DIV gets the background setting.

Spec compliance
Font-size calculation Internet Explorer 3.0—the font size is calculated as a percent of the element's default/initial font size.

Internet Explorer 4.0 and later—the font size is calculated as a percent of the parent element's font size.

If you set a font-size style for H1 to 85%, for example, the font will be slightly smaller than a normal H1 in Internet Explorer 3.0, but it will be smaller than normal text in Internet Explorer 4.0 and later.

Bug fix
Error handling Internet Explorer 3.0 would throw errors for missing/badly linked style sheets; Internet Explorer 4.0 and later will fail silently. Better user experience

Using Different Style Sheets

Several techniques can be used to tailor your page for use in Internet Explorer 3.0 and Internet Explorer 4.0 and later using CSS.

This section describes three of them:

  • Using Multiple Style Sheets 
  • Using @import 
  • Using the Document Object Model to Manipulate Style Sheets 

Using Multiple Style Sheets

To use this technique, observe these facts about Internet Explorer 3.0:

  • Only a single style sheet is supported.
  • The disabled attribute is not supported.

Define multiple style sheets using the STYLE or link element 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 and later from using it, 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 and later will set the content within the BODY of the document to bold, but Internet Explorer 3.0 will italicize that same content.

Using @import

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

When Internet Explorer 4.0 and later loads a document containing the following HTML code, it will import and use the style sheet information in ie4specfic.css. Because the link element includes the disabled attribute, Internet Explorer 4.0 and later will not apply the styles. On the other hand, Internet Explorer 3.0 will use the styles defined in 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 and later uses the styles contained within ie4specific.css as well as the styles defined directly within the style tag. Internet Explorer 3.0 only applies 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 and later exposes styles and style sheets through the Dynamic HTML (DHTML) 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,

  1. Check for Internet Explorer 4.0 or later at document load time.
  2. Disable the first style sheet in the styleSheets collection.
  3. 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>

International Issues

Summary or Symptom in Internet Explorer 4.0 and later Description Reason
One NCR represents one character Under DBCS language, 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, &#136;&#159; is rendered as Chinese character U+4e9c (Unicode codepoint) in Internet Explorer 3.0 with charset=Shift_JIS. In Internet Explorer 4.0 and later the same pair is displayed as two high-ANSI characters. Bug Fix
Line spacing For FE fonts where leading is not 0, Internet Explorer 4.0 and later increases the font height by 1/8 for better readability of ascenders and descenders. Enhancement
Font linking 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 and later font linking picks up an appropriate font if Internet Explorer 4.0 and later can find one. Internet Explorer 4.0 and later uses the information you provide under View.Options.Fonts. You can use the Multilingual support offered on the Internet Explorer 4.0 and later download site or shipped with Microsoft Windows NT 4.0 to add fonts for languages that are not native to your system.

Enhancement
Express Unicode values directly Internet Explorer 3.0 interpreted NCRs (&#nnn) as bytes within the system's active code page. Internet Explorer 4.0 and later 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 and later treats less than 256 as Latin1 and greater than 256 as Unicode.) Better compatibility with existing pages
Carriage return is treated as white space In Internet Explorer 3.0, carriage returns (white space) in the source of FE characters result in one single space regardless of the contents. Internet Explorer 4.0 and later collapses the space if the carriage return is between FE characters in source. Enhancement
Form posting Internet Explorer 3.0 submits a FORM using the window's character set of the local machine. Internet Explorer 4.0 and later submits form data using the character set that the FORM element is embedded in. Bug Fix