Je suis assez confus. Je devrais pouvoir régler
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
et IE8 et IE9 doivent afficher la page en utilisant le dernier moteur de rendu. Cependant, je viens de le tester, et si le mode de compatibilité est activé ailleurs sur notre site, il restera activé pour notre page , même si nous devrions le forcer à ne pas le faire.
Comment êtes-vous censé vous assurer qu'IE n'utilise pas le mode de compatibilité (même dans un intranet)?
FWIW, j'utilise la déclaration HTML5 DocType ( <!doctype html>
).
Voici les premières lignes de la page:
<!doctype html>
<!--[if lt IE 7 ]> <html lang="en" class="innerpage no-js ie6"> <![endif]-->
<!--[if IE 7 ]> <html lang="en" class="innerpage no-js ie7"> <![endif]-->
<!--[if IE 8 ]> <html lang="en" class="innerpage no-js ie8"> <![endif]-->
<!--[if (gte IE 9)|!(IE)]><!-->
<html lang="en" class="innerpage no-js">
<!--<![endif]-->
<head>
<meta charset="ISO-8859-1" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
EDIT: Je viens d'apprendre que le paramètre par défaut sur IE8 est d'utiliser le mode de compatibilité IE7 pour les sites intranet. Cela remplacerait-il la balise META compatible X-UA?
Réponses:
Si vous devez remplacer les paramètres d'affichage de compatibilité d'IE pour les sites intranet, vous pouvez le faire dans le web.config (IIS7) ou via les en-têtes HTTP personnalisés dans les propriétés du site Web (IIS6) et y définir X-UA-Compatible. La balise META ne remplace pas le paramètre intranet d'IE dans les paramètres d'affichage de compatibilité, mais si vous la définissez sur le serveur d'hébergement, elle remplacera la compatibilité.
Exemple pour web.config dans IIS7:
Edit : j'ai supprimé le
clear
code juste avant leadd
; c'était un oubli inutile de copier et coller. Bonne prise, commentateurs!la source
<clear />
? Quels en-têtes personnalisés sont effacés par cela?<urlCompression...>
règle au moins pour moi. Cette règle fait gzipping, ce que je veux donc j'ai commenté le clair. Toute autre information serait agréable.<?php header('X-UA-Compatible: IE=edge'); ?>
La solution côté serveur est la solution recommandée, comme @TimmyFranks l'a proposé dans sa réponse, mais si l'on doit mettre en œuvre la
X-UA-Compatible
règle au niveau de la page, veuillez lire les conseils suivants, pour bénéficier de l'expérience de celui qui a déjà été brûléLa
X-UA-Compatible
balise META doit apparaître juste après le titre dans l'<head>
élément. Aucune autre balise META, liens css et appels de scripts js ne peuvent être placés avant.S'il y a des commentaires conditionnels dans la page (disons situés dans le
<html>
), ils doivent être placés sous, après le<head>
.L'équipe de Html5BoilerPlate a écrit sur ce bug - http://h5bp.com/i/378 Ils ont plusieurs solutions.
En ce qui concerne la vue Intranet et compatibilité, il existe des paramètres lorsque vous accédez à Outils> Paramètres de la vue Compatibilité.
la source
X-UA-Compatible
devrait apparaître le plus tôt possible, probablement aprèscharset
. Je ne pense pas qu'il soit vrai qu'il "doit apparaître juste après le titre".X-UA-Compatible
balise META peut apparaître aprèstitle
,base
et toute autre balise META sans perdre son effet. C'est ce que j'ai testé dans IE8. Cependant, aucun commentaire conditionnel ne peut lui être soumis.Notez que si vous le servez depuis PHP, vous pouvez également utiliser le code suivant pour le corriger.
la source
<!--[if lt IE 7 ]> <html>...
! MERCI! Vous êtes envoyé par Dieu !!Il s'avère que cela a à voir avec le choix «intelligent» de Microsoft de forcer tous les sites intranet à passer en mode de compatibilité, même s'il
X-UA-Compatible
est défini surIE=edge
.la source
J'ai également eu le même problème de rendu IE9 dans les normes de document IE7 pour l'hôte local. J'ai essayé de nombreuses balises de commentaires conditionnelles mais sans succès. En fin de compte, je viens de supprimer toutes les balises conditionnelles et j'ai simplement ajouté une méta-balise immédiatement après la tête comme ci-dessous et cela a fonctionné comme un charme.
J'espère que ça aide
la source
Même si vous avez décoché l'option "Afficher les sites intranet dans la vue de compatibilité" et que la compatibilité X-UA est présente dans vos en-têtes de réponse, il y a une autre raison pour laquelle votre navigateur peut par défaut être en "vue de compatibilité" - votre stratégie de groupe. Regardez votre console pour le message suivant:
Où xxx.xxx est le domaine de votre site (par exemple test.com). Si vous voyez cela, la stratégie de groupe pour votre domaine est définie de sorte que tout site se terminant par test.com s'affiche automatiquement en mode de compatibilité, indépendamment de doctype, des en-têtes, etc.
Pour plus d'informations, veuillez consulter le lien suivant (explique les codes html): http://msdn.microsoft.com/en-us/library/ie/hh180764(v=vs.85).aspx
la source
Comme le souligne NEOSWF ci-dessus, les commentaires conditionnels de Paul Irish empêchent la balise META d'avoir un effet.
Il existe plusieurs correctifs ici ( http://nicolasgallagher.com/better-conditional-classnames-for-hack-free-css/ )
Ceux-ci inclus:
Ajout de deux classes HTML, utilisation d'en-têtes de serveur et ajout d'un commentaire conditionnel au-dessus du doctype.
Sur mon dernier projet, j'ai décidé de supprimer les commentaires conditionnels de Paul Irish. Je n'aimais pas l'idée d'ajouter quoi que ce soit avant le html sans faire BEAUCOUP de tests d'abord et c'est agréable de voir ce qui a été défini juste en regardant le HTML.
À la fin, j'ai entouré un div juste après le corps et j'ai utilisé des commentaires conditionnels, par exemple
J'aurais pu faire cela autour du corps mais c'est plus difficile avec des CMS comme Wordpress.
Évidemment, c'est une autre DIV à l'intérieur du balisage, mais ce n'est que pour les navigateurs plus anciens.
Je pense que cela pourrait être une décision par projet.
J'ai également lu quelque chose sur la balise meta charset qui doit venir dans les 1024 premiers octets, donc cela garantit cela.
Parfois, les idées les plus simples et les plus faciles à lire sont les meilleures et il vaut vraiment la peine d'y penser! Merci au 6ème commentaire sur le lien ci-dessus pour l'avoir signalé.
la source
X-UA-Compatible
ne remplacera que le mode Document, pas le mode Navigateur, et ne fonctionnera pas pour tous les sites intranet; si tel est votre cas, la meilleure solution consiste à désactiver "Afficher les sites intranet dans la vue de compatibilité" et à définir un paramètre de stratégie de groupe pour spécifier les sites intranet qui ont besoin du mode de compatibilité.la source
J'ai ajouté ce qui suit à mon fichier htaccess, ce qui a fait l'affaire:
la source
De plus, X-UA-Compatible doit être la première balise META dans la section head
Soit dit en passant, l'ordre correct ou les principales balises de tête sont:
Par ici
la source
Timmy Franks avait raison pour moi. Nous venons d'avoir le problème aujourd'hui où le client avait IE8 à l'échelle de l'entreprise, et cela forçait le site que nous avons écrit pour son intranet en mode de compatibilité. Le réglage de "IE-Edge" semblait le corriger.
la source
Pour Nginx,
réf: https://github.com/h5bp/server-configs/commit/a5b0a8f736d68f7de27cdcb202e32975a74bd2c5
la source
IE 11 ne vous permet plus de remplacer le paramètre d'affichage de compatibilité du navigateur en envoyant l'en-tête ...
Il semble que le seul moyen de forcer le navigateur à ne pas utiliser la vue de compatibilité consiste à demander à l'utilisateur de le désactiver dans son navigateur. Le nôtre est un site Intranet, et l'option IE par défaut consiste à utiliser la vue de compatibilité pour les sites Intranet. Quelle douleur!
Nous avons pu empêcher l'utilisateur de modifier les paramètres de son navigateur pour les utilisateurs d'IE 9 et 10, mais cela ne fonctionne plus dans IE 11. Nos utilisateurs IE passent à Chrome, où ce n'est pas un problème, et n'a jamais été.
la source
IE11
ne prend pas en charge d'autres modes de compatibilité queedge
. Lien vers la documentation officielle . Cela signifie que nous n'avons plus besoin d'utiliser cette balise META pour masquer le bouton CM sur la barre d'adresse.J'ai pu contourner ce chargement des en-têtes avant le HTML avec php, et cela a très bien fonctionné.
ix.html est le contenu que je voulais charger après l'envoi des en-têtes.
la source
Je rencontrais le même problème dans IE11. Aucune de ces réponses n'a résolu mon problème. Après avoir creusé un peu, j'ai remarqué que le navigateur fonctionnait en mode Entreprise . (vérifiez en appuyant sur F12 et cliquez sur l'onglet d'émulation, recherchez la liste déroulante du profil du navigateur) Le paramètre a été verrouillé, ne me permettant pas de modifier le paramètre.
J'ai pu changer le profil en bureau après avoir supprimé CurrentVersion de la clé de registre suivante:
Après avoir changé le mode Desktop, les réponses à ce message fonctionneront.
la source
Lorsque votre navigateur s'ouvre avec les modes de compatibilité, même si vous supprimez et désactivez la configuration de tous les modes de compatibilité de votre navigateur Web et de l'éditeur de stratégie de groupe local, vous pouvez essayer de désactiver la clé d'enregistrement.
Cela m'arrive également lors de l'utilisation du domaine et du sous-domaine pour se connecter côté serveur. La machine est limitée à s'ouvrir en mode de compatibilité pour tous les sous-domaines.
DÉSACTIVER LE MODE DE COMPABILITÉ POUR L'INTRANET
HKEY_LOCAL_MACHINE - SOFTWARE - Policies - Microsoft - Internet Explorer - BrowserEmulation -> IntranetCompalityMode La valeur doit être 0 (zéro) . Et supprimez également le nom de domaine existant de PolicyList.
Sinon, vous pouvez ajouter une nouvelle valeur (DWORD) contenant des données de valeur 0 (zéro) .
la source
J'ai eu le même problème après avoir essayé de nombreuses combinaisons J'ai eu cette note de travail J'ai vérifié la compatibilité de l'intranet
la source
Si vous utilisez la pile LAMP, ajoutez-la à votre fichier .htaccess dans votre dossier racine Web. Pas besoin de l'ajouter à chaque fichier PHP.
la source