target or not target

[adatim]

Salut à tous,

je suis assez indécis face à l'attribut target des liens. Pour ceux qui ne le savent pas encore cet attribut n'est plus autorisé par l'HTML 4.1 STRICT.

Il y a donc trois possibilités :

- passer en TRANSITIONNAL

- utiliser javascript avec quelque chose ds ce genre :

 onclick="window.open(this.href);return false;" onkeypress="window.open(this.href);return false;"

- assembler la DTD du XHTML STRICT avec la DTD du module target qui se trouve dans la modularisation XHMLT 1.1.

C'est la dernière solution qui est préconisée par le W3C et qui personnellement me semble aussi la plus fine ... J'aimerais cependant savoir ce que vous dans votre cas réalisez en général ?

Je vous joins un très bon lien à ce sujet qui rejoint ces pensées :

L'attribut target et les standards W3C.

[destroyedlolo]

Pourquoi faire simple quant on peut faire complique ...

Non, bien sur, je passe en TRANSITIONNAL.

De toutes, la solution Javascript est de loins la pire car ca risque de casser l'hegonomie du site si le visiteur a devalide le Javascript.

M'enfin, c'est un tres bon exemple des abuts de la normalisation : pourquoi n'est-il pas valide en STRICT, pourquoi ce faire @#%@^%# avec les DTD en XHTML ... Les techno web etaient sense etre simple, ici, le W3C ajoute des limites simplement pour le plaisir ...

Enfin, a mon avis bien sur

[Ganf]

Pour ceux qui ne le savent pas encore cet attribut n'est plus autorisé par l'HTML 4.1 STRICT.

Hum ... HTML 4.01 je pense que tu veux dire.

Je me permet aussi de contester le n'est *plus* :

HTML 4.0 a été finalisé en 97, en contenant déjà l'attribut target en transitionel et pas en strict. Déjà je doute que tu fasses du Web depuis 97 donc le statut de cet attribut n'a jamais du changer pour toi. Mais même si c'était le cas, l'attribut target n'existait pas avant, il est absent de HTML 3.2.

onclick="window.open(this.href);return false;"

onkeypress="window.open(this.href);return false;"

Ca ne marchera pas sans javascript. Bon, à la limite ça dégrade correctement donc ce n'est pas dramatique mais c'est à signaler.

Le onkeypress est aussi contestable, ça veut dire que si j'appuie sur une touche en ayant sélectionné le lien, ça active le lien. Une touche ... n'importe laquelle. Y compris tabulation (normalement pour sauter au lien suivant), la touche échap, les raccourcis claviers ou les touches qui normalement n'activent pas le lien.

Mais surtout ça n'a aucun intérêt par rapport à la version transitionnelle :

- ton code est toujours bardé de propriété de présentation (sauf qu'au lieu d'être en HTML elles sont en Javascript)

- c'est plus long et complexe à écrire

- ça n'a aucun avantage par rapport à un doctype strict

assembler la DTD du XHTML STRICT avec la DTD du module target qui se trouve dans la modularisation XHMLT 1.1.

Et certains navigateurs ne vont plus reconnaitre correctement ta page en mode text/html, d'autres vont passer en mode quirk au lieu du mode standard et les derniers ne remarqueront même pas cette personnalisation de doctype.

C'est une solution qui a d'autant moins de sens qu'un modèle ayant le module target existe déjà ... le mode transitionnel.

Je vous joins un très bon lien à ce sujet qui rejoint ces pensées :

*TRES* mauvais article à mon avis

.

Il préconise au beau milieu une solution qu'il qualifie de pragmatique : utiliser le target tout en gardant le doctype strict. C'est totalement idiot dans le sens que ça garde le désavantage du transitionnel (on met de la mise en forme dans le code) tout en rajoutant des incompatibilités majeures (tout client HTML strict provoquera une erreur). On est moins compatible et on n'a toujours aucun des avantages du modèle strict.

Il oublie rapidement l'unique but du doctype : déclarer la grammaire utilisée. Là il utilise volontairement un doctype qui ne correspond pas à sa grammaire, ça n'a réellement aucun intérêt mis à part se la jouer en disant qu'il a un meilleur doctype que les autres.

