X-UA-Compatible : IE=Edge

Je rage devant tous ces afficionados qui veulent être à la pointe et qui tout en crachant sur les mode de compatibilité et doctype switching, forcent les futurs navigateurs à reproduire les mêmes problèmes.

N’utilisez pas « X-UA-Compatible : IE=Edge ». C’est inutile et contre-productif.

Un pari risqué sur l’avenir

Avec cette entête, on déclare explicitement une compatibilité avec tout moteur Internet Explorer futur. Celui de dans deux ans ou celui de dans cinq ans.

Avec le passé des navigateurs, l’histoire du doctype switching, les modes de compatibilité et les ruptures de compatibilité diverses, c’est quand même un pari qui semble perdu d’avance.

La question n’est pas tellement de savoir si vous codez « standard », mais que le standard peut évoluer ou se préciser, que certaines fonctionnalités peuvent être abandonnées, ou que certains bugs peuvent être corrigés en introduisant des effets de bords sur vos pages. Même ceux qui codent « standard » jusqu’au bout des ongles choisissent en général tel ou tel montage pour contourner les manques ou différences des navigateurs et que ces manques et différences évoluent avec le temps.

Le problème n’est pas vos pages ou votre code, c’est l’environnement autour.

Et encore, je laisse de côté ceux qui s’attachent tellement fort aux standards qu’ils finissent pas n’utiliser que des fonctionnalités avant leur stabilisation voire avec préfixées dans des versions de test. Eux *vont* des problèmes, mais ils le méritent.

… (le plus souvent) inutile

Le système est fait pour trois cas :

Permettre à un site codé pour une ancienne version d’Internet Explorer et non compatible avec les suivantes, de bloquer le moteur de rendu à cette version précise.
Permettre à un intranet ou à un site autrefois liste noire pour incompatibilité historique, après une refonte et en attendant d’être retiré des listes noires, de déclarer pouvoir/vouloir désormais utiliser les versions récentes du moteur d’Internet Explorer.
Permettre à un site incompatible avec les anciennes versions d’Internet Explorer d’être embarqué via une iframe dans un site non compatible (soit sur liste noire, soit qui demande explicitement une ancienne version du moteur)

Si vous n’êtes pas dans un de ces trois cas, il est très probable que vous n’ayez pas besoin d’une entête X-UA-Compatible. Pour utiliser la dernière version respectueuse des normes du moteur d’Internet Explorer, il vous suffit de coder des pages valides avec un doctype correct et sans prologue XML.

Sauf à être dans un des cas précédents, le X-UA-Compatible n’apportera rien de plus à part les effets négatifs qui seront décrits plus haut.

Mais si vous souhaitez quand même un opt-in

Même si vous vous retrouvez dans un des trois cas décrits plus haut, ou si vous souhaitez quand même être explicite, se déclarer explicitement compatible avec de futures versions qui n’ont même pas commencé à voir le jour est toujours aussi risqué.

Vous avez testé avec IE10 ? alors déclarez IE=10. Vous n’aurez rien de moins que prévu, même si un IE11 ou un IE12 sortent. Si ces prochains n’introduisent pas de problème de compatibilité, il est probable que vous bénéficierez de toutes façons du nouveau moteur. À l’inverse, s’il y a rupture de compatibilité majeure, vous aurez probablement moins de problèmes avec un mode de compatibilité « IE=10 » qu’avec un nouveau moteur incompatible « IE=Edge ».

Vous avez tout à gagner à être honnête et à déclarer la compatibilité réelle de vos pages. Au pire le site développé pour IE10 continuera d’être vu avec un moteur compatible avec ce que proposait IE10. Est-ce vraiment si peu souhaitable ?

Si ces pages sont toujours en maintenance active lors d’une nouvelle version du moteur IE *et* que ce moteur est compatible avec la version précédente *et* pourtant qu’il décide de passer en compatibilité quand vous précisez IE=[la_version_précedente] (vous remarquerez que les deux dernières conditions sont assez incohérentes entre elles), alors il vous sera facile de mettre à jour la déclaration. L’avantage c’est que si une de ces hypothèses devient invalide à l’insu de votre plein gré, au moins ça continuera à fonctionner comme avant et comme prévu.

