Javascript Differences in Mozilla Firefox and Internet Explorer

document.all

Internet Explorer 4 introduced the document.all DOM (document object model) to allow access to the various parts of the web page. Soon after that the standard DOM method getElementById was introduced and is therefore available in all version 5+ browsers. This means that the document.all references are only needed to support IE4.

document.all doesn’t work  mozilla why?

Some proprietary document objects such as document.all anddocument.layers are not part of the W3C DOM and are not supported in Mozilla. (There is partial undetectable support for document.all, though, in newer versions of Mozilla. However, that functionality only exists for compatibility with sites authored specifically for IE. You should not rely on Mozilla’s document.all support on new pages.) The methoddocument.getElementById() can be used instead.

In the Standards mode Mozilla does not generate implicit top-level JavaScript variable bindings for elements with the id or name attribute. The correct way to access an element by id is to call the document.getElementById() method with the id as a string as the argument.

Also, old client sniffers can shut out new browsers. The point of having a common API (the W3C DOM) is interoperability, and checking for a particular browser defeats that purpose. When working with the DOM, it is better to check for the existence of the methods and objects you are planning on using. For example, the existence of document.getElementById() can be checked as follows:

if(document.getElementById) {
  /* code that uses document.getElementById() */
}

1. Window/Body OnLoad

When dealing with a site that uses Master Pages, you lose some control, including the ability to declare a page specific event handler. There are ways around this, and I found that the following code example works pretty well.

<script language=”javascript” type=”text/javascript” for=”window” event=”onload“>
    if (document.all)
    {
        initialize();
    }
   else    {
        window.document.addEventListener(“DOMContentLoaded”, initialize, true);
    }
</script>

2. Get Control Inner Text

Retrieving the text of an element is done by using element.innerText in Internet Explorer and element.textContent in Mozilla Firefox.

function getText(control)
{
if (document.all)
    {
return control.innerText;
    }
else
    {
return control.textContent;
    }
}

function setText(control, value)
{
if (document.all)
    {
        control.innerText = value;
    }
else    {
        control.textContent = value;
    }
}

3. Element Height and Width

To retrieve an element’s height and width, use element.currentStyle forInternet Explorer and element.style for Mozilla Firefox.

if (document.all)
{
    top += parseValue(element.currentStyle.borderTopWidth);
    …
}
else{
    top += parseValue(element.style.borderTopWidth);
    …
}

4. Source Elements

To get a reference to the element that fired an event within an event handler, use event.srcElement for Internet Explorer and event.target for Mozilla Firefox.

function getSourceElement(event)
{
if (document.all)
    {
return event.srcElement;
    }
else    {
return event.target;
    }
}

5. Firing Events

You can call fireEvent on an element in Internet Explorer, but it’s more complicated in Mozilla Firefox, requiring an event to be instantiated, initialized, and dispatched.

function fireClickEvent(control)
{
if (document.all)
    {
        control.fireEvent(“onclick”);
    }
else    {
var clickEvent = window.document.createEvent(“MouseEvent“);
        clickEvent.initEvent(“click“, false, true);
        control.dispatchEvent(clickEvent);
    }
}

6. Window Height and Width

Internet Explorer exposes the visible content area dimensions usingdocument.body.offsetHeight and document.body.offsetWidth, whereasMozilla Firefox uses document.body.offsetWidth and window.innerWidth.

function getWindowHeight()
{
if (document.all)
    {
return document.body.offsetHeight;
    }
else
    {
return window.innerHeight;
    }
}

function getWindowWidth()
{
if (document.all)
    {
return document.body.offsetWidth;
    }
else
    {
return window.innerWidth;
    }
}

7. Why doesn’t Mozilla display my alt tooltips?

Contrary to a popular belief stemming from the behavior of a couple browsers running on the Windows platform, alt isn’t an abbreviation for ‘tooltip’ but for ‘alternative’. The value of the alt attribute is a textual replacement for the image and is displayed when the image isn’t.