Pragamatique ? c'est au contraire inutilement extrémiste, choisir un doctype strict alors qu'il n'est pas adapté à ce qu'on fait, uniquement pour dire "je fais du strict" (alors que ce n'est pas le cas).

Il oublie qu'on peut tout à fait que mettre un doctype transitionnel n'oblige pas à dégrader sa page. Tu peux mettre un doctype transitionnel en n'utilisant que l'attribut target et pas tous les autres.

L'idée générale "je montre que je suis un pro parce que j'utilise un doctype strict même si mon contenu ne respecte pas ce modèle en réalité" se retrouve d'ailleurs dans la page puisqu'il a la fierté de marquer "Page conforme : XHTML 1.0 strict" alors que le validateur dit l'inverse.

Mis à part faire semblant et se la jouer auprès des copains sa préconisation n'a aucun intérêt.

Je ne vais pas être objectif mais je te conseille très fortement la lecture de http://www.cybercodeur.net/weblog/commenta...?idmessage=1088

L'idée principale c'est :

- es tu vraiment sûr d'avoir besoin d'une nouvelle fenêtre ? dans la plupart des cas c'est une mauvaise idée

- si tu es convaincu que tu en as besoin et que tu veux préciser tout ça dans ton HTML, c'est que dans la démarche tu as une démarche transitionnelle (préciser la présentation dans la description de contenu). Tu aura donc tout avantage à utiliser un doctype transitionnel ainsi que l'attribut target. C'est fait pour ça, c'est ce qui sera le plus accessible (et ça ne t'oblige pas pour autant à utilsier tous les autres éléments et attributs de présentation ; tu peux garder le reste le plus proche possible du modèle strict)

- mais si tu veux vraiment utiliser un modèle strict et des nouvelles fenêtres, il y a moyen de jouer avec du javascript évolué et du marquage de contenu.

[Steph. K.]

Il y a donc trois possibilités :

Tu en oublies une 4e : ne pas ouvrir de nouvelle fenêtre. Le visiteur qui tient à ouvrir une nouvelle fenêtre découvrira bien tout seul comment il faut faire.

Perso, je n'ouvre jamais de nouvelles fenêtre mais de nouveaux onglets et tu ne peux rien contre cela, ce sont les réglages de mon navigateur.

[Ganf]

M'enfin, c'est un tres bon exemple des abuts de la normalisation : pourquoi n'est-il pas valide en STRICT, pourquoi ce faire @#%@^%# avec les DTD en XHTML ... Les techno web etaient sense etre simple, ici, le W3C ajoute des limites simplement pour le plaisir ...

Si tu veux faire simple tu utilises le transitionnel, comme tu le dis. C'est tout à vait normalisé et valide. Où est la limite du W3C ?

S'il veut utiliser le doctype strict c'est lui qui se met une limitation, personne d'autre. Le modèle strict n'est pas obligatoire et le doctype strict n'apporte qu'une facilité de validation pour celui qui veut le respecter. Pour tous les autres (les lecteurs) ça n'a aucun avantage par rapport au doctype transitionnel (je parle bien de la ligne de doctype, pas du modèle utilisé dans le contenu)

Quant à savoir pourquoi ça n'est pas valide en strict, c'est simplement la raison d'être du strict : se séparer à terme de tout ce qui ne décrit pas directement le contenu mais décrit la présentation. Savoir comment afficher la page n'est pas de la description de contenu mais de la présentation. Pourquoi serait-ce présent dans le strict ?

[adatim]

Oulà bien plus de polémique que je ne l'imaginais ... je vais essayer de répondre petit à petit dans l'ordre...

Tout d'abord si je codais avant 1997 même si à l'époque je dois bien admettre que la validation W3C me passait bien au dessus de la tête ... comme à beaucoup d'autres. Heureusement le web a beaucoup évolué et maintenant de plus en plus de gens respectent ces directives ... ou essayent de les respecter.

Pour l'ouverture d'une pop up il y a malheureusement des cas où celle-ci est beaucoup plus pratique que de rester dans une même page. Dans un annuaire par exemple il peut être plus que pratique de proposer (non pas forcer mais proposer!) l'ouverture dans un pop up. Et non je ne suis pas d'accord l'utilisateur ne saura ni ne pourra pas forcément le faire de lui même !

Il y a encore de(s) (nombreuses) personnes qui ne savent pas ouvrir une nouvelle fenêtres. La solution dans ce cas et ca n'engage que moi c'est deux liens permettant d'ouvrir aussi dans une nouvelle fenêtre. Certes là aussi on pourra me rétorquer qu'ergonomiquement on va rajouter un lien qui va rajouter une indécision (mais où dois-je cliquer ?!?) mais je prends ce risque que je promets de tester dans ce cas lors des études utilisateurs.

Pour le code javascript. Le fait qu'il y ait à la fois une gestionnaire sur le clic et au clavier est tout de même très pratique. Ca ne gènera personne puisque à partir du moment où vous déplacez les liens avec le clavier, il vaut mieux que n'importe quelle touche puisse l'activer. Ceci par exemple pour les personnes qui souffriraient d'handicaps moteurs et ne pourrait pas forcément appuyer sur la touche X Y ou Z. Bon ensuite le fait que ce soit du javascript je suis d'accord avec vous ce n'est certainement pas la meilleure solution et dans ce cas il vaut même carrément mieux le target vous avez raison.

Ensuite pour ce qui est de l'opposition entre transitionnal et strict ... Ce que je vais dire est peut être propre à ma vision ! Mais je pense que l'on peut vouloir une séparation stricte du contenu à une seule exception : vouloir proposer ces pop-ups sans vouloir le javascript. Ainsi mettre les pages en strict permet non pas de se glorifier d'être en strict mais de lancer une vérification sur le W3C validator, corriger ses erreurs s'il y en a et être sûr de ne pas avoir oublié quelque chose.

Assembler la DTD du module target permet donc mais je me trompe peut-être et dans ce cas là expliquez moi pourquoi, de respecter son optique de code, tout en réalisant une seule exception. Même si après le site pourra par les puristes ne pas être considéré comme vraiment une perle du strict mais j'ai du mal à comprendre où se situe alors le problème tant que le fond est bien respecté et surtout justifié. Ainsi, on peut vérifier ces pages selon une DTD stricte tout en sachant qu'on ne le sera jamais vraiment.

En tout cas j'ai apprécié de lire l'article donnée en lien et les divers commentaires, c'est d'ailleurs pour ca que je réponds après un si long temps) et effectivement il a le mérite d'être très clair et d'ouvrir une discussion que je ne pensais pas si vivante.

[Denis]

Malgré tous les commentaires fort instructifs et pertinents, je crois que le tout se résume à une chose... strict ou transitionnel, l'un est aussi valable que l'autre... et ce, autant en HTML qu'en XHTML. Pourquoi se poser des questions ? L'attribut target est incontournable ? Transitionnel, c'est tout.

Cela n'empêche aucunement le concepteur de coder comme s'il faisait du strict et de se permettre uniquement une entorse en utilisant l'attribut target... au coût de la mention Strict, qui semble si chère aux yeux de tous ceux qui se mettent à coder selon les normes.

[adatim]

Oui mais j'en reviens à un problème dont je parlais tout à l'heure : indiquer un site en tant que transitionel implique une vérification beaucoup moins serrée par le validateur du w3c.

Et cet outil sert autant (du moins dans mon cas) à obtenir la conformité qu'à vérifier celle-ci et à corriger les erreurs qu'il nous indique.

Et si je mets transitionnal il ne verra plus "ses erreurs" ....

Sauf si j'ai mal compris et que ce que tu proposes c'ets plutôt de mettre strict de lancer les vérifications telles quelles quitte à ce que la vérification final indique que la page n'est pas stricte.

Pourquoi pas après tout à partir du moment où celà est justifié ...

[Denis]

Ce que je dis simplement, c'est : si tu peux tout coder en strict, fais-le et essaie de suivre ces règles là au mieux de tes capacités... au pire tu obtiendras quelques erreurs, toutes reliées à l'utilisation de l'attribut target. Quand tu seras prêt, tu balances en doctype transtionnel et bingo, pas d'erreurs, avec un code qui respecte autrement le doctype strict.

Et le jour ou tu parviendras à convaincre qui que ce soit que les nouvelles fenêtres, c'Est mal et que tout ce qui les sépare du strict c'est cet attribut, ils voudonrt peut-être passer de l'autre côté.

[Ganf]

Ca ne gènera personne puisque à partir du moment où vous déplacez les liens avec le clavier, il vaut mieux que n'importe quelle touche puisse l'activer. Ceci par exemple pour les personnes qui souffriraient d'handicaps moteurs et ne pourrait pas forcément appuyer sur la touche X Y ou Z.

Ah ?

Petit tour du propriétaire :

Le onclick javascript est déjà activé si je déclenche le lien par le clavier. Le nom est trompeur, il concerne l'activation et pas uniquement le click souris. Tu peux considérer l'activation clavier comme un click clavier. Le onkeypress n'est pas nécessaire à l'utilisation du js sur tes liens, même pour le clavier.

Avec ton onkeypress je ne peux plus naviguer dans mes liens. Dès que je suis sur le premier, la touche pour passer au suivant risque d'activer le premier lien sur certains navigateurs au lien de passer au suivant. C'est idiot parce que ça veut dire que seul ton premier lien est accessible au clavier, les autres sont inaccessibles alors qu'ils fonctionneraient sinon.

Dans le même genre je ne peux peut être plus utiliser les touches suivantes si je suis sur un lien :

' qui permettait de faire une recherche dans les liens

/ qui permettait de faire une recherche dans le texte

backspace qui permettait de revenir à la page précédente

les flêches qui permettaient de faire défiler la page

Je ne parle pas non plus des raccourcis plus classiques ou des touches que quelqu'un qui a des difficultés avec la souris peut justement avoir définit pour une action précise.

Au lieu d'améliorer l'accessibilité et les possibilités de navigation clavier tu viens de casser l'utilisation du clavier sur certains navigateurs. Ta personne qui souffre d'un handicap moteur elle sera super contente, crois moi.

Ainsi mettre les pages en strict permet non pas de se glorifier d'être en strict mais de lancer une vérification sur le W3C validator, corriger ses erreurs s'il y en a et être sûr de ne pas avoir oublié quelque chose.

Ca je peux comprendre.

Mais il y a deux notions : le développement et la publication. Vouloir prendre comme objectif le modèle strict peut peut être une raison pour te mettre un doctype strict pendant le développement, pas pour publier avec si tu ne le respectes pas (et donc publier quelque chose de faux).

Notes d'ailleurs qu'il n'y a pas besoin de mettre une DTD stricte pour tenter la validation en strict. Le validateur permet de forcer le modèle pendant le test, justement pour ce genre de cas.

Assembler la DTD du module target permet donc mais je me trompe peut-être

et dans ce cas là expliquez moi pourquoi, de respecter son optique de

code, tout en réalisant une seule exception.

Tu ne te trompe pas, mettre un doctype XHTML 1.1 personnalisé ça "fonctionne" en théorie.

Maintenant, quel est ton but ?

- compatibilité ? quasiment aucun client ne sait interpréter les DTD perso, par contre beaucoup passeront dans un mode quirk si tu n'as pas une DTD officielle. Bref, tu dégrades la compatibilité

- validité ? pour être valide avec ton XHTML 1.1 modulaire il faudrait que tu envoies ta page en application/xhtml+xml. Elle ne serait alors lisible et comprise que par un ou deux navigateurs (pas MSIE par exemple). Tu l'envois donc certainement en text/html et le résultat c'est que ce n'est pas valide

- accessibilité ? en pratique il y a assez peu de clients qui connaissent le XML, c'est loupé de ce coté là aussi

- plus pratique ? la plupart des éditeurs et outils savent se servir des DTD officielles, pas des personnalisées. Ca ne sera pas plus pratique non plus

Oui, ça fonctionne en théorie, mais en pratique ça n'a aucun intérêt car c'est "moins bien" que les autres solutions sur quasiment tous les points.

Je me demande d'ailleurs pourquoi ils ont continué à forcer la déclaration de DTD dans les versions XMLisées. Ce n'est plus nécessaire pour les clients et ça amène ce genre de problèmes.

Même si après le site pourra par les puristes ne pas être considéré comme vraiment une perle du strict mais j'ai du mal à comprendre où se situe alors le problème tant que le fond est bien respecté et surtout justifié. Ainsi, on peut vérifier ces pages selon une DTD stricte tout en sachant qu'on ne le sera jamais vraiment.

Boaf, le site ne sera pas strict, c'est un fait établi. Maintenant nous on s'en fout un peu.

Par contre en informatique les logiciels ont un comportement binaire. Quelque chose est valide ou ne l'est pas. Ca ne l'est jamais "presque" ou "un peu".

Ce que je veux dire c'est un lecteur HTML strict risquera de provoquer une erreur fatale sur ta page. Certes la plupart des navigateurs sont super tolérants et laxistes et tu peux te permettre de profiter de cette tolérance

Mais .... quel intérêt ? qu'y gagnes tu ? si tu cherches à faire valider et à viser le modèle strict c'est bien pour ne pas reposer sur les facilités non standard du navigateur non ? ça serait aller pile contre ce que tu cherches à priori à faire avec les DTD.

Sauf si j'ai mal compris et que ce que tu proposes c'ets plutôt de mettre strict de lancer les vérifications telles quelles quitte à ce que la vérification final indique que la page n'est pas stricte.

Sauf si j'ai mal compris Denis, il propose pile le contraire (mettre un doctype transitionnel)

_AT_Denis : tu surveilles les liens entrants sur tes billets ?

Modifié 19 Mai 2005 par Ganf

[adatim]

Et le jour ou tu parviendras à convaincre qui que ce soit que les nouvelles fenêtres, c'Est mal et que tout ce qui les sépare du strict c'est cet attribut, ils voudonrt peut-être passer de l'autre côté.

Je suis assez d'accord avec la deuxième partie mais la première pas vraiment ... je ne dis pas que c'est mal (ou bien) mais que dans certain cas ca peut-être très utile et faciliter certaines choses ... En tout cas merci pour vos points de vue.

[adatim]

Sauf si j'ai mal compris Denis, il propose pile le contraire (mettre un doctype transitionnel) wink.gif

oui désolé c'est moi qui n'ai pas finit ma phrase sur le papier ... il manquait juste le fait qu'après je rajoutais le doctype transitional

Pour ta réponse Ganf tu m'apprends effectivement pas mal de choses au niveau de la compatibilité DTD j'en prends note.

Quant à javascript je ne le voyais pas sous cet angle et là et je dois bien admettre que ce n'est pas faux non plus et que ca bloque pas mal ... merci pour cette réflexion.

[Steph. K.]

Pour l'ouverture d'une pop up il y a malheureusement des cas où celle-ci est beaucoup plus pratique que de rester dans une même page.  Dans un annuaire par exemple il peut être plus que pratique de proposer (non pas forcer mais proposer!) l'ouverture dans un pop up. Et non je ne suis pas d'accord l'utilisateur ne saura ni ne pourra pas forcément le faire de lui même !

C'est typiquement le cas ou la nouvelle fenêtre ne sert qu'à flatter l'égo du concepteur ;-) (Je suis persuadé que le visiteur va revenir sur mon annuaire).

Qu'elle-est la différence entre apprendre à jongler avec de multiples fenêtres (et oui, le site que ton annuaire propose a fait le même choix que toi : nouvelles fenêtres) et apprendre à ouvrir une nouvelle fenêtre soit même ?

[Denis]

Sauf si j'ai mal compris Denis, il propose pile le contraire (mettre un doctype transitionnel)

pile

@Denis : tu surveilles les liens entrants sur tes billets ?

Jamais. Honnêtement, je n'y vois strictement aucun intérêt. Pas plus que mes logs ou mes statistiques d'ailleurs.

oui désolé c'est moi qui n'ai pas finit ma phrase sur le papier ... il  manquait juste le fait qu'après je rajoutais le doctype transitional

Ben voilà. Il me semblait aussi que j'avais été clair.

[adatim]

C'est typiquement le cas ou la nouvelle fenêtre ne sert qu'à flatter l'égo du concepteur ;-) (Je suis persuadé que le visiteur va revenir sur mon annuaire).

Non pas du tout puisque l'intérêt même d'un annuaire n'est-ce pas d'être quitté pour aller ailleurs ? Sinon je ne mets pas d'annuaires ni de liens vers l'extérieur c'est beaucoup plus simple.

C'est plutôt le cas où l'on prévoit que l'utilisateur pourra vouloir visiter plusieurs pages qui se trouvent dans l'annuaire. Et fermer une page c'est une des choses qui est vraiment à la portée de tout le monde. Donc il ferme la nouvelle page revient sur l'annuaire et peut soit rechoisir une page soit partir pour de bon en fermant.

Quant à la touche précédent qui devrait permettre de revenir en arrière là aussi je me demande vraiment s'il est si facile à prendre en main. Surtout que les navigateurs ne sont pas encore capable de permettre des retours directs sur d'autres sites sans retracer toutes les pages. (ex je fais ce site je regarde 5 pages puis 13 pages et encore un autre 2 pages et dire je veux retourner non pas 3 pages plus tôt mais trois sites plus tôt).

Le jour où cette fonctionnalité sera prise en compte dans les navigateurs je dis oui on pourra étudier la question beaucoup plus sainement.

Modifié 19 Mai 2005 par adatim

[Cleden]

Si l'attribut n'avait jamais existé, l'apprentissage de " l'ouverture dans une nouvelle fenêtre" ferai probablement partie des premiers lors de nos pas de débutants sur le net . L'apprentissage passe par la reflexion, on apprend jamais quelque chose qui nous est servit sur un plateau.

Pour ma part, j'ai "oublié" cet attribut et ne m'en sert sur aucun de mes sites (sauf oubli), j'ai pourtant un annuaire.

Loïc.

[Dudu]

Pourquoi faire simple quant on peut faire complique ...

Non, bien sur, je passe en TRANSITIONNAL.

De toutes, la solution Javascript est de loins la pire car ca risque de casser l'hegonomie du site si le visiteur a devalide le Javascript.

Je ne te comprends pas Si le visteur a désactivé le javascript, il va ouvrir le lien dans la même fenetre et puis basta

Tu en oublies une 4e : ne pas ouvrir de nouvelle fenêtre. Le visiteur qui tient à ouvrir une nouvelle fenêtre découvrira bien tout seul comment il faut faire.

Perso, je n'ouvre jamais de nouvelles fenêtre mais de nouveaux onglets et tu ne peux rien contre cela, ce sont les réglages de mon navigateur.

Çà ressemble un peu à une guerre de clocher tout çà (rien de méchant dans mes propos, attention). Il peut y avoir certaines raisons pour ouvrir un lien dans une nouvelle fenêtre, sinon il n'y aurait peut-être pas autant de ces liens. L'argument de l'égo surdimensionné peut d'ailleurs tout à fait tenir la route (en changeant la formulation) Mettons que le site A m'appartienne et que je fasse un bête lien vers le site B. Si je donne ce lien vers B juste à titre d'exemple au beau milieu d'une argumentation, je vais quand même désirer que mes visiteurs aient encore une fenêtre ouverte sur mon site pour continuer leur lecture sans être interrompu par le remplacement de ma page par une page du site B. Sachant que beaucoup de gens sont toujours sous Explorer et ne disposent pas d'onglets. Certains aussi cliquent sur les liens sans réfléchir, sauront-ils retrouver la page initiale s'ils le veulent ? Si oui comment ? bouton Précédent ou bouton Fermer la fenêtre ?

Et pourtant, les arguments de type "çà casse le bouton Précédent" sont recevables aussi.

Ne soyons pas bornés (que ce soit dans une attitude ou dans une autre)

Pour en revenir à la question initiale, la manière la plus simple est de passer en Transitional, çà me paraît clair.

[Dash]

A propos de javascript, et sans vouloir prendre partie pour telle ou telle religion...

Lorsqu'il m'arrive de vouloir ouvrir une fenetre, au lieu d'utiliser des "target", je fais le choix de l'attribut rel="external", plus conforme aux normes.

<a href="document.html" rel="external">external link</a>

Ensuite, un javascript se charge de parser le document. Pour peu que le client ait active le javascript

Rel est assez libre dans la norme, mais principalement concu pour les relations entre les documents ou sections de documents, ce qui semble approprie.

> New-Window Links in a Standards-Compliant World

[Denis]

Mettons que le site A m'appartienne et que je fasse un bête lien vers le site B. Si je donne ce lien vers B juste à titre d'exemple au beau milieu d'une argumentation, je vais quand même désirer que mes visiteurs aient encore une fenêtre ouverte sur mon site pour continuer leur lecture sans être interrompu par le remplacement de ma page par une page du site B.

Et c'est pour ça que le bouton précédent existe, non ? Qu'est-ce qu'ils ont les gens a toujours vouloir garder l'utilisateur captif sur leur site ? Si les contenus intéressent les gens, ils reviendront d'eux mêmes...

[YannCo]

Et c'est pour ça que le bouton précédent existe, non ? Qu'est-ce qu'ils ont les gens a toujours vouloir garder l'utilisateur captif sur leur site ? Si les contenus intéressent les gens, ils reviendront d'eux mêmes...

<{POST_SNAPBACK}>

[Hors-sujet]

Heu oui et non, personnellement il m'arrive de suivre des liens puis fouiller un peu à droite à gauche voir suivre encore un autre lien ........ si le site où se trouvait le premier lien ne m'a pas dirigé sur une nouvelle fenetre il y a très peu de chance pour que je fasse l'effort de revenir en arriere jusqu'a ce que je tombe dessus ou que je fouille dans l'historique.

Par contre ma page d'accueil est google donc je peux effectivement relancer la même recherche si le contenu du site m'intéressait plus que les autres.

Je fais parti de ceux qui n'ont rien dans les favoris, même mes sites ne sont pas dans les favoris, pas même webmaster-hub uniquement les pages introuvables via google, administration, phpmyadamin ...

Donc je préfere renvoyer mes visiteurs sur une nouvelle fenetre, à chacun sa politique

[/Hors-sujet]

[Ganf]

à chacun sa politique

Notes que c'est justement pour ça que tu ne devrais pas forcer l'ouverture d'une nouvelle fenêtre : chacun cherche des choses différentes ou a ses propres préférences.

En forcant l'ouverture d'une nouvelle fenêtre tu forces tes préféences à toi alors que ce sont celles de ton visiteur qui devraient être utilisées.

Il faut bien se souvenir que ce n'est pas vus qui êtes la cible de vos pages. Vos références à vous sont totalement hors sujet.

[adatim]

tu ne devrais pas forcer l'ouverture d'une nouvelle fenêtre :

Mais personne pour le moment n'a parlé de forcer ... enfin j'en ai pas l'impression du moins. Dans mon cas j'ai clairement précisé et à plusieurs reprises que je pensais que le choix était la meilleure solution mais comme le dit si bien dudu :

Çà ressemble un peu à une guerre de clocher tout çà

J'ai l'impression que les personnes anti-nouvelles fenêtres ni voient aucun intérêt dans aucune situation mais je ne suis pas d'accord il peut y en avoir. Elles peuvent être très pénibles je le conçois mais aussi très utiles. Ou alors qu'on me prouve études ergonomiques à l'appuye que les liens sur de nouvelles fenêtes sont un trouble complet pour l'utilisateur même lorsqu'il a le choix. J'ai cherché et je n'ai pas trouvé mais je suis sûr que des spécialistes du domaine pourront nous répondre.

Notes que c'est justement pour ça que tu ne devrais pas forcer l'ouverture d'une nouvelle fenêtre : chacun cherche des choses différentes ou a ses propres préférences.

Oui mais vous semblez oubliez que la personne ne sait pas forcément faire ce genre de choses ... quand elle arrive sur un site web elle doit avoir le choix proposé à mon avis de faire ce qu'elle veut.

ET il ne rentre là dedans aucun ego personnel, ni *références hors sujets*.

Personnellement je sais utiliser un historique les boutons précédents, ouvrir un onglet, et tout le tralala mais depuis quand c'est à l'utilisateur de devoir se débrouiller ? C'est à nous de lui proposer un choix et à lui de choisir.

Je ne suis pas pour le forcer à ouvrir une nouvelle fenêtre car je trouve ca très désagrable parfois mais je ne suis pas non plus pour ne pas lui laisser le choix de pouvoir lancer une nouvelle fenêtre.

Qu-est ce que ca coûte d'ajouter un petit bouton permettant d'ouvrir dans une nouvelle fenêtre ? D'un point de vue temps rien, d'un point de vue financier rien, d'un point de vue cognitif rien. Alors si ca ne coûte que le fait de passer en transitonnal plutôt qu'en strict je pense que ca peut valoir la peine. Après c'est sûr ca n'engage que moi ...

[Ganf]

Elles peuvent être très pénibles je le conçois mais aussi très utiles. Ou alors qu'on me prouve études ergonomiques à l'appuye que les liens sur de nouvelles fenêtes sont un trouble complet pour l'utilisateur

Bien sûr qu'elles peuvent être utiles. La preuve en est pour moi que j'use et j'abuse des onglets, qui sont à peu près la même chose au niveau du concept (mais pas au niveau ergonomie). Le problème c'est qu'il est quasiment impossible pour l'auteur d'affirmer que le visiteur trouvera ça "utile".

Pour ce qui est des études je te propose de quitter le domaine Web et d'aller dans les études sur l'ergonomie des modes fenêtrés et surtout du concept de fenêtre multiple + barre des taches.

La plupart des gens n'utilisent qu'une seule fenêtre à la fois, maximisée. Avoir des fenêtres déclenchées involontairement qui viennent se positionner au dessus, c'est souvent mauvais. Si tu veux quelque chose d'objectif, comptes le nombre de logiciels que tu utilises et qui utilisent plus d'une fenêtre. La règle est même de commencer à ranger les barres d'outils flottantes car on s'est rendu compte que même ça c'est dérangeant.

Qu-est ce que ca coûte d'ajouter un petit bouton permettant d'ouvrir dans une nouvelle fenêtre ?

Une case à cocher ou un lien supplémentaire ? pourquoi pas. Ca se sont des solutions. Reste à trouver une manière simple et efficace pour que l'utilisateur comprenne de lui même à quoi servent ces buotons, et à ne pas trop complexifier l'interface, mais ça peut être une solution.

Ce qu'il faut éviter en général de faire ce sont les target ou javascript automatiques, car eux ne permettent pas à l'utilisateur d'imposer son choix (je peux ouvrir dans une nouvelle fenetre quelque chose qui n'est pas prévu pour mais l'inverse est impossible sur la plupart des navigateurs)

[shangailily]

Si je devais clore le débat, voici mon point de vue simple :

- j'utilise un doctype HTML transitionnal,

- Je suis sur un site A, un lien me propose d'aller sur un site B. Ce lien s'ouvre dans une nouvelle fenêtre.

La nouvelle fenêtre est nécessaire pour l'internaute afin de garder la fenêtre du site A ouverte, ce qui évite à l'internaute de se perdre.

Cela n'a rien à voir avec l'ego du concepteur ? Cela a à voir avec le confort de navigation, point barre.

- Ne pas imposer une nouvelle fenêtre automatique.

Par nouvelle fenêtre, j'entends autant nouvelle fenêtre du navigateur (obtenue avec l'attribut "_target") et pop-up. J'avoue que si je veux rendre accessible (dans le sens de la méthode des critères AccessiWeb) un site, je serai tentée d'utiliser une pop-up accessible.