À quoi ça sert alors ?

Le mode IE=Edge est utile à condition que vous testiez toutes les pages différentes à chaque nouvelle beta d’Internet Explorer, et ce tant qu’au moins une de vos pages est en ligne (chez vous ou chez un tiers).

Ça peut être votre cas si vous avez un petit site et que vous avez du temps à y passer. C’est toutefois un pari sur le fait que vous restiez en maintenance active et que vous aurez du temps à perdre à l’avenir. Je ne compte pas le nombre d’applications ou de sites abandonnés qui sont en théorie en maintenance ou dont on pensait qu’ils seraient encore en maintenance.

Le plus souvent IE=Edge c’est surtout pour les sites en développement, et ça devrait y rester cantonné.

Mon problème n’est pas tant que vous choisissiez d’utiliser une déclaration IE=Edge, à vrai dire vous faites ce que bon vous semble et comme je n’utilise pas IE je n’aurai pas à en souffrir. Mon problème c’est quand ça arrive en recommandation ou en bonne pratique à destination des développeurs. Là désolé de vous le dire, mais vous avez fauté. Vous engagez fortement un tiers à quelque chose dont je doute qu’il ait saisi toutes les implications, et ce pour un bénéfice qui reste franchement à démontrer.

Petite pensée pour l’avenir

Si trop de gens utilisent IE=Edge, et qu’Internet Explorer se sent obligé d’introduire une rupture de compatibilité significative, quelle(s) solution(s) leur restera-t-il ?

Casser la compatibilité, mais ils ont prouvé que dans leur cas spécifique, sachant que leur moteur était fortement utilisé aussi pour les applications natives et pas que le Web, c’était franchement nocif
Introduire un nouveau mécanisme d’auto-détection bancal comme le doctype switching et complexifier encore plus le développement web qui est déjà bien tordu à ce niveau si on prend en compte tous les modes de compatibilité
Considérer que IE=Edge correspond en fait à IE=13 (par exemple) et créer un nouveau mot clef pour le remplacer, ou ajouter un suffixe explicite ; ceux qui ont joué avec les User-Agent savent combien ce mode de fonctionnement a ses limites

Même du point de vue du web, en trichant à ce niveau vous n’aidez pas le web à rester à jour, vous risquez surtout de le casser ou de le complexifier. À bon entendeur…

Publié

17 août 2012

dans

Développement web

par

Éric

Étiquettes :

Commentaires

13 réponses à “X-UA-Compatible : IE=Edge”

thesorrow

17 août 2012

Complètement d’accord avec toi.
A préciser aussi qu’il s’agit d’une entête HTTP et qu’il vaut mieux configurer son application/serveur pour envoyer l’entête plutôt que de mettre un meta pas beau.

Autre question : Dans quels cas le Google Chrome frame est déclenché ?

Répondre
Felipe

19 août 2012

@thesorrow : GCF empêche toute communication entre la couche accessibilité d’IE et l’API accessibilité de Windows puisqu’il court-circuite l’échange entre navigateur et OS. Donc plus aucune accessibilité pour les lecteurs d’écran (JAWS, NVDA, …) et autres assistances techniques. À éviter donc.

Répondre
PhilippeH

9 janvier 2013

