X-UA-Compatible est défini sur IE = edge, mais n’arrête toujours pas le mode de compatibilité

Je suis assez confus. Je devrais être en mesure de définir

 

et IE8 et IE9 doivent rendre la page en utilisant le dernier moteur de rendu. Cependant, je viens juste de le tester et si le mode de compatibilité est activé ailleurs sur notre site, il restra actif pour notre page , même si nous ne le devrions pas.

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 ( ).

Voici les premières lignes de la page:

       <!--    

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?

    Si vous devez remplacer les parameters 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. La balise META ne remplace pas le paramètre intranet d’IE dans les parameters 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 code clear juste avant l’ add ; c’était un oubli inutile de copier et coller. Bonne prise, commentateurs!

    La solution côté serveur est recommandée, comme @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 astuces suivantes pour bénéficier de l’expérience de celui qui s’est brûlé


    La balise META X-UA-Compatible doit apparaître directement après le titre dans l’élément . Aucune autre balise META, aucun lien css et aucun appel de script js ne peut être placé avant lui.

      Site Title        

    S’il y a des commentaires conditionnels dans la page (disons situés dans le ), ils doivent être placés sous, après le .

     // DON'T: place class inside the HTML tag    // DO: place the class inside the BODY tag    

    L’équipe de Html5BoilerPlate a écrit à propos de ce bug – http://h5bp.com/i/378 Ils ont plusieurs solutions.

    En ce qui concerne la vue Intranet et Compatibilité, il existe des parameters lorsque vous accédez aux outils> Paramètres d’affichage de compatibilité.

    Paramètres d'affichage de compatibilité

    Notez que si vous le diffusez depuis PHP, vous pouvez également utiliser le code suivant.

     header("X-UA-Compatible: IE=Edge"); 

    Il s’avère que cela a à voir avec le choix “intelligent” de Microsoft de forcer tous les sites intranet à utiliser le 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 nombreux tags de commentaires conditionnels mais sans succès. En fin de compte, j’ai simplement supprimé toutes les balises conditionnelles et ajouté la balise meta immédiatement après la tête comme ci-dessous et cela a fonctionné comme du charme.

       

    J’espère que cela aide

    Même si vous avez désélectionné l’option “Afficher les sites intranet dans l’affichage de compatibilité” et que X-UA-Compatible est présent dans vos en-têtes de réponse, il existe une autre raison pour que votre navigateur affiche “Compatibility View” par défaut. 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.-à-d. 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 sera automatiquement rendu en mode de compatibilité, quels que soient 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 le souligne NEOSWF ci-dessus, les commentaires conditionnels de Paul Irish empêchent la balise meta d’être affectée.

    Il y a plusieurs corrections ici ( http://nicolasgallagher.com/better-conditional-classnames-for-hack-free-css/ )

    Ceux-ci inclus:

    Ajout de deux classes HTML, en utilisant les en-têtes de serveur et en ajoutant 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’ai pas aimé l’idée d’append quelque chose avant le HTML sans faire beaucoup de tests en premier et c’est bien de voir ce qui a été défini en regardant le HTML.

    A la fin, j’ai entouré une div après le corps et utilisé des commentaires conditionnels, par ex.

       ... regular body stuff  

    J’aurais pu le faire autour du corps mais c’est plus difficile avec les CMS comme WordPress.

    Évidemment, c’est une autre DIV à l’intérieur du balisage, mais c’est uniquement pour les anciens navigateurs.

    Je pense que cela pourrait être une décision par projet.

    J’ai également lu quelque chose à propos de la balise Meta de charset devant figurer dans les 1024 premiers octets pour que cela soit assuré.

    Parfois, les idées les plus simples et les plus faciles à lire sont les meilleures et cela vaut vraiment la peine d’y penser! Merci au 6ème commentaire sur le lien ci-dessus pour le signaler.

    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 l’affichage 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é.

    J’ai ajouté ce qui suit à mon fichier htaccess, 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 META dans la section head

        

    En passant, l’ordre correct ou les balises principales sont:

        Site Title   

    Par ici

    1. nous définissons le moteur de rendu à utiliser avant que IExplorer ne commence à traiter
    2. le document alors nous définissons l’encodage à utiliser pour tous les navigateurs
    3. Ensuite, nous imprimons le titre, qui sera traité avec l’encodage déjà défini.

    Pour Nginx,

     add_header "X-UA-Compatible" "IE=Edge,chrome=1"; 

    ref: https://github.com/h5bp/server-configs/commit/a5b0a8f736d68f7de27cdcb202e32975a74bd2c5

    Timmy Franks avait raison pour moi. Nous venons d’avoir le problème aujourd’hui où le client disposait d’IE8 à l’échelle de la société, et il obligeait le site que nous écrivions pour leur intranet à passer en mode de compatibilité. Le réglage “IE-Edge” semblait résoudre le problème.

           

    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é est de le désactiver dans son navigateur. Notre site 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 éviter à l’utilisateur de modifier les parameters de son navigateur pour les utilisateurs d’IE 9 et 10, mais cela ne fonctionne plus dans Internet Explorer 11. Nos utilisateurs d’IE basculent vers Chrome, où cela ne pose aucun problème et où été.

    J’ai pu contourner ce chargement des 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 avoir envoyé les en-têtes.

    J’ai eu le même problème après avoir essayé de nombreuses combinaisons J’avais cette note de travail 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">    

    Si vous utilisez une stack LAMP, ajoutez-la à votre fichier .htaccess dans votre dossier racine Web. Pas besoin de l’append à chaque fichier PHP.

      Header add X-UA-Compatible "IE=Edge"  

    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 émulation, recherchez la liste déroulante du profil du navigateur) Le paramètre était verrouillé, ne me permettant pas de modifier le paramètre.

    J’ai pu modifier le profil sur 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 pour le bureau, les réponses sur ce post 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 désactiver la clé de registre.

    Cela m’arrive aussi lorsque j’utilise domain and sub-domain pour connecter le serveur. La machine est limitée à ouvrir en mode de compatibilité pour tous les sous-domaines.

    MODE DE COMPATIBILITÉ À DESACTIVATION POUR INTRANET

    HKEY_LOCAL_MACHINE – LOGICIEL – Stratégies – 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 append une nouvelle valeur (DWORD) contenant des données de valeur 0 (zéro) .