Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.
Vos résultats de recherche

    FAQ de Mozilla pour développeurs web

    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.

    Cette page est en cours de traduction, son contenu peut donc être incomplet ou contenir des parties en anglais. N'hésitez pas à participer à sa traduction à partir de

    Que sont les modes Quirks et Standards ?

    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.

    • La manière la plus simple de s'assurer que le mode Standards est activé en HTML est d'utiliser cette déclaration de doctype :
      <!DOCTYPE html>
    • La manière la plus simple de s'assurer que le mode Presque Standards est activé en HTML est d'utiliser cette déclaration de doctype :
      <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "https://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.

    Pourquoi y a-t-il de l'espace autour des images dans les tableaux en mode Standards ?

    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; }

    Explication plus détaillée…

    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.

    Ma feuille de style ne fonctionne pas! Pourquoi?

    Voici quelques points à vérifier:

    • Le document HTML est-il valide? Appliquer un style à une balise mal formée peut produire des effets inattendus.
      • Les éléments <link> et <style> doivent être placés dans l'élément <head>.
    • La feuille CSS passe-t-elle le contrôle de syntaxe? Les règles de gestion des erreurs CSS font que les parties erronées sont ignorées.
      • Les longueurs différentes de zéro doivent être suivis d'une unité valide, sans espace (ex: 1.2em).
      • Le caractère à utiliser entre le nom et la valeur d'une propriété est «:» et non «=».
      • Les balises HTML, telles que <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».
      • Si @import est utilisé, ce doit être la première entité du fichier CSS.
      • Les erreurs de parsing CSS sont affichées dans la console Javascript.
    • Le serveur envoie-t-il le Content-Type adéquat pour les feuilles CSS?
    • Les noms de classe et les identifiants sont sensibles à la casse.
    • Les sélecteurs d'éléments sont sensibles à la casse avec XML.
    • Les instructions de traitement de feuille de style («Style sheet processing instructions») ne sont permises que dans le prologue des documents XML. De plus, il ne fonctionnent que dans les documents XML, pas dans les documents déclarés comme 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.

    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: &#945;.

    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 (&lt;, &gt;, &amp;, &quot; and &apos;) 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.

    Informations sur le document original

    • Auteur(s) : Henri Sivonen
    • Date de dernière mise à jour : May 12, 2007
    • Informations de copyright : Henri Sivonen

     

    Étiquettes et contributeurs liés au document

     Contributeurs à cette page : tregagnon, fscholz, traan, BenoitL
     Dernière mise à jour par : tregagnon,