Très bien… Mais j’ai quand même quelques question :
– Vous préconnisez de ne pas utiliser l’option « dernière version d’IE » parce que vous n’avez testé le site qu’avec telle version d’IE… Mais quid de Chrome ou Firefox ? Ils sont toujours dans leur dernière version !
– Plus embêtant pour moi : Votre site, par exemple est proprement déclaré en HTML 5. Mais Internet Explorer a quand même décidé de l’afficher avec le rendu IE7, alors que j’ai un IE9. C’est bien domage quand on sait le nombre de lacunes CSS et bugs CSS qu’IE7 possède d’autant plus que selon les stats de gs.statcounter il ne représente plus que 0,8% des clients en décembre 2012. Mettre en edge me permet de proposer un site avec des directives CSS connues par la plupart des nivigateurs en profitant des futures évolutions d’IE, éternellement en retard sur ses concurrents… Ce ne sont, il est vrai, que de petites nuances, qui agrémentent l’expérience utilisateur, mais sont de toutes façons utilisées à bon escient, j’entends par là que le mode « dégradé » (avec la CSS mal comprise) reste tout à fait lisible et acceptable.

Répondre
1. Éric D.
  
  9 janvier 2013
  
  * Pour Chrome c’est la même chose (Firefox n’utilise pas ce mécanisme à ma connaissance), et d’autant plus s’ils se mettent souvent à jour. Je n’ai aucune envie que l’application ou le site casse du jour au lendemain pour tous les utilisateurs de Chrome.
  
  * Le site fonctionne sur la version testée. Le fait qu’une nouvelle version existe avec de nouvelles possibilités n’y change rien. Quand j’utiliserai ces nouvelles fonctionnalités, je les testerai et mettrai à jour la déclaration (bon, je ne le ferai pas ici, le blog a le thème par défaut, non modifié, d’autres s’en occuperont, ou pas). Mais justement, parlons en de tous ces bugs. On les évite avec de multiples contournements et des sur déclarations pour combler tous les cas supportés ou non. C’est justement à cause de ça que les futures versions risquent de casser des choses. Je ne parle pas de théorie, je parle de concret qui a justement motivé ce genre de déclarations X-UA-Compatible. Si dans la réalité les mises à jour avaient tendance à corriger les problèmes sans en créer, personne n’aurait même eu l’idée de ce machin là.
  Tu ne profites pas des futures versions de IE : tu espères qu’un moteur conforme interprétera correctement les choses. Tu le fais parce que ne rien faire serait pire. Maintenant si tu as le choix, les moteurs que tu as testé ont toutes les chances de mieux se comporter avec ton code que tous les futurs hypothétiques moteurs que justement tu n’as pas testé.
Philippe C.

30 septembre 2013

Salut,

Absolument pas d’accord avec tout ça… Edge est de loin la meilleure solution qui soit à partir du moment ou l’on code propre et qu’on n’utilise pas de hacks CSS et autres bidouilles… Pour rappel, il n’est pas nécessaire d’utiliser de hacks, même pour rendre un site compatible avec IE6…

Il est également fort peu probable que Microsoft décide du jour au lendemain de « casser » un rendu qu’il tend à rendre le plus conforme possible à mesure des versions de IE. Je ne vois pas pourquoi vouloir s’obstiner à prétendre le contraire (« Si trop de gens utilisent IE=Edge, et qu’Internet Explorer se sent obligé d’introduire une rupture de compatibilité significative, quelle(s) solution(s) leur restera-t-il ? »).

Je rejoins Philippe un peu plus haut. D’une part, certains sites, bien que semblant très bien codés et tout aussi bien déclarés, s’affichent en mode IE7, voire en Quirks, sans raison apparente, et d’autre part, bloquer un rendu pour une version de IE serait comme interdire à un utilisateur de Chrome ou de Firefox de mettre à jour son navigateur sous prétexte que comme on a testé le site avec la version 23 de Firefox, on ne sait pas trop si ça va fonctionner avec la version 24…

On survol(e) bien les choses ici… Et puis, je laisse moi aussi de côté des phrases comme « je laisse de côté ceux qui s’attachent tellement fort aux standards qu’ils finissent pas n’utiliser que des fonctionnalités avant leur stabilisation voire avec préfixées dans des versions de test. » S’il fallait attendre que CSS3 soit complètement finalisé avant de l’utiliser, on y serait encore dans 10 ans… Si on peut faire des ombres sous des navigateurs méritant comme Firefox et Chrome grâce à des -moz- ou -webkit-, ne nous en privons pas. Si IE ne sait pas les afficher, ce ne sera qu’un rendu légèrement dégradé, et absolument pas gênant.

