Remplacement de contenu - Pourquoi éviter innerHTML ?

Bonjour,

Je me remet au développement d'un jeu par navigateur et la création d'une belle interface, pratique et ergonomique me pousse à me servir de Javascript (et Ajax).

Le problème du remplacement de contenu va bien sur se poser, c'est pourquoi je souhaite prendre les devants et vous demander pourquoi innerHTML est à éviter ?
Est-ce simplement parce qu'il n'est pas inclus dans les recommandations du W3C ou bien y à-t-il réellement des problèmes d'accessibilité ?

La méthode avec appendChild(), createNodeText() et compagnie sont tout de même moins pratiques à mettre en place.

J'aimerai aussi votre avis concernant une technique pour déployer l'interface de mon jeu selon que l'utilisateur utilise ou non Javascript.

Est-il conseillé de créer l'interface de base (en xHTML) et, à l'aide de l'événement onload, remplacer tout ce qui doit l'être par son équivalent Javascript ? Ça me permet de régler simplement les problèmes d'accessibilité.

J'espère que vous pourrez m'aider et vous en remercie d'avance,


Sephi-Chan

Bonjour.

Sephi-Chan a écrit :
Le problème du remplacement de contenu va bien sur se poser, c'est pourquoi je souhaite prendre les devants et vous demander pourquoi innerHTML est à éviter ?

Qui a dit que c'était à éviter ?

Sephi-Chan a écrit :
Est-il conseillé de créer l'interface de base (en xHTML) et, à l'aide de l'événement onload, remplacer tout ce qui doit l'être par son équivalent Javascript ? Ça me permet de régler simplement les problèmes d'accessibilité.

Rajouter ou remplacer via Javascript ce qui peut l'être c'est en effet la méthode appliquée en général.

J'ai lu que c'était une propriété à éviter sur ce même forum.

De plus, je cite le dernier ouvrage que j'ai acheté :

Javascript pour le Web 2.0 a écrit :

L'utilisation de l'attribut innerHTML sur un élément est particulièrement tentante, puisqu'elle évite de multiples appels à la méthode appendChild et autant de créations de nouveaux nœuds. Elle force cependant à construire des chaînes de caractères contenant un ensemble de balises ainsi que leurs propriétés (événements, styles, etc.) sous la forme de multiples concaténations de chaînes Or ces chaînes nuisent à la maintenabilité du code Javascript et peuvent conduire à des syntaxes HTML invalides. De plus, l'utilisation de cette méthode rompt la structuration définie dans les spécifications du DOM.

Comme je prends rarement pour argent comptant ce que je lis (même chez les auteurs les avis divergent), je prends généralement soin d'avoir plusieurs versions des faits. D'où ce post.


Sephi-Chan

Sephi-Chan a écrit :
J'ai lu que c'était une propriété à éviter sur ce même forum.

De plus, je cite le dernier ouvrage que j'ai acheté :


Comme je prends rarement pour argent comptant ce que je lis (même chez les auteurs les avis divergent), je prends généralement soin d'avoir plusieurs versions des faits. D'où ce post.


Sephi-Chan

Bravo à toi de faire attention à tous les détails.
Le innerHTML est à éviter quand il est question de dupliquer des nodes et tout autre manipulation, que seul le dom permet de faire facilement.

Je bosse pas mal d'appli (du début à la fin).
Je peux t'assurer que le innerHTML change la vie dans pleins de cas.
exemple, dans ma page je met le HTML comme je voudrais qu'il soit, les parties qui sont répétés (genre ligne de tableau, ligne d'une liste, affichage d'un truc répété X fois), je les templatise au sein même de la page :

<tr class="template" id="templatepourlignetableau"><td>%nom%</td><td>%truc%/<td></tr>

la classe "template" fait juste un simple "display:none". J'enleve cette classe au moment ou je duplique l'élément.

Un fois que j'ai récupéré mon élément de template via son id, j'injecte les données en faisant un simple replace du innerHTML:

var myNewLine = template.cloneNode(true);
myNewLine.innerHTML = myNewLine.innerHTML.replace("%nom%", data["nom"]);

Bien sur c'est une version simlpifiée, j'ai des fonctions d'injection et autres tralala.
Mais cette méthode est redoutable, car quand tu dois modifier le HTML, tu tapes juste dans la page HTML, pas besoin de taper dans le JS

Sephi-Chan a écrit :
Comme je prends rarement pour argent comptant ce que je lis (même chez les auteurs les avis divergent), je prends généralement soin d'avoir plusieurs versions des faits. D'où ce post.

Tu as tout à fait raison de comparer c'est la meilleur façon de s'informer.

Je n'ai pas les connaissances requises pour t'en dire plus donc attendons que Julien ou koala64 passent par ici ...

Édit : grillé.
Modifié par CNeo (01 Sep 2007 - 17:59)

Merci à vous pour ces réponses. La propriété innerHTML ne pose donc aucun problème d'accessibilité, elle sort juste de la normalisation du W3C.

Concernant le clonage de nœuds, je n'en ai jamais encore jamais utilisé. Dans quel cas cela peut servir ?


Sephi-Chan, désolé pour la dérive

En plus du coté trés pratique, le innerHTML, comme me la fait remarqué une fois Koala64, permet d'épargner le navigateur du visiteur en évitant une grosse appli js pour recréer tout les noeuds.
Il suffit, avec le language serveur, de generer un document text ou xml avec les balises, et innerHTML se chargerat de tout afficher d'un coup. On passe donc d'un script Ajax de plusieur dizaine d'octet à un petit script de quelques lignes.
Et c'est beaucoup plus rapide à développer également.

Il y a par contre quelques cas comme la création d'un liste ou d'un menu via ajax ou il est peut-être plus propre de charger un xml bien clean avec ta liste et de la construire avec js.

Pour ta question secondaire, comment construire ton jeux accessible sans js, je te conseil de tout simplement le construire d'abord sans js. Dans un premier temps tu vas avoir l'impression de perde du temps, mais ensuite tu vas t'apercevoir surtout quand ton site est un ligne que c'est un démarche super confortable. En effet ton site reste accessible si ton js bug au cour d'une mise à jour ou selon les naviguateurs ce qui est fréquent.

De plus tu peux utiliser les mêmes script post et get sur ton language serveur donc finalement tu perds peu de temps a développer les deux et tu gagne en robustesse. Cela te permet également d'isoler plus facilement le probléme quand il survient: en effet (si tu utilise return:false), si le script js bug et que tu n'as aucun réponse c'est que c'est le script serveur. Si le script bug est que tu as tout de même une bonne réponse au réchargement c'est le script.
ça parrait bête mais des fois on passe plus de temps à trouver le probléme qu'a le résoudre...
Un autre avantage c'est de pouvoir travailler en desactivant js et ainsi voir quand l'utilisation d'ajax est vraiment pertinente ou non.
Modifié par matmat (01 Sep 2007 - 19:04)