Tout le monde s'accorde à dire aujourd'hui que les frames sont plus généralement source d'ennuis que d'avantages dans la conception d'un site web. (Je ne reviendrais pas sur les pages impossibles à marquer, l'indexation difficile et la surcharge serveur engendrée par l'augmentation du nombre de fichiers à télécharger.)
Cependant, j'avais à l'époque trouver une utilisation amusante de l'attribut target : et si celui-ci, au lieu de désigner la fenêtre de destination du lien servait maintenant à désigner l'élément de destination, en utilisant un ID. La page liée se chargerait alors dynamiquement à l'intérieur de la page courante, sans avoir à recharger la page courante. Les avantages des frames sans leurs inconvénients.
Aujourd'hui, tout le monde me dira que c'est très facilement réalisable en utilisant l'objet XMLHttpRequest. Mais à l'époque, cette technologie n'était pas aussi répandue qu'aujourd'hui et je trouvais qu'il s'agissait d'une bonne voie à prendre pour le futur des pages web.
Pour expliquer ma vision, je souhaitais développer une page web simulant ce phénomène en utilisant Javascript. Malheureusement, mon ignorance de l'objet XMLHttpRequest et ma méconnaissance des fonctionnalités du DOM m'ont empêché de réaliser cette page.
Suite à un billet récent de Laurent Jouanneau (pointant sur un autre encore plus intéressant), j'ai repensé à cette histoire. Avec mes connaissances actuelles de l'objet XMLHttpRequest et de la manipulation du DOM, je pouvais facilement réaliser cette démonstration. Sitôt dit, sitôt fait :)
J'ai fait une petite page web affichant les fichiers et les dossiers de mon répertoire mess. Les deux liens possèdent un attribut target pointant vers un ID dans la page. Lorsque l'utilisateur clique sur un lien, le contenu pointé est chargé directement dans l'élément pointé par l'attribut target. La responsabilité du formatage reste donc du côté du serveur (pas comme AJAX) mais cela permet cependant de réaliser de manière simple et rapide une application web plutôt dynamique.
La version actuelle utilise bien sûr du Javascript et n'a pour le moment été testé que sur Firefox et Safari, mais cette fonctionnalité pourrait facilement être disponible nativement dans les navigateurs. Il faudrait pour cela ajouter une fonction open() dans les éléments Node comme il en existe une dans Window et normaliser le fait qu'une valeur d'attribut target commençant par un # signifie d'appeler cette fonction open() sur l'élément pointé plutôt que sur la Window.
1 De Classics -
Les frames posent n problème de référencement, c'est tout.
2 De teddyber -
Concept interessant. en fait, c'est une encapsulation basique de l'objet XMLHttpRequest mais elle fait son effet. Mais si l'utilisateur n'a pas javascript, il va se retrouver sur une page qui ne sera pas fonctionelle puisque destinée à être uniquement un div quelque part. non ?
3 De teddyber -
j'avais pas déjà fait un commentaire moi ? bon.
c'était pour dire que je trouvais le concept intéressant mais que se passe -t-il si je n'active pas le JavaScript ? je vais me retrouver sur une page non fonctionnelle ne contenant que ce qui est destiné à un div
4 De Vincent -
Les commentaires sont modérés. Désolé, je n'ai pas eu le temps de le préciser.
En ce qui concerne les problèmes d'utilisation dans le cas de l'absence de Javascript, c'est connu. Mais tout comme le mécanisme d'overlays développé par Daniel il y a quelques temps, le but est d'effectuer une démonstration d'un comportement qui pourrait devenir un standard. Le but n'est pas ici de proposer un script que tout le monde doit utiliser sur son site demain matin :)
5 De Eric Daspet -
Est-ce que tu n'es pas en train de détourner purement et simplement un attribut ? Cet attribut sert à désigner un nom de cadre ou fenêtre non ? Y mettre un identifiant indique bien une destination mais en rien un nom de fenêtre/cadre.
Pour moi ça ressemble fortement à utiliser <blockquote> pour faire une identation ou <table> pour faire des colonnes. Tu rédiges du code qui n'a pas le sens que lui donne le langage HTML, et tu te reposes en conséquence sur des lecteurs (ici en js) qui implémentent ces même contresens.
C'est mauvais pour l'interop et pour la pérénité. Et surtout, tu dénatures le langage.
Si tu souhaites ajouter tes éléments persos fais le, mais fais le réellement en l'assumant, pas en détournant ce qui existe. Certes, ça ne "validera" plus, mais bon, si ça valide avec in identifiant dans l'attribut target ce n'est qu'un leure technique, en réalité le contenu de ta page n'est pas plus conforme aux spec que si tu avais rajouté un id_target="#monid". Mieux, distribues en XML et ajoutes un espace de nom.
6 De Vincent -
Je n'ai sûrement pas été suffisamment clair dans mon billet. Ce fonctionnement n'est pas du tout un fonctionnement que je souhaite utiliser avec les normes actuels.
Il s'agit d'une réaction au retour de l'attribut target en XHTML 2 qui avait été déprécié en XHTML 1. Pour moi, si l'attribut target doit refaire son apparition dans la nouvelle version d'XHTML, il devrait se faire avec le comportement que je présente, ce qui serait un retour de la fonctionnalité que souhaite les gens utilisant autrefois l'attribut target sans pour autant sacrifier l'accessibilité du document.
Cette page simule le comportement que je souhaiterais voir dans une page XHTML 2 utilisant l'attribut target. Il ne faut pas oublier que la norme XHTML 2 n'existe pas encore, je ne transgresse donc aucune règle établie, je propose simplement un autre comportement pour cet attribut s'il doit revenir.