Extension du champ d'application de l'attribut target

Bonjour, et joyeuses Pâques à tous.

J'ai hésité une seconde à poster dans le salon "demande d'avis...", mais je me suis dit que c'était tout de même gonflé. Donc, je me rabat sur le bar, j'espère y recueillir vos avis éclairés de la même manière.

Bon. Je respire un grand coup, et je me lance :

Je propose l'extension de la syntaxe de l'attribut target afin de permettre aux balises <a> de charger du contenu html dans le noeud DOM de son choix à l'intérieur même de la page en cours.

<a href="contenu.frg" target="#zone">Charger contenu.frg dans la zone identifiée "zone"</a>

J'obtiens ainsi un comportement dynamique normalement réalisé avec des "include" php ou avec xmlHttpRequest. J'obtiens cette fonctionalité, donc, mais avec un code html "pur", sans adjonction de php ni javascript.

J'ai bricolé une page qui illustre mon propos à cette adresse :

http://lomago.com/xhtarget

C'est austère à souhait, je stylerai plus tard...

Le code est valide par rapport à une DTD recopiée de xhtml transitionnal, dans laquelle l'attribut target est autorisé à recevoir le signe "#".

Enfin, le principe est le même pour la balise <form>, le résultat de la soumission d'un formulaire pouvant très bien "atterrir" dans une zone de la même page.

Voilà. Qu'en pensez-vous ?
Modifié par GeorgesM (06 Apr 2007 - 15:26)

Heu... ben heureusement que t'as posté ça un vendredÿ, hein.

En gros c'est une simplification qui ancrerait l'usage le plus basique des include PHP ou de xmlHttpRequest dans la syntaxe HTML. Effectivement, avec le DOM les navigateurs auraient tout à fait les moyens d'aller chercher des contenus à insérer dans le document sans recharger la page.

Si on laisse de côté l'aspect réalistede ce genre de dispositif (c'est à dire : vu que c'est pas toi qui écrit les specs HTML 5, c'est juste une vue de l'esprit pour s'amuser et réfléchir un peu), on peut soulever les aspects suivants :
- accessibilité de la méthode ? Les lecteurs d'écran par exemple doivent pouvoir avertir du changement de contenu et proposer, par exemple, de conserver le focus actuel (lien), de le donner au bloc de contenu chargé, voire de repartir du début du document... pas insurmontable, c'est une question d'implémentation ;
- concurrence avec la création de pages dynamique côté serveur : que se passe-t-il si on veut changer plusieurs noeuds DOM du document avec un seul lien ?
- le title de la page ne change pas... on considère donc que l'on charge des contenus appartenant à un unique meta-document ?
- etc.

Salut, Florent.

1) Accessibilité. Je ne suis pas un spécialiste. En gros il y a trois écoles (dont une maternelle):
- L'include php : permet de spécifier en GET ce qui se passe dans l'évolution de la page, et permet de "marque-pager" (bookmark) un aspect à un moment donné de la page.
- l'ajax pur et dur qui ne peux pas faire grand chose
- ma méthode (l'école maternelle) qui permet au moins de savoir quel est le contenu suceptible d'être intégré (url href réelle)

a écrit :

Les lecteurs d'écran par exemple doivent pouvoir avertir du changement de contenu...

Cela se fait avec l'affichage de l'url cible dans la barre de status (?) (arrête moi si je trompe (novice)). En tant que visiteur, j'aime bien savoir où me mène le lien sur lequel je clique. Les navigateurs affichent dans la barre de status le libellé complet de la cible du lien. Avec un peu de jugeote, on constate aisément si le lien est intra-domaine ou vous envoi vous promener dans des régions indésirables du web.
J'ai prévu la fonctionnalité de faire afficher effectivement l'adresse du nouveau contenu au survol de la souris.
Après, le navigateur fait par défaut ce qu'il veut. Par exemple, firefox désactive par défaut l'autorisation pour un script de modifier le contenu de la barre de status.
Pour bénéficier (hum,hum) de cette fonctionnalité, il faut configurer via about:config... chose que le visiteur lambda a toute les chances de ne pas faire.

Donc, à suivre quand l'inspiration viendra (les suggestions sont bienvenues).

2) Chargement simultané de plusieurs noeud DOM, non. On ne peux pas le faire avec ça.

3) Le title ne change pas, on considère donc effectivement que l'on charge des contenus appartenant à un unique meta-document. Oui.
Modifié par GeorgesM (07 Apr 2007 - 09:05)

Hello,

Le problème de ta solution, à mon avis, est le même que celui des frames et de la navigation basée sur AJAX : on casse l'unité de navigation, qui est habituellement la page, avec tous les problèmes que cela implique (et que Florent a explicités).

D'ailleurs, ce que tu décris ressemble fort à une iframe, non ?

Julien Royer a écrit :
D'ailleurs, ce que tu décris ressemble fort à une iframe, non ?

À la différence qu'on n'inclue pas une page dans une page mais du code dans du code, il me semble.

Sauf que du coup la chose référencée par l'URL n'est pas une ressource à elle toute seule, mais un morceau de ressource, dans un format bizarroïde puisque tronqué.

Une URL (ou un URI si vous préférez) est censée identifier une ressource complète, compréhensible par un agent utilisateur en tant que telle.

Remarque personnelle : c'est marrant tous ces gens ne veulent pas recharger l'intégralité du document. Ça sert à quoi, concrètement, de recharger juste des petits bouts ?
Modifié par Lanza (07 Apr 2007 - 14:20)

Florent V. a écrit :
À la différence qu'on n'inclue pas une page dans une page mais du code dans du code, il me semble.

