2005-11-15

Épanouissement compromis des technologies Web innovantes

Ajax par ci, Ajax par là, ça fait plusieurs mois qu'on ne rebat les oreilles avec ce truc. Mais le buzz a quand même un aspect positif, il permet de mettre en lumière un point qu'on pouvait ignorer. J'aurais bien voulu connaitre tout ça il y a quelques années quand je commençais à refaire du Web de façon sérieuse, ça m'aurait permis d'apporter des réponses élégantes à certains problèmes. Aujourd'hui, je sais de quoi il s'agit, ça m'ajoute une carte à mon jeu de solutions pour d'éventuels nouveaux problèmes.

D'ailleurs j'ai utilisé cette carte récemment. Vi vi, je suis en plein dans une application Web. C'est dans un cadre professionnel, j'ai en effet repris le travail depuis une semaine ^^ L'Ajax c'est pas pour suivre la mode, mais il m'a semblé parfaitement adapté pour ce qu'on m'a demandé de faire.

Alors Ajax, c'est plein de trucs sympathiques. Du XML, du Javascript (ou E4X pour faire branché : ECMAScript for XML), et mettre en ½uvre ces technologies avec Firefox est un vrai plaisir. On a la sensation d'utiliser quelque chose de moderne, qui fonctionne bien, et on profite de nombreux outils pour aider le développeur dans sa tâche.

Aujourd'hui cependant, j'ai eu comme objectif difficile de rendre mon application compatible avec IE. J'ai franchi un nouveau pas dans la fange IEesque en découvrant à quel point son moteur javascript+DOM est vieillot, et combien la non évolution du tout fait beaucoup de mal au Web. Cela pousse les développeurs à casser des solutions élégantes au profit de vieux hacks immondes, ou alors à stagner sur une technologie qui a pourtant bien évolué chez les concurrents. Je ne peux résister de vous faire part des points qui m'ont exaspérés. Attention, passage inintéressant pour certains, mais j'ai envie de laisser ça comme une note.

  • IE ne connait pas le type « const » pour déclarer une valeur constante. Ça peut être bien pratique, par exemple mes chaines de message : const k_strMessage = "plop"; On remplacera donc ça par des déclarations de variables classiques : var k_strMessage; Dommage.
  • IE n'utilise pas toujours de noms standardisés. Je pense à « attachEvent » au lieu de « addEventListener ».
  • le DOM d'IE est loufoque, on ne retrouve pas une hiérarchie bien définie. Ainsi, tous les éléments sont de type « Object ». J'ai dû retirer mon extension à la classe Node, façon : « Node.prototype.removeAllChildren = function ... ». Aha, mais pourquoi ne pas utiliser Object dans ce cas ?  : « Object.prototype.removeAllChildren ». Bah non, ça ne fonctionne pas, un « div » aura beau avoir le type « Object » dans IE, l'extension du prototype sera sans effet.
  • le fait que IE ne connaisse pas le vrai XHTML, délivré en application/xhtml+xml, implique son lot de problème : tous les noms des éléments se retrouvent en haut de casse au lieu d'être en bas de casse. J'ai dû changer toutes mes vérifications de type : « ASSERT(elem.nodeName == "input"); » qui sautaient les unes après les autres.
  • grâce à Ajax, je rapatrie un fichier XML à partir duquel j'enrichis mon document XHTML. Sous Firefox, on reste dans le monde du XML, par conséquent il m'est possible de récupérer un n½ud texte du fichier XML, de le cloner, et de l'accrocher directement à un n½ud XHTML. Sous IE, on est en HTML, et les n½uds texte XML et les n½uds texte HTML sont incompatibles. J'ai donc dû oublier la méthode cloneNode du DOM en faveur d'un code plus compliqué.
  • il y a un gros bug dans IE quand on souhaite créer dynamiquement des boutons radio. En (X)HTML, pour regrouper des boutons radios, on donne la même valeur à leur attribut « name ». Le code d'origine ressemblait à ça : « var input = document.createElement("input"); input.setAttribute("type", "radio"); input.setAttribute("name", "NomCommun"); ». Impossible de fixer l'attribut « name » sous IE, c'est un bug connu. Pour parvenir à ses fins, il convient (pour IE seulement) d'écrire ce truc affreux : « document.createElement("<input type=radio name=nomCommun>"); ».
  • les labels n'agissent pas sur l'élément input qui leur est associé quand ces labels sont créés dynamiquement. Quand le label est défini directement dans le HTML, ça passe. J'ai aussi remarqué que le label et l'input doivent obligatoirement être associés via l'attribut « for » du label : « <label for="Plop">blabla</label> <input id="Plop"/> ». Un label englobant ne fonctionnera pas sous IE : « <label>blabla<input /></label> ».
  • ça c'est sur la WishList : instancier l'objet XMLHttpRequest de la même façon que sous Gecko : « new XMLHttpRequest() » ; c'est quand même plus agréable à la lecture :)

Eh bien, ça fait une sacrée liste. Et c'est rempli de choses qu'on aurait pu voir gommées si le produit n'avait pas arrêté son évolution en 2001. Tout ce que j'espère c'est qu'IE7 améliorera tout ça. Et encore, de nombreux postes avec du IE6 ne pourront jamais évoluer (Windows 2000 ?). Reste à espérer que la transition vers des navigateurs plus modernes se poursuive...