Il faudrait réviser vos bonnes pratiques…

Répondre
1. edaspet
  
  30 septembre 2013
  
  > Pour rappel, il n’est pas nécessaire d’utiliser de hacks, même pour rendre un site compatible avec IE6…
  
  Tout dépend ce que tu ranges dans cette catégorie. Tu vas probablement souvent utiliser deux ou trois structures différentes en te basant sur la cascade pour que chaque navigateur comprenne ce qu’il peut. Très bien, sauf que si le lendemain un navigateur comprend un peu un truc et un peu un autre, ça risque de mal se passer, tout simplement.
  
  > Il est également fort peu probable que Microsoft décide du jour au lendemain de « casser » un rendu qu’il tend à rendre le plus conforme possible à mesure des versions de IE.
  
  Pourtant cette phrase porte une superbe contradiction. Si on tend à rendre le rendu le plus conforme possible, c’est qu’on le change, donc forcément qu’on va casser des choses un jour, même si on l’évite le plus possible. Même sans ça, on ajoute des choses, on en supporte qui ne l’étaient pas avant. Ça a forcément des effets de bords à un moment où un autre.
  
  Croire que ça n’arrive pas c’est nier toute l’histoire des navigateurs. Croire que ça n’arrivera plus c’est avoir une foi dans l’avenir qui relève plus de l’idéologique que du pratique.
  
  > D’une part, certains sites, bien que semblant très bien codés et tout aussi bien déclarés, s’affichent en mode IE7, voire en Quirks, sans raison apparente
  
  Autre qu’une foi en l’avenir un peu moins optimiste que la votre ?
  
  Mais surtout : Quel est le problème en pratique ? Si ça fonctionnait lors de la conception et que ça fonctionne toujours, sans risque et sans casse ? Le simple fait de vous dire dans votre fort intérieur qui vous n’utilisez pas la future version du moteur pas encore sortie à l’heure de la mise en production du site ? et alors ?
  
  Ces sites fonctionnent, tout en ayant fait un choix moins risqué que le votre. Si ça vous fait mal, peut être fixez-vous mal vos objectifs.
  
  > bloquer un rendu pour une version de IE serait comme interdire à un utilisateur de Chrome ou de Firefox de mettre à jour son navigateur sous prétexte que comme on a testé le site avec la version 23 de Firefox, on ne sait pas trop si ça va fonctionner avec la version 24…
  
  Sauf que oui mais non.
  On ne bloque rien, on déclare qu’on est compatible avec un certain moteur. Si Microsoft décide que le moteur N+1 ne risque nullement de casser un rendu avec le moteur N, croyez bien que la déclaration IE=N fonctionnera parfaitement avec le moteur N+1. En fait c’est même ça l’intention. Le fait qu’on utilise les versions de IE et non celles du moteur est juste une question d’interface utilisateur.
  
  Si un jour IE pense qu’il fonctionne avec des moteurs suffisamment stables d’une version à l’autre non seulement il se permettra de tracer le rendu avec la version suivante malgré la déclaration X-UA, mais en plus il finira par abandonner la version X-UA.
  Damned! c’est d’ailleurs exactement ce qu’il s’est passé avec IE11.
  
  > S’il fallait attendre que CSS3 soit complètement finalisé avant de l’utiliser, on y serait encore dans 10 ans…
  
  Si vous croyez que les préfixes ne sont là que parce que CSS3 dans son ensemble n’est pas finalisé, c’est vous qui survolez beaucoup.
  Mais on revient au sujet initial : si vous n’attendez pas que ce soit finalisé, c’est que ça peut être modifié (et sur CSS3 les propriétés qui ont été abandonnées après implémentation ou qui ont changé de sens, il y en a à la pelle). Comment vous assurez-vous que vous ne cassez rien ?
  
  Je ne parle pas de dégradation du genre « oh, il n’aura pas les bords arrondis » mais de structures qui peuvent être totalement illisibles parce que tel ou tel détail sur l’algo de rendu a été précisé de façon différente de l’implémentation initiale.
  
  Vous pouvez me dire de réviser mes bonnes pratiques, je vous dirai de réviser l’histoire des navigateurs.
  
  Mais surtout vous êtes en train de vous dire plus intelligents que tous ces gens qui font les navigateurs que vous utilisez (et croyez-moi, les développeurs des moteurs de rendus sont parmi les plus smart). Si les dev de IE ont jugé pertinent de mettre en place ce X-UA jusqu’à IE10, c’est que *eux* ont jugé que la compatibilité était risquée vis à vis des évolutions de leur moteur. Pensez-vous être tellement au-dessus pour prétendre que c’est inutile ?
  
  Votre sortie sur les préfixes est du même tonneau. Ce qu’il se passe en ce moment c’est que justement les navigateurs sont sur le point de réinternaliser les directives préfixées. Certaines vont devenir masquées par défaut et utilisables uniquement après activation dans les préférences, pour bien marquer qu’elles ne sont pas toutes là pour être utilisées ; et les autres vont probablement passer plus rapidement sans préfixes pour dissuader les gens d’utiliser des versions préfixées. Vous allez à contre-courant de toute l’histoire là aussi.
  
  Si j’osais : Il faudrait réviser vos bonnes pratiques.
  
  Mon billet a plus d’un an mais non seulement il n’a pas pris une ride, mais en plus l’histoire récente lui donne plutôt raison.
