Ce document répond aux questions que les auteurs web posent souvent en relation avec Firefox et d'autres navigateurs basés sur Gecko. Des liens vers des FAQ plus généralistes sur le développement web sont disponibles à la fin de ce document.
Gecko dispose de deux modes de mise en page et demi : Quirks, Presque Standards et Standards. Dans son mode Standards, Gecko a pour but de traiter les documents écrits en concordance avec les spécifications de formats web applicables. Dans son mode Quirks, et à des fins de rétrocompatibilité, Gecko imite certains comportements d'anciens navigateurs qui le conduisent à violer certaines de ces spécifications. Le mode Presque Standards est semblable au mode Standards, sauf qu'il traite la question suivante en dessinant les cellules de tableaux comportant des images selon la méthode traditionnelle. Ce mode est déterminé en fonction de la déclaration doctype (ou de son absence) au début d'un document HTML.
<!DOCTYPE html><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">La manière la plus simple d'activer le mode Quirks pour un document HTML est de ne pas mettre de déclaration de doctype. Il est toutefois vivement déconseillé de créer de nouveaux documents qui dépendraient du mode Quirks.
Le mode Presque Standards a été ajouté dans Mozilla 1.1 beta et Mozilla 1.0.1. Dans les versions plus anciennes, les déclarations de doctype qui activent le mode Presque Standards aujourd'hui activaient plutôt le mode Standards.
Le reniflage de doctype s'applique uniquement aux documents servis comme text/html. Les documents envoyés en XML activent toujours le mode de rendu Standards. C'est notamment le cas des documents servis comme application/xhtml+xml. Par conséquent, les documents XHTML 1.0 Transitional sont rendus en mode Presque Standards lorsqu'ils sont servis en text/html selon l'Annexe C de XHTML, mais en mode Standards lorsqu'ils sont servis en application/xhtml+xml.
Comme les autres navigateurs contemporains disposent également d'un mode Standards, l'utilisation des doctypes mentionnés ci-dessus est la meilleure manière d'obtenir une mise en page CSS consistante quel que soit le navigateur utilisé. Par contre, les dérogations du mode quirks varieront d'un navigateur à l'autre et ne sont donc pas fiables.
Dans le modèle de mise en page par boîtes de CSS2, la taille verticale des boîtes et l'alignement vertical des images diffèrent du comportement des anciens navigateurs. Ces aspects de la mise en page peuvent être changés en définissant explicitement la propriété CSS display des images (et éventuellement des éléments <a> qui les entourent) à block.
Si les cellules de tableaux qui contiennent uniquement une image sont par exemple marquées avec <td class="imgcell">, la règle CSS correspondante sera : .imgcell img, .imgcell a { display: block; }
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.
Voici quelques points à vérifier:
<link> et <style> doivent être placés dans l'élément <head>.1.2em).:» et non «=».<style>, n'ont pas leur place dans un fichier CSS.font-face n'est pas une vrai propriété CSS. La propriété est font-family, @font-face est une «at-rule».@import est utilisé, ce doit être la première entité du fichier CSS.Content-Type adéquat pour les feuilles CSS?
text/css.text/html.width et height ne s'appliquent pas aux éléments en ligne («inline») comme, par défaut <span>.text-align: center; centre le contenu en ligne dans un bloc. Il ne centre pas le bloc lui-même (et n'est pas censé le faire). Un bloc peut être centré en positionnant margin-left et margin-right à auto et width à une valeur qui rend le bloc plus étroit que son propre bloc englobant.Il est aussi possible, mais moins probable, que vous fassiez l'expérience d'un bug du navigateur.
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() */
}
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.
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.)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.
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).
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).
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.
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).
application/xhtml+xml documents different from the treatment of text/html documents?<, >, &, " 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.document.write() is not supported. The stream that is going into the parser can’t be tampered with in mid-parse.script or style 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.<foo/>) is supported.inputs.body element gets no special treatment.createElementNS() instead of createElement()).xml:base is observed when following links.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.