Authoring Notes for Migrating from Internet Explorer 3.0 to Internet Explorer 4.0


		Contents Index Topic Contents

Authoring Notes for Migrating from Internet Explorer 3.0 to Internet Explorer 4.0

Compatibility is a key priority for Microsoft® Internet Explorer 4.0. 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 W3C standards—CSS1, HTML 4, and so on.
Accurate rendering of content on the Web. Web site authors expect Internet Explorer 4.0 to render their pages as they designed them.

Users should experience the behavior they expect, and 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 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
International Issues

General Authoring Issues

Summary or Symptom in IE4 Description Reason

FRAMESET inside a BODY is ignored. FRAMESET and BODY are mutually exclusive tags for IE4. Either 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 DTD

Improved table width algorithm. IE4 calculates the width of a table more accurately than IE3, 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, IE4 uses the cumulative width of the cells to override the width set for TABLE. IE3 would have adjusted the widths of the cells to fit the width of the TABLE.
TFOOT, TBODY, THEAD were rendered in source order for IE3. According to W3C specifications, the order of these table elements should not matter. IE4 matches the spec. For example, if a TFOOT appears first in source order, IE4 will still render the contents of the TFOOT at the end of the table.
Better compatibility with real-world pages.

Case sensitivity Javascript is case sensitive in IE4. 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 IE3, except where case-sensitivity was meaningful. For example, &nbsp works for both, but &NBSP will only work on IE3.
Javascript 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, IE4 sets the background color based on the system's Windows color, where as IE3 set the window background to the system's default button-face color. Consistency with other Microsoft applications.

mouse* events renamed mouse* events are non-standard. They are now onmouse*. JavaScript 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. Also known as the "expando" feature. Enhancement - better compatibility with real world pages.

Accessing X-object properties for ActiveX controls X-object properties are properties which are exposed by the IE4 container on all objects in IE4. If an object has a property or method which conflicts with an X-object property/method, then the object's property/method should be accessed explicitly as item.object.property, instead of item.property. Enhancement

Page cache (1) IE3 kept the last 4 pages in memory as they were rendered. When the user hit the back arrow, IE3 pulled the page straight from cache to the screen. This caused some subtle problems. For instance, Scripts were not re-run (for instance, the onload event was not fired), dynamically generated content was not up-to-date (like a script generating the local time), and this mechanism used a lot of memory.
IE4 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 which want to persist their state must support IPersistHistory.
Better support for dynamic pages and existing content

Page caching (2) IE30 - doesn't always pull from the cache for a repeat visit to a page with a form.
IE40 - always pulls from the cache if HTTP (won't pull from cache for HTTPs).
Solution:
Put the following in the 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="http://www.Microsoft.com?value1=boo">
For the above HTML, IE3 would submit the name/value pair "value1=boo" to the server. IE4 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 cascading style sheets (CSS) to the Web with the first implementation of a working draft from the World Wide Web Consortium (W3C). Since this time, the W3C style sheets working group has published a CSS recommendation. The Internet Explorer 4.0 implementation of CSS 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. See the section following the table for ideas on how to use separate style sheets for each browser.

Summary or Symptom in IE4 Description Reason

Multiple stylesheets IE3 applied only one (the last) styleSheets for a page. IE4 supports multiple stylesheets per page - including multiple linked and imported stylesheets. Better CSS support

HTML vs. CSS inheritance Correct inheritance when style properties are mixed with HTML properties. In IE3, style properties always override any non-styleSheets 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 IE4, underlining is removed only if text-decoration is set to "none" on all <A> tags, not the <HTML> tag.
Another example: IE3 would set margins on the BODY relative to the default BODY margins or the margins set with the TOPMARGIN and LEFTMARGIN attributes. IE4 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 IE4 correctly implements vertical margin (top and bottom) collapsing; inserted non-overridable margins between paragraph elements. IE4 collapses vertical margins together, as per specifications, and vertical paragraph margins are overridden by any top- and bottom-margins on the paragraphs.
IE4 replaces margin values, where IE3 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 decenders) 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.
IE4.0 - treats CSS formatting for tables the same as HTML formatting elements. Precedence for HTML 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 stylesheets IE3 didn't handle background images and body properties set through linked stylesheets. IE4 does. Bug fix

Comments IE3 supported C++ style comments - IE4 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. IE4 does not pick up the color from the BODY. Spec Compliance