Arnaldo

1 octobre 2013

Bonjour Monsieur, je vais également « critiquer » votre billet si vous me le permettez :)

Vous dites :

Vous êtes en train de vous dire plus intelligents que tous ces gens qui font les navigateurs ….
Si les dev de IE ont jugé pertinent de mettre en place ce X-UA jusqu’à IE10, c’est que *eux* ont jugé que la compatibilité était risquée vis à vis des évolutions de leur moteur.
Pensez-vous être tellement au-dessus pour prétendre que c’est inutile ?

Et vous, vous pensez aussi être en dessous d’eux parce qu’ils ont créé un navigateur ? Franchement….
Je déteste les gens qui passent leur temps à démontrer aux autres qu’ils sont moins intelligents qu’un autre !
Et c’est pour ça que je vous écris ce commentaire ! Revenons en au sujet.

Premièrement, ce code « X-UA-Compatible » n’est pas W3C, ni compatible avec les autres navigateurs…
C’est du pur Microsoft !
Si chaque constructeur de navigateur invente son langage pour influer sur le rendu je vous laisse deviner les conséquences ?
(On a le même problème avec les SGBD, chacun rajoute sa surcouche par dessus SQL)

Deuxièmement, soyons honnête, ce code à SURTOUT été créé dans le but de forcer un navigateur récent à se comporter comme un vieux navigateur pourri pour ne pas dégrader les vieux sites pourris que personne ne recodera jamais.
Grâce à cette technique Microsoft peut pousser les clients à passer à la version la plus récente de leur navigateur (ainsi on peut éventuellement acheter leur nouvel OS qui n’est pas livré avec leur vieux IE7 LOL ) tout en conservant un affichage correct sur leurs anciennes applications.

Les clients disent : Mon application marche avec IE7, pourquoi payer pour la recoder !
Je trouve ça utile pour les vieux sites, je crache pas dessus, au départ c’est pas une mauvaise idée de la part de Microsoft …
MAIS… je pense (comme les autres personnes ci dessus apparemment) que la grosse erreur de Microsoft (Une erreur parmi plein d’autres diront certains…! ) à été de l’appliquer par défaut … !
Car par défaut toute application en zone intranet est affichée en mode IE7 !

C’est plutôt ça qui devrait vous faire rager …

