Le quotidien de l’intégrateur HTML est parfois ponctué de vide existentiel lorsqu’il s’agit de livrer des pages web compatibles avec la majorité des navigateurs dont la liste se divise grosso modo en deux groupes : ceux qui intègrent au mieux les standards recommandés par le W3C en matière de rendu CSS (Firefox, Safari, Opera et Konqueror, etc.) et les autres, principalement les versions 5 et 6 d’Internet Explorer.
Si le premier groupe nous donne satisfaction, il faut bien reconnaitre que le second reste scotché près du radiateur dès qu’on parle d’overflow, de min-height, de positionnement implicite avec right, bottom ou left ou encore d’interactivité avec :hover sur autre chose qu’une ancre a…
Bref, toutes ces petites choses très utiles au cours de l’intégration CSS qui manquent cruellement à Internet Explorer. Sans parler de la prise en charge inexistante de certains sélecteurs CSS qui seraient très pratique pour éviter de spécifier une classe chaque fois que l’on veut atteindre un élément en fonction de sa position dans le DOM.
Dans la suite de cet article nous verrons que la bibliothèque Javascript IE7 peut nous aider à travailler plus efficacement avec Internet Explorer pour faciliter la mise en œuvre de « composés » HTML / CSS cross-browser.
Est-ce vraiment nécessaire d’avoir un affichage identique quelque soit le navigateur ?
Dans le flux de production habituel, la production d’un site web passe par la conception d’une charte graphique dont il conviendra de découper et d’agencer les morceaux à coup de balises HTML et de déclarations CSS.
L’image servant de référence quasi-absolue, il devient très difficile de défendre auprès de son commanditaire le point de vue selon lequel la sacrosainte charte graphique puisse présenter des différences — même minimes — d’un navigateur à l’autre, fut-ce d’un pixel !
Pour parvenir à ses fins, l’intégrateur web dispose de deux armes : le code HTML qui — s’il suit une ligne sémantique de bon aloi — devrait garder la même structure d’un bout à l’autre du projet, et les CSS qui servent de variable d’ajustement jusqu’à la fin.
Reste à trouver une méthode de travail qui limite à la fois les différences de rendu et le nombre de lignes de code à produire :
- Les visionnaires conseillent de faire un site conforme aux standards en prenant un navigateur comme Firefox ou Opera comme référence pour le rendu CSS, et d’utiliser au maximum les possibilités offertes par…
- les sélecteurs CSS,
- la transparence PNG en 256 niveaux,
- le calcul des largeurs minimales et maximales,
- etc,
…puis de faire au mieux pour les navigateurs non conformes. Cette approche, pour intéressante qu’elle soit, n’est pas possible dans un contexte commercial car seule une poignée de visiteurs verrait le site web dans toute sa splendeur, tandis que la majorité n’en aurait qu’une version dégradée, fut-ce gracieusement…
- Les réalistes proposent de n’utiliser que les propriétés disponibles sur la majorité des plate-formes, en prenant pour chaque fonctionnalité, le plus petit dénominateur commun en fonction du projet.
Cette approche permet de concilier le respect des standards (même s’il ne s’agit pas des toutes dernières recommandations) avec un rendu uniforme des pages en contrepartie d’une éventuelle limitation des fantaisies graphiques souhaitées par le client.
En effet, selon la maquette, le fait de ne pas pouvoir utiliser la transparence PNG, par exemple, peut avoir une incidence sur la rigidité de la structure HTML / CSS à cause des découpes d’images : on sera enclin à réunir plusieurs partie d’image en une seule, alors qu’avec la gestion de la transparence, il est sera plus souvent possible de « granulariser » les découpes.
- Une troisième approche réalistico-visionnaire que l’on retrouve parfois sous l’acronyme MOSe (Mozilla, Opera, Safari enhancement) mélange les deux premières approches en cherchant le plus petit dénominateur commun pour assurer une large compatibilité, puis en introduisant des améliorations visibles uniquement dans les navigateurs modernes.
Cette dernière approche est celle qui offre une plus grande cohérence à vos pages web dans le temps, puisque qu’en suivant les recommandations au plus près, plus le temps passe et plus le souvenir des mauvais navigateurs s’estompe.
(Ceci est à rapprocher de l’annonce de la nouvelle balise meta mise en place à l’occasion de la sortie prochaine d’IE8 qui réintroduirait dans l’écosystème du web un pis-aller dont on commençait à peine à se débarrasser : la détection du navigateur pour savoir s’il doit basculer en mode standard ou non. Voir ma petite note sur le sujet.)
*IE7.js : ce n’est pas de la magie, c’est de la technologie ! »*
Ah oui en effet c’est plutôt plaisant cette histoire 🙂
Je l’utiliserai certainement également.
De ce que tu dis je suis plutôt visionnaire (j’ai envie de développer uniquement du conforme et d’envoyer chier le reste :p) mais en effet ce n’est pas toujours possible une fois hors projet perso, donc je fais au mieux avec IE6 mais c’est parfois assez lourd, notamment comme tu le mentionne sur les hover et la transparence PNG.
Bref j’aime bien IE7.js, pour le IE8 par contre j’attendrai encore un peu ‘déjà règler quelques soucis IE6 sera pas mal).
En tant que développeur front, je suis plutôt réservé quant à l’usage de ce genre de bibliothèque javascript.
A cela une raison toute simple : que font les utilisateurs ne disposant pas de javascript ou d’un support partiel ? Je pense notamment aux utilisateurs naviguant avec un navigateur texte, un navigateur ancien ou encore un lecteur d’écran. Ils se retrouvent face à un site qui ne tient plus debout, car reposant sur des correctifs d’une technologie qu’ils ne possèdent pas. Cela peut donc fortement nuire à l’accès à l’information contenu sur le site.
En un mot : contre. Mais cela n’engage que moi 😉
Sébastien si je peux me permettre et bien que je sois en partie d’accord avec toi je pense que l’accessibilité est plus une question de développement que de technologie.
Un site développé avec ces technos peut tout à faire « tenir debout » si des alternatives ont été prévues (javascript non intrusif, « dégradation gracieuse »…)
Perso, j’ai décidé de ne pas l’utiliser parce que ça me semble difficile de respecter ces règles avec cette librairie (bien que je rêve de pouvoir utiliser les sélecteurs CSS dans mes dev de tous les jours 😉 )
#Arkan {
Beaucoup utilise des hacks ou des scripts pour gérer la transparence du PNG et la plupart du temps, les sélecteurs qui manquent à IE6 sont simulés par du javascript maison ou par jQuery (c’est ce que j’utilise en général), ce qui peut nuire à l’accessibilité, alors que là, on garde la maitrise puisque tout ce passe dans la feuille de style CSS.
}
#Sébastien,
#Rhaze {
L’accessibilité ne risque absolument rien avec cette bibliothèque car je rappelle qu’il s’agit juste d’avoir la possibilité d’utiliser des sélecteurs et autre pseudo-classes mis à notre disposition par le W3C (comme si on codait pour les navigateurs standards) et de faire en sorte que ces sélecteurs soit compris par IE5/6 ou IE7 via un commentaire conditionnel.
Les navigateurs texte, oraux, anciens, etc. réagiront comme il le font d’habitude en ignorant ce qu’il ne peuvent pas comprendre.
Je crois qu’il y a beaucoup de travail pédagogique à refaire après ces dernières années où Javascript n’avait pas bonne presse 😉
}
Merci pour cet article très intéressant.
Je me pose juste une question :
Est ce qu’il peut y avoir des interférences entre cette librairie IE7.js et nos CSS Reset ?
#pixenjoy { à priori non, et pour m’en assurer j’ai mis IE8.js en place sur ce blog (qui utilise le reset CSS « Resetting » d’Eric Meyer et je note rien de spécial.
Concernant l’utisation du script, il ne semble pas fonctionner avec les feuilles de style externes, ce qui peut-être gênant.
Pour le moment je coupe la poire en deux en faisant un incluse php vers un fichier du genre « styles-avances.css.php » pour éviter de gérer des styles dans le head.
}
Sébastien >
Internet Explorer 6 est un vieux navigateur ( presque 7 ans ! ), complètement dépassé aujourd’hui. Malheureusement, les pages sont toujours conçues dans le souci d’une compatibilité avec IE6, et tous les navigateurs en sont pénalisés. Les sélecteurs CSS, pour ne prendre qu’un exemple, sont complètement sous-exploités.
Dans ce contexte, IE7.js me semble un compromis largement acceptable pour accompagner la fin de carrière de ce navigateur : ce « patch » permet à IE6, sous réserve que Javascript soit activé, d’afficher correctement des pages, utilisant pleinement les sélecteurs CSS 2.1 (datant de 2001), parfaitement valides et correctement interprétés par les autres navigateurs du marché.
Il faut juste s’assurer que la page reste visible et utilisable dans IE6 sans Javascript (on ne choisit pas toujours son navigateur). Voici une expérience intéressante, dans laquelle l’utilisateur ne peut naviguer sur un site car Javascript est désactivé dans le navigateur qu’il utilise : http://webyboom.canalblog.com/archives/2007/09/04/6095964.html .
Contrairement au cas cité, nous restons dans la modification de l’affichage : cela n’a rien à voir avec le fait d’utiliser par exemple un événement onclick sur un lien plutôt qu’un bouton submit pour valider un formulaire.
Tout ce qui arrivera aux utilisateurs d’IE6 sans Javascript sera un affichage dégradé. Le site restera tout à fait utilisable si l’on y prête attention, et il pourrait même être envisagé de masquer complètement les styles aux utilisateurs d’IE6 sans Javascript, dans le même esprit que l’utilisation de la règle @import dans le but de ne plus se soucier de la dégradation du style sur les navigateurs ayant un support limité de CSS.
Pour les navigateurs texte, les lecteurs d’écran et les navigateurs anciens, aucun problème : ce script ne s’applique qu’à IE6 en utilisant les commentaires conditionnels.
Concernant la mise à jour d’IE7.js, ma plus grosse attente (je ne l’ai jamais utilisé sur un projet) est le support des classes multiples par IE6, ce qui permettra enfin de pouvoir créer des structures souples basées sur la multiplicité des classes et de profiter pleinement de l’héritage des styles.
J’ai donc profité de cette mise à jour pour tester cette possibilité ( http://essais.pierrebertet.net/IE7/test1.htm ), mais IE7.js transforme les combinaisons de classes multiples en une classe unique créée, pour lui appliquer les styles. La priorité du sélecteur n’est donc pas préservée, et il faut prêter attention à l’ordre dans lequel les déclarations sont faites, ou alors « gonfler » artificiellement le poids du sélecteur.
Ce problème sera à priori réglé dans la prochaine mise à jour du script : http://code.google.com/p/ie7-js/issues/detail?id=9
Bruno >
Au sujet du reset CSS justement, comme le dit Eric Meyer : « /* remember to define focus styles! */ »
Un focus:0 est appliqué à tous les éléments de ce blog, y compris aux liens : il n’est donc plus possible de naviguer au clavier :/
#Pierre Bertet { Merci pour toutes ces précisions concernant le script et l’accessibilité, c’est exactement mon point de vue aussi, en mieux expliqué 😉
Concernant les classes multiples, je n’ai jamais remarqué de problèmes particuliers en utilisant par exemple div class= »class1 class2 class3″. A moins qu’il ne s’agisse d’autre chose.
C’est clair qu’il faut prendre se script avec des pincettes, mais je suis convaincu qu’il faut le tester et garder ce qui fonctionne, se serait-ce, comme tu le précise, « pour accompagner la fin de carrière de ce navigateur ».
Merci pour le rappel du :focus, c’est réparé ^_^v
}
Bruno Bichet >
Pour les classes multiples, je parle de leur sélecteur CSS, avec lequel
seule la dernière classe comptera pour IE6 :
.maclasse.monautreclasse{// IE6 comprend ".monautreclasse"
}
C’est bien réparé avec IE7.js, mais actuellement la priorité du
sélecteur n’est pas la même que sur les autres navigateurs.
Le sélecteur devrait avoir la priorité « classe + classe », ou 0020 selon ce mode de calcul, et elle n’est que « classe », soit 0010.
Désolé, j’ai tout cassé avec ma balise pre :/
Merci pour l’information, je vais de ce pas tester ça.
C’est clair que ce serait plus pratique de faire une correction ‘à la source’ plutot que des hacks dans tous les sens.
De plus quitte à mettre un Hack javascript pour les PNG, autant utiliser ce script qui devrait résoudre d’autres problèmes par la même occasion.
Excellente source d’informations ce site, je reviendrai 😉
Merci @seebz 🙂
Pour apporter quelques infos sur l’utilisation d’IE7, je suis en train de l’utiliser sur un projet et ça fonctionne plutôt bien. Je me contente pour l’instant d’inclure le fichier IE7.js qui permet à ie6 de se comporter comme ie7.
Bon, pour un début, je ne fais pas le kakou en faisant reposer sur le script des éléments-clés du design, mais ça apporte quand même un peu de confort, notamment sur les pseudo classes (:hover en particulier).
En tout cas, mis à part quelques pétouilles, j’ai fais le pari de tester le site uniquement sur FF et IE7 et de faire une session de rattrapage pour ie6 et j’ai eu la bonne surprise de n’avoir que peu de modifications à apporter au code.
tiens, une webapp qui permet de visualiser les différences entre IE6 et IE7 :
http://blog.sitxpress.com/index.php?2008/03/11/11-netrender-affichage-sous-ie55-ie6-ie7
@NetRender > Merci pour le lien qui se trouvait déjà caché dans la grosse grosse liste 🙂
Personnellement, j’utilise déjà JavaScript pour pallier à certains défauts de HTML et CSS dans le design, et en particulier si de telles astuces me permettent de gagner en performances de chargement en réduisant la quantité d’éléments externes chargés. Et si l’utilisateur n’a pas activé le JavaScript ? Euh… dans ce cas, il aura quelques imperfections ci-et-là, l’ensemble de la charte graphique reposant tout de même sur du HTML et CSS standard ou équivalent (la compatibilité ayant priorité sur la standardisation).
Maintenant, mieux vaut ne pas reposer sur le JavaScript pour garantir une bonne visualisation du design graphique. Néanmoins, pour le support d’anciens navigateurs peu compatibles, la tentation est importante, et j’aurais tendance à m’y adonner de plus en plus à l’avenir pour gagner du temps du développement et de cohérence entre navigateurs, d’autant que le JavaScript est de toutes façons de plus en plus présent sur des sites de plus en plus interactifs.
@Martin > C’est clair que se reposer sur du JS pour assurer les fondations d’un site n’est pas la meilleure idée du siècle… Pour la prise en compte des anciens navigateurs je pense que nous sommes globalement d’accord. Reste à déterminer ce qu’est un ancien navigateur 😀
Pour ma part, je fais confiance au script de Dean Edwards pour pallier les insuffisances d’IE6 que je considère déjà comme un vieux, même s’il est encore largement utilisé.
Evidemment, dans des cas spécifiques d’intranet patati patata… il faut revoir la copie et s’assurer que le site fonctionne aussi sans JS…
Mais bon, je crois qu’il faut être pragmatique et ne plus trop se poser des contraintes intenables en terme de « pureté » de codage : rien n’est moins pur que le développement web qui est le fruit illégitime d’une multitude de technologies toujours en développement :))
Le principe d’insérer ces codes javascript serait intéressant si cela fonctionnait.
Dans la pratique, j’ai testé le script ie8.js sur deux pages web et sur ces deux pages, la présentation est partie en vrac sous IE6 :
blocs se décalant dans tous les sens, images png qui disparaissent.
Pour les blocs qui se décalent, je pourrais sans doute solutionner le problème en écrivant une css spécifique à ie.
Pour les png en revanche, c’est plus compliqué :
si je supprime mon code javascript charger de corriger les problèmes de transparence sous IE6, les images png réapparaissent mais ne sont plus transparentes.
De fait j’ai des doutes sur l’utilité de ces scripts $crosoft : pour créer des pages simples, IE7/8.js me semblent n’avoir que peu d’intérêt, et pour créer des pages à la mise en page plus complexe, ça ne me semble pas très stable.