Internet Explorer 9 téléchargeable en version finale

> Et vous, qu'attendez-vous d'IE9 ?

Strictement rien. J'attends surtout qu'IE 6 7 et 8 dégagent.

Box-shadow marche non ?
Gradient non par contre.
Avoir « oublié » details et summary c’est assez lamentable.

même pas un ptit border-radius... cette honte. IE restera IE...

Merci dew pour cet excellent article !

@picks : Si si border-radius est supporté.

Quand est-il du système de mise à jour ?
Car vu toutes les API qui manquent, on peut oser espérer qu'ils vont ajouter ça par la suite et si il est aussi difficile de mettre à jour IE9 que IE6, c'est mal barré.

Et voilà, il se retrouve dernier sur la liste des 5 plus récents.
C'est vraiment lamentable, ils font des efforts sur-humains pour rester obsolètes rapidement, c'est dingue.

Pour ma part, j'ai décidé de ne plus supporter IE6 dans mes développements. Ceux qui ne sont pas content n'ont qu'à changer de navigateur. Je me sens beaucoup mieux depuis que j'ai pris cette décision.

ah oui j'ai confondu la liste des CSS3 supporté avec celle des non-supportés...et non ce n'est pas de la mauvaise foi anti-IE :p.
sinon @levince, pareil.

La nouvelle bête noire sera IE7... éternel recommencement, tout ca :p

@levince : Pareil.
Espérons que la tentative n°9 ne sera pas un echec.

Et vous, qu'attendez-vous d'IE9 ?
Il ne marche pas sous XP, il ne marche pas sous linux, il ne marche pas.

je rejoins Joffreyd, je ne comprends que Microsoft fasse tous ces efforts (qu'on ne peut que saluer d'une part) mais que leur navigateur arrive tout le temps derrière les navigateurs alternatifs

Il prends en compte le drag&drop ?