Ce qu’il aurait fallu faire c’est laisser le comportement normal par défaut (Donc laisser IE utiliser « son moteur maximal » comme ce que font tout les autres navigateurs ! ), et appliquer ce code uniquement sur un vieux site pour forcer un navigateur récent a dégrader son moteur pour l’afficher correctement, et uniquement dans ce cas là !

C’est aux administrateurs de bloquer la mise à jour des navigateurs de leurs utilisateurs si leur applications ne sont pas compatibles avec la dernière version d’IE.

C’est mon avis, je pense avoir raison, et je pense donc que votre billet est ridé… il l’était déjà au moment où vous l’avez écrit !

D’ailleurs, allez sur sur la page d’accueil du site de Microsoft : http://www.microsoft.com/fr-fr/default.aspx

Affichez la source, vous verrez ceci : X-UA-Compatible IE=edge

Vous en concluez que Microsoft himself est idiot, contre productif ?

Si vous vous considérez toujours en dessous d’eux, alors nous pouvons logiquement en conclure que votre billet est ridé puisqu’ils ont forcement raison et qu’ils sont passé au mode IE=Edge !

Qu’en dites vous ? Allez vous rester sur votre position ?

Arnaldo

Répondre
1. edaspet
  
  2 octobre 2013
  
  En dessous ? je ne vois pas les choses ainsi. Certes ma formulation était provocatrice mais pertinent sur des questions de compatibilité de moteur de rendu ? Certainement.
  
  Oui ce n’est pas standardisé. Vous pouvez ne rien mettre en ce cas. Le =edge n’est pas standardisé non plus. il s’agit d’une aide, qui ne gêne pas les autres.
  
  Il *faut* faire en sorte que le code soit nickel s’il est interprété par des moteurs standards idéaux. Maintenant ces moteurs n’existent pas, donc il faut en plus faire s’assurer que ce code fonctionne aussi sur une série de moteurs particuliers.
  
  On le fait intuitivement en limitant naturellement son code à ce qui est implémenté, mais aussi en testant et en ayant certains navigateurs qui utilisent certaines règles CSS et d’autres qui en utilisent des alternatives. Au bout d’une certaine expérience ça se fait un peu sans y penser mais c’est le coeur de l’activité et des tests.
  
  Ici on déclare juste sur quoi on a testé. On ne modifie pas le rendu, on informe le navigateur, qui lui agit comme il le souhaite en fonction. Pour moi c’est très différent dans la philosophie.
  
  «  » » Ce qu’il aurait fallu faire c’est laisser le comportement normal par défaut […] et appliquer ce code uniquement sur un vieux site pour forcer un navigateur récent a dégrader son moteur pour l’afficher correctement, et uniquement dans ce cas là ! «  » »
  
  Ils ont fait un choix, qui n’était pas simple. Ce qui est certain c’est que non, on ne pouvait pas envisager de faire du opt-out sur le nouveau moteur. Le principe est justement de gérer les applications qui ne sont pas ou mal maintenues, donc celles où ajouter cette entête n’était pas simple ou envisageable.
  
  «  » » C’est aux administrateurs de bloquer la mise à jour des navigateurs de leurs utilisateurs si leur applications ne sont pas compatibles avec la dernière version d’IE. «  » » »
  
  Et laisser des gros trous de sécurité. Et faire que justement jamais ces utilisateurs ne migrent vers un navigateur plus récent et donc qu’on puisse enfin abandonner IE 6 et IE 7. C’est Parce qu’ils ont justement pris une autre option qu’on a pu s’en sortir aujourd’hui.
  
  «  » » Vous en concluez que Microsoft himself est idiot, contre productif ? «  » »
  
  Je conclus que Microsoft a un site qui vit, maintenu en permanence par une batterie d’ingénieurs. Si c’est votre cas alors mettez un X-UA à edge, OK. Si une nouvelle version sort en bêta, faites tourner des tests exhaustifs ou suffisamment représentatifs, corrigez si besoin et avancez.
  
  Le X-UA c’est justement parce que beaucoup de sites et d’applications ne sont pas dans cette dynamique, ou ne le seront pas forcément encore dans quelques années. Là avoir à l’avance mis le X-UA aura pu sauver quelques problèmes.
  
  D’ailleurs vu la complexité et l’étendue du site de MS, je ne mettrai pas ma main au feu qu’il n’y a pas des séries de pages avec des X-UA en entête, ou dans les listes de compatibilité en dur du navigateur.
  
  La question : votre boite est-elle certaine de pouvoir maintenir ce niveau d’effort pendant des années sur tout ce qu’elle sort en production sur le web ? Microsoft le fait (et encore). Pas certain que ce soit si courant. Même Yahoo a eu du X-UA un moment (et a même été dans les listes en dur de IE), comme beaucoup beaucoup de gros joueurs du web.
