Alors que Windows Blue commence à se dévoiler grâce à la fuite d’une préversion, Internet Explorer 11 en fait de même. Blue intègrera bien la prochaine mouture du navigateur, soulignant pour la première fois un espace d’un an seulement entre deux versions majeures du navigateur.
Internet Explorer 11 sera le navigateur de Windows Blue. Peu d’éléments ont filtré à ce jour, notamment parce qu’il ne s’agit que d’une préversion.
Comme le montre la capture cependant, on sait déjà que le prochain navigateur proposera la synchronisation des onglets. Il s’agit d’une fonctionnalité très pratique qui permet de retrouver les onglets ouverts depuis une autre machine. Une possibilité que l’on retrouve déjà dans Chrome et Safari. Pour ce dernier, la fonctionnalité est même présente sur les versions fixe et mobile, et Microsoft pourrait tout à fait le proposer sous Windows Phone 8. D’autant que Blue concerne autant Windows 8 que le système mobile. Comme les autres fonctionnalités synchronisées, c’est certainement le compte Microsoft qui servira de liaison.
Plus surprenant, l’agent d’identification d’Internet Explorer 11 a été modifié. Ainsi, la mention « MSIE » n’est plus à l’ordre du jour, Microsoft identifiant son navigateur avec « IE ». Une modification conçue pour casser les fameux hacks CSS mis en place pour d’anciennes versions du navigateur et dont la firme souhaite se débarrasser. Mais pour aller plus loin, Microsoft ajoute carrément une mention « like Gecko » pour être reconnu... comme un Firefox.
Il s’agit de deux mesures drastiques pour en finir avec les codages spéciaux mis en place pour les versions 6, 7 et 8 du navigateur. La mouture 9 avait fait un bond en avant sur le support des technologies, mais son absence sur Windows XP ne lui avait pas permis de devenir réellement majoritaire. Même problème désormais avec Internet Explorer 10 qui n’est ni sur XP, ni même sur Vista. Mais Microsoft ne souhaite visiblement plus être pénalisé par son User Agent sur des sites qui se contenteraient du minimum pour Internet Explorer, tout en s’affichant normalement sur Chrome et Firefox.
Nul doute que Mozilla ne doit pas être mécontent de cette modification.
Commentaires (134)
#1
C’est cool, ils veulent se faire passer pour un navigateur qu’ils ne peuvent égaler jusque là au niveau de l’implémentation des standards. A voir ce que ça donne sur le terrain, mais si on différencie encore IE sur certains points c’est peut-être pas pour rien…
" />
Qu’ils se mettent à ajouter régulièrement les nouveautés des langages dans leur navigateur et on verra ensuite, plutôt que de devoir attendre plusieurs années que les gens fassent des màj.
[Et ne me dites pas que des màjs régulières bloqueraient les intranets des entreprises, ceux-ci tournent encore sur du IE6-7, à la limite 8, donc des màjs régulières à partir de 10-11 ne bloquerait pas.]
#2
Il s’agit d’une fonctionnalité très pratique qui permet de retrouver les onglets ouverts depuis une autre machine. Une possibilité que l’on retrouve déjà dans Chrome et Safari. Pour ce dernier, la fonctionnalité est même présente sur les versions fixe et mobile
La synchro des onglets sur mobile est dispo chez Chrome et Firefox depuis longtemps.
#3
Opera également.
#4
#5
Je ne vois pas ce qu’il y a d’étonant. Historiquement ce n’est pas la première fois l’UA d’IE contient déjà Mozilla depuis l’époque de Netscape.
#6
Il s’agit de deux mesures drastiques pour en finir avec les codages spéciaux mis en place pour les versions 6, 7 et 8 du navigateur.
Pourtant ils (les 7 et 8) ont été présenté à leur sortie comme des bons navigateurs, ne nécessitant plus ces fameux hacks pour avoir un résultat normal…
#7
J’espère qu’il n’y aura plus les modes de compatibilité et mode de document…
#8
#9
#10
ils ont du se dire: tiens on est passe d’une sortie tout les 3 ans a tous les ans, le moteur de rendu commence a être pas mal, les performances sont bonnes… Oh mince mais attends on va avoir de bon retours de des dev web, faut trouver une idée a la con pour leurs faire perdre du temps et les emmerder.
" />
#11
dire qu’il fallait pendant longtemps faire passer firefox pour internet explorer afin de ne pas avoir de message du type :
“Ce site web a été optimisé pour internet explorer, merci d’aller vous faire foutre si vous venez de firefox.”.
#12
#13
#14
on va arriver avec 100% de Mozilla dans les stats sur les sites avec ça
#15
#16
#17
Pas cool : Comment on va pouvoir identifier les utilisateurs de IE pour les envoyer bouler et leur dire d’installer un vrai navigateur s’ils avancent masqués ?
" />
#18
#19
Un article intéressant sur l’histoire des User-Agents
http://lehollandaisvolant.net/index.php?d=2013/03/10/12/53/35-lhistoire-des-user-agents
Ça a toujours été un joyeux bordel !
#20
Faisant du dèvs web, on a plus de souci avec FF que les IE actuels en attendant …
C’est ce que j’allais dire et pourtant je fais pas essentiellement du Dev web…
Après toujours rien de comparable avec les écarts entre IE6/7 et le reste du monde cela dit :)
Enfin, tout ça ça reste dût aux implémentations perso des fameux STANDARDS du web de chaque moteur de rendu. Au final pour les transformations CSS … bah c’est IE9+ qui les implémentent de la façon la plus standard (si si les -moz;machin et -webkit:blabla x) )
Après j’suis pas un pro du web non plus. Mais beaucoup de sites optimisent leur taf pour Chrome et FF … et se font chier avec les vieilles versions de IE plutôt que de suivre les standards.
#21
#22
#23
#24
#25
Quand à l’école un gamin prétend s’appeler d’un autre nom que le sien, c’est souvent parce qu’il a honte de sa propre famille.
" />
#26
#27
#28
#29
Le plus marrant maintenant c’est qu’on se fait envoyer bouler de chez Microsoft quand on veut activer les mises à jour Microsoft Update (pour Windows et les autres produits Microsoft) parce que l’on utilise pas IE 5 et supérieur…
Preuve
Bon c’est une M1, on pardonne ;-)
#30
Mais ça va être comique d’aller sur ce site maintenant :http://jvachez.free.fr/
(comment ça ça l’était déjà ?)
#31
#32
Si les codeurs se basaient sur le test les fonctionnalités supportées plutôt que sur le user agent, ça éviterait ce genre de soucis à la con …
Ceci étant, ce WE, j’ai joué avec du CSS récupéré sur un site, avec des animations.
J’ai supprimés tous les CSS du genre -moz- et -webkit-
et au final, le code que j’ai fonctionne de façon identique sur IE10 et FF19 …
Y’a pas à dire, IE10 a franchement bien rattrapé son retard.
#33
#34
#35
C’est une bonne nouvelle, juste le dernier symbole de la victoire des standards sur le “Web selon Microsoft”, propriétaire et verrouillé de licences et brevets qu’ils voulaient nous imposer quand Mozilla a sortit Firefox en 2004.
" />
" />
donc
#36
#37
#38
#39
#40
#41
#42
Le 9 est une refonte déjà beaucoup plus complète et nettement plus potable (j’irai pas jusqu’à dire que c’est un “bon” navigateur, mais je ne hurle plus quand je le vois sur un PC).
Heureusement que tu moderes…
IE 9 est un bon navigateur.
Ensuite, je ne suis pas sur que mettre à jour son navigateur 10 fois par an en ajoutant des versions Draft de langages juste pour essayer d’imposer sa propre version des standards soit un signe de maturité !
#43
#44
#45
#46
#47
#48
#49
#50
#51
#52
Ça me fait penser a un ami qui vient chez moi et veux utiliser internet, il se met directement sur chrome et au bout d’un petit moment finit par passer sur Ie10, et à ce moment-là j’entent mais putain ton internet exploreur est plus rapide que ton chrome …
#53
#54
#55
#56
Y’en a qui ferrait bien de faire un tour ici :
Comparison of layout engines (Cascading Style Sheets)
Comparison of layout engines (HTML5)
Je sais que les parties Gecko sont à jour (c’est moi qui les mets à jour, un peu webkit aussi, même si c’est plus le suivi W3C qui m’intéresse)
#57
#58
#59
#60
#61
#62
#63
#64
#65
#66
#67
#68
Ça serait tellement plus simple si les webmasters savaient coder un site conforme aux standards du web…
#69
#70
#71
#72
#73
#74
seb2411>+1
Fuinril>Oui, je grossis le trait pour aider les myopes à mieux voir (d’où ma remarque sur le coté trollesque).
#75
#76
#77
#78
La dernière version de jQuery a viré l’objet browser pour que les gens arrêtent de tester le navigateur au lieu de tester l’existence des fonctions, donc peu à peu les gens vont arrêter cette façon de faire…
#79
La plupart des développeurs qi codent encore avec ce type de hacks n’ont pas du sortir de chez eux depuis longtemps car depuis IE9 et 10 le support des standards des CSS est plutôt bon…
Faudrait qu’ils mettent à jour leur repertoire d’idées reçues…
On pourrait presque trouver un problème inverse maintenant : comment rattraper la mauvaise habitude des ces développeurs qui rajoutent plein de lignes de propriétés non standard pour faire des effet whoua sur Webkit…
J’ai l’impression qu’on est revenu 10 ans en arrière et que dans 5 ans, au lieu de se foutre de la gueule comme avant des webdesigner qui codait leur pages avec des tables, on va se moquer des développeurs qui codent tout en CSS dédiées uniquement à tel ou tel navigateur…
#80
En attendant, la méthode JS postMessage qui permet de la communication entre pages/onglets/frames ne fonctionne pas sur IE comme sur tous les autres navigateurs…
Impossible de faire un appel entre une Popup et une la page qui a ouvert la popup sous IE, obligé de faire une fonction transversale juste pour IE.
Donc merci MS pour les problèmes…
Plus d’infos :http://javascript.info/tutorial/cross-window-messaging-with-postmessage#nifty-de…
#81
#82
#83
#84
J’suis pas sûr d’avoir tout compris : on n’aura plus besoin de hack css, ou on en aura encore besoin, mais on pourra plus le faire ?
#85
#86
#87
#88
#89
Est-ce que cela signifie que FF est devenu la référence, même pour MS qui n’arriverait pas à contrer les hacks et est contraint d’avancer masqué ?
" />
Un aveu de faiblesse, là !
#90
#91
#92
#93
D’un côté, on a gueulé pendant des années sur IE7 et ses balises proprio qui ne respectaient pas la norme, et de l’autre côté, on voudrait pouvoir utiliser des trucs pas encore finalisés, mais proposés par FF/Webkit en mode dev, en criant sur IE qui ne les supporte pas …
" />
#94
#95
#96
#97
Non mais cela a meme gueulé sur des balises proprios qui respectaient la norme (voir les news concernant le système permettant d’épingler un site web dans la barre des taches).
sauf que ce type de fonction ne gêne en rien le rendu d’une page web pour les navigateurs qui ne les supportent pas.
rien à voir avec les sites qui utilisent des propriétés css critiques pour le layout d’une page uniquement dans leurs versions prefixées -moz et -webkit, et dont le rendu casse sous IE qui ne supporte “que” les versions standard non préfixées.
#98
Les putois qui gueulent à tout va que IE9 ne supporte même pas WebSocket devraient se remémorer ceci:
http://www.pcinpact.com/news/60786-html5-websocket-mozilla-opera-arret-support.h…
heureusement que MS n’a pas supporté ce brouillon tel qu’il était à l’époque de la sortie d’ IE9.
#99
#100
Sauf que HTML 5 ou CSS3 apportent des solution et Active X des problèmes
Ca n’a jamais bien fonctionne et a part donner des sueurs froides pour la sécurité et le fonctionnement, compliquer la vie des utilisateurs et des devs et n’être pas multi-plateforme on peut pas dire que ce fut un grand pas en avant.
je pense qu’il faisait allusion à xmlhttprequest, introduit sous ie5.5 sous la forme d’un objet activex préinstallé dans IE (aucun risque de sécurité, ce n’est pas comme si c’était l’utilisateur qui devait installer un plugin provenant d’une source inconnue).
et pour les autres navigateurs, il aurait été facile d’assurer la compatibilité en reconnaissant la syntaxe d’instanciation de xmlhttprequest spécifique à IE, mais sans avoir à gérer activex évidemment.
après les trolls ont gueulé parce que IE6 ne supportait pas l’instanciation de xmlhttprequest de la même façon que les autres navigateurs, alors que ce standard est dérivé de l’implémentation propriétaire de Microsoft.
#101
#102
2010, t’as pas plus vieux.
Flash et Java sont des passoires, ça n’empêche rien non plus
décembre 2010, ca correspond à la phase où IE9 était déjà feature complete, et prêt à passer en RC.
je te rappelle que la faille en question était bien plus problématique qu’une faille classique affectant un logiciel sur un poste de travail.
cette faille était de nature à exposer à des risques des machines autres que celles où le logiciel était installé (empoisonnement de cache).
citer flash et java est complètement hors sujet.
au passage, Flash a nettement moins de failles que webkit par exemple, malgré le fait que ce soit des environnement d’une complexité similaire (flash comprend même d’avantage de fonctionnalités que webkit seul)
même vupen (société spécialisée dans la recherche et revente de failles dans les navigateurs) a déclaré que le point faible de chrome était webkit (à cause du nombre de failles), et qu’ adobe n’est pas si mauvais qu’on peut le croire.
#103
#104
#105
#106
#107
Quand une des fonctions est standardisée, Mozilla remplace l’API par la version standardisée immédiatement,
non c’est faux.
Mozilla et webkit continuent à supporter les versions prefixees en parallèle.
du coup tant que ca marche, les webmasters continuent à les utiliser, au détriment d’IE qui respecte uniquement le standard finalisé non préfixé.
même problème sur les sites mobiles où le préfixe -webkit est massivement utilisé, ce qui va obliger Microsoft à le supporter dans ie mobile.
la vrai solution serait que Mozilla et webkit retirent le support des versions prefixees lorsque la version non préfixée devient supportée.
mais évidemment du jour au lendemain tous les sites codés avec les pieds cesseraient de fonctionner sur ces navigateurs…
ce n’est donc pas dans l’intérêt de Google et Mozilla d’épurer le web de leurs préfixes proprios.
encore une fois contrairement à MS, qui s’est explicitement et publiquement battu pour tenter d’imposer SON API Web en concurrence avec celle du w3c.
n’importe quoi. Le gars qui réécrit l’histoire a sa sauce.
bon nombre de fonctionnalités “proprio” d’IE5.X ont été naturellement adoptées par les autres navigateurs sous forme modifiée, puis standardisées 10 ans plus tard dans html5 (contenteditable, innerhtml, xmlhttprequest, …)
même svg est un dérivé de VML que MS avait tenté de soumettre au w3c fin 90, bien avant l’existence de SVG.
Ironiquement, les trolls qui réécrivent l’histoire voient ça autrement : “MS a tenté d’imposer sa techno proprio à la place d’un standard existant”
#108
#109
#110
Donc si quelqu’un sort un truc 10x mieux que W3C , il pourra rien faire puisque W3C est la norme.
bon j’avoue je chipote complétement …
c’est ce qu’a fait MS dans les années 90 avec IE5.
beaucoup de fonctionnalités propriétaires étaient beaucoup plus avancées que tout ce qui était standardisé par le w3c:
VML (bien avant svg)
transparence alpha , gradient, transitions animees
Ajax (xmlhttprequest)
support des fonts css
contenteditable, innerHTML
les webmasters ont adoré ça à l’époque, jusqu’au jour où ils ont commencé à détester…
#111
#112
A la base l’article traite de IE11 et le fait qu’il puisse être identifier comme firefox.
" />
Les anciennes versions de IE, faut les laisser là où elles sont.
Reste à savoir ce qui est le plus important entre le degré d’équivalence sur la prise en charge des standard entre IE11 et FF, ou le degré de prise en charge des standard tout court de IE11.
#113
#114
#115
#116
#117
Des infos sur l’ajout de WebGl pour IE 11 ?
" />
Paske ca fait quand même un bout de temps que tout le monde s’y est mis (ou presque), ils vont finir par être vraiment à la traine.
… à moins qu’ils préparent un WebDirect3D
#118
Des infos sur l’ajout de WebGl pour IE 11 ?
Paske ca fait quand même un bout de temps que tout le monde s’y est mis (ou presque), ils vont finir par être vraiment à la traine.
… à moins qu’ils préparent un WebDirect3D
webGL n’est pas un standard w3c.
et ce n’est franchement pas une bonne idée sur les mobiles. Apple l’a implémenté uniquement pour sa régie de pub. Peut être redoutent ils les risques de jailbreak via un simple site web, à cause des problèmes inhérents à laisser n’importe qui exécuter des shaders via des drivers gpu tournant en mode kernel.
et vu la tendance à remplacer les applis web par des applis natives, ce n’est pas dans leur intérêt de supporter webgl dans safari (sans oublier le coup porté à l’autonomie si tout le monde en abuse comme Flash)
MS refuse de l’implémenter à cause des risques de sécurité. Même dans Silverlight 5.x ils ont désactivé XNA par défaut pour éviter de soumettre les utilisateurs de Silverlight aux même risques de sécurité potentiels que les navigateurs supportant WebGL.
#119
#120
Bah au final c’et plutôt normal si leur navigateur marche un peu mieux qu’ils veuillent se débarrasser des hack pourris de l’époque.
" />
Les 6,7 et 8 sont tout les trois a jeter, le 9 marche a peu près correctement a deux/trois détails près, j’ai pas testé le 10 mais si ça s’est amélioré depuis le 9, le 11 devrais être potable.
#121
#122
#123
#124
#125
#126
#127
#128
J’ai plutôt l’impression que c’est un prétexte de Microsoft pour freiner OpenGL indirectement.
Mais j’aimerais bien qu’on m’explique en quoi WebGL n’est pas assez sécurisé par rapport à ce qu’il est possible de faire actuellement en web (question sérieuse).
http://www.pcinpact.com/news/64165-microsoft-apple-webgl-danger-securite.htm
le but n’est pas de se braquer contre OpenGL, puisque MS peut tres bien faire une implementation de webgl qui exploite direct3d.
#129
La communauté a gueulé (à raison) justement parce que Microsoft voulait tout faire dans son coin à sa sauce sans s’occuper des autres. Certes xmlhttprequest existait sous forme de contrôle activeX mais non seulement l’instanciation mais, et surtout, l’implémentation était différente, avec des préoccupations de sécurité qui n’étaient pas les mêmes (intégration avec l’OS, comme tous les activeX)
“la communauté” s’est reveillée un peu tard… Des années après l’apparition de ces fonctionnalités dans IE5! Elle espérait quoi? Que Microsoft retire des fonctionnalités d’IE 5 et 6 dans une maj WU et casse la compatibilité du jour au lendemain? Complément ridicule.
quant à l’instanciation de xmlhttprequest, tu n’a pas compris ce que j’expliquais
nul besoin de gérer les contrôles activex pour créer un navigateur alternatif qui comprenne la syntaxe d’instanciation de xmlhttprequest d’IE, et qui instancie un objet interne au navigateur, comme c’est le cas actuellement.
#130
Perso, j’ai pas grand chose à reprocher à IE9 si ce n’est ses régressions sur les tableaux. (Pas les tableaux pour faire la mise en page, les tableaux pour faire des tableaux de données.) Je ne comptes même plus le nombre d’anomalies rencontrées dessus alors qu’elles ne sont pas présentes sous IE8
es tu sûr que ces anomalies ne sont pas en réalité un comportement d’avantage conforme aux standards?
car si on va par là, le comportement d’IE6 est souvent plus pratique que celui défini dans les standards (ex: conteneur qui s’adapte à la taille de l’élément enfant si celui ci dépasse).
#131
#132
#133
#134
Ouah, le niveau des commentaires. Je vois qu’à PC INpact, le niveau est toujours aussi élevé ; on n’a pas affaire au café du commerce, les INpactiens savent de quoi ils parlent. N’étant pas développeur WEB, je me garderais bien de ramener ma fraise sur un terrain technique que je ne maîtrise pas. J’apprécie seulement à sa juste valeur le retournement qui a fait passer du “site Internet développé pour IE6 et si c’est moche chez vous avec votre browser en freeware, utilisez IE” au “Je suis IE11 mais mes parents ont été si mauvais que j’ai honte de mon nom et je me fais passer pour Gecko ou Webkit”. JE biche aussi Webkit qui, il y a quelques années, était évoqué avec au mieux un sourire condescendant quand on disait “Konqueror / KDE / Linux” et qui maintenant motorise Chrome et Safari…