Es-ce que le test acid 3 est pertinent. L'évolution de Firefox semble montré que Mozilla n'est pas fan de ce test:
Firefox 2.0 en mars 2008: 52/100 (création de l'acid test)
Firefox 3.0 en juin 2008: 71/100
Firefox 3.5 en juin 2009: 93/100
Firefox 3.6 en janvier 2010: 94/100
Firefox 4.0RC1 en mars 2011 97/100 (source en.wikipédia)
D'après ce que j'ai lu cela bloque sur le SVG font dont Mozilla a proposé une alternative: WOFF (avec MS et rejoint par Opera).
D'après ce blogueur, webkit aurait surtout tout fait pour avoir juste ce qui faut pour passer le test: http://ljouanneau.com/blog/post/2008/03/27/77...
et dans celui-ci (...)2010/06/24/Pourquoi-Firefox-n-aura-probablement-jamais-100-au-test-acid-3, il cite 2 développeurs de Mozilla qui ne sont pas emballé par l'implémentation de SVG Font.

Bref, es-ce que l'Acid Test 3 est pertinent ??

Firefox est pas top pour le multibackground, ça ram à mort (malgré mes efforts de rendre les images le plus légère possibles).

J'irai essayer de choper le PC d'un pote demain pour tester IE9 tout de même et voir ce que mes sites donnent dessus (et j'ai peur :D)

@agaric : Acid 3 est un bon test mais c'est moitié marketing, moitié standards d'après ce qu'on peut lire à droite à gauche sur le net.

En tout cas vu que Mozilla ne se fatigue pas à obtenir de 100 % et ce depuis un bon moment, je pense qu'on ne peut définir la qualité d'un navigateur à son score.

Surtout que FF, Safari, Chrome et Opéra (les dernières versions) sont presques toutes à jour en ce qui concerne les nouveautés HTML5, CSS3 et autres API.

http://www.generation-nt.com/test-ie9-interne...

Suivant cet article, IE9 aurait une rapidité accrue en JS (test sunspider) !

Alors moi, la première chose que j'ai remarqué c'est que la propriété CSS focus avec un outline:none ne marche plus !!! Ca commence mal.

Même le site Alsacreations montre bien le problème. Dès que vous cliquez sur un lien par exemple, vous voyez apparaître l'encadrement en pointillé au moment du focus.

Quelqu'un a-t-il déjà trouvé une solution autre que de faire appel aux méthodes JavaScript ?

Bonjour,

Vous avez certainement du effectuer vos tests de performance SunSpider sur la version 64 bits d'IE9. En effet, sur le test SunSpider, tout le monde s'accorde à dire d'IE9 est aujourd'hui le plus rapide (plus rapide que Chrome 10/11/12, Firefox 4 RC et Opera 11). Mais pour le voir il faut tester la version 32 bits d'IE9. C'est d'ailleurs la version par défaut qui est lancée sur un PC. Cette version contient le nouveau moteur Chakra qui compile en arrière-plan le code JavaScript en code natif. La version 64 bits ne dispose pas de ce mécanisme car les équipes de développements d'IE ont préféré se concentrer sur la version quasiment utilisée par tout le monde aujourd'hui : la version 32 bits et ne pas écrire le compilateur JS en 64 bits. Certains journalistes se sont ainsi amusés à "faire exprès" d'utiliser la version 64 bits sans le dire sur le test sunspider pour tenter de faire croire qu'IE9 était toujours à la traine sur les performances JavaScript.

J'espère que cela n'est pas votre cas ici et que vous avez simplement oublié de préciser que vous aviez effectué les tests de performances sur la version 64 bits d'IE9. Il serait alors également intéressant que vous publiez les résultats avec la version 32 bits d'IE9.

David Rousset
Microsoft France

Par ailleurs, sur ACID3 et HTML5Test, nous nous sommes déjà exprimés à ce sujet ici : http://bit.ly/epjH2y. Sur ACID3, Mozilla prend d'ailleurs la même position que nous: Mythbusting : Why Firefox 4 won’t score 100 on ACID3

Sur le support des standards, vous avez raison de regarder l'état actuel de leur support dans IE. Mais c'est dommage que vous alliez dans le sens de Paul Rouget plutôt que de regarder de manière plus pragmatique l'état de finalisation des spécifications. Typiquement, WebSockets a déjà montré ses faiblesses par le passé avec une faille dans le protocole de communication (géré par l'IETF et récemment mis à jour). Mozilla a déjà d'ailleurs eu ses propres débats internes sur ce sujet: https://bugzilla.mozilla.org/show_bug.cgi?id=602028

WebSockets est donc aujourd'hui toujours à l'état de Working Draft depuis Décembre 2009 : http://www.w3.org/TR/websockets/ comme d'aill... CSS3 Animations & CSS3 Transitions.

Ce sont certes des technos "cool" avec lesquelles les développeurs Web ont envie de développer au plus vite. Je le comprends tout à fait. Mais nous essayons du côté de Microsoft de ne pas reproduire les erreurs commises avec IE6 : implémenter des features avant qu’elles ne soient terminées ou standardisés pour ensuite faire un code qui devient propriétaire à une version d'un moteur spécifique et donc hors standard. Ou alors de demander aux développeurs Web de fréquemment mettre à jour leur code en fonction de l'évolution des brouillons et des navigateurs associés.

Microsoft essaie donc d'être responsable sur le choix et la vitesse d'implémentation des nombreux standards qui gravitent autour d'HTML5 (CSS3, SVG, Geoloc, etc.). En effet, nous avons un nombre conséquent de clients grand-comptes qui ne peuvent se permettent de mettre à jour leurs parcs toutes les 6 semaines pour suivre l'évolution des drafts des dernières trucs cool à la mode. Ils ont déjà en ce moment un boulot important pour passer d'IE6 à IE8/9... Alors IE6 a 10 ans!

De la même manière, nous oeuvrons aujourd'hui de manière importante à la création de jeux de tests unitaires au près du W3C. Nous en avons soumis près de 6000 au W3C. Alors évidement, IE9 passe mieux ces tests que la concurrence car ce sont nos propres tests unitaires que nous fournissons au W3C pour fabriquer la suite "officielle". Je ne souhaite donc surtout pas tirer la moindre conclusion de cette suite de tests sur la qualité de notre implémentation versus la concurrence. Mais la participation à la Task Force des tests unitaires au W3C est ouverte. Mozilla ferait d'ailleurs mieux de nous aider plus activement plutôt que de perdre son temps à pointer vers des machins de type feature detection comme HTML5test

Sur WebGL, c'est plus simple: ce n'est pas un standard géré par le W3C. Je ne vois ainsi pas l'intérêt de le mettre dans le panier fourre-tout HTML5.

Bref, nous avons le sentiment que la course à celui qui implémente le plus vite les drafts n'est pas un service à rendre aux développeurs et encore moins aux utilisateurs. C'est une des raisons qui bloque aujourd'hui de nombreux utilisateurs en entreprise sur IE6.

David

J'attends plutôt de voir comment M$ va faire évoluer son navigateur. Si c'est pour refaire une version tout les x années, IE aura toujours un train de retard qui handicapera le web.

Et puis je me forme en autodidacte , je suis sous xp (comme la majorité du parc info mondiale je crois) et je n'ai pas les moyens (ni l'utiliter d'ailleurs) de passer à seven. Comment je fais pour tester mes sites sous IE9?
Une version pour XP aurait été apprécié.

Concrètement, aujourd'hui, pour les webdesigners du monde entier, internet explorer est une plaie.
On est obligé de faire un design pour ie8, un autre pour ie7 et encore un autre pour ie6.
C'est incroyable de voir comme tout fonctionne mieux et plus simplement sous linux ou macos.

Je m'attendais à quelque chose de vraiment bien, mais je suis déçu.
Bien qu'il y ait eu des efforts de Microsoft. C'est déjà plus pratique.
Mais ce qui est vraiment dommage et qui va être handicapant c'est la non-compatibilité avec XP...
Comme beaucoup d'ordinateurs tournent avec XP, si les utilisateurs d'IE ne peuvent plus le mettre à jour... on sera bloqué avec IE8 :)
Ca sera encore une partie de plaisir...
Espérons qu'ils utiliseront un navigateur "alternatif" !
Bon bon, pour l'instant, il faut déjà tuer les restes de IE6, ce sera déjà bien.

