Mozilla Web Developer FAQ

This document answers questions that Web authors ask frequently specifically in connection with Firefox and other Gecko-based browsers. There are links to more general Web authoring FAQs at the end of this document.

What are the Quirks mode and the Standards mode?

Gecko has two and a half layout modes: Quirks, Almost Standards and Standards. In the Standards mode Gecko aims to treat documents authored in compliance with the applicable Web format specifications. In the Quirks mode—for the purpose of backwards compatibility—Gecko mimics some behaviors of legacy browsers in ways that are spec violations. The Almost Standards mode is like the Standards mode except it addresses the issue of the next question by rendering table cells with images in the traditional way. The mode is picked based on the doctype declaration (or the lack thereof) at the beginning of an HTML document.

The easiest way to make sure that the Standards mode is activated for HTML, is to use this doctype declaration:
<!DOCTYPE html>
The easiest way to make sure that the Almost Standards mode is activated for HTML, is to use this doctype declaration:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "https://www.w3.org/TR/html4/loose.dtd">

The easiest way to activate the Quirks mode for HTML is to omit the doctype declaration. However, authoring new documents that rely on quirks is discouraged.

The Almost Standards mode was introduced in Mozilla 1.1 beta and Mozilla 1.0.1. In earlier versions the doctype declarations that now activate the Almost Standards mode activated the Standards mode.

Doctype sniffing only applies to documents served as text/html. Documents sent as XML always activate the Standards layout mode. This includes documents sent as application/xhtml+xml. The consequence is that XHTML 1.0 Transitional documents are rendered in the Almost Standards mode when served as text/html under pretext of the Appendix C but in the Standards Mode when served as application/xhtml+xml.

Since also other contemporary browsers have a standards mode, activating the Standards mode or the Almost Standards mode in other browsers as well (using the above-mentioned exact doctypes) is the best way to get consistent CSS layout results across different browsers. On the other hand, the quirks implemented in the quirks modes of different browsers vary from browser to browser.

Why are there gaps between image rows in tables when the layout engine is in the Standards mode?

In the CSS2 box layout model the default vertical sizing of layout boxes and the default vertical alignment of images is different from the behavior of old browsers. These aspects of the layout can be changed by explicitly setting the display CSS property of the images (and possible surrounding <a> elements) to block.

If the table cells that contain only an image are marked with <td class="imgcell">, the required CSS rule is: .imgcell img, .imgcell a { display: block; }

Longer explanation…

Why are there still gaps even between text rows in tables when the layout engine is in the Standards mode or in the Almost Standards mode?

In the Standards mode and in the Almost Standards mode Mozilla does not suppress the default margins of the first and last child element in table cells. Therefore, the default margins for paragraphs apply even with markup such as <td><p>foo</p></td>.

Often the content of a cell in a table of tabular data does not constitute a paragraph. In that case, the easy solution is not to mark the contents of the cell as a paragraph.

When the paragraph markup is called for but the default margins are unwanted, zero margins can be suggested using CSS.

My style sheet doesn’t work! Why?

Here’s the check list:

Does the HTML document validate? Styling misnested markup may cause strange effects.
- The <link> and <style> elements should be inside the <head> element.
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.
- CSS parsing errors are reported to the JavaScript console.
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 the LiveHTTPHeaders extension or by using the Web sniffer.
Class names and ids are case-sensitive.
The element selectors are case-sensitive with XML.
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.
width and height do not apply to non-replaced inline elements such as (by default) <span>.
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.

JavaScript doesn’t work! Why?

Some proprietary document objects such as document.all and document.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 method document.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() */
}

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 bad alt 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.

Does Mozilla support downloadable fonts?

Downloadable fonts in TrueType and OpenType formats (.ttf and .otf) are supported since Firefox 3.5. The fonts have to be served from the same origin (protocol, host, port) as the content that uses them unless the fonts are served with the appropriate Cross-Origin Resource Sharing HTTP headers.

Downloadable fonts in the EOT format are not supported.

If you use downloadable fonts, please make sure the fonts have the right Unicode mappings and the content uses the right Unicode characters. The past practice of displaying non-Latin text by assigning non-Latin glyphs to Latin code points breaks copying and pasting, breaks searching on the page, breaks indexing by search engines and breaks readability in browsers that do not support downloadable fonts (e.g. legacy browsers or mobile browsers that opt not to download fonts due to file size).

Why aren’t symbol/dingbat fonts working?

They are working. Characters in HTML 4 and XML documents are Unicode characters (even if the document has been encoded using a legacy encoding for transfer)—not font glyph indexes.

<font face="Symbol">a</font> means the character LATIN SMALL LETTER A (U+0061) preferably displayed using the Symbol font. Since the Symbol font does not have glyph for that character, another font is used. If you mean α, you should use GREEK SMALL LETTER ALPHA (U+03B1). If you are using a legacy encoding that cannot represent that character, you can use a numeric character reference: α.

Likewise, to use a dingbat, you should use the appropriate Unicode character instead of trying to apply a dingbat font to an ASCII character. For example, to represent ☺, you should use WHITE SMILING FACE (U+263A).

Why isn’t Mozilla rendering my page as I intended? So my page isn’t standards-compliant, but good browsers should render pages as the author intended anyway!

Authors are supposed to communicate their intentions using the Web standards. Otherwise, finding out the intentions of each particular author would require psychic abilities which can’t be implemented in software. Even in cases where a human could deduce the intention, doing so in software would be very slow, bug-inducing, difficult and complicated.

The usual counter argument is that there is no need to guess—Mozilla should do whatever browser x does (where x is the favorite non-Mozilla browser of whoever is presenting the counter argument). However, doing whatever browser x does in every conceivable case isn’t simple at all, even though it might appear to be simple when presented as a passing remark.

