IE8 et le super standard mode
Le
Laurent vilday
Bonjour,
[1] Le mois dernier (19/12/07) Dean Hachamovitch nous annonçait que IE8
passait le test Acid2.
<http://blogs.msdn.com/ie/archive/20...e.aspx>
<http://www.webstandards.org/files/a...t.html>
[2] Tandis que cette semaine (21/01/08) Chris Wilson a annoncé sur le
IEBlog l'apparition du nouveau mode de rendu le "super standard mode" de
IE8.
<http://blogs.msdn.com/ie/archive/20...8.aspx>
<http://alistapart.com/articles/beyonddoctype>
<http://www.quirksmode.org/blog/arch...g.html>
Voila pour les faits, c'est fait :)
Pour le passage du test Acid2 (cf [1]) j'en suis plutôt ravi.
Par contre concernant la nouvelle balise meta (ou entête serveur) (cf
[2]) pour passer en mode "super standard" j'ai beaucoup plus de réserves.
<meta http-equiv="X-UA-Compatible" content="IE=8">
Surtout quand je vois sur A List Apart cette horreur :
<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4">
Un débat houleux gronde actuellement suite à cette annonce du mode
"super standard" (cf [1] et [2]).
Outre le fait que contrairement à ce qui est dit, IE8 ne passera
toujours pas le test Acid2 puisque la balise méta n'existe pas dans la
page de test et que par défaut IE8 utilise le moteur de rendu de IE7.
J'ai très peur d'une chose c'est de la multiplication des "render
engines" à gérer qui me semble loin de l'idée du web que je me fait. Non
pas que ce soit fastidieux, une ligne à changer dans les templates des
sites ou une ligne pour envoyer le bon entête et c'est fait.
Mais, IMO, sous prétexte de ne pas casser le web, Microsoft refuse de le
faire avancer. Puisque ça donne une justification pour continuer à faire
du code bas de gamme (avec comme dénominateur commun IE6) aux
intégrateurs HTML qui refusent d'apprendre correctement les "langages"
HTML/CSS qu'ils utilisent.
Et vous, qu'en pensez-vous ?
--
laurent
[1] Le mois dernier (19/12/07) Dean Hachamovitch nous annonçait que IE8
passait le test Acid2.
<http://blogs.msdn.com/ie/archive/20...e.aspx>
<http://www.webstandards.org/files/a...t.html>
[2] Tandis que cette semaine (21/01/08) Chris Wilson a annoncé sur le
IEBlog l'apparition du nouveau mode de rendu le "super standard mode" de
IE8.
<http://blogs.msdn.com/ie/archive/20...8.aspx>
<http://alistapart.com/articles/beyonddoctype>
<http://www.quirksmode.org/blog/arch...g.html>
Voila pour les faits, c'est fait :)
Pour le passage du test Acid2 (cf [1]) j'en suis plutôt ravi.
Par contre concernant la nouvelle balise meta (ou entête serveur) (cf
[2]) pour passer en mode "super standard" j'ai beaucoup plus de réserves.
<meta http-equiv="X-UA-Compatible" content="IE=8">
Surtout quand je vois sur A List Apart cette horreur :
<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4">
Un débat houleux gronde actuellement suite à cette annonce du mode
"super standard" (cf [1] et [2]).
Outre le fait que contrairement à ce qui est dit, IE8 ne passera
toujours pas le test Acid2 puisque la balise méta n'existe pas dans la
page de test et que par défaut IE8 utilise le moteur de rendu de IE7.
J'ai très peur d'une chose c'est de la multiplication des "render
engines" à gérer qui me semble loin de l'idée du web que je me fait. Non
pas que ce soit fastidieux, une ligne à changer dans les templates des
sites ou une ligne pour envoyer le bon entête et c'est fait.
Mais, IMO, sous prétexte de ne pas casser le web, Microsoft refuse de le
faire avancer. Puisque ça donne une justification pour continuer à faire
du code bas de gamme (avec comme dénominateur commun IE6) aux
intégrateurs HTML qui refusent d'apprendre correctement les "langages"
HTML/CSS qu'ils utilisent.
Et vous, qu'en pensez-vous ?
--
laurent
Poser une question
(...)
A lire ce commentaire qui tempère de beaucoup le débat :
"HTML5 DOCTYPE"
http://ejohn.org/blog/html5-doctype/
Je ne me suis pas encore assez documenté sur le sujet... et je reste
étonné qu'il faille un switch entre le mode de rendu de IE7 et IE8 ! Car
autant IE6 était buggé pour des choses CSS assez basiques et même en
mode de rendu strict, autant IE7 avait apporté quand même du progrès je
crois là-dessus... Je ne m'imaginais pas que passer de IE7 et IE8
casserai autant de pages "standard" (doctype strict et code valide) ?
Je viens de lire ça.
Et pour l'instant j'en suis toujours à "oui mais pourquoi ce switch ?" :)
Ce que j'en comprends, c'est que toute page utilisant une DTD
"implémentée" à l'heure actuelle devra inclure le meta tag pour
permettre d'indiquer à IE8 d'utiliser tel ou tel autre de moteur de
rendu sinon par défaut IE8 se comportera comme IE7. Tandis que toute DTD
future/inconnue (not widely deployed - par qui, par quoi, quand, etc ? -
) sera par défaut en "super standard mode" pour IE8.
Donc jusque là oui à condition que le "not widely deployed" soit plus
explicite.
Sinon c'est pas la peine si c'est pour m'inventer un nouveau <meta>
lorsque IE2015 sortira avec le nouveau "super uber standard mode"
permettant d'utiliser correctement HTML17 et CSS9 sans les bugs de
IE2010 qui avait inventé un "super quirks mode" pour garder la
compatibilité avec IE15 qui avait décidé d'interpréter CSS7 d'une façon
différente du reste du marché ...
Bref, ça me semble être un <meta> introduit pour permettre - enfin - de
faire bouger le web mais c'est en même temps le même frein pour le futur
que l'introduction du rendu quirks/strict.
Microsoft, part la voix de Chris Wilson, parle de "not breaking the web"
pour justifier ce <meta>
Et c'est là que je suis pas du tout d'accord, parce que c'est un
problème exclusif du web Microsoft, c'est pas le web dans sa globalité.
Si c'est pour que le web historique ne "casse" pas, le "besoin" evoqué
n'existe pas puisque c'est la même chose que de ne pas avoir la CSS. Le
rendu au pixel prêt n'est pas bon, mais le contenu est accessible.
Si c'est pour que le web Microsoft (intranet en grosse quantité)
développé exclusivement pour IE6 (et tant bien que mal mis à jour pour
IE7) ne "casse" pas, il existe plusieurs solutions plus ou moins chères.
C'est le prix à payer pour avoir accepté d'enfermer ses outils sur une
plateforme propriétaire (IE6).
Et c'est de ça, les outils intranets historiques développés que pour IE6
et pas ou peu mis à jour, je pense que Microsoft parle à travers le "not
breaking the web"
Mais le fond du problème, imo, c'est que Microsoft a pour objectif de
vendre des licences de son dernier OS à la mode, pas d'ouvrir les
marchés. Il lui faut donc une solution pour vendre son OS (avec IE
inclus) tout en conservant la compatibilité avec tout ce qui a été
développé pour IE6.
M'enfin je t'avoue que j'ai beau suivre ça d'assez prêt, j'ai du mal à
me faire une opinion tranchée sur le sujet. Pas encore le recul
nécessaire j'imagine. C'est d'ailleurs bien pour ça que j'ai posté ici :)
--
laurent
C'est ce que j'ai compris aussi...
Oui, ça parait logique : on ne va pas lancer sur le marché un navigateur
qui ne sait afficher quasiment aucune des pages de l'Internet !
Cependant, en mode de rendu strict il me semble que IE7 ne génère pas
bcp de bugs ? Et puis il y a les commentaires conditionnels...
C'est bien ce que je ne comprend pas : la "bascule" (adaptation des
hacks de contournement des bugs de rendu de IE 5 et 6 plus valables sur
IE7) entre IE6 et IE7 a normalement du être effectuée par les sites
voulus pour s'afficher en mode de rendu "standard". Je m'imagine qu'un
site qui s'affiche correctement en mode de rendu standard sur IE6 et IE7
devrait s'afficher très correctement aussi sur IE8 ??
Il y a sans doute des choses qui m'échappent, je manque malheureusement
de temps pour fouiller plus avant
En fait le problème n'est pas là, au sens de l'affreux enfermement
propriétaire de Microsoft (pour autant qu'on ait codé proprement son HTML),
c'est qu'IE6 fait quelques interprétations singulières des marges et ne
gérait pas le PNG transparent. Hors il n'est pas hors de porté d'un
webmestre moyen (j'y suis bien arrivé donc "ce qu'un âne sait faire, un
autre peut le faire") de faire que le rendu d'une page Web avec plein de
blocs et de marges se conporte pareillement avec les 3 navigateurs usuels
(sous Windows). Et ce sans une seule fois tester l'identité du navigateur
avec du Javascript ou autre. Quant au problème des PNG il suffisait
d'introduire un élément htc qui déboguait la balise img. Et ce n'est plus
nécessaire avec IE7.
Je dois dire que je m'enquiquine davantage avec Firefox qui veut, pour le
multimédia, son Quicktime alors qu'il a, en standard, le WMP de Windows qui
ne marche pas si mal en plugin Web (pour Windows). Aucun ennui de ce genre
avec Opera.
Cette histoire d'IE8 est, à mon avis, une espèce de compatibilité
descendante pour continuer à faire fonctionner d'immondes sites fabriqués
avec les pieds au temps du HTML 3.5. J'imagine Balmer soupirant dans son
yacht : "Si je ne fais pas un navigateur Web dans les règles de l'art, on
m'engueule et si j'en fait un qui ne veut plus des trucs mal écrits on
m'engueule aussi. Pourquoi tant de haine ?"
--
=================================== William Marie
Attention antiSpam remplacer trapellun.invalid
par free.fr
Web : http://wmarie.free.fr
http://www.pandemonium.dnsalias.org (site expérimental)
====================================
pour le png l'tilisation d'alphaloader (à la base des behavior) pose
quand même des problèmes ça va si on empile pas les images sinn on peut
perdre des événements.
sur le principe tout ajout aux "standards" est préjudiciable à la
compatibilté, s'agissant d'un méta c'est du hors lanage ce n'est pas
trop grave.
Par contre assurrer l'égalité de comportement à un moment donné de
navigateurs développes par des éqipes différentes esst une utopie. CSS
devrait intégrer des sélecteurs de moteur de rendu.