@davrous : Pourquoi ne pas simplement dire que vous n'avez pas le temps de tout faire à temps pour IE9 ? Ce n'est pas une honte, c'est juste la réalité des choses. La différence est tellement énorme entre IE8 et IE9 qu'on ne peut pas reprocher aux équipes de IE de ne pas en avoir fait plus.

Le prétexte des spécifications non-stables est tout simplement un énorme mensonge. Si Microsoft n'implémentait que des spécifications stables, il n'y aurait pas CSS Transforms ou WebTiming dans IE9. De plus, cette philosophie va totalement à l'encontre des principes de stabilisation d'une spécification. Sans implémentation, on ne peut pas savoir si une spécification a besoin d'être retravaillée ou si elle est prête.

Donc bravo pour IE9, pourvu que ça continue dans ce sens avec IE10 mais par pitié, pas d'excuses inutiles.

Oups, j'ai oublié de signer en précisant que je suis employé Mozilla (mais développeur web)

IE9 n'est pas compatible XP ... normal, il faut vendre Win 7 !

Logique, en fait.

"::before ::after ::first-letter ::first-line" non-supportés.
RAAAAAH

Bon, réjouissons-nous, nth-child est là, c'est déjà ça. Les text-shadow et compagnie, va encore falloir taper dans ces filters crades.