Different people have different ideas about what x should be. The second problem is that Web authors are very creative in coming up with different ways of deviating from the standards. In fact, since the input to the browser can be of arbitrary length, there is no upper bound for the number of distinct ways of deviating from the standards. Therefore, it is impossible to test whether Mozilla reacts exactly like browser x to every possible input. (Likewise, there is no upper bound for the number of ways different features of the standards themselves can be combined, which makes software quality assurance challenging.)

Also, the ways in which browser x reacts to some standards-incompliant input are not all intentional. Some of the reactions are due to unknown and unintentional interactions within a complex program. Even if you had the source code for browser x, you couldn’t change anything without risking changing one or more of the unknown and unintentional interactions within the program.

The usual counter argument is that Mozilla doesn’t need to match the behavior of browser x in every possible case but only in the alleged common cases. However, it turns out Mozilla is doing that already. Mozilla’s Standards mode is, obviously, already compatible with other browsers that implement the same standards reasonably correctly. On the other hand, Mozilla’s quirks mode already accommodates common non-standardisms that are due to the behaviors of common legacy browsers.

Instead of putting time and effort into reverse-engineering and cloning legacy browsers, it makes more sense to focus on implementing standards. Standards (when implemented by others as well) promote interoperability better than cloning legacy software bug by bug.

Also, HTML was designed to adapt to different presentation media, so different presentations of the same document are to be expected.

According to the `Accept` header, Gecko accepts both `application/xhtml+xml` and `text/html`. Should I serve `application/xhtml+xml` to Gecko?

application/xhtml+xml was added to the Accept header in order to enable the serving of MathML to both Mozilla and IE with Apache without scripting back when the MathPlayer plug-in for IE did not handle application/xhtml+xml.

If your document mixes MathML or SVG with XHTML, you should use application/xhtml+xml (until HTML5 parsing is supported).

However, if you are using the usual HTML features (no MathML or SVG) and are serving your content as text/html to other browsers, there is no need to serve application/xhtml+xml to Mozilla. Serving valid HTML as text/html ensures the widest browser and search engine support.

There is a fad of serving text/html to IE but serving the same markup with no added value as application/xhtml+xml to Gecko. This is usually done without a mechanism that would ensure the well-formedness of the served documents. Mechanisms that ensure well-formed output include serializing from a document tree object model (eg. DOM) and XSLT transformations that do not disable output escaping. When XHTML output has been retrofitted to a content management system that was not designed for XML from the ground up, the system usually ends up discriminating Gecko users by serving tag soup labeled as XML to Gecko (leading to a parse error) and serving the same soup labeled as text/html to IE (not leading to a parse error).

How is the treatment of `application/xhtml+xml` documents different from the treatment of `text/html` documents?

An XML parser (expat) is used instead of the tag soup parser.
- Most well-formedness constraints are enforced. Despite common allegations to the contrary, the document is not checked for validity.
- Externally defined character entities other than the five pre-defined ones (<, >, &, " and ') are only supported if the document references a public identifier for which there is a mapping in Mozilla’s pseudo-DTD catalog and the document has not been declared standalone.
- In older versions of Mozilla as well as in old Mozilla-based products, there is no pseudo-DTD catalog and the use of externally defined character entities (other than the five pre-defined ones) leads to an XML parsing error. There are also other XHTML user agents that do not support externally defined character entities (other than the five pre-defined ones). Since non-validating XML processors are not required to support externally defined character entities (other than the five pre-defined ones), the use of externally defined character entities (other than the five pre-defined ones) is inherently unsafe in XML documents intended for the Web. The best practice is to use straight UTF-8 instead of entities. (Numeric character references are safe, too.)
- document.write() is not supported. The stream that is going into the parser can’t be tampered with in mid-parse.
- Things that look like XML comments are treated as XML comments—even inside script or style elements.
- Elements need to be in the XHTML namespace in order to be treated as XHTML elements.
- meta tags are not examined for character encoding information.
- tbody, head, body, and html are not inferred if the tags are not explicitly present.
- CDATA sections are supported.
- XML empty element notation (<foo/>) is supported.
- White space characters in attribute values are normalized to spaces at parse time, so the original white space never makes it to the DOM. This affects data round tripping using hidden form inputs.
In versions prior to Gecko 1.9/Firefox 3, the document is not loaded and rendered incrementally.
The layout mode is the (Full) Standards Mode regardless of doctype.
CSS works according to the XML+CSS rules.
- HTML-specific CSS exceptions do not apply. For example, the body element gets no special treatment.
- CSS selectors are case-sensitive.
The DOM is in the XML mode.
- Namespace-aware variants of methods need to be used when working with elements (eg. createElementNS() instead of createElement()).
- Element and attribute names are not normalized to upper case.
Other namespaces are supported.
- MathML
- SVG (in SVG-enabled builds only)
- XUL (Please note that XUL is Mozilla-specific and, therefore, using it on the public Web causes interoperabilty problems.)
xml:base is observed when following links.
Style sheets can be references using processing instructions.

I didn’t find the answer I was looking for. Where should I ask?

Try asking in the newsgroup relevant to your question in the comp.infosystems.www.authoring.* hierarchy or, if your question is about JavaScript/ECMAScript or the DOM, in comp.lang.javascript (after reading the group FAQs first, of course). Please do not ask Web authoring questions in the newsgroups intended for discussion about the development of Mozilla.

Original Document Information

Author(s): Henri Sivonen (Please, no authoring questions to this address.)
Last Updated Date: May 12, 2007
Copyright Information: Henri Sivonen