Philippe C.

2 octobre 2013

Ce sera mon dernier message sur ce sujet puisque je vois que nous n’avons pas la même vision des choses, mais je vais quand même répondre à certains points.

Tout d’abord : non, je ne me crois pas plus intelligent que « ces gens qui font les navigateurs », et bien au contraire, sinon, je ne serai pas en train de dire qu’ils font du bon boulot, notamment pour IE.

Un hack : c’est une bidouille comme par exemple ajouter un « * » ou un « / » dans le nom d’une propriété afin que celle-ci ne soit reconnu que par certaines versions de IE. Exemple, IE6 ne reconnaît pas le sélecteur +, plutôt que d’utiliser un hack, il y a toujours moyen de modifier son CSS pour le rendre compatible toutes versions confondues. Au pire, il est possible une CSS spécifique pour IE. Mais je ne suis pas là pour un cours de CSS, mieux vous orienter vers des gens bien plus intelligents que moi…

Rendre le rendu le plus conforme possible ne veut pas dire casser la rétrocompatibilité, et heureusement !!! Maintenant, si un intégrateur aujourd’hui code encore en pensant « alors, ça je le fais pour IE et ça je le fais pour les autres… », c’est certainement lui qui n’a rien compris !

Concernant l’histoire des navigateurs, c’est justement tout l’inverse de ce que vous dites : jusqu’à maintenant les évolutions des navigateurs n’ont pas perturbé les sites existants, sauf bien entendu ceux codés avec les pieds (et encore, vu les horreurs que je vois passer sur internet, les navigateurs sont quand même parfois bien motivés pour les afficher…). Un exemple concret : j’ai du ressortir dernièrement du placard un site codé du temps de IE7, et bien, croyez-le ou pas, mais il n’a pas pris une ride, que ce soit pour IE ou les autres… Mais déjà à l’époque, bien entendu, je me suis forcé à ne pas faire n’importe quoi dans le code… Et si mon exemple vous laisse songeur, regardez simplement tous ces sites qui existent et qui ont été codés sous d’anciennes versions : ils s’affichent toujours bien, non ?

Votre question : Quel est le problème en pratique ? Mais il est très simple : si vous bloquez un rendu à une certaine version, vous vous privez volontairement des améliorations futures que peut apporter un moteur de rendu, sous prétexte que ces améliorations peuvent casser votre design… Et vous ne répondez pas à ma question, ni à celle posée plus haut par un autre Philippe : Pour Firefox et pour Chrome, vous affichez un message sur votre page d’accueil « attention, ce site est codé pour FF23, utilisez FF24 à vos risques et périls… », ce n’est pas séreux, voyons…

Vous prétendez qu’une mise à jour peut complètement casser votre structure, là, je dirai que ce n’est pas seulement vos bonnes pratiques qu’il faut réviser, mais tout depuis les bases…