Comme d'hab, en fait. Les trucs récents qui sont marketing à mort (audio/video/canvas) sont implémentés, et le reste on l'oublie. Même ce qui est antérieur (CSS2 n'est toujours pas réellement présent, et paf ! Du CSS3 apparaît).

joska : depuis l'annonce publique du jeter de IE6 aux orties, on peut donner au client la raison sus-évoquée, pour ne plus créer pour cette version. Et ça, c'est déjà beau.

Lpu8er: Il y a encore trop d'ie6 en circulation pour pouvoir se permettre d'ignorer tous ses utilisateurs. Je parle par expérience puisque j'ai rencontré ce problème récemment. Beaucoup d'entreprise sont encore bloqué avec ie6.

@Lpu8er : Attention à ne pas trop de jeter sur des impressions fausses ::before, ::after, etc. ne sont que les syntaxes CSS3 des éléments :before , :after etc. déjà implémentées depuis IE8

Chouette, bon pour moi cela ne changera pas grand chose puisque que j'ai encore 20% de visiteurs utilisant IE6...et 30 % IE7.

Je vais encore m'amuser un moment à développer avec 3-4 feuilles de style par site.

Je trouve l'effort de Microsoft louable, surtout dans le fait de ne pas vouloir reproduire les mêmes erreurs que précédemment. Mais le fait de ne pas pouvoir l'avoir sur XP c'est juste....abominable...

Beaucoup de points négatifs relevés par les commentaires... mais sinon il y a pas mal de points positifs à relever ;)
Je ne pense pas que l'article veuille casser l'effort de Microsoft, mais présenter succinctement ce qui a été mis en œuvre, et pas.

Je suis persuadé que Firefox 4 aura aussi ses faiblesses...

@Riku Asakura : Je suis assez d'accord. Et puis au final notre métier consiste aussi à savoir faire face à toutes ces différences entre navigateur. Le w3c ne fourni que des recommandations et non pas des obligations.

@davrous : Si vous attendez que tout ce qui fait défaut à IE9 et pas à ses concurrents soit validé par le W3C avant de l'implémenter, il ne reste aux développeurs web qu'une seule chose à faire : prier pour que vous arrêtiez de faire des navigateurs.

Si c'est pour que IE soit à la traîne ad vitam aeternam et qu'il ne représente qu'une exception dérangeante à chaque création de site, je ne vois pas l'intérêt de vous donner tant de mal à le mettre à jour.

Ou adoptez WebKit. Une solution qui aurait été infiniment plus simple et qui n'a pas empêché Google de grapiller une part de marché non négligeable sans avoir à coder quoi que ce soit à ce niveau.

J'ai testé quelques-uns de mes sites vieux de 6 mois avec IE9 sorti il y a une semaine et ils s'affichent mieux sous Firefox 3.6 ou Safari 4.
J'ai vraiment du mal à comprendre ce qui passe par la tête de Microsoft parfois, la seule réponse logique qui me vient est que MS n'a pas envie de faire de un navigateur digne de ce nom. Quand je vois qu'une multinationale de cette importance n'arrive pas à pondre un navigateur du niveau de ses concurrents dont le budget de certains représente le budget crayons à papier de MS, j'ai du mal à piger.

Enfin bon, j'admets tout de même que IE9 est la version qui a apporté le plus depuis IE6, mais tout n'est pas encore rose.

@Skoua: notre approche est clairement différente de Google ou Mozilla car nous avons aujourd'hui une responsabilité qu'ils n'ont pas (ou beaucoup moins): un énorme écosystème de clients ayant déployé XP et IE6 et n'ayant plus jamais mis à jour pendant des années. Or IE6 a gagné la première guerre des navigateurs en séduisant tout le monde en allant plus vite que la musique et en étant nettement plus innovant que la concurrence qui à sortir des specs standards comme le rappel Bruce (de chez Opera) dans son billet très intéressant:
http://www.brucelawson.co.uk/2010/in-praise-o...

Je trouve que son avertissement est intelligent et fait clairement écho à la mode actuelle qui consiste à dire que WebKit c'est d'la balle et que l'on peut y aller franco sans aucun risque. Cela moi, c’est totalement faux et on l’a déjà vu avec certaines specs comme WebSockets.