C'est un peu plus spécifique que ça je trouve. On inclut un fragment de page dans une page.

Lanza a écrit :
Sauf que du coup la chose référencée par l'URL n'est pas une ressource à elle toute seule, mais un morceau de ressource, dans un format bizarroïde puisque tronqué.

C'est vrai.

Florent V. a écrit :
Remarque personnelle : c'est marrant tous ces gens ne veulent pas recharger l'intégralité du document. Ça sert à quoi, concrètement, de recharger juste des petits bouts ?

+1

Lanza a écrit :
Remarque personnelle : c'est marrant tous ces gens ne veulent pas recharger l'intégralité du document. Ça sert à quoi, concrètement, de recharger juste des petits bouts ?

Je vais me faire un peu l'avocat du diable, mais ça ne servirait pas à améliorer l'ergonomie, par hasard ?

S'il s'agit de modifier l'essentiel du contenu du document en ne conservant que « l'habillage » (en-tête, menu de navigation, pied de page...), c'est d'une utilité très réduite, et mieux vaut recharger toute la page.

S'il s'agit de modifier un seul contenu au sein d'une interface complexe, ça devient tout de même plus utile. Je n'utiliserais pas un Netvibes où il faut recharger toute la page pour marquer les items d'un flux comme lus ou pour lire rapidement un item.

Lanza a écrit :

Remarque personnelle : c'est marrant tous ces gens ne veulent pas recharger l'intégralité du document. Ça sert à quoi, concrètement, de recharger juste des petits bouts ?

Chercher à ne pas recharger l'intégralité du document est une préocupation naturelle pour préserver de la bande passante, et gagner en fluidité. Ceci participe à rendre le site visité plus agréable et attractif.
En effet, l'intégralité du document implique la section head qui peut faire appel à un nombre important de fichiers externes, comme les feuilles de style et les scripts.
Bien sur, le navigateur dispose d'un mécanisme de cache chargé d'éviter au maximum de recharger plusieurs fois le même fichier, mais celà n'évite pas de devoir effectuer les requêtes http correspondantes, ne serai-ce que pour comparer les fichiers du serveur avec les fichiers en cache.

Un concepteur de site peut avoir une vision heuristique (non, non, çà mord pas) de son document, et dans ce cas, les "petits bouts" correspondent aux feuilles des branches, la page étant le tronc. Ces petits bouts constitue donc l'essentiel de la substantifique moelle.

Bien entendu, si on considère ce modèle comme mauvais, rien n'empèche de ne pas l'employer, ou d'employer la technique des "include" PHP qui a le mérite de permettre de servir l'intégralité de la page, quelle que soit sa déclinaison, avec l'url indiquant souvent assez clairement ce que le visiteur a devant les yeux :

exemple : http://monsite.ext/index.php?page=intro

De plus, cette technique permet de marquer la page, et donc de revenir dessus à l'aide des favoris ou d'un raccourci.

Enfin, cette technique ne perturbe pas les robots indexeurs, du moins ceux qui indexent les pages php (la majorité).

Seulement, à ce stade se repose le problème de départ, c'est que recharger la totalité de la page pour visualiser une simple modification de contenu, peut être pénalisante si les fonctions de cache sont désactivées (certains aiment les nouvelles fraiches) ou si le concepteur modifie l'en-tête http pour inhiber la mise en cache (on peut être tenté...). Il y a de toute façon un impact sur la bande passante, libre à tous d'en tenir compte ou pas.

Alors, "tous ces gens qui ne veulent pas recharger l'intégralité du document" se tournent généralement vers ajax et son xmlHttpRequest.

Pour simplifier, ajax se résume en gros à une seule technique de chargement sélectif d'une zone de l'ecran soutenu par beaucoup de littérature.

Ceux qui utilisent cette technique et en apprécient les avantages connaissent les inconvénients :
Le code html est "hybride" avec l'utilisation des propriétés de gestion d'événement onclick, onmouseover et consort.
Cet inconvénient est "cosmétique", j'en conviens, mais j'apprécie aussi le "joli code", et le préfère à l'autre.
L'autre inconvénient de taille, presque rédhibitoire, est l'impossibilité laissée aux robots d'indexer le contenu. Et cette situation n'est pas près de changer, les robots ne devraient pas intégrer d'analyseurs du DOM à la recherche des cibles des liens ajax, et se contenteront d'une analyse syntaxique en mode texte à la recherche des propriétés src et href du document.
Le référencement est pourtant une préocupation légitime pour le concepteur (et d'avantage pour son client).

Pour vous rendre compte, vous pouvez faire un tour sur cette page, où je met en oeuvre cette technique à base de target "étendus" à des cibles DOM : http://lomago.com/xhtarget
Modifié par GeorgesM (08 Apr 2007 - 06:44)

Bien sur, vous allez me dire que ce n'est pas encore opérationnel, et plein de défauts, mais néanmoins, c'est quand même remarquable.

Donc, tenez vous bien :

Je viens de faire indexer par google, et ceci pour la première fois à ma connaissance, du contenu normalement chargé dynamiquement par ajax ! ce qui était précédemment réputé imposiible.

Voilà la requête générée avec les mots clé xhtarget "proposition d'extension"
http://www.google.fr/search?hl=fr&q=xhtarget+%22proposition+d%27extension%22&btnG=Rechercher&meta=

Le moteur de recherche a donc effectivement noté les liens de la page de base, et est allé lire le contenu du fichier normalement chargé dynamiquement, et enregistré le texte.

Ce n'est qu'un début, mais ça me semble tout de même prometteur...
Modifié par GeorgesM (10 Apr 2007 - 13:49)