X-UA-Compatible est défini sur IE = Edge, mais il n'arrête toujours pas le mode de compatibilité
Je suis assez confus. Je devrais pouvoir mettre
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
et IE8 et IE9 doivent restituer la page à l'aide du 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é pendant notre page , même si nous devrions le forcer à ne pas le faire.
Comment êtes-vous censé vous assurer que IE utilise pas le mode de compatibilité (même sur 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 méta compatible X-UA?
Si vous devez remplacer les paramètres d'affichage de compatibilité d'IE pour les sites intranet, vous pouvez le faire dans le fichier Web.config (IIS7) ou via les en-têtes HTTP personnalisés dans les propriétés du site Web (IIS6) et définir X-UA-. Compatible là-bas. La balise méta 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 annulera la compatibilité.
Exemple pour web.config dans IIS7:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-UA-Compatible" value="IE=EmulateIE8" />
</customHeaders>
</httpProtocol>
</system.webServer>
Edit: J'ai supprimé le code clear juste avant le add; c'était un oubli inutile de copier/coller. Bonne prise, commentateurs!
La solution côté serveur est la solution recommandée, comme l'a proposé @TimmyFranks dans sa réponse, mais si vous devez implémenter la règle X-UA-Compatible au niveau de la page, veuillez lire les conseils suivants pour bénéficier de l'expérience de celui qui a déjà brûlé
La balise méta X-UA-Compatiblemust apparaît immédiatement après le titre dans l'élément <head>. Aucune autre balise méta, lien css et appel de scripts js ne peut être placé avant.
<head>
<title>Site Title</title>
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1">
<meta charset="utf-8">
<script type="text/javascript" src="/jsFile.js"></script>
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="Apple-touch-icon" href="/Apple-touch-icon.png" />
<link rel="shortcut icon" href="/Apple-touch-icon.png" />
</head>
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>.
// DON'T: place class inside the HTML tag
<!--[if gt IE 8]><!-->
<html class="aboveIe8">
<!--<![endif]-->
// DO: place the class inside the BODY tag
<!--[if gt IE 8]><!-->
<body class="aboveIe8">
<!--<![endif]-->
L'équipe de Html5BoilerPlate a écrit sur ce bug - http://h5bp.com/i/378 Elle propose 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é.
Notez que si vous le utilisez depuis PHP, vous pouvez également utiliser le code suivant pour le réparer.
header("X-UA-Compatible: IE=Edge");
En fin de compte, il s'agit du choix "intelligent" de Microsoft pour forcer tous les sites intranet à passer en mode de compatibilité, même si X-UA-Compatible est défini sur IE=Edge.
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 conditionnels mais infructueuses . En fin de compte, j'ai simplement supprimé toutes les balises conditionnelles et ajouté une balise méta immédiatement après la tête, ci-dessous et cela a fonctionné comme un charme.
<head>
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1">
J'espère que ça aide
Même si vous avez décoché l'option "Afficher les sites intranet dans l'affichage de compatibilité" et si vous avez activé la compatibilité X-UA dans vos en-têtes de réponse, il existe une autre raison pour laquelle votre navigateur peut par défaut afficher "Affichage de compatibilité" - votre stratégie de groupe. Regardez votre console pour le message suivant:
HTML1203: xxx.xxx a été configuré pour s'exécuter dans l'affichage de compatibilité via la stratégie de groupe.
Où xxx.xxx est le domaine de votre site (c'est-à-dire test.com). Si vous voyez cela, la stratégie de groupe de votre domaine est définie de sorte que tout site se terminant par test.com sera automatiquement rendu en mode de compatibilité, quel que soit le type de document, les en-têtes, etc.
Pour plus d'informations, consultez le lien suivant (explique les codes HTML): http://msdn.Microsoft.com/en-us/library/ie/hh180764(v=vs.85).aspx
Comme NEOSWF le souligne ci-dessus, les commentaires conditionnels de Paul irlandais empêchent la méta-balise d'avoir un effet.
Il existe plusieurs correctifs, tous 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.
Lors de 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 code HTML sans faire BEAUCOUP de tests et il est agréable de voir ce qui a été défini en regardant simplement le code HTML.
Finalement, j'ai entouré une div tout de suite après le corps et utilisé des commentaires conditionnels, par exemple
<!--[if IE 7]><div class="ie7"><!--<![endif]-->
... regular body stuff
<!--[if IE 7]></div><!--<![endif]-->
J'aurais pu le faire autour du corps, mais c'est plus difficile avec des CMS comme Wordpress.
Évidemment, c’est un autre DIV à l’intérieur du balisage, mais ce n’est que pour les anciens navigateurs.
Je pense cependant que cela pourrait être une décision basée sur chaque projet.
J'ai aussi lu quelque chose à propos de la méta-balise charset qui doit entrer dans les 1024 premiers octets, ce qui le garantit.
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é.
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 les options "Afficher les sites intranet en mode d'affichage de compatibilité" et définir un paramètre de stratégie de groupe pour spécifier les sites intranet nécessitant un mode de compatibilité.
J'ai ajouté ce qui suit à mon fichier htaccess, ce qui a fait l'affaire:
BrowserMatch MSIE ie
Header set X-UA-Compatible "IE=Edge,chrome=1" env=ie
De plus, X-UA-Compatible doit être la première balise méta dans la section head.
<head>
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1">
</head>
En passant, le bon ordre ou les balises principales sont:
<head>
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1">
<meta charset="utf-8">
<title>Site Title</title>
<!-- other tags -->
</head>
Par ici
- nous avons défini le moteur de rendu à utiliser avant qu'IExplorer ne commence à traiter
- le document puis nous définissons l'encodage à utiliser pour tous les navigateurs
- ensuite, nous imprimons le titre, qui sera traité avec le codage déjà défini.
Pour Nginx,
add_header "X-UA-Compatible" "IE=Edge,chrome=1";
ref: https://github.com/h5bp/server-configs/commit/a5b0a8f736d68f7de27cdcb202e32975a74bd2c5
IE 11 ne vous permet plus de remplacer le paramètre d'affichage de compatibilité du navigateur en envoyant l'en-tête ...
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
Il semble que le seul moyen de forcer le navigateur à ne pas utiliser l'affichage de compatibilité consiste à demander à l'utilisateur de le désactiver dans son navigateur. Notre site est un site intranet et l’option par défaut IE 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 de IE 9 et 10, mais cela ne fonctionne plus dans IE 11. Nos utilisateurs IE basculent vers Chrome, où ce n'est pas un problème et ne l'a jamais été.
Timmy Franks a eu raison pour moi. Nous venons tout juste d’avoir aujourd’hui le problème où le client disposait d’IE8 à l’échelle de la société et obligeait le site que nous avions écrit pour son intranet à passer en mode de compatibilité. Paramétrer "IE-Edge" semblait résoudre le problème.
<httpProtocol>
<customHeaders>
<clear />
<add name="X-UA-Compatible" value="IE=Edge" />
</customHeaders>
</httpProtocol>
J'ai pu contourner ce problème en chargeant les en-têtes avant le HTML avec php, et cela a très bien fonctionné.
<?php
header( 'X-UA-Compatible: IE=Edge,chrome=1' );
header( 'content: width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no' );
include('ix.html');
?>
ix.html est le contenu que je voulais charger après l'envoi des en-têtes.
Si vous utilisez la pile LAMP, ajoutez-la dans votre fichier .htaccess du dossier racine Web. Pas besoin de l'ajouter à chaque fichier PHP.
<IfModule mod_headers.c>
Header add X-UA-Compatible "IE=Edge"
</IfModule>
J'ai eu le même problème après avoir essayé de nombreuses combinaisons, j'avais ce travail Note J'ai vérifié la compatibilité pour l'intranet
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<meta http-equiv="X-UA-Compatible" content="IE=Edge">
<head runat="server">
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 Enterprise. (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 le modifier.
J'ai pu modifier le profil en Desktop après avoir supprimé CurrentVersion de la clé de registre suivante:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Internet Explorer\Main\EnterpriseMode
Après avoir changé le mode sur Desktop, les réponses à ce message fonctionneront.
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é à partir 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 aussi à l’utilisation du domaine et du sous-domaine pour la connexion côté serveur. La machine est limitée à l'ouverture en mode de compatibilité pour tous les sous-domaines.
DISABLE MODE COMPABILITY POUR INTRANET
HKEY_LOCAL_MACHINE - LOGICIEL - Règles - Microsoft - Internet Explorer - BrowserEmulation -> IntranetCompalityMode La valeur doit être 0 (zéro) . Et aussi supprimer le nom de domaine existant de PolicyList.
Sinon, vous pouvez ajouter une nouvelle valeur (DWORD) contenant les données 0 (zéro) valeur.