Du coup, on se retrouve avec un début de comportement identique à il y a 10 ans: on développe en testant principalement pour le moteur de rendu le plus sexy du moment aux yeux des WebDesigners (WebKit par exemple) puis on teste rapidement sous IE, voir on teste pas du tout. C'est clairement :
1 - un manque de professionnalisme vu les parts de marché restantes d'IE que ce soit dans le monde ou en France
2 - c'est glisser doucement vers un mode de développement propriétaire à un moteur donné

Du coup, on se retrouve dans le scénario que vous mentionnez: vos "vieux" sites d'il y a 6 mois s'affichent moins bien dans IE9 que FF 3.6 ou Safari. Mais la différence d'interprétation vient d'où?

Par ailleurs, on voit clairement le gap énorme qui sépare la création de sites "publics" et les applications web d'entreprise. Les DSI ne veulent pas d'une spec qui bouge ou d'être obligé de requalifier un navigateur toutes les 6 semaines. Ils mettent des années à mettre à jour le parc. Que cela nous plaise ou non, c'est régie par des raisons évidentes liées aux coûts de migration.

Pourtant les standards sont bien là pour éviter ce genre de désagrément mais il faut pour cela qu'ils soient proprement testés, finalisés et correctement implémentés par tous les navigateurs. Du coup, cela prend effectivement du temps et cela ne plait pas à Google qui préfère pousser son approche à travers le WhatWG et son concept de « Living Standard ».

Nous n’adhérons clairement pas à ce principe. Je conçois que cela donne l'impression que nous freinons ou que nous n'allons pas assez vite mais j'ai plutôt l'impression de mon côté que nous sommes plus responsables.

Mais je pense qu'il y a peu de chances que l'on tombe d'accord de toute façon ;-)

David

@davrous : je rebondis juste sur WebSocket : il ne faut pas l'enterrer en une phrase comme ça :) La faille de protocole est présente dans Flash, et ce depuis des années. Elle est difficilement exploitable (il faut posséder un proxy) et il est de toute façon plus intéressant d'utiliser ce proxy pour capturer tous les mots de passe qui passent dans les requêtes HTTP classiques, qui elles ne seront jamais protégées.
Tout ça pour dire que WebSocket n'est pas mort, et est utilisable sereinement en prod cross browser (avec Flash), si on accepte le même niveau de risque que HTTP

@jpvincent: non, il n'est pas mort (heureusement! :)), preuve en est, le protocole a été mis à jour la semaine dernière. Mais cela illustre aussi le problème auquel on aurait été confronté si nous l'avions mis dans IE9 et que nos clients entreprise avaient déployés IE9 massivement et avait créé du code basé sur cette version bancale du protocole.

"IE6 a gagné la première guerre des navigateurs en séduisant tout le monde"
"..."
Vous voulez dire que toutes ces années ie était présent sur tous les postes de travail non pas à cause de la position dominante de MS qui a par ailleurs été condamné pour cela, mais à cause de ses qualités ?

"c'est glisser doucement vers un mode de développement propriétaire à un moteur donné".
Vous voulez dire que Microsoft n'a jamais voulu étouffer le marché des navigateurs en publiant des specs propriétaires tout en étant quasiment le seul navigateur du marché?

C'est un point de vue intéressant, mais vouc comprendrez qu'on a un peu du mal à vous croire...
Merci pour les progrès d'IE de ces dernières années, sans doute pas du tout contraints par la concurrence.

Sinon, j'ai un petit message à destination de l'auteur de l'article: pourquoi avoir testé IE9 64 bits dans le benchmark SunSpider et ne pas l'avoir précisé? Comme je l'ai dis plus haut, cette version est nettement moins rapide que la version 32 bits qui est 1ère à ce bench.