background on block level elements In IE3, the background would not extend to the complete width of the element. In IE4 it does.
For example, in IE3, only the text contained in a DIV would have a background color. In IE4 the entire rectangle for the DIV gets the background setting.
Spec compliance

font-size calculation IE3 - the font size is calculated as a percent of the elements default/initial font size
IE4 - 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 IE3, but it will be smaller than normal text in IE4.
Bug fix

Error handling IE3 would throw errors for missing/bad linked stylesheets - IE4 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 using cascading style sheets. This section describes two of them:
use multiple style sheets, and place Internet Explorer 4.0 specific styles in the primary style sheet, or
use @import to import Internet Explorer 4.0 specific styles
use the Document Object Model to manipulate the style sheets if Internet Explorer 4.0 is in use

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 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 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 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 in "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 "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 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 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 styleSheets 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>
International Issues
Summary or Symptom in IE4 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 IE3. For instance,  is rendered as Chinese character U+4e9c (Unicode codepoint) in IE3 with charset=Shift_JIS. In IE4 the same pair is displayed as two high-ANSI characters in IE4. Bug Fix

Line spacing For FE fonts where leading is not 0, IE4 increases the font height by 1/8 for better readability of ascenders and decenders. 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 IE3, non ASCII characters enclosed by a FONT element are displayed in default glyphs (looks like garbage to the end user). For the same scenario, IE4 fontlinking picks up an appropriate font if IE4 can find one. IE4 uses the information you provide under View.Options.Fonts. You can use the Multilanguage support offered on the IE4 download site or shipped with NT4 to add fonts for languages that are not native to your system.
Enhancement
Express Unicode values directly. IE3 interpreted NCRs (&#nnn) as bytes within the system's active code page. IE4 interprets the NCRs as Unicode code points. This breaks compatibility with pages authored for IE3 using NCRs and designed for character sets other than Latin1. (IE4 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 IE3, carriage returns (White space) in the source of FE characters result in one single space regardless of the contents. IE4 collapses the space if the carriage return is between FE characters in source. Enhancement

FORM posting IE3 submits a <FORM> using the Window's character set of the local machine. IE4 submits form data using the character set that the <FORM> element is embedded in. Bug Fix
Top of Page
© 1997 Microsoft Corporation. All rights reserved. Terms of Use.

Summary or Symptom in IE4	Description	Reason
FRAMESET inside a BODY is ignored.	FRAMESET and BODY are mutually exclusive tags for IE4. Either 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 DTD
Improved table width algorithm.	IE4 calculates the width of a table more accurately than IE3, 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, IE4 uses the cumulative width of the cells to override the width set for TABLE. IE3 would have adjusted the widths of the cells to fit the width of the TABLE. TFOOT, TBODY, THEAD were rendered in source order for IE3. According to W3C specifications, the order of these table elements should not matter. IE4 matches the spec. For example, if a TFOOT appears first in source order, IE4 will still render the contents of the TFOOT at the end of the table.	Better compatibility with real-world pages.
Case sensitivity	Javascript is case sensitive in IE4. 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 IE3, except where case-sensitivity was meaningful. For example, &nbsp works for both, but &NBSP will only work on IE3.	Javascript 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, IE4 sets the background color based on the system's Windows color, where as IE3 set the window background to the system's default button-face color.	Consistency with other Microsoft applications.
mouse* events renamed	mouse* events are non-standard. They are now onmouse*.	JavaScript 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. Also known as the "expando" feature.	Enhancement - better compatibility with real world pages.
Accessing X-object properties for ActiveX controls	X-object properties are properties which are exposed by the IE4 container on all objects in IE4. If an object has a property or method which conflicts with an X-object property/method, then the object's property/method should be accessed explicitly as item.object.property, instead of item.property.	Enhancement
Page cache (1)	IE3 kept the last 4 pages in memory as they were rendered. When the user hit the back arrow, IE3 pulled the page straight from cache to the screen. This caused some subtle problems. For instance, Scripts were not re-run (for instance, the onload event was not fired), dynamically generated content was not up-to-date (like a script generating the local time), and this mechanism used a lot of memory. IE4 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 which want to persist their state must support IPersistHistory.	Better support for dynamic pages and existing content
Page caching (2)	IE30 - doesn't always pull from the cache for a repeat visit to a page with a form. IE40 - always pulls from the cache if HTTP (won't pull from cache for HTTPs). Solution: Put the following in the 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="http://www.Microsoft.com?value1=boo"> For the above HTML, IE3 would submit the name/value pair "value1=boo" to the server. IE4 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.