- utiliser à la fois des gestionnaires d'événement de souris et clavier.

Et là, Ganf, c'est instructeur, ce que tu nous as dit sur le "onKeypress". Mais alors que proposer comme gestionnaire de souris pour les personnes handicapées moteur ?

[Steph. K.]

- Je suis sur un site A, un lien me propose d'aller sur un site B. Ce lien s'ouvre dans une nouvelle fenêtre.

La nouvelle fenêtre est nécessaire pour l'internaute afin de garder la fenêtre du  site A ouverte, ce qui évite à l'internaute de se perdre.

Cela n'a rien à voir avec l'ego du concepteur ? Cela a à voir avec le confort de navigation, point barre.

- Ne pas imposer une nouvelle fenêtre automatique.

Je sens comme une légère contradiction dans tes propos... tu imposes une nouvelle fenêtre ou pas ?

En quoi le fait de se retrouver avec 10 ou 12 fenêtres ouvertes (et regroupées en un seul groupe par Win XP) facilite la navigation ?

Si Internet est (un petit peu) synonyme de liberté, autant laisser la liberté à chacun d'ouvrir ou pas une nouvelle fenêtre. Le pire c'est que pour préserver cette liberté il n'y a rien à faire et que de toutes façons essayer d'imposer un mode de navigation n'a aucun avenir : tous les navigateurs graphiques modernes proposent la navigation par onglets et le paramétrage fin du comportement des liens (même IE 7 offrira cela).