Quand à l'affirmation : "Une accélération matérielle proche des performances de Chrome 10 et Firefox 4 est certainement une des innovations majeures", elle est basée sur quoi? Quels sont les tests qui ont été effectués? Cette affirmation laisse sous-entendre d'IE9 est moins rapide que Chrome 10 ou FF4 dans ce domaine là alors que tous les tests que j'ai effectué sur des benchmarks MS et non MS semble prouver le contraire:

http://blogs.msdn.com/b/iefrance/archive/2011...

Alors comme on va me dire que je publie les résultats sur un blog MS, il y a également des journalistes qui obtiennent des résultats similaires: http://www.generation-nt.com/test-ie9-interne...

Bref, je suis un peu surpris de la méthodologie retenue. Ou alors, si c'est pour faire de la bonne pub à Firefox et Chrome, c'est réussi. :-P

David

@amk : non, vous avez raison, il faut également mettre en balance la position dominante de Windows dans cette affaire. Chose pour laquelle nous avons d'ailleurs été condamné en Europe et suite auquel nous avons mis en place le Ballot Screen. Mais je ne pense pas que ce soit l'unique raison du succès d'IE à l'époque. Microsoft a quand même inventé pas mal de chose avec IE : XMLHTTPRequest, Drag'n'drop, Offline aujourd'hui en cours de standardisation pour certaines. Puis il y avait des trucs méchamment propriétaires basés sur des filtres DirectX que l'on retrouve maintenant plus ou moins dans CSS3 Transitions & Animations : http://msdn.microsoft.com/en-us/library/ms532... . Je n'ai pourtant pas l'impression d'être très vieux mais il me semble important de rappeler un peu l'histoire car quand je vois ce qu'il y a dans la doc MSDN pour IE6, j'ai des fois l'impression de revivre la même chose avec certaines extensions -webkit ou -moz. Mais j'espère me tromper!

J'ai bien conscience également que nous en sommes arrivés là grâce au coup pied au derrière donné par le petit panda roux. Le web a raison de leur être reconnaisant.

Mais lisez l'article de Bruce, il est vraiment intéressant sur le sujet. En tout cas, plus crédible je pense à vos yeux que s'il avait été écrit par moi vu que là, c'est un auteur de chez Opera. ;-)

@davrous : Quand je parle de différences entre IE9 et les autres navigateurs sur mes sites, je parle de choses aussi "inoffensives" telles que les text-shadow ou les CSS gradients.
Pour les gradients vous êtes pardonnés car de toute façon personne n'utilise encore vraiment la même syntaxe pour l'instant, cependant des bêtises telles que les text-shadow sont un manque ennuyant.

En ce qui concerne les DSI, elles ont la facheuse tendance à installer une version de IE et rester dessus pendant 5 à 10 ans. Que ce soit dû au coût de prod ou autre ça n'est pas trop mon affaire je l'avoue.
Mais en suivant cette logique, vu que ces millions d'employés dont on parle vont devoir se taper IE9 jusqu'à en 2020, ce serait logique de leur sortir un navigateur "à jour" par rapport à ce qu'il se fait en 2011.

Très franchement je n'ai rien contre MS ou IE, ou du moins je n'avais rien contre vous jusqu'à ce que je me mette à intégrer des sites. IE6 m'a fait perdre des centaines d'heures comme à tous les autres intégrateurs web de la planète, c'est pour cela que quand je vois poindre un IE9 annoncé comme le Messie mais qui ne remplit pas toutes les attentes, c'est un peu frustrant.

Le problème de DSI n'est encore une fois par un problème car ces utilisateurs particuliers ne mettent jamais à jour, tandis que vos utilisateurs grand public eux devraient être amenés à le faire tout comme le fond parfois sans le savoir ceux qui utilisent Firefox ou Chrome.
Et ces mises à jours devraient être fréquentes.

Enfin pour ce qui est du propriétaire s'intallant chez vos concurrents, je pense pouvoir m'avancer sans trop prendre de risques qu'ils tomberont tous d'accord sur une syntaxe unique grâce au W3C comme ils l'ont fait pour la plupart des nouvelles propriétés CSS3 et que ces features propriétaires seront des standards sous peu.
Par contre, avec des name="msapplication-tooltip" on va avoir du mal à l'harmoniser cette syntaxe.

