Le changement de mode inclus dans cet article s'applique à Firefox et autres navigateurs basés sur Gecko, Safari, Chrome et autres navigateurs basés sur Webkit, Opera, Konqueror, Internet Explorer pour Mac, Internet Explorer pour Windows et le navigateur IE intégré. Évitez de mentionner le nom du moteur du navigateur et mentionnez plutôt le nom du navigateur le plus connu utilisant ce moteur.
Cet article se concentre sur le mécanisme de sélection de mode plutôt que de documenter le comportement exact de chaque mode.
Voici les différents modes :
La sélection du mode pour le contenu texte/html dépend du reniflage du doctype (discuté plus loin dans cet article). Dans IE8, le mode dépend également d'autres facteurs. Cependant, par défaut dans IE8, le mode pour les sites non intranet qui ne figurent pas sur la liste noire de Microsoft dépend du type de document.
On ne saurait trop insister sur le fait que le comportement précis des modèles diffère dans chaque navigateur, même s'il est abordé de manière uniforme dans cet article.
Dans Firefox, Safari, Chrome et Opera, le type de contenu HTTP application/xhtml xml (pas un méta-élément ni un doctype !) déclenchera le mode XML. En mode XML, le navigateur tente de fournir au document XML un traitement conforme aux spécifications dans la mesure spécifiée dans le navigateur.
IE6, 7 et 8 ne prennent pas en charge application/xhtml xml, ni Mac IE5.
Dans le navigateur Nokia S60 basé sur WebKit, le type de contenu HTTP application/xhtml xml ne peut pas déclencher le mode XML, car l'objectif des jardins clos mobiles est la compatibilité avec le contenu non standard. (Les anciens « navigateurs mobiles » ne peuvent pas utiliser de vrais analyseurs XML car le contenu non canonique est étiqueté comme XML.)
N'ayant pas suffisamment testé Konqueror, je ne peux pas dire exactement ce qui va se passer dans ce navigateur.
Certains moteurs ont des modes qui n'ont rien à voir avec le contenu Web. Par souci d’exhaustivité, ils sont uniquement mentionnés ici. Opera a un mode WML2.0. WebKit sur Leopard dispose d'un mode spécifique pour les anciens widgets de tableau de bord.
Voici les principaux impacts de ces schémas :
Le mode texte/html affecte principalement la mise en page CSS. Par exemple, c'est une bizarrerie que les tableaux n'héritent pas des styles. Dans certains modes bizarreries du navigateur, le modèle de boîte devient le modèle de boîte IE5.5. Ce document n'énumère pas toutes les bizarreries de mise en page.
En mode semi-standard (dans les navigateurs disposant de ce mode), seule la hauteur de la cellule du tableau contenant l'image est différente de celle du mode standard.
En mode XML, les sélecteurs ont un comportement différent en fonction de la casse. De plus, les règles spécifiques à l'élément HTML body ne s'appliquent pas aux anciens navigateurs qui n'implémentent pas les dernières modifications CSS 2.1.
Il existe également des bizarreries qui affectent l'analyse du HTML et du CSS et peuvent entraîner une analyse incorrecte des pages Web conformes aux normes. La disposition des bizarreries détermine si ces bizarreries sont activées ou non. Quoi qu'il en soit, il est important de comprendre les principales similitudes et différences entre le mode Quirks et le mode Standards dans la mise en page et l'analyse CSS (et non dans l'analyse HTML).
Certaines personnes qualifient à tort le mode standard de « mode d'analyse stricte », ce qui conduit à des malentendus sur la capacité du navigateur à appliquer les règles de syntaxe HTML et sur la capacité du navigateur à évaluer l'exactitude du balisage. Ce n'est pas le cas. Même lorsque la présentation en mode standard est en vigueur, les navigateurs effectuent toujours un travail de correction de la soupe de balises (http://en.wikipedia.org/wiki/Tag_soup). (Avant la sortie de Netscape 6 en 2000, Mozilla disposait de modes d'analyse pour appliquer les règles de syntaxe HTML. Ces modes étaient incompatibles avec le contenu Web existant et ont été abandonnés.)
Une autre idée fausse courante concerne l’analyse XHTML. Il est généralement admis que l’utilisation du doctype XHTML entraîne une analyse différente. En fait, ce n'est pas le cas. Les documents XHTML avec un type de contenu text/html utilisent le même analyseur que les documents HTML. Actuellement, tous les navigateurs se soucient du fait que XHTML avec le type de document text/html n'est qu'une "soupe de balises avec des croûtons" (des barres obliques supplémentaires partout).
Uniquement lorsque des documents utilisant le type de document XML (par exemple : application/xhtml xml ou xmapplication/) déclenchent le mode XML pour l'analyse, l'analyseur à ce stade est complètement différent de l'analyseur HTML.
Bien que le mode Quirks concerne principalement le CSS, il y a aussi un peu de script. Par exemple, dans le mode bizarreries de Firefox, l'attribut HTML id établit une référence d'objet globale au niveau du script, tout comme dans IE. L'impact des scripts dans IE8 mérite plus d'attention que dans les autres navigateurs.
En mode XML, le comportement de certaines API DOM est complètement différent, car le comportement de l'API DOM de XML n'est pas compatible avec le comportement du HTML lorsqu'il est défini.
Les navigateurs modernes utilisent le reniflage de doctype pour déterminer le mode moteur des documents texte/html. Cela signifie que le choix du mode est basé sur la déclaration du type de document (ou son absence) au début du document HTML. (Cela ne s'applique pas aux documents utilisant le type de document XML.)
La déclaration de type de document (doctype) est une contrefaçon grammaticale de SGML. SGML est un cadre de balisage à l'ancienne, et HTML avant HTML5 a été défini sur cette base. Dans la spécification HTML4.01, la déclaration du type de document décrit les informations de version du HTML. Malgré le nom « Déclaration de type de document » et la spécification HTML 4.01 décrivant les « informations de version », une déclaration de type de document ne classe pas un document SGML ou XML comme un type spécifique de document, même s'il y ressemble (à cause du nom) . (Plus en annexe)
Ni la spécification HTML4.01 ni la norme ISO 8879 (SGML) ne disent quoi que ce soit sur l'utilisation des déclarations de type de document comme conversions en mode moteur. Le reniflage de doctypes est basé sur l'observation qu'au moment où le reniflage de doctypes a été conçu, la grande majorité des documents originaux n'avaient ni déclaration de type de document ni référence à une DTD plus ancienne. HTML5 accepte ce fait et définit le doctype en texte/html comme seul mode de conversion.
Une déclaration de type de document pré-HTML5 typique contient (séparées par des espaces) la chaîne "". La déclaration du type de document est placée avant la balise d'ouverture de l'élément racine du document.
Voici un guide simple sur la façon de choisir un doctype lors de la création d'un nouveau document texte/html :
Je ne recommande aucun doctype XHTML car Le XHTML utilisé comme text/html est considéré comme dangereux . Quoi qu'il en soit, si vous choisissez d'utiliser le doctype XHTML, sachez que les déclarations XML déclencheront le mode bizarreries dans IE6 (mais pas IE7 !).
Une ligne directrice simple pour application/xhtml xml est de ne jamais utiliser doctype. Les pages Web de cette manière ne sont pas « strictement cohérentes » avec XHMTL 1.0, mais cela n'a pas d'importance. (Veuillez consulter l'Annexe au dos)
A List Apart a introduit une fois qu'en plus du doctype, IE8 utilisera la conversion de mode basée sur les méta-éléments comme l'un des facteurs de sélection de mode. (Voir les commentaires de Ian Hickson, David Baron, David Baron, Robert O'Callahan et Maciej Stachowiak. . )
IE8 dispose de 4 modes : le mode bizarreries IE5.5, le mode normes IE7, le mode quasi-normes IE8 et le mode normes IE8. Le choix du mode dépend des données provenant de plusieurs sources : doctype, méta-éléments, en-têtes HTTP, données de téléchargement périodique de Microsoft, domaine LAN, paramètres définis par l'utilisateur, paramètres définis par l'administrateur LAN et le mode de la trame parent (si any) Compatible avec le bouton d'affichage de la barre d'adresse est déclenché par l'utilisateur. (Pour les autres applications intégrées au moteur, le mode dépend également de l'application intégrée.)
Heureusement, IE8 utilisera généralement le reniflage de doctypes comme les autres navigateurs si :
À l'exception des deux cas ci-dessus concernant la compatibilité X-UA, IE8 effectue un reniflage de doctype comme IE7. L'émulation IE7 est appelée vue de compatibilité.
Dans le cas de X-UA-Compatible, IE8 se comporte complètement différemment des autres navigateurs. J'aimerais voir l'Annexe ou l'organigramme aux formats PDF et PNG sur cette page.
Malheureusement, sans l'en-tête HTTP ou la balise méta compatible X-UA, même avec le doctype approprié, IE8 permet aux utilisateurs de rétrograder par inadvertance la page du mode standard d'IE8 au mode IE7, qui est une émulation du mode standard d'IE7. Pire encore, les administrateurs LAN peuvent également le faire. Microsoft peut également mettre sur liste noire tous les noms de domaine que vous utilisez.
Pour gérer ces effets, le doctype ne suffit pas, vous avez besoin d'un en-tête HTTP et d'une balise méta compatibles X-UA.
Ce qui suit est un guide simple sur la façon de sélectionner l'en-tête HTTP ou la balise méta compatible X-UA pour les nouveaux documents texte/html qui ont déjà un doctype qui déclenche le mode standards ou le mode quasi-standards dans d'autres navigateurs :
Le reniflage de Doctype est une approche similaire à celle d'une chaudrée de balises pour résoudre un problème de chaudrée de balises. Le reniflage de Doctype est une heuristique conçue après la publication des spécifications HTML4 et CSS2 qui distingue les documents obsolètes des documents conformes au comportement auquel leurs auteurs auraient pu s'attendre.
De temps en temps, il est suggéré d'utiliser le reniflage de doctypes sur XML pour planifier différents traitements, identifier le vocabulaire utilisé ou activer des fonctionnalités. C'est une mauvaise idée. La planification et l'identification du vocabulaire doivent être basées sur des espaces de noms, tandis que l'activation des fonctionnalités doit être basée sur des instructions ou des éléments de traitement explicites.
L'idée même de la bonne formation est d'introduire une analyse XML sans DTD et de promouvoir une documentation sans doctype. Dans le cas formel où deux documents XML ont la même forme canonique et que l'application les traite différemment (et la différence n'est pas due à un manque de choix pour traiter les entités externes), l'application peut être cassée. En pratique, si deux documents XML provoquent le rapport du même contenu (qnames ignorés) à un gestionnaire de contenu SAX2
et que l'application traite les documents différemment, l'application peut être interrompue. Considérant qu'en tant qu'auteurs Web, vous ne pouvez pas être sûr que tout le monde utilisera un processeur XML qui résoudra les entités supplémentaires pour analyser leurs pages (même si certains navigateurs semblent le faire car ils mappent certains identifiants publics à une DTD définissant une entité tronquée), Insérer Les doctypes en XML pour le Web sont inutiles et conduisent souvent à des habitudes sectaires. (Vous utilisez toujours la fonctionnalité de remplacement de DTD du W3C Validator pour valider une DTD, bien que le W3C Validator dise que le résultat n'est que temporairement valide. Ou mieux encore, vous pouvez détendre NG avec Valider , cela ne pollue pas le document référencé par le schéma. ) Exiger un doctype pour renifler est assez stupide, même si c'est la solution de contournement dans la pratique HTML. De plus, lorsqu'une spécification de niveau inférieur définit deux choses comme égales, une spécification de niveau supérieur ne doit pas essayer de leur donner des significations différentes. Veuillez considérer . Si vous supprimez l'identifiant public, la même DTD est toujours spécifiée, donc doctype signifie la même chose que le doctype précédent. Faut-il les renifler différemment ? Peut théoriser davantage. Supposons qu'une DTD appelée foobar.dtd soit copiée sur example.com : . Comment renifler ça ? Cela devrait signifier la même chose. Même la DTD entière peut être jointe au document. En d'autres termes, s'il y a #include "foo.h", vous ne devez lier aucune magie noire au nom foo.h, car cela devrait permettre de copier le contenu de foo.h dans le document ou de copier foo. h into in bar.h et signifie #include "bar.h". La raison pour laquelle je ne m'inquiète pas du fait que HTML et SGML construisent les mêmes paramètres est que les navigateurs Web n'utilisent pas de véritables analyseurs SGML pour analyser le HTML, donc je ne pense pas qu'il soit utile de prétendre être SGML. Quoi qu’il en soit, si vous n’êtes pas encore convaincu, voici l’article de W Eliot Kimber sur le sujet comp.text.sgml Dans le tableau ci-dessous, le mode bizarre, le mode standard et le quasi-standard sont représentés respectivement par Q, S et A. Lorsque le navigateur n'a que deux modes, si la hauteur de ligne de la cellule du tableau est cohérente avec le mode standard de Mozilla, le mode standard est marqué "S". Si la hauteur de ligne de la cellule du tableau est cohérente avec le mode quasi-standard de Mozilla, , alors il est marqué comme « A ». Veuillez noter que le XHTML servi à l'aide du modèle de contenu XML est rendu en mode XML. Le but de ce tableau n'est pas de dire que tous les doctypes du tableau sont des choix raisonnables pour les nouvelles pages. Le but de ce tableau est de montrer sur quelles données sont basées mes recommandations. Les symboles d'abréviation suivants sont utilisés pour les en-têtes de colonnes : Annexe : Comment gérer certains doctypes en texte/html
Le code de détection de doctype de Moziila a été considérablement modifié en octobre 2000, septembre 2001 et juin 2002. L'état de la version de Mozilla (et Netscape 6.x) décrite dans ce document peut être consulté sur ftp.mozilla.org à partir du 19/10/2000. Ce document ne couvre pas le fonctionnement du reniflage de doctypes dans Mozilla M18 (et Netscape 6.0 PR3). Le code de détection de doctype de Safari a également été considérablement modifié depuis la première version bêta publique. Ce document ne couvre pas les comportements antérieurs à la version V73 également appelée 0.9.
Le code reniflant doctype avant Konqueror 3.5 semble provenir d'une toute première version de Safari. Konqueror correspond désormais à Safari et son code de détection de doctype provient de Mozilla.
Comme le montre le tableau, le reniflage de doctype d'Opera change régulièrement de similaire à IE à Mozilla, bien que Opera 9.5 et 9.6 soient sur le chemin du retour. Dans le même temps, le comportement de mise en page du mode bizarreries d'Opera est passé de l'émulation du mode bizarrerie d'IE6 au mode bizarrerie de Mozilla.
Merci Merci à Simon Pieters, Simon Pieters et Anne van Kesteren de m'avoir aidé à corriger les feuilles de patrons des différentes versions d'Opera et pour leurs commentaires. Merci à Simon Pieters d'avoir créé un autre organigramme IE8.
L'ordinateur dispose d'Internet mais le navigateur ne peut pas ouvrir la page Web
Que signifie le navigateur
Compatibilité du navigateur
Comment résoudre le problème des caractères tronqués lors de l'ouverture d'une page Web
Vérifiez le statut en ligne de vos amis sur TikTok
Comment réparer winntbbu.dll manquant
A quoi sert principalement javascript ?
Quel est le codage utilisé à l'intérieur d'un ordinateur pour traiter les données et les instructions ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