Mozilla doesn’t display the alt attribute as a tooltip, because it has been observed that doing so encourages authors to misuse the attribute.

• * When the alternative text is shown in a tooltip, some authors write badalt texts, because they intend the text as auxiliary tooltip text and not as a replacement for the image. (‘Bad’ in the sense that the textual alternative is less useful for people who don’t see the image.)
• * When the alternative text is shown in a tooltip, other authors don’t want to supply textual alternatives at all, because they don’t want tooltips to appear. (Again, making things harder for people who don’t see the image.)

There is another attribute that Mozilla shows as a tooltip: title. In fact, the HTML 4.01 specification suggests that the title attribute may be displayed as a tooltip. However, this particular display method is not required and some other browsers show the title attribute in the browser status bar, for example.

At this point some people feel compelled to post a “But IE…” rant in the newsgroups or in Bugzilla. Please note that Mac IE 5 behaves in the same way as Mozilla when it comes to the alt and title attributes. Windows IE also shows the title attribute in a tooltip.

8. Does Mozilla support downloadable fonts?

Downloadable fonts are not supported.

Downloadable fonts are usually used on sites using writing systems for which proper support has been missing in browsers in the past. These sites (for example some Indian sites) code the text in Latin gibberish and then use a font that to the browser and operating system seems to be a Latin font but has eg. Devanagari glyphs, so that when the Latin gibberish is rendered with the font it seems to a human reader to be intelligible text in some language.

Obviously, that kind of ad hockery falls apart when Unicode-savvy browsers come along and render Latin gibberish as Latin gibberish (since that’s what is coded in the file from the Unicode point of view). Instead of providing support for downloadable fonts, Mozilla is addressing the real issue: support for various Unicode ranges.

However, there are still bugs related to support for Indic scripts on some platforms. For example, on Mac OS X Mozilla does not use the Devanagari font that comes with the system but can use a third-party font like TITUS Cyberbit.

A lot of work has been put into Mozilla’s Unicode support. Supporting downloadable fonts in a cross-platform way would also be a lot of work and would potentially require navigating past a bunch of patents but the rewards would be small. For the purpose of rendering non-ISO-8859-1 characters Mozilla already provides Unicode support that, in the long run, is a lot better approach than using pseudo-Latin downloadable fonts separately on each site.

9. In Mozilla Firefox my style sheet doesn’t work! Why?

Here’s the check list:

• 1. Does the HTML document validate? Styling misnested markup may cause strange effects.
  • * The <link> and <style> elements should be inside the <head>element.
• 2. Does the CSS style sheet pass the syntax check? The CSS error handling rules require erroneous parts to be ignored rather than fixed by guessing.
  • * Lengths other than zero should be followed by a proper unit without a space between the number and the unit (eg. 1.2em).
  • * The character to use between the property name and the value is the colon—not the equal sign.
  • * HTML markup, such as <style>, does not belong in .css files.
  • * font-face is not a real CSS property. The property is font-family and @font-face is an at-rule.
  • * If @import is used, it should be the first thing in a CSS file.
  • * In Mozilla 1.8a4 and later (not in Firefox 1.0) CSS parsing errors are reported to the JavaScript console.
• 3. Is the server sending the proper Content-Type header for CSS style sheets?
  • * The correct type is text/css.
  • * In the Standards mode and the Almost Standards mode only style sheets with the correct type are applied.
  • * You can see the HTTP headers sent by the server by using theLiveHTTPHeaders extension or by using the Web sniffer.
• 4. Class names and ids are case-sensitive.
• 5. The element selectors are case-sensitive with XML.
• 6. Style sheet processing instructions are only allowed in the prolog of XML documents. Also, they only work in XML documents—not in documents served as text/html.
• 7. width and height do not apply to non-replaced inline elements such as (by default) <span>.
• 8. text-align: center; centers inline content within a block. It does not (and should not) center the block box itself. A block is centered by setting its margin-left and margin-right to auto and its width to a value that makes the block narrower than its containing block.

It is also possible, although not very likely, that you are seeing a bug.