@Skoua: je ne connais que trop bien l'histoire et la frustration que vous avez. Maintenant, entre les grandes entreprises et le grand public, les attentes sont totalement différentes. Et nous devons essayer de faire le grand écart entre les 2. Le grand public d'ailleurs se fout royalement des standards mais n'a souvent aucun souci à mettre à jour son navigateur ou à en changer. Donc ils bénéficient des nouveautés sans le savoir. Ils sont plus attachés à la cosmétique, les services proposés par le navigateur et les "performances" (souvent réduite à la vitesse à laquelle se charge pour la 1ère fois un navigateur).

Les grandes entreprises cherchent de leur côté une administration centralisée, un bon patch management, du packaging, une sécurité aussi bonne que possible et un support d'entreprise.

Heureusement, je pense que le grand-écart va être de meilleure facture avec IE9 car les DSI ont appris de leurs erreurs également et s'intéressent beaucoup plus à des développements suivant les standards. C'est ce que nous poussons en tout cas en rendez-vous clients dans les nouveaux projets ou les projets de migration.

Les chemins de migration devrait donc être bien plus simples entre IE9 et les versions suivantes d'IE.

Maintenant que les problèmes des DSI ne soient pas votre affaire, je le comprends mais eux, de leur côté, les longs temps d'intégration dus à IE6/IE7 sur le web public, ce n'est pas leur affaire non plus. ;-)

ie restera ie c'est tout...
On peut au moins leur attribuer le fait d'avoir réagis assez rapidement à la concurrence (Chrome10, firefox4...) et d'avoir une réel intention que ses utilisateurs surf sur un navigateurs moderne et abandonne leur vielle version d'ie.

@davrous : J'ai effectué les tests avec la version 64 bits d'IE9 puisque c'était celle proposée en téléchargement. Je me suis donc mis dans la peau d'un utilisateur lambda qui tournerait sous Windows 7 64, ce qui me semble être un cas classique.
S'il faut leur expliquer que dans la situation présente, malgré leur OS 64 bits il faut télécharger IE9 32 pour obtenir de meilleures performances, alors pourquoi ne pas diffuser qu'une seule version ? (Oui un brin de mauvaise foi, mais dans le fond, je m'interroge tout de même) Cependant, je vais effectuer des tests avec la version 32 bits (si je parviens à désinstaller le tout "proprement").

@dew: non, ce n'est pas IE9 64 bits qui est proposé en téléchargement mais un package IE9 pour les plateformes Windows Vista/7 64 bits. Une fois le package 64 bits installé, dedans, il y a ensuite 2 versions d'IE9 : la 32 bits qui est celle lancée par défaut lorsque l'on click sur le "E" et il y a une version 64 bits cachée quelque part qui n'est pas exposée à l'utilisateur par défaut. L'utilisateur lamdba ne lancera donc probablement jamais la version 64 bits.

Donc il ne faut pas télécharger une version 32 bits. Il suffit de télécharger le package qui correspond à sa plateforme et d'utiliser IE par défaut, c'est tout.

Cela fonctionne ainsi depuis que nous avons des plateformes 64 bits, je ne comprends pourquoi soudainement c'est plus compliqué avec IE9. Mais si nous ne sommes pas clairs, je suis preneur des retours.

@davrous : Dans ce cas-là il faut faire une version "pro" de IE et une version grand public.

Que vous le vouliez ou non votre navigateur est le plus utilisé du marché pour l'instant et le manque de réactivité d'IE par rapport à ses concurrents ralenti le web tout entier.

Enfin, je ne comprends qu'à moitié pourquoi ces fameuses DSI ne peuvent pas s'adapter comme le font Google, Facebook ou n'importe quel autre mastodonte du web qui y arrivent très bien avec pourtant un grand désavantage par rapport aux DSI : ce ne sont pas eux qui disent aux utilisateurs quand mettre à jour leur navigateur et surtout lequel utiliser.

hey Skoua,

Allez, pour une fois je me fait l'avocat du diable : un intégrateur qui défend (un tout petit peu) IE, c'est si rare :)