Et pour en finir avec cette balise, elle ne devrait même pas exister. Personnellement, je ne m’en sers uniquement que parce que je veux être sûr que IE ne passe pas pour une raison obscure Microsoftienne en mode Quirks, ce qui arrive, comme je l’ai déjà dit, même pour des sites bien codés et parfaitement valides. Et je crois que cette remarque vous a également été faite plus haut et restée sans réponse.

Mais le pire dans tout ça, c’est que vous dites dans votre article qu’il vaut mieux ne pas utiliser cette balise. Alors là, je ne vous comprends plus : ne pas utiliser cette balise revient à toujours vouloir utiliser la dernière version du moteur du navigateur… En résumé, ne pas l’utiliser signifie IE=Edge (la différence étant d’être sûr avec cette balise de ne pas être en mode Quirks ou en rétrocompatibilité).

Ce que vous dites sur les préfixes n’est pas non plus pertinent : si des navigateurs souhaitent implémenter certains modules de CSS3 avant qu’ils ne soient finalisés (plusieurs années pour certains…), ou est le problème ? Si vos CSS sont bien codées, vous utilisez par exemple -moz-border-radius, suivi de -webkit-border-radius, suivi de border-radius (sans préfixe). Le jour ou le navigateur implémente la version finale, ce sera la version sans préfixe qui sera utilisée. J’ai pris l’exemple des arrondis, mais cela est valable pour les dégradés, pour les transformations, etc…

Répondre
edaspet

2 octobre 2013

> Le jour ou le navigateur implémente la version finale, ce sera la version sans préfixe qui sera utilisée. J’ai pris l’exemple des arrondis, mais cela est valable pour les dégradés, pour les transformations, etc…

Les dégradés sont un bon exemple de mémoire. Il y a eu une version préfixée, puis une autre, incompatible. les flex box ont eu 3 ou 4 versions. Et là je ne parle que du simple.

Si c’est préfixé c’est justement que ce n’est pas stable et que ça pourra casser si on l’utilise, sinon ce serait sans préfixe immédiatement.

Répondre
Johan Chouquet

20 janvier 2014

Bonjour,

Je pense qu’il faut simplement se poser la question de l’expérience utilisateur. Il est donc pour ma part essentiel de délivrer à un internaute la meilleure expérience possible sur un site web, ou une application web.

Le but 1er d’un site web, c’est de permettre à un internaute ou utilisateur d’avoir la meilleure expérience possible. C’est bien ce que IE-Edge nous permet de faire facilement et simplement. Le jour où Microsoft sortira une nouvelle version de son IE, il faudra alors tester, comprendre les spécificités, adapter, etc…

Répondre
1. Éric
  
  20 janvier 2014
  
  > d’avoir la meilleure expérience possible. C’est bien ce que IE-Edge nous permet de faire facilement et simplement
  
  Ça mérite explication, parce qu’à priori ce n’est pas le cas.
  
  > Le jour où Microsoft sortira une nouvelle version de son IE, il faudra alors tester, comprendre les spécificités, adapter, etc
  
  Ok, sauf que si on part de ce postulat, on peut bien mettre ce qu’on veut sur le X-UA-Compatible vu que ce sera testé et adapté à chaque version. Bref, je ne vois pas l’argument.
JohnJohn

1 avril 2014

Bonjour,
Nous avons 15 applications web totalisant environ 2000 écrans (les plus anciennes datent de 2002).
Tous les 6 mois, une nouvelle release de chaque application est livrée avec son lot de nouvelles fonctionnalités, de bugs, de regressions…
En parallele, nous devons regulierement upgrader: database, JDK, OS, librairies, middleware, outils, etc… avec leurs nouvelles fonctionnalités, leurs bugs, leurs regressions…
Aujourd’hui, coté client, nous devons faire face à une nouvelle release d’IE chaque année… avec ses nouvelles fonctionnalités, ses bugs (si!), ses regressions… (si! si!)
Nous sommes une équipe avec des ressources (temps/hommes/sous) de plus en plus réduites (c’est la crise!).
Conclusion: nous n’utiliserons jamais X-UA-Compatible : IE=Edge

Répondre