« Très franchement je n'ai rien contre MS ou IE, ou du moins je n'avais rien contre vous jusqu'à ce que je me mette à intégrer des sites. IE6 m'a fait perdre des centaines d'heures comme à tous les autres intégrateurs web de la planète »

Bah tant que le temps perdu pour la compatibilité IE6 est devisé rubis sur l'ongle, moi perso ça me pose pas vraiment de problème :P …et puis si tu fais de l'intégration, j'imagine que tu connais les concepts d'amélioration progressive/dégradation élégante :)

Concernant le rôle des DSI, faut aussi être un peu compréhensif : une appli intranet utilisée par des centaines (voir bien plus) de postes et optimisée (à l'époque) pour IE6 (après la guerre des navigateurs, c'était le standard, bien plus que les normes W3C) ne se refait pas comme ça tous les 5 ans…

@audrasjb : Pour le temps dévisé, perso je préfère le passer sur un autre projet. :p

Et pour les DSI, je pense qu'ils devraient utiliser IE pour leur intranet et laisser les employés utiliser le navigateur qui leur chante pour le reste, dans l'idéal.

@davrous : sur websocket : la faille en question ne remet pas en cause tout code déjà écrit, car l'API ne va pas bouger, c'est le protocole sous-jacent qui doit être patché.

@DAVROUS : "j'ai plutôt l'impression de mon côté que nous sommes plus responsables. "

Il ne faudrait pas non plus nous prendre pour des grosses tanches.
Ça fait des années que vous pourrissez le web avec vos navigateurs en mousse alors ne venez pas maintenant faire les malins. Vous devriez plutôt faire preuve d'humilité en nous expliquant combien la politique de MS a été (est?) pernicieuse, au mépris des utilisateurs et travailleurs du web.

Oui mon avis n'est pas contrasté et très lapidaire; on me dit que les équipes de développement comprenaient et comprennent des gens très talentueux, je n'en doute pas, mais le talent au service d'une guerre économique aussi inutile que néfaste n'est rien. Personnellement, j'aurais démissionné...

@dew : Hello Dew. Alors tu as réussi à vraiment te mettre dans la peau d'un utilisateur Lambda (c'est à dire lancer la version 32 bits proposée par défaut)? Je serais curieux du nouveau résultat au test sunspider dans les conditions de "monsieur tout le monde" (et pas en faisant exprès d'aller chercher la version 64 bits). Je pense qu'il serait plus honnête ensuite de publier le résultat en 32 bits également.

Pour rappel, sur une plateforme 64 bits, c'est la version 32 bits d'IE9 (IE8 c'était pareil) qui est bien lancée par défaut. La version 64 bits est cachée quelque part et quasiment jamais utilisée car aucun plug-ins n'est supporté aujourd'hui pour cette version (Flash en cours et Silverlight arrive aussi mais ils ne sont pas encore là). Alors pourquoi livrer une version 64 bits cachée quelque part? Car certaines applications qui tournent sous Windows s'appuient sur certains modules d'IE. Donc une application natives 64 bits a besoin des modules 64 bits d'IE.

Cela fait des années que cela fonctionne comme ça avec IE en 64 bits. C'est quand même bizarre que le jour où une version d'IE devient 1er au test sunspider, beaucoup s'amusent à aller chercher une version moins rapide (64 bits) car moins optimisée pour indiquer le contraire... Enfin, bref.

Pour ceux que cela intéresse, toutes les infos sur nos choix 32/64 bits sont ici : http://blogs.msdn.com/b/ieinternals/archive/2...

Bye,

David

La seule conclusion de ce débat, quelque semaines après, c'est que l'on peut plaindre les utilisateurs lambdas pour le coup (c'est toujours eux qui se prennent tout dans la tronche :( )