<C²: webløg />

Courriel - email address

Avatar Eric

samedi 30 octobre 2004
par Eric Daspet

Liens et nouvelle fenêtre

Ce qui est gênant avec les mauvaises questions c'est que la réponse semble toujours hors-sujet à notre correspondant. En réalité c'est souvent la question qui est hors sujet par rapport à son problème. Si je vous parais hors sujet dans la première partie de cet article, dites vous bien que c'est parce que j'essaie de répondre au problème réel, pas à la question.

" En HTML strict on ne peut pas utiliser l'attribut target sur les liens, comment ouvre t-on une nouvelle fenêtre alors ? "

Hier encore j'ai vu cette question. Je la vois trop souvent et malheureusement elle est suivie à chaque fois par une horde de solutions, toutes aussi mauvaises. Y répondre complètement est long, je vais m'y essayer ici. Tout ce que je vous demande c'est de ne pas sauter sur le code à la fin sans avoir lu le début. Les premiers textes sont les plus importants, de loin. C'est là que vous trouverez ma réponse à l'essentiel du problème.

Des liens ciblés

À titre de rappel, on signalise les liens HTML avec la balise <a>. Pour être un lien cette balise doit contenir au moins un attribut href (qui spécifie l'adresse de la page cible) : <a href="http://openweb.eu.org/">mon lien</a>. Par défaut, quand on clique sur ce lien, la page cible remplace la page courante.

Optionnellement, on peut ajouter un attribut target qui permet de spécifier un nom de fenêtre. La page s'affichera alors dans la fenêtre portant ce nom au lieu de la fenêtre courante. Cet attribut a une valeur magique nommée _BLANK qui demande au navigateur d'ouvrir une nouvelle fenêtre pour afficher la page.

Il se trouve que cet attribut target est autorisé dans les versions transitionnelles de HTML 4 et XHTML 1, mais est inexistant dans les versions strictes de ces mêmes formats.

Une fenêtre ouverte sur le monde extérieur

Ma première réaction à ceux qui posent la question de l'attribut target c'est leur demander pourquoi ils veulent absolument ouvrir une nouvelle fenêtre. En général, sur le Web, c'est une mauvaise idée.

Ouvrir une nouvelle fenêtre c'est perturber l'utilisateur débutant, qui n'en comprend pas toujours le principe. Les fenêtres s'empilent souvent et celles de dessous sont oubliées à jamais. Quant à celle ouverte sur le dessus, elle risque de dérouter l'utilisateur, elle lui fait perdre son principal outil de navigation et son meilleur point de repère : le bouton pour revenir en arrière. L'historique de navigation ne sera en effet remis à zéro dans cette nouvelle fenêtre. Qu'on soit débutant ou averti, c'est quelque chose qui est gênant, ou au moins agaçant.

On entend parfois que les nouvelles fenêtres permettent de ne pas perdre l'utilisateur en laissant l'ancienne page visible. En réalité c'est tout le contraire, et si vous voulez faciliter la vie de vos visiteurs, contentez-vous de mettre un titre pertinent à vos pages pour qu'il puisse naviguer correctement dans son historique quand il revient en arrière.

Pensez d'ailleurs qu'en plus de perturber les utilisateurs débutants, vous agacerez l'utilisateur averti. Ce dernier sait très bien ouvrir une fenêtre tout seul quand il le veut, mais n'appréciera pas qu'on le force à quoi que ce soit. Si en plus cette nouvelle fenêtre lui casse son historique et lui encombre sa barre des taches, vous risquez de ne plus le voir revenir. Je ne parle même pas des logiciels anti-popup qu'il peut avoir lancé et qui, s'ils sont mal réglés, fermeront automatiquement toutes vos nouvelles fenêtres.

L'attribut target ne sert pas qu'à l'ouverture de nouvelles fenêtres, il sert aussi à envoyer un lien vers une fenêtre déjà ouverte et nommée explicitement. Mais là c'est encore pire, l'historique ne veut plus rien dire et l'utilisateur, même averti, ne comprendra pas forcément que le lien est en train de s'ouvrir dans une seconde fenêtre qu'il n'a pas sous les yeux. Globalement les fenêtres nommées ne servent que pour les frames, et comme vous ne devriez pas utiliser les frames...

Oh, il existe des cas où cibler une fenêtre particulière est utile, mais c'est rare. Ouvrir une nouvelle fenêtre est pertinent presque uniquement pour les liens de contexte. Ce que j'appelle les liens de contexte ce sont ces petites popup qui donnent une information sur la page en cours, qu'on utilise et qu'on referme tout de suite : les liens d'aide, les confirmations, les outils de zoom, etc.

Vous ai-je convaincu ? Alors n'allez pas plus loin, le reste c'est pour ceux qui persistent. Si toutefois vous persistez à vouloir cibler autre chose que la fenêtre courante, alors mettez au moins en œuvre le minimum indispensable : prévenir l'utilisateur que le lien ne s'ouvrira pas comme il peut s'y attendre. C'est généralement faisable par une petite icône et/ou une note manuscrite en haut de page.

Be cool, be strict

Il existe deux modèles en HTML, le modèle dit transitionnel et le modèle dit strict. Le premier est ce qu'on pourrait appeler " le bon vieux HTML ", utilisé par la majorité des gens. Il permet de contrôler la mise en forme et la présentation du document : couleurs, alignements, tailles, positionnement, ouvertures de fenêtres, etc.

Le modèle strict vise lui à séparer la description du contenu (sens et structure des différentes parties du document) de sa présentation (mise en forme, contrôle de l'affichage, gestion de l'interface avec les fenêtres, etc.). Il en résulte logiquement que certains éléments y sont inexistants, on peut citer par exemple les balises ou <center>, ainsi que les attributs align et target.

La question posée au départ contient donc à la base une demi contradiction. Pourquoi vouloir en même temps faire une séparation stricte et pourtant vouloir contrôler la présentation à coup d'attributs HTML target ? C'est soit l'un soit l'autre.

Faire un javascript avec <a href="mapage.html" onclick="window.open(this.href)"> n'y changera rien. Le validateur HTML ne râlera plus, mais dans les faits vous ne respecterez pas plus le principe du modèle strict. Si vous voulez vraiment contrôler l'interface utilisateur à l'aide de code au milieu de votre document, c'est que vous ne faites pas une séparation stricte entre la description du contenu et sa présentation. Vouloir mettre une déclaration stricte pour votre HTML ne trompera que vous, ça ne changera rien pour vos clients ni pour la maintenance de vos pages.

Utiliser le modèle transitionnel n'est pas mal en soi, c'est simplement une philosophie de conception de la page. Si c'est la vôtre, alors ne vous cachez pas : Utilisez les outils pour ça, utilisez une déclaration de HTML transitionnel et l'attribut target. Cela sera supporté partout et plus accessible que les onclick ou autres astuces javascript.

Si vous choisissez le modèle strict (et je vous le conseille), alors considérez qu'il n'est pas une bonne idée de spécifier " ce lien doit s'ouvrir dans une nouvelle fenêtre " au milieu du HTML. Le problème ne vient pas de l'attribut target en lui-même, mais simplement de votre but de contrôler l'interface utilisateur en modifiant le balisage du document.

La solution existe, je l'ai rencontrée

La suite vous donne une des possibilités pour gérer la problématique des nouvelles fenêtres en modèle strict, mais réfléchissez bien aux deux réflexions plus haut avant : êtes-vous sûrs qu'une nouvelle fenêtre est profitable à l'utilisateur ? êtes-vous sûr que ce que vous cherchez n'est pas simplement le modèle transitionnel ?

Si vous lisez encore c'est que vous devez être sûrs de vous. Nous allons donc respecter la philosophie du modèle strict et séparer la description du document de sa présentation (je classe les comportements comme celui-ci dans la rubrique présentation). Je vous propose donc une procédure en trois étapes :

  1. Catégorisation sémantique : lors de la rédaction du contenu, on catégorise chaque lien suivant son rôle ou son sens. On spécifie s'il s'agit d'un lien qui sert pour appeler de l'aide, afficher un exemple, etc.
  2. Définition du comportement : dans un fichier javascript lié, on définit une fonction dont le seul rôle est de recevoir un événement quant quelqu'un clique sur un lien. Elle se contente alors d'ouvrir une popup vers la page souhaitée et demande au navigateur de ne pas exécuter son action par défaut (chargement de la page dans la fenêtre en cours).
  3. Association sens-comportement : on créé un second code javascript qui va explorer la page HTML pour repérer tous les liens. Il filtre les liens suivant leur type, et, pour chaque lien, s'il faut l'ouvrir dans une nouvelle fenêtre, il demande au navigateur d'intercepter les clics avec la fonction précédente.

Cette procédure utilise du javascript dit " non intrusif ". Il a deux avantages : tout d'abord vous n'avez pas à l'insérer partout au milieu de votre contenu. De plus, il se base sur une description correcte du HTML. Si ce javascript n'est pas compris par un navigateur, le visiteur restera avec une page HTML tout à fait classique totalement fonctionnelle. Javascript agit comme une surcouche pour paufiner le comportement de la page, et n'est en rien indispensable ou pertirbateur.

À titre d'information, il existe une méthode bien plus efficace et élégante pour résoudre notre problème. Elle exploite les XBL de Mozilla ou les HTC de Microsoft Internet Explorer. Le défaut de cette solution est qu'elle ne repose sur aucun standard commun et se révélera incompatible avec tous les autres navigateurs. Le code présenté ci-dessous est normalement bien plus compatible et repose sur des comportements standardisés.

Show the source Luke

L'intégralité du code javascript est fait à partir de DOM, une interface normalisée par le W3C qu'on retrouve sur la plupart des navigateurs modernes. Il ne fonctionnera par contre pas sous Netscape 4 (il doit être possible de l'adapter mais on sort alors du code simple, standard et rapide à faire). Il n'y a pas à craindre d'incompatibilité puisque de toute façon la page restera totalement utilisable, sans dégradation réelle, même si le javascript est totalement désactivé.

Baliser le contenu

Avant toute chose, ce code se base sur une description complète du contenu. Il va nous falloir catégoriser les différents liens de notre page : déterminer quels sont les liens d'aide, quels sont les liens qui mènent à des exemples, à des pages d'articles, etc. Pour qualifier les liens nous avons deux attributs, l'attribut rel et l'attribut class. Le premier est spécifique aux liens et c'est celui qui devrait avoir notre préférence. Malheureusement, si on souhaite par la suite donner un style spécifique à chaque type de lien par CSS, pour compatibilité avec MSIE il vaut mieux utiliser l'attribut class.

Dans notre cas nous cherchons à ouvrir les pages d'aide en popup. On pourra les noter ainsi :

<a class="help" href="aide.html#sujet">aide</a>

Gérer les navigateurs non standards

On utilisera de DOM quelques fonctions pour naviguer à travers la page HTML (pour repérer les liens) et quelques fonctions pour gérer les événements (clic sur les liens). Malheureusement, au niveau des événements, Microsoft joue solo et a une syntaxe non standard. Il va donc nous falloir créer deux méthodes d'abstraction pour pouvoir rester compatibles.

function addEvent(source, type, callback) {
  // fonction d'abstraction pour enregistrer un gestionnaire d'evenement
  // comprend le DOM standard, la syntaxe prorietaire MSIE, l'ancien modele HTML
  // source : objet sur lequel ajouter le gestionnaire d'evenement
  // type : type d'evenement
  // callback : fonction qui traitera l'evenement
  if (source.addEventListener){		// code standard DOM
    source.addEventListener(type, callback, false);
    return true;
  } else if (source.attachEvent){ 	// code propriétaire MSIE
    var r = source.attachEvent("on"+type, callback);
    return r;
  } else {        	// code navigateur sans support DOM-event
    eval('source.on' + type + '= callback') ;
  }
}
function getStandardEvent(e) {
 // abstraction pour recuperer un objet standard pour l'evenement en cours 
 // comprend le modele DOM standard et le modele proprietaire de MSIE
 // e : parametre recu lors de l'appel du gestionnaire d'evenement 
 // retour : objet d'evenement standard
 if (e == null && window.event) {
   // cas particulier de MSIE pour recuperer l'evenement en cours
   e = window.event ;
 }
 if (e.target == null && e.srcElement) {
   // cas particulier de MSIE pour recuperer la balise DOM cible
   e.target = e.srcElement ;
 }
 if (! e.preventDefault ){
   // cas particulier de MSIE pour empecher l'action par defaut du navigateur
   e.preventDefault = function () { this.returnValue = false ; } ;
 }
 return e ;
}

Demander l'interception des clics

Le cœur de notre application se compose de deux autres fonctions : une qui sait recevoir un événement de clic et demander l'ouverture d'une popup à la place, une qui sait explorer la page HTML pour demander l'interception des clics sur les liens d'aide.

function openLinkInPopupWhenClick(e) {
  // gestionnaire d'evenement actif lors d'un clic sur les liens
  // ouvre le lien dans une popup et pas dans une page normale
  // e : evenement de clic
  e = getStandardEvent(e)  ;
  var link =  e.target  ;
  var addr = link.getAttribute('href') ; 
  window.open(addr, '_blank', 'resizable=yes,width=200,height=300')  ;
  e.preventDefault()  ;
  return false ;
}
function prepareHelpLinks() {
 // explore le document pour rechercher les liens d'aide
 // à chaque lien, on verifie s'il a "help" dans la liste de ses classes
 // si oui, on enregistre un gestionnaire d'evenement pour le clic de ce lien
 var link, list, i ;
 list = document.getElementsByTagName('a') ;
 for(i=0; i<list.length; i++) {
   link = list.item(i) ;
   if (link.getAttribute('href') && link.className) {
     if ((' '+link.className+' ').indexOf(' help ') != -1) {
       addEvent(link, 'click', openLinkInPopupWhenClick) ;
     }
   }
 }
}

Il ne nous reste qu'à initialiser notre page en exécutant la fonction prepareHelpLinks(). Cette exécution doit être différée jusqu'à que la page soit complètement chargée, reçue et interprétée (sinon on ne trouvera pas tous les liens). On utilise donc ici aussi un événement DOM :

if (document.getElementById) {
  addEvent(window, 'load', prepareHelpLinks) ;
}

Pour faire fonctionner notre code il suffit de le regrouper dans un unique fichier javascript, et d'inclure ce fichier à l'aide d'un balise <script> dans l'entête de la page. Nous avons au final un composant qu'on peut ajouter ou retirer à volonté pour modifier le comportement de notre page, sans rien toucher au contenu lui-même, il suffit d'une ligne :

<script type="text/javascript" src="helplinks.js"></script>

Le mot de la fin

Si j'avais un mot de la fin il serait " n'interférez pas avec l'interface de vos utilisateurs, ne créez pas de fenêtre ". Maintenant, comme je sais que vous n'allez pas m'écouter, je dirai " ne cédez pas à la versionite aiguë ". Si vous utilisez un modèle où vous mixez contenu et présentation/comportement, assumez-le et arrêtez de vouloir marquer " strict " en haut de votre document uniquement pour être à la mode.

Le code développé plus haut ne devrait finalement presque jamais être utilisé. Il peut par contre vous donner un exemple concret de javascript non intrusif. Les excès passés avec du javascript partout, n'importe comment ont conduit les concepteurs modernes à fuir ce langage. Et si on se remettait plutôt à faire les choses correctement, avec une bonne séparation contenu/comportement/présentation et des composants qui s'ajoutent au HTML au lieu de le remplacer ? Le javascript est utile, il a une réelle valeur ajoutée, il suffit de bien s'en servir. Maintenant que vous avez une solution, la balle est dans votre camp.

Eric Daspet | 2004.10.30 @ 21:40

Alors, qu'en pensez-vous ?

Voici ce que vous aviez à en dire... vos impressions, recueillies à vif.

2004.10.30 @ 21:44 par DenisB.

Voilà une référence qui sera bien utile sur les nombreux forums ou ces questions de nouvelles fenêtres en doctype strict reviennent toujours !

Haut retour au début de la page

2004.10.31 @ 00:53 par Laurent Denis

Je n'ai qu'un mot: excellent !

Ah, si j'en ai un autre : merci ! (je saurais désormais quoi donner à lire à ceux qui me posent la question du target ;) )

Haut retour au début de la page

2004.10.31 @ 01:04 par Etienne

Exellentissime

A noter, tout de même, que dans le cadre d'un site commercial, une page ne s'ouvrant pas dans une autre fenêtre peut faire perdre des clients

Haut retour au début de la page

2004.10.31 @ 01:16 par ElMoustiko

Oui c'est pas mal, mais je préfère ma solution, qui n'a pas besoin d'une double version IE/'les autres'.

Je suis en train de finaliser mon script et il y a des choses supplémentaire qu'il est possible de faire pour améliorer l'interaction avec l'utilisateur, c'est simplement une checkbox 'ouvrir les liens marqués comme externes dans un nouvelle fenêtre ?' et il ne reste plus qu'a donner un look particulier aux liens class='blank' (je met ça dans mon exemple). La valeur de la checkbox contrôlant la fonction unique, inhibant ou non son action.

Si tu me le permet, je ferais référence à ce billet dans le tuto que je suis en train de réaliser à ce sujet, je pense que tes explications sont très claires et que j'aurais du mal à en faire autant.

Haut retour au début de la page

2004.10.31 @ 01:50 par Raphael

En théorie, rien à redire : tout y est.
En pratique cela revient quand-même à pondre 50 lignes de codes pour simuler (en mieux, je ne dis pas le contraire) un simple attribut target devenu déprécié en strict.

Haut retour au début de la page

2004.10.31 @ 02:08 par Dam

Raphael > donc tu n'as pas lu le début de l'article puisqu'en fait ces 50 lignes, comme tu dis, ne devraient pas exister ... on ne devrait pas ouvrir de nouvelles fenêtres tout simplement ...

Etienne > Est ce que tu peux détailler un peu plus ta remarque sur les sites commerciaux s'il te plait ?

Eric > bravo et merci :) je suis parti sans voir qui etait l'auteur, j'ai deviné juste en le lisant :)))

Haut retour au début de la page

2004.10.31 @ 02:44 par Monique

Bonjour,

> un simple attribut target devenu déprécié en strict

Ben oui Raphaël, le JavaScript c'est pour uniquement pour ceux qui persistent...
La meilleure solution finalement, c'est d'adopter le doctype qui convient à ses besoins - et de le respecter !

> une page ne s'ouvrant pas dans une autre fenêtre peut faire perdre des clients

Hum, légende ou vérité ?
Il est vrai qu'à l'époque des navigateurs ancienne génération le target_blank était présenté comme LA méthode pour ne pas perdre de visiteurs. Mais on peut aussi en perdre parce que la fenêtre initiale est noyée dans la masse, parce qu'on la ferme par erreur ou encore parce que le trop grand nombre de fenêtres ouvertes gèle le système...
Ce n'est plus le cas avec les navigateurs récents (Firefox, Opera...) et la navigation par onglets :-)

Amicalement,
Monique

Haut retour au début de la page

2004.10.31 @ 02:45 par Eric Daspet

@Raphael:
Ah non ! si c'était pour simuler un attribut target, je suis clairement pour mettre directement ce maudit attribut. Il existe, autant l'utiliser.
Dans ce code on utilise un tout autre modèle, un modèle de séparation. C'est comme si tu me disais (et je sais que tu ne le feras pas) que les CSS c'est juste X lignes de code pour simuler les <font> et autres attributs de présentation, donc que ça ne sert que parce que c'est plus court à écrire..
Le code javascript est ici d'une taille importante, mais c'est vraiment une donnée technique annexe. L'important c'est la philosophie de conception (séparation contenu/structure/comportement), les gains en réutilisation, en indépendance, en pérénité, etc.
La taille du code (pas si importante que ça tout de même) n'a elle vitruellement pas d'importance. Le fichier js obtenu est en effet indépendant du contenu. Il peut donc être mis en cache par les navigateurs au même titre qu'un logo. Son poids ne gênera pas (il est trop petit pour faire une réelle différence sur une page, et comme il part en cache on ne le multiplie pas par le nombre de page). Au final le visiteur n'auras comme surcout que 50 lignes de javascript à télécharger la première fois qu'il vient sur le site. N'est-ce pas négligable ?

@Dam:
J'ai un style d'écriture si reconnaissable ?

@ElmOustiko: pas de problèmes. Par contre du coup je penses, si tu as un code beaucoup plus court, que tu restes dans un modèle transitionnel, non ? (ça n'a rien de négatif pour moi, mais à ce moment là c'est juste que le final réalisé n'est pas le même).

Haut retour au début de la page

2004.10.31 @ 02:48 par Raphael

@Dam > si si, j'ai lu le début de l'article et je suis entièrement d'accord avec la non ouverture de nouvelles fenêtres (vivement l'utilisation massive des onglets dans tous les navigateurs dignes de ce nom).
Cependant, la question n'est pas là.

'puisqu'en fait ces 50 lignes, comme tu dis, ne devraient pas exister'
> C'est uniquement de cela que je parlais : ces 50 lignes existent et tout le code produit est bien censé reproduire le comportement du target blank, non ?

Donc tu as mal compris mon message : non aux ouvertures dans une nouvelle fenêtre, mais dommage qu'il faille passer par 50 lignes de code pour simuler proprement un target blank.
Personne n'est en cause, c'est juste un constat ;-)

PS : j'utilise la nouvelle version de tabbrowser quie j'ai configuré pour qu'il se comporte ainsi :
- lorsque le lien fait partie du même domaine, il l'ouvre dans le même
- lorsque le lien est un domaine extérieur, il l'ouvre dans un onglet différent.
Très pratique je trouve : jamais de popups, jamais de nouvelle fenêtre.

Haut retour au début de la page

2004.10.31 @ 02:57 par Raphael

@Eric : 'L'important c'est la philosophie de conception (séparation contenu/structure/comportement), les gains en réutilisation, en indépendance, en pérénité, etc.'

>> Ça c'est le gros point positif en effet et une énorme valeur ajoutée.
Créer un 'target blank' adapté aux besoins des utilisateurs est primordial.

Ma remarque est sans doute mal formulée : ce que je regrette c'est qu'on en soit venu à des codes et techniques complexes pour faire ce qui aurait dû être fait par défaut au départ... par les organismes compétents.

Haut retour au début de la page

2004.10.31 @ 05:42 par Azon

J'avoue ne pas avoir bien compris toutes les subtilités du code js que tu as écrit Eric ... mais après tout, c'est pas très grave.

J'ai décidé de me mettre au XHTML 1.0 Strict et si il est décidé que l'attribut target et toutes ces conséquences sont proscrites, alors je m'y plie. ;-) Non pas parce que je suis docile ( :p ) mais surtout parce qu'après tout, qui a dit que tous les utilisateurs devaient naviguer comme moi et aimer voir les liens externes s'ouvrir dans de nouvelles fenêtres ? Personne ... et s'il n'y avait que moi qui aimais naviguer entre toutes mes fenêtres FireFox grâce à l'alt tab ?

Les utilisateurs avertis savent comment ouvrir le lien dans une nouvelle fenêtre ... les utilisateurs débutants sont tout simplement avertis du MAJ+click via un petit message sur le site.

J'attends néanmoins avec impatience le script de ElMoustiko qui, si j'ai bien compris, pourra être une bonne alternative à mes petits messages 'MAJ+click' ;)

Perrine

Haut retour au début de la page

2004.10.31 @ 22:59 par mee2

Très bon article, bravo ! Que dire d'autre ? =)

Haut retour au début de la page

2004.11.01 @ 05:53 par Elie

Excellent article, notamment en ce qui concerne les problémes d'utilisabilité de ces ouvertures de nouvelles fenêtres.
Maintenant, je vais être un peu provocateur :
Mes sites sont généralement en XHTML 1.0 STRICT .
Mais maintenant, imaginons que pour pouvoir utiliser l'attribut Target, qui marche très bien un peu partout (mais qui pose des problèmes à de nombreux publics, je le sais bien), je décidais de changer de doctype pour du XHTML Transitionnel ?
En quoi serais-je critiquable ?
En fait, la question que je pose en arrière-plan est la suivante : d'un strict point de vue du respect des standards, un site qui utilise un doctype Transitionnel de façon conforme a t-il moins de valeur qu'un même site en Strict ?
C'est une question très intéressante vis-à-vis des professionnels : faut-il simplement respecter les standards ? ou faut-il respecter les standards stricts ?
La différence est énorme..
Vous savez comment ça s'appelle, ce que viens de faire : c'est un immonde troll ;-)

Haut retour au début de la page

2004.11.01 @ 06:18 par DenisB.

Personellement, je ne crois pas qu'un site utilisant un doctype transitionnel soit moins bien, ou de moins bonne qualité qu'un autre, utilisant un doctype strict... tout est dans la façon de coder son (x)HTML. C'est aussi simple que ça.

C'est certain que d'un point de vue de pérennité et de séparation nette entre contenu, structure et présentation, le DTD strict invite à aller plus loin que le DTD transitionnel qui lui, accepterait sans problème une présentation entremêlée et indissociable de la structure. Mais quelqu'un qui coderait son site conformément à un DTD Strict et qui, par soucis d'assumer son choix de recourir à l'attribut target, changerait son Doctype à la dernière minute pour le passer en transitionnel n'y perdrait absolument rien au change en terme de 'qualité'... si ce n'est le respect de tous ceux qui croient que le Doctype est le but à atteindre. ;)

Haut retour au début de la page

2004.11.01 @ 06:32 par Eric Daspet

C'est là que malheureusement on touche au mélange des genres. D'un coté on a la standardisation, dont le but est d'avoir une langue commune, peu importe qu'elle soit bonne ou pas. De l'autre coté on a une philosophie de création, et là on s'aventure à choisir l'une ou l'autre sur des critères de qualité.

Il me parait difficile de faire un site de qualité mais non conforme. La conformité aux standards et au langage commun fait partie des pré-requis de base.
À l'inverse, on peut faire un site de qualité correcte avec un doctype transitionnel. Même si, toujours à mon avis, une meilleure pérénité et qualité ne peut s'obtenir que via du strict.

La conformité est (devrait être) une nécessité, le modèle strict est plus un but à atteindre (pas si innaccessible que ça. Le doctype n'est lui qu'une déclaration d'intention face au modèle utilisé. Changer la déclaration d'intention n'a aucune influence (tant qu'elle n'est pas fausse), ce qui est important c'est le contenu.
Mais là on dérive pas mal et c'est un débat qui aurait bien plus de sens et d'echo sur le forum que vient de monter Raphael.

Haut retour au début de la page

2004.11.01 @ 08:41 par Benoit Piette

Hmmm.... Je vais commencer par faire un mea-culpa et avouer que ça m'arriver assez souvent d'utiliser un doctype strict et de faire des onclick='window.open(this.href);return false'. Remarquez que je le fais de moins en moins souvent, car on me le demande de moins en moins souvent.

Si je suis votre raisonnement, je ne devrais jamais utiliser de onclick, onblur, et autre binding d'évenements en (x)html et ne le faire qu'en javascript. Je comprends que l'objectif ici est de complètement séparer le comportement de la structure, objectif très louable en soit, pas toujours pratique, mais louable.... oui.

Réflichissons maintenance maintenant. L'attribut class sert ici à effectuer le lien entre l'évenement et le javascript. Pas clair, en tout cas pas pour tout le monde. Si je dois modifier le comportement d'une page d'aide, comment je peux savoir que les liens d'aide sont gérés par l'attribut class='help' ? En cherchant dans le javascript ? A ce que je sache, class sert en premier lieu pour les styles, c'est dans les standards. Oui, pour des évenement complexes (genre menu déroulant, etc) je peux m'attendre à ce que des class soient utilisés dans du javascript, mais pour un simple lien ? Si je veux trouver le css relié à un class, très simple je regarde dans le css. Si je veux trouver le javascript relié à un class, je dois me fier à la simplicité du javascript. AYOYE!!!

D'ici à ce que nous ayions une façon intelligente de faire le lien entre class et évenement du genre :

.help::click {
nomDeLaFonctionJavascriptAAppeler()
}

je vais continuer de laisser les onclick et autre binding d'évenements simples dans le xhtml strict.
onclick n'a pas été retiré du xhtml strict probablement pour cette raison.

Je pense aussi que d'écrire onclick='window.open(this.href);return false' est mieux que target='_blank', puisque c'est clair que ce qui est dans un onclick est du comportement et est dans le monde du javascript. target est du html. C'est sûr que ce n'est pas parfait au niveau de la séparation comportement/structure, mais c'est déjà un pas de franchi au niveau de la compréhension et c'est pourquoi je m'efforce d'utiliser xhtml strict. Pour arriver à une maintenance plus simple, il serait peut-être intéressant d'écrire plutôt onclick='gereEvenement(CLICK, this.class)'. De cette façon, c'est clair pour la personne qui maintient le code qu'il y a un lien entre la class et un evenement qui est définit dans le javascript. En fait, ce que je pense qu'il est important de se souvenir, est que le xhtml strict n'est pas parfait (et même loin d'être parfait) au niveau de la séparation comportement/structure et qu'il est en soit un pas dans cette direction. Je ne suis pas sûr qu'il est nécessaire d'ajouter des artifices pour améliorer cette séparation au risque de rendre la maintenance plus complexe qu'elle ne l'est déjà. (Ce qui est a comme conséquence un éloignement du standard plutôt qu'un rapporchement, le preuve : tout le javascript spécifique à IE)

A réfléchir...

Haut retour au début de la page

2004.11.01 @ 09:18 par Laurent Denis

@Elie> 'En fait, la question que je pose en arrière-plan est la suivante : d'un strict point de vue du respect des standards, un site qui utilise un doctype Transitionnel de façon conforme a t-il moins de valeur qu'un même site en Strict ?'

A quel domaine apartient cette notion de 'valeur' ? Elle me semble étrangère au point de vue 'respect des standards', justement : il n'y a pas d'échelle de valeur des DTD, mais uniquement l'exigence d'en choisir une et de s'y tenir, pour en tirer un certain bénéfice (De ce point de vue, effectivement, le bénéfice attendu du 'strict' est plus grand que celui attendu du 'transitional').

Ta question est en fait uniquement du ressort de la 'qualité', dans un sens que tu connais bien ;)

Haut retour au début de la page

2004.11.01 @ 11:00 par Benoit Piette

Pour ceux qui n’ont pas la patience de lire ma longue réponse ci haut (dans laquelle il y a bien trop de fautes d’orthographes épouvantables causées par le manque de concentration durant la relecture), je voudrais résumer en disant ceci : j’ai adoré cet article, il est très intéressant. Il y a un seul élément avec lequel je ne suis pas du tout d’accord. Et je cite :

« Si vous utilisez un modèle où vous mixez contenu et présentation/comportement, assumez-le et arrêtez de vouloir marquer ' strict ' en haut de votre document uniquement pour être à la mode. »

Le XHTML strict avec CSS2.1 permet de mixer contenu/présentation/comportement. C’est correct de le faire si on ne se fie qu’au standard. Le standard le permet, parce qu’il n’y a pas de moyen simple et compatible avec un minimum d’agent utilisateur de gérer certains éléments. Le XHTML 1.0 Strict ne force pas non plus l’utilisation du DOM Level 2.

Les événements utilisateur sont particulièrement problématiques ici, car mal standardisés et mal supportés. Il y a des événements définis dans le DOM, d’autres dans le HTML (onclick, target) et d’autres dans le CSS ( pseudo-classes), sans compter le javascript. C’est un fouillis. Pour les futurs standards on ajoute les namespace, SVG, XML Events, XML Schema, CSS 3, XHTML 2. Le tout, même pas compatible avec qqch qui peut exister. Microsoft va nous régler cela : XAML. Même le CSS va aux poubelles.

Dans un autre ordre d’idée, est-ce que c’est mal d’utiliser le XHTML 1.0 Strict, en ne mettant que les polices dans le CSS? Le fait d’avoir utilisé ce standard a au moins forcé cela et c’est définitivement mieux que rien. Comme plusieurs l’ont dit, ce n’est pas le DOCTYPE qui définit la qualité du site, mais j’avoue que cela aide un peu. Juste un peu.

Zut, je suis incapable de pondre une réponse simple et courte. Désolé.

Haut retour au début de la page

2004.11.01 @ 13:14 par Eric Daspet

> je ne devrais jamais utiliser de onclick ... objectif très louable en soit, pas toujours pratique ...

Non, il ne s'agit pas de t'imposer ta manière de coder. C'est à toi de la choisir. Si tu préfères coder en mélangeant la description du contenu et sa présentation c'est ton choix. Il est respectable, par contre ce que je conseille c'est de rester cohérent dans ce que tu utilises et de l'admettre.

> L'attribut class sert ici à effectuer le lien
> entre l'évenement et le javascript.
> ... class sert en premier lieu pour les styles,

Il est clair d'après moi que l'attribut 'rel' aurait été plus logique, si j'ai utilisé class c'est que ça permet de styler en plus à partir de la même déclaration.
Maintenant je ne suis pas d'accord. L'attribut class n'a pas pour unique but de servir aux styles. Il n'a pas non plus pour but dans mon script de faire la liaison entre l'événément et le script.
L'attribut me sert à classifier mes liens. À les séparer suivant leur rôle. Le javascript se ressert du rôle et de la classification. Le fait que cette classification se fasse avec l'attribut class n'est qu'un détail d'implémentation.
Dans les faits ça revient peut être au même mais dans l'esprit c'est à mon avis bien différent. Je n'usurpe pas un attribut de style pour faire du javascript, comme tu sembles le penser. Je m'en sers tout à fait logiquement, et le javascript lit les métas données là où elles sont.


> Si je veux trouver le css relié à un class, très
> simple je regarde dans le css. Si je veux
> trouver le javascript relié à un class, je dois ...


Si tu veux modifier le contenu tu regardes dans le fichier de contenu, si tu veux modifier le style tu regardes dans le fichier qui gère le style, si tu veux modifier le comportement tu regardes dans le fichier qui gère le comportement. Ça me semble au contraire des plus naturel.

> .help::click {
> nomDeLaFonctionJavascriptAAppeler()
> }

C'est ce à quoi je fais référence sous les termes XBL et HTC. Mais il faudra attendre encore pas mal de temps pour avoir du standard.

> Je pense aussi que d'écrire onclick='window.open(this.href);return false'
> est mieux que target='_blank'

C'est là qu'on dévie fortement. Ce n'est pas plus accessible (au contraire), pas plus 'simple', pas plus économe ... qu'y a t'on gagné ? autant utiliser les outils prévus pour.

> c'est pourquoi je m'efforce d'utiliser xhtml strict

C'est là que je ne comprend pas. Que t'apporte le strict ? pourquoi fais tu du strict ? parce que ton truc est techniquement valable, mais dans les fais tu continues à tout mélanger. Pourquoi alors met cherches tu à te conformer à du strict ? qu'y gagnes tu ?

> d'ajouter des artifices pour améliorer cette
> séparation au risque de rendre la maintenance
> plus complexe qu'elle ne l'est déjà.

Tout d'abord tu me parles de maintenance plus complexe mais je ne suis pas d'accord. Prend un site réel, je te demande du jour au lendemain de me changer le comportement d'un certain type de lien. Dans ma version tu as à lire et modifier 2 lignes de code dans un fichier d'une cinquantaine. Dans ta version il faudra que tu relise et remodifie tous tes fichiers où du code HTML apparait, que tu revérifies à la main de quel type et quel lien, et que tu fasses les modifications. Est-ce que ma version est vraiment plus complexe ?

Mais le fond n'est pas là. Ta version et la mienne ne font pas le même travail. La mienne va associer un comportement à une catégorie de lien, à un type de donnée. Ta version va associer un comportement à une donnée précise, à chaque lien un à un. La différence ne se trouve pas dans la quantité ou la complexité du code mais dans l'approche et dans l'action réalisée. Tu ne fais simplement pas la même chose.

Ce n'est pas le doctype qui définit la qualité, je le confirme. C'est pour ça que faire un doctype strict avec un onclick n'améliorera jamais rien. Par contre si tu fais une description des données et que tu associes un comportement à cette classification, la qualité et la maintenance vont s'améliorer. C'est vrai que tu utilises une première ligne avec 'strict' ou avec 'transitional', et c'est tout l'objet de cet article.


Désolé de cette réponse encore plus longue, mais si tu souhaites continuer la discussion je te propose de continuer par mail ou par le forum de Raphael, ça sera peut être un peu plus adapté qu'ici.

Haut retour au début de la page

2004.11.01 @ 14:19 par Benoit Piette

Je suis bien content que tu détruises tous mes arguments... c'était mon but en les écrivant (quoique je ne suis pas encore tout à fait convaincu sur tous les points). Faut dire que j'aime bien me faire l'avocat du diable ;-) J'aimerais bien continuer la discussion. Je vais aller faire un tour sur le forum.

Haut retour au début de la page

2004.11.01 @ 21:42 par Laurent Denis

@Eric> Une remaque à propos du choix d'utiliser l'attribut class ('Je n'usurpe pas un attribut de style pour faire du javascript, comme tu sembles le penser. Je m'en sers tout à fait logiquement, et le javascript lit les métas données là où elles sont.') : l'attribut title n'est-il pas plus indiqué s'il s'agit d'une métadonnée ?

Ah... bien-sûr, il pose le même problème de compatibilité que rel avec MSIE quand il s'agit de styler les liens, tout en étant moins pertinent... Oubliez-ça ;)

Haut retour au début de la page

2004.11.02 @ 07:50 par Aurélien

Yop
Je suis tout a fait d'accord pour dire qu'ouvrir une nouvelle fenetre n'est pas utile dans 95% des cas (voire plus). Et du coup cet article me convainc encore plus sur le sujet...
Cependant, je vois que des solutions sont proposees, et que dans certains cas, ca peut etre utile...
Donc j'ai juste une question :
pour les gens qui ne veulent pas de javascript (comme moi), il n'y a don pas d'autre moyen, en fait?

Bon c'esst de la pinaillerie, et je ne m'en servirai probablement pas, mais c'est pour info!

Haut retour au début de la page

2004.11.02 @ 08:37 par DenisB.

Bien sûr qu'il y a un moyen... tout simple même... assumer l'utilisation de l'attribut target avec un doctype XHTML 1.0 Transitionnel. ;)

Haut retour au début de la page

2004.11.02 @ 09:34 par Benoit Piette

Un des points que j'apportais dans ma réponse mal argumentée et incohérente était qu'il me semblait pas évident d'un coup d'oeil rapide dans le (X)HTML qu'il y avait un évenement rataché au liens avec un atribut class='help'. En fait je ne crois pas que ce soit un réflexe très répandu (malheureusement) de regarder dans le javascript pour rechercher le binding de ce type d'évenements (le onclick, 'in the wild' est en général directement dans le (x)html, comme le onload d'ailleurs.).

J'aimerais proposer une solution (ça se peut fort bien qu'elle soit mauvaise, je n'y ai pas tellement réfléchi, mais bon...)

Si nous ajoutions qqch du genre à l'intérieur de la balise head.

<script type='text/javascript'>
// Enregistrement des évenements pour cette page
registerEvent(FOR_CLASS, 'help', CLICK, openHelpWindow, DEFAULT_FALSE);
registerEvent(FOR_ID, 'toto', MOUSEOVER, obliterateToto, DEFAULT_TRUE);
initialiseEvents(window, ON_LOAD);
</script>

ou pour les puristes :
<!-- Initialisation des évenements pour cette page. Les évenements doivent être dans ce fichier et jamais ailleurs sous peine de se faire sermonner par le guru XHTML de votre groupe. Vous ne voulez pas que cela vous arrive à moins que vous aimiez la douleur.-->
<script type='text/javascript' src='initaliseEvents.js' ></script>

De cette façon, la personne qui maintient le code et qui n'est pas nécessairement sénior en séparation structure/présentation/comportement saura où regarder pour maintenir le code.

Le seul problème que j'entrevois au niveau de la maintenance de cette méthode est qu'il est difficile de s'assurer que personne n'ajoutera un onclick quelque part dans le (x)html. Le (x)html validera encore et il est possible qu'en ajoutant ce fameux onclick cela puisse causer des effets non désirables. C'est vrai pour pas mal tous ce qui est (x)html, mais l'ajout par exemple d'un mauvais tableaux dans le modèle strict, malgré que ce soit Mal(tm), n'aura pas ce type d'effets secondaires.

Personnellement j'aurais tendance à laisser les appels pour les enregistrement d'événements dans le (X)HTML (autour de balise scripts, évidemment), je trouve cela plus clair, mais totalement subjectif, à moins qu'il y ait beaucoup d'événements à enregistrer dans une page, et tout ce qui est 'boite noire' dans les fichiers javascript. Il ne faut pas oublier aussi les problématiques de cache qui peuvent influencer la solution.

Haut retour au début de la page

2004.11.02 @ 10:07 par Benoit Piette

<sarcasme>
J'imagine le spécialiste (x)html s'assumant :

-Spéc standards : Bon je vais m'assumer, je n'ai plus le choix je vais mettre un DOCTYPE Transitionnel.

-Dev. java: Wow, le spécialiste standard a abandonné ses crédo, il a mi un DOCTYPE Transitionnel. Tout le monde sait qu'un DOCTYPE Transitionnel n'a pas besoin de valider. Je vais mettre plein de d'attributs pas standards utilisés par mes taglibs pour gérer les menus super complexes pas utilisables, mais orienté objet.

-Dev. VB: Wooohoooo !!! Cut and paste code FRONTPAGE

- Architecte d'entreprise: Enfin, je vais pouvoir installer le CMS qui a coûte 10,000,000$ à l'entreprise et qui ne supporte pas le HTML!!

-Directeur marketing : On va rajouter du popop, des FLASH, des petites animations ahahaha!.

-Directeur TI : On va outsourcer le HTML!

- Spéc. standards : Je pense que je vais aller faire un tour sur le pont Jacques Cartier là...
</sarcasme>

Haut retour au début de la page

2004.11.02 @ 11:00 par Eric Daspet

@Benoit:

J'ai effectivement hésité à faire un truc de ce style. J'ai fini par me dire que c'était une surcharge inutile dans le cadre de cet article. Par contre l'idée n'est pas dénuée de sens. Je ne sais pas si ça vaut vraiment le coup mais ça se défend.

Pour ce qui est de quelqu'un qui met à la main des onclick en plus, jamais aucun code ne résistera si on met volontairement le bordel dedans. Maintenant mon code ne fait que remplacer l'action par défaut, c'est donc géré relativement élégament. Si tu rajoutes un bête onclick, il agira juste avant l'ouverture des popup. Si tu fais un 'return FALSE' volontaire alors ton onlick remplacera la popup (sans mon script le onclick aurait remplacé l'ouverture normale du lien). Bref, ça ne marche pas si mal.
Maintenant utiliser ce type de code pour après rajouter des onclick de partout, ça serait du gachi ;)



Haut retour au début de la page

2004.11.03 @ 01:42 par Yeca

J'ai encore pas bien compris l'utilité de persister avec un tel code JS, alors que le seul intérêt est de pouvoir dire que la page est en strict plutôt qu'en transitionnel.

Mais joli exercice de style, il est vrai. Dommage qu'il soit causé par un excès d'effet de mode, des gens qui veulent à tout prix faire du strict alors que cela ne leur apporte rien d'autre que de la satisfaction personnelle de gruger le validateur...

Haut retour au début de la page

2004.11.03 @ 02:30 par Eric Daspet

Relis plus haut Yeca, tu verras que comme toi je trouve inutile de vouloir faire toute une histoire juste pour avoir marqué 'strict' tout en haut.
Par contre le code présenté n'est pas juste un code pour gruger le validateur et marquer strict en haut. C'est comme si tu disais que les codes CSS ne sont là que pour gruger le validateur. Ici le js marche effectivement suivant la philosophie stricte, avec tout ce que ça comporte au niveau indépendance et facilité de maintenance. La seule différence avec CSS c'est le langage utilisé, mais le concept et la philosophie sont exactement les mêmes.
C'est peut être du détail, mais pour moi cette différence d'approche est fondamentale.

Haut retour au début de la page

2004.11.03 @ 02:38 par SToto98

Très bon article, vraiment très agréable à lire :-)

J'ai écris un billet au sujet de cet article sur mon blog et j'y pose quelques questions à l'auteur. J'aimerai avoir un retour de sa part si il en a le temps bien entendu :-) ici puisque je n'ai pas encore mis en place de système de commentaire (ça vas venir vite) ou direct par email.

Merci beaucoup par avance ;-)

http://stoto98.dyndns.org...

Haut retour au début de la page

2004.11.03 @ 05:02 par Yeca

@Eric : on est tout à fait d'accord, pas de problème. Mais ce que je dis, c'est que dans ta démarche de dire que le strict n'est pas fait pour ouvrir une nouvelle fenêtre, l'effort de créer ce script peut paraître inutile non ?

Haut retour au début de la page

2004.11.03 @ 08:30 par Eric Daspet

@SToto98:
Tu soulèves deux points. Le premier c'est le commercial qui cherche à imposer la solution 'nouvelle fenêtre'. Effectivement il se moque à priori de casser l'historique de l'utilisateur. Maintenant si tu lui expliques que la nouvelle fenêtre va passer au dessus de l'ancienne, que la sienne va probablement être oubliée donc non utilisée, et que le seul moyen que l'utilisateur connait pour revenir sur le site de départ (l'historique) ne marche plus. Son choix risque de devenir bien moins évident.

Sur un autre sujet, pour la direction du W3C : Déjà, non, le HTML transitionnel n'est pas amené à disparaitre. Il ne sera peut être plus dans les futures versions, mais le HTML4 et le XHTML1.0 seront encore pour *très* longtemps des normes valides, supportées et tout à fait implémentables. La mise au placard du target date de 1996, on est en 2004 et c'est toujours autant utilisé. Tu peux coder du XHTML 1.0 transitionel sans aucune arrière pensée sur la pérénité de tes fichiers.
Maintenant il te faut bien voir que l'activité du W3C n'est pas simple. Soit ils font directement tout ce qu'ils veulent comme des autistes et on a des normes inutiles car non acceptées/utilisées, soit ils mettent de l'eau dans leur vin pour faire un consensus et un accord global. L'attribut de target ne fait pas parti de la version XHTML 1.1 diffusée, mais il reste dans un module que X ou Y peut volontairement choisir. Les évolutions sont longues à mener.

Haut retour au début de la page

2004.11.03 @ 10:42 par SToto98

@Eric Daspet :
Merci pour ta réponse, je me suis malencontreusement trompé dans ton nom dans mon billet, mais c'est corrigé, je te fais mes plus plates excuses :-)
Sinon, concernant ton point de vue sur le commercial à convaincre les habitudes sont bien ancrées à ce niveau là, j'ai déjà tenté la discussion mais sans grand résultat, l'argument donné généralement étant que l'utilisateur moyen d'un site internet sais faire la différence entre une fenêtre et une autre du fait de l'habitude d'utilisation de windows et partant de là qu'il vaux mieux en ouvrir une nouvelle (dans le cas d'un lien pointant sur un autre site).
On peux aussi ajouter que le nouveau site visité peut-être plus interressant que celui dont on viens et même sans ça, il est vite fait de d'oublier l'ancien et de ne pas revenir en arrière sur l'historique alors que dans le cas d'une nouvelle fenêtre, en la fermant (à la fin de la visite donc), on retombe forcément là ou on en était du site précédent.
Bref c'est une discussion sans fin qui touche plus de l'habitude de l'internaute de se laisser guider par le site ou d'utiliser lui même les controles 'avancés' de son navigateur pour ouvrir de lui même les fenêtre qu'il souhaite.
Cela évoluera peut-être comme pour les pop-ups, à partir d'un certain abus les gens finiront par changer.
Pour le reste (XHTML transitionnel) je me faisais l'avocat du diable, je sais que les normes sont valable très longtemps, du fait même de leur utilisation d'ailleurs. et de toute manière, la compatibilité descendante des navigateurs est là pour palier tout problème.

Haut retour au début de la page

2004.11.04 @ 03:08 par David Duret

Bonjour, bravo et merci pour cet article. Je suis tout a fait d'accord avec le fait que les ouvertures de fenêtres sont plutôt à bannir mais parfois le client demande explicitement cette fonctionnalité et pour lui les arguments présentés ici ne voudrait rien dire.

J'ai me me suis donc penché sur cette histoire de nouvelle fenêtre et avait pondu le code suivant (hou, pas beau en prévisualisation...) :

window.onload = function() {
if ( document.getElementsByTagName ) {
var x = document.getElementsByTagName('a');
for ( var i = 0; i < x.length; i++ ) {
if ( x[i].className.indexOf('external') == -1 ) continue;
navigator.appName == 'Microsoft Internet Explorer'
? x[i].setAttribute('onclick', function anonymous() { window.open(this.href);return false; })
: x[i].setAttribute('onclick', 'window.open(this.href);return false;');
}
}
}

Il est exécuté au chargement de la page et ajoute un attribut 'onclick' aux liens dont la classe est 'external'. Il fonctionne bien pour ma part et je ne voit pas le pourquoi du comment de tout le code gérant les évenements ? A quoi sert-il exactement ? En effet, si, au chargement de la page, on spécifie déjà le 'onclick' des liens concernés, il n'y a plus besoin de préciser ce qui se passe pour ce type de lien au moment du clic puisque l'action à effectuée est déjà connue (avec le setAttribute('onclick'))... Merci d'éclairer ma lanterne :)

Haut retour au début de la page

2004.11.04 @ 03:36 par nanoum

je ne remets pas en cause le fait qu'il faille laisser le choix aux utilisateurs
je suis par contre convaincue que dans certains cas spécifiques et bien utilisé, le target peut s'avérer utile
je voulais juste apporter un complément sur l'évolution à venir du target
les css3 proposent l'utilisation d'une propriétée target sur les liens avec différentes options : nouvelle fenetre ou nouvel onglet, position devant/derrière la fenetre en cours qui pourraient également amener des habitudes différentes

Haut retour au début de la page

2004.11.04 @ 10:32 par Eric Daspet

@David:
et si tu as un autre javascript qui remplit une autre fonction ? et si ils essayent d'accéder tous les deux à cet attribut HTML ? la réponse tient en grande partie la dedans.

Haut retour au début de la page

2004.11.04 @ 12:52 par David Duret

@Eric : dans ce cas, pourquoi ne pas utiliser que l'interception de l'événement 'click' et de vérifier à ce moment là le type de lien (via sa classe dans le cas présent) et de l'action à effectuer ? Oui, forcément, on doit intercepter tous les liens... hum, ok je vois maintenant :)

Pour ce qui est du onload dans le script, je serais de l'avis de Benoit Piette (commentaire du 2004.11.02 @ 09:34) en ce qui concerne l'enregistrement d'une série d'evénements à traiter en passant par des 'register' préalables, si quelqu'un à déjà travailler là-dessus, je serais preneur d'info, ou si ca interresse quelqu'un, je veux bien plancher dessus avec lui.

Haut retour au début de la page

2004.11.04 @ 16:54 par Jean-François Fortin

Je viens de livrer un petit truc pour un intranet. La page de résultats ne s'ouvrait pas dans une nouvelle fenêtre. J'ai reçu de vives critiques de la part des gens qui utilisent l'application.

S'il y en avait un ou deux sur 11, j'aurais parlé de mauvaises langues. À 10 sur 11, je parle de constat général. Ces gens-là voulaient une nouvelle fenêtre qu'il n'avait pas jusque-là (l'ancienne application n'ouvrait pas de nouvelle fenêtre et ça semblait cruellement leur manquer). Semble-t-il que c'était même sur le devis (ils en ont fait la demande, m'ont-ils répété) mais je n'ai rien vu de cela.

J'ai ajouté du code pour l'ouvrir dans une nouvelle fenêtre. L'harmonie est revenue. Je les trouve un peu bizarre mais bon, c'est pas moi qui va travailler dedans.

Morale de l'histoire : arrêtez de penser ce qui est bon pour votre client. Il est assez intelligent pour vous le dire s'il n'aime pas.

Haut retour au début de la page

2004.11.05 @ 10:38 par Eric Daspet

@Jean-François:

C'est intéressant (sisi), et effectivement, le client a toujours raison. Maintenant le problème c'est que sur un site internet on a rarement des retours des utilisateurs, on a généralement des retours du chef client qui lui n'a pas forcément que des bonnes idées.
Ce qui m'intéresse par contre c'est de savoir quel est le type d'application mis en oeuvre (son but) et quel est le profil moyen de ton utilisateur.

Autre question : si tu leur avait expliquer comment ouvrir une nouvelle fenêtre avec un clic milieu (donc sans le menu contextuel) ou la gestion des tab d'un navigateur récent, est-ce que ça ne leur aurait pas convenu ?
Les nouvelles fenêtres manque fréquement sur des applications (j'oppose 'application' à 'site internet') quand on a des utilisateurs avancés qui sont ancré dans des habitudes. Attention, je ne dis pas qu'ils ont tort : quelles que soient les raisons de l'utilisateur, même si c'est par vile habitude, il a forcément raison quand il dit que ce n'est 'pas pratique'. Par contre je suis curieux de savoir ce qu'aurait donné une information des utilisateurs. Si tu as l'occasion d'essayer n'hésites pas à écrire ici le compte rendu.

Haut retour au début de la page

2004.11.05 @ 14:10 par Benoit Piette

@Eric et Jean-François

Une des plus grandes différence entre les applications intranet et Internet est que les utilisateurs d'intranet sont déjà habitués à utiliser des applications client-serveur et s'attendent à ce que les applications Web réagissent de la même manière.

Les utilisateur d'intranet sont habitués à ce de nouvelles fenêtre s'ouvrent, aux auto-tabs dans les formulaires, et beaucoup d'autres fonctionnalités évidentes en Visual Basic, faisable en Web, mais difficilement réutilisables et non standardisés, ou peu et plein de bogues. Les métaphores Web sont très différentes des métaphore client serveurs.

Par exemple pour naviguer ou rechercher de l'information dans une base de données, en client serveur on aurait un gros formulaire complexe. En Web, cela ressemblerait peut-être plus à une navigation de répertoire à la Yahoo (souvent plus simple en passant).

Quand on défini des interfaces utilisateur web, même pour un intranet, il est je pense mieux d'utiliser les métaphore Web, sinon, si les utilisateurs veulent absolument une interface de type client serveur, vaut mieux faire l'application comme un contrôle activex ou un applet Java. Sinon, je vous garanti que le projet sera over-budget. (Si le projet n'est pas trivial)

C'est pourquoi la prochaine révolution dans les interfaces Web donnera les capacités client serveur out-of-the box aux langages Web (c'est ce que je pense que veut faire Microsoft avec XAML). C'est ce que les clients corporatifs veulent.

Je sors un peu du sujet, mais bon....

Haut retour au début de la page

2004.11.11 @ 12:05 par Cédric DS

Bel article.

Je n'aime pas particuliairement les nouvelles fenêtres, au besoin, les onglets de firefox, bien commode et encore...

En effet, je n'ai pas toujours envie d'ouvrir un onglet.

Au sujet de target, je l'ai cepandant utilisé sur un projet (html 4.01 trans), non pas pour ouvrir une autre fenêtre mais pour empécher de retrouver la page du lien dans une frame. Cela m'est souvent arrivé et c'est vraiment frustrant.

Je pourrais faire un site en strict, meme xhtml, je ne l'ai pas fait du fait que l'ami pour qui je le fais devra utiliser un Wysiwyg (nvu, pour le moment) et que je n'en connais pas pour le xhtml.

Haut retour au début de la page

2004.11.13 @ 10:33 par thierry

Quel est le but d'un site ?

Qui a jamais dit dit que le but d'un site était de faciliter la navigation de l'utilisateur sur le web ? Le but d'un site n'est pas de faciliter la navigation du visiteur sur le web, mais bien de retenir celui-ci sur le site. Un des moyens d'un parvenir est d'ouvrir les liens sortants dans une nouvelle fenêtre, afin que celle de votre site reste à l'arrière-plan et que le visiteur puisse y revenir facilement.

L'usage du bouton Back n'offre pas de garanties suffisantes: le visiteur occasionnel ne va pas nécessairement revenir en arrière; le site à retrouver peut impliquer trop de retours en arrière. Il y a bien une liste déroulante associée à ce bouton, c'est vrai, mais les surfeurs lambda ne constatent pas nécessairement l'existence de cette liste, et celle-ci est d'une longueur limitée (9 items dans IE).

En fait, la fonction Back est plutôt maîtrisée par les surfeurs expérimentés, qui ont un plan de navigation, savent d'où ils viennent et où ils vont. La navigation des surfeurs lambda est souvent beaucoup plus erratique... et ils n'ont guère de notion d'historique de navigation.

L'argument selon lequel le surfeur lambda perdrait de vue un site sous l'accumulation des fenêtres est totalement fallacieux. Les interfaces graphiques comportent une Barre des tâches affichant les fenêtres ouvertes. Le surfeur peut donc aisément passer d'une fenêtre ouverte à l'autre; l'argument selon lequel l'ouverture d'une page dans une nouvelle fenêtre irriterait le surfeur expérimenté l'est à peu près tout autant. Primo, cela n'irrite guère que guère que le surfeur expérimenté fanatique des standards en toutes circonstances... ce qui constitue quand même une population beaucoup plus réduite, et son irritation sera sans doute d'origine doctrinale plutôt que liée à des difficultés de navigation.

Des sites tels que Cybercodeur se basent sur le modèle du web universitaire, un modèle basé une vision communautaire et collaborative du web, sur le partage des ressources, sur une communauté d’égaux, dans lequel l'audience d'un site est fondée sur la valeur de son contenu.

Il s'agit là d'un modèle approprié pour un site non promotionnel, qui a une démarche énonomiquement désintéressée d'expression ou de transmission d'information/mise à disposition de contenu, qui s'adresse à une communauté constituée et importante (les tenants des standards web), qui fait partie d'un réseau d'autres sites, qui a une notoriété importante... et qui a donc une audience assurée.

La problématique n'est pas du tout la même quand il s'agit de sites promotionnels ou vitrines. Il ne faut pas réduire les sites promotionnels aux sites marchands ou d'entreprises. La moindre asso, à but totalement non lucratif a besoin de se faire connaître et n'a pas nécessairement les arguments d'un site au design soigné et/ou au contenu attrayant et constamment enrichi. Que croyez-vous donc qu'elle va mettre comme attribut à un lien pointant vers le site d'Adobe pour télécharger le lecteur Acrobat Reader afin de pouvoir lire un PDF qu'elle aura mis en ligne? Un lien avec attribut target, évidemment. La réaction est évidemment la même avec un site d’asso présentant des liens pointant vers les sites de structures connexes. L'attribut target est pour elles la possibilité d'offrir aux visiteurs des liens vers d'autres sites tout en offrant la garantie qu'ils pourront revenir au leur, garantie que le bouton Back n'offre pas. Alors, ces doctes discours sur le Respect de la Liberté de l'Utilisateur et sur l'Importance de ne pas Casser l'Historique de Navigation...

Certains pourront faire remarquer qu'il ne s'agit que d'une question de DTD, que l'attribut target est proscrit en strict mais pas en transitional, et que le concepteur d'un site qui utilise l'attribut target n'a qu'a utiliser le XHTML transitional.

C'est peut-être vrai sur un plan technique, mais l'auteur condamne de toute façon l'emploi de l'attribut target comme mauvaise pratique, perturbante pour les surfeurs débutants, et agaçante pour les surfeurs avertis. Donc, concepteurs de sites, vous pouvez certainement utiliser l'attribut target en XHTML transitional, mais il n'en reste pas moins que c'est, définitivement, une mauvaise pratique en soi.

Il serait tant que les auteurs de telles opinions cessent d'universaliser leurs propres normes et valeurs. Celles-ci sont adaptées à une conception donnée du web et de leurs sites (modèle communautaire - transmission économiquement désintéressée d'opinions et/ou d'information/mise à disposition économiquement désintéressée de contenu), à un contenu intéressant et constamment enrichi et à une notoriété importante dans une communauté importante (la communauté pro-standards). Ces normes sont, dans ce cas précis, tout simplement inapplicables à des sites répondant à d'autres contraintes. Cette condamnation de l'attribut target est tout simplement ridicule.

Haut retour au début de la page

2005.01.04 @ 14:01 par Eric Daspet

@Thierry
> Le but d'un site n'est pas de faciliter la
> navigation du visiteur sur le web, mais bien de
> retenir celui-ci sur le site

Le but de ton site n'est pas de diffuser une information ou un service (donc d'en faciliter l'accès) ? si tu répond non tu as des soucis à te faire sur la pérénité de ton site, car il n'offre aucun intérêt pour l'utilisateur.

Ton but c'est de retenir un utilisateur (comprendre 'contre sa volonté' vu la connotation de 'retenir') ? quel gain y as tu ? qu'y gagnes tu ? probablement rien à part générer du traffic inutile.

> L'argument selon lequel le surfeur lambda
> perdrait de vue un site sous l'accumulation des
> fenêtres est totalement fallacieux. Les
> interfaces graphiques comportent une Barre des
> tâches affichant les fenêtres ouvertes. Le
> surfeur peut donc aisément passer d'une fenêtre
> ouverte à l'autre;

Fais donc un tour dans le support utilisateur. C'est encore peut être le plus gros éccueil dans l'interface des bureaux modernes. Quand on parle de fenêtres non déclenchées volontairement c'est encore pire.
Je ne compte pas le nombre de fois où j'ai entendu un 'pourquoi il revient à l'ancienne page alors que j'ai tout fermé ?' alors qu'il s'agit juste d'une ancienne fenêtre.
Sérieusement il y a beaucoup d'idées reçues sur les interfaces mais de ce que j'ai pu voir, le bouton 'back' est un repère, les fenêtres sont une difficulté. Ce qui m'arrange c'est que Apple qui est connu coté ergonomie a à peu près les mêmes conclusions sur la multiplications des fenêtres (le fameux exposé pour remplacer la barre des taches après s'etre rendu compte que les fenêtres étaient toutes maximisées).

> l'argument selon lequel l'ouverture d'une page
> dans une nouvelle fenêtre irriterait le surfeur
> expérimenté l'est à peu près tout autant.

Pourtant c'est globalement une constante ces derniers temps comme remarque. Je ne l'invente pas.

> Alors, ces doctes discours sur le Respect de la
> Liberté de l'Utilisateur et sur l'Importance de
> ne pas Casser l'Historique de Navigation...

En même temps tu fais beaucoup d'affirmations non argumentées là. tu dis qu'elle veut, mais tu n'argumentes nullement sur le fait que ce soit une bonne idée ou pas. C'est toujours très facile de dire 'mais non, c'est juste un discours intellectuel', mais c'est beaucoup plus difficile d'argumenter, surtout en prenant des utilisateurs réels et en ne se basant pas sur les volontés du webmaster.

Tu donnes l'impression d'être en cas spécial (pourquoi ?) ou que les sites commerciaux ont des buts différents, mais c'est une grossière illusion. Même pour un site qui a pour but de vendre (et surtout pour lui), contraindre le visiteur est rarement une bonne idée.
Sur le net les gens sont très volatiles et ce qui est quasi certain c'est que retenir quelqu'un contre sa volonté ne sert à rien sur le long terme. Si des sites comme Google ont fait réussite c'est aussi grace à leur dépouillement et à l'optique 'on donne à l'utilisateur ce qu'il cherche' au lieu de l'optique 'on lui donne ce qu'on veut qu'il prenne'.
Si tu veux des exemples plus parlant, ce vers quoi les précurseurs d'Internet s'orientent c'est ce que font Google et Amazon : faire en sorte d'offrir des services externes pour que l'utilisateur n'ai même pas besoin de passer sur le site et puisse utiliser d'autres méthodes d'accès.
Leur but c'est de fournir un produit/service, pas de générer des visites. Ils ont vite compris que plus ils facilitaient l'accès à ce service et rendaient cet accès confortable, plus ils avaient à y gagner.

Sortez de vos préjugés, demandez vous bien quel est votre but et si vous avez réellement intérêt à aller contre l'intérêt et les envies de vos visiteurs ou clients. Un client qui reste et qui revient c'est un client qui est content, pas celui qui peine et qui se sent contraint. Le milieu Internet est assez volatile pour que cette règle soit la règle la plus importante.

Haut retour au début de la page

2005.01.07 @ 02:53 par Philippe Worontzoff

Très bonne article qui, avec un meilleur code JavaScript (qui éviterais le code propriétaire pour MSIE) mériterais bien d'être sur OpenWeb. :-)

En lisant m'est très vite venu une bonne idée que je m'étonne de ne pas voir ici exploitée.

Tant qu'a utiliser l'attribut class, autant l'utiliser la technique d''ajout d'une icône pour une classe' décrite là : http://openweb.eu.org/art... pour ajouter une icone (par exemple une image où le mot 'aide' est écrit ou alors : 'nouvelle fenêtre') ou, pour qui n'aimerais pas l'idée d'une icone, simplement la ligne de css suivante :
.aide:after{content:' [aide]';}
ou
.aide:after{content:' [nouvelle fenêtre]';}

Ca (pour rappel un code JavaScript sans solution propriétaire pour MSIE et le signalement en CSS qu'une nouvelle fenêtre s'ouvre en cliquant sur le lien) et l'idée d'une checkbox désactivant ce javascript, ça serais parfait pour qui veut imiter le target'_blank' en (X)HTML strict. Ce qui, pour moi est parfaitement inutile, mais, tant qu'a proposer une solution pour ceux qui n'en démordent pas, autant qu'elle soit la meilleurs possible.

Tout ceci (code non-propriétaire, signalement en CSS et checkbox) mis en oeuvre, cette article serait un must pour OpenWeb.

Haut retour au début de la page

2005.01.08 @ 02:05 par Eric Daspet

@Philippe :

Sauf qu'il est impossible d'éviter le code propriéraire pour MSIE. Les méthodes standards n'existes pas sur ce navigateur. Alors soit on l'exclu (et on met à la porte 90% des utilisateurs) soit on prévoit le cas.

Maintenant ce n'est pas gênant : le code marche sur un navigateur standard, avec uniquement des méthodes standardisées. Où est-ce le mal de prévoir un bête 'si la méthode standard n'existe pas et que la méthode propriétaire de MSIE existe alors on l'utilise' ? ça ne gênera pas les autres (la syntaxe reste bonne et ils sauteront la condition).

Pour la CSS c'est effectivement intéressant et tu noteras dans mon article que c'est justement pour ça que j'ai choisi l'attribut class. Simplement bon ... le texte est assez long sans en plus rajouter des CSS, les possibilités sont là, à chacun de prévoir ce qu'il veut.

Haut retour au début de la page

2005.01.16 @ 18:19 par k2r6

Un beau paquet de blablah pour vraiment pas grand chose (et quel ton pontifiant de donneur de leçon, foutre de dieu).
L'utilisateur averti, qui sait si bien les ouvrir, les liens, dans des fenêtres extérieures (pas de navigateur à onglets chez vous ? encore la préhistoire, z'êtes sous Lynx ?), à mon humble avis il sait aussi les fermer ; et si c'est méchant de lui imposer une nouvelle fenêtre (quel foutage de gueule que cette démagogie de vendeur de serviettes hygiéniques : on parle pas de pop-up de merde là, simplement d'ouvrir des liens que le visiteur clique lui-même, hein) c'est carrément pas sympa de s'évanouir sans lui dire au revoir. Bref, on peut pas satisfaire tout le monde.
Mais la bonne question à laquelle personne n'a répondu, c'est : que préfère l'utilisateur (en majorité) ? (je préfère la démocratie au triste dogmatisme des standardistes de web, désolé).
A défaut de sondage, je m'en remets à mon avis éclairé : quand je suis sur ce site, c'est vrai, je ne tiens pas à rester, mais quand je suis un site ou un forum bien informé, je lis l'article, j'ouvre tous les liens qui m'intéressent (je les mets de côté si vous préférez, le temps qu'ils se chargent), puis, quand j'ai fini l'article, je le garde sous le coude, et je vais voir les liens. Ensuite, j'ajoute des favoris si nécessaires, j'insulte un imbécile pour redresser la barre et je ferme les onglets).
Une seule fenêtre à la fois, c'est pas vraiment le bonheur. C'est pas strict ? et alors ? keskeçapeubienfoutre ? Enfin, moi ça me chagrine de voir que pour être proche des diktats des standards, il faut perdre son confort. Mais j'avoue, je ne gagne pas d'argent avec ça, donc je suis pas intéressé (au sens économique).

/j'ai dit.

Haut retour au début de la page

2005.01.17 @ 09:05 par Eric Daspet

C'est dommage qu'avant de critiquer tu n'aies pas lu à fond l'article (en tout cas c'est ce que tu laisses paraitre). Où est il dit qu'il fallait enlever les nouvelles fenêtres pour les standards ? relis donc il y est dit explicitement :
''' Utilisez les outils pour ça, utilisez une déclaration de HTML transitionnel et l'attribut target. ''''.
C'est ça que tu nommes perdre le confort ?


Ceci dit, puisque tu parles de ton confort personnel, et puisque tu connais la navigation par onglet. As tu vraiment besoin qu'on les ouvres à ta place les onglets ? un clic milieu ne suffit pas ?
Ou plus précisément, quel légitimité a exactement l'auteur de la page pour savoir si *toi* tu souhaites ouvrir de nouveaux onglets ou garder le même onglet de navigation sur ce site en question ?
Comme tu le dis très bien, il y a des sites sur lesquels tu veux continuer une navigation unique et d'autres pour lesquels tu veux pouvoir explorer des recoins annexes. Puisque tu sais faire un clic milieu pour les nouveaux onglets tout seul, à quoi sert-il donc de te forcer à une nouvelle fenêtre ? Tout ce qu'on risque c'est de te forcer sur un site où justement tu voudrais l'autre comportement.

Ce n'est malheureusement pas en maniant la comparaison critique facile et sans objet que le sujet gagne en réflexion ou en argument. Merci d'éviter.

Haut retour au début de la page

2005.01.17 @ 09:59 par DenisB.

T'en fais pas Eric, le monsieur aime beaucoup brasser en public ce que nous préférons tous produire en privé dans le confort de notre salle de bain. Laisse-le gueuler tout seul, il finira bien par se lasser. Ils se lassent tous puisque derrière quelques paroles à sensations fortes, il n'y a généralement que du vent soutenu par une objectivité qui discrédite à elle seule l'ensemble de leurs propos... ;)

/j'ai dit aussi

Haut retour au début de la page

2005.01.19 @ 12:06 par Monique

Bonjour,

Puisque le sujet vient d'être relancé, je me permets de citer un sondage et une discussion intéressante sur le Hub... http://www.webmaster-hub....

Amicalement,
Monique

Haut retour au début de la page

2005.01.24 @ 22:18 par k2r6

>Eric Daspet

«As tu vraiment besoin qu'on les ouvres à ta place les onglets ? un clic milieu ne suffit pas ?»
Le bouton de ma molette est trop 'dur', je ne peux pas m'en servir. Et, puisqu'il est toujours question d'accessibilité (démagogie?), tout le monde n'a pas une souris avec bouton milieu (si, si, j'en connais). (et puis, pardon, puisqu'on pense toujours aux aveugles, pensons un peu aux amputés).
Peu importe, je voulais dire qu'il faut faire un choix (à la place de quelqu'un) et mécontenter une partie des visiteurs : soit ne rien ouvrir (pour avoir son inutile logo/lien de test, genre j'ai pas le sida, de geek en bas de page (ce qu'il faut souffrir pour être xhtml compliant)) soit accepter - mais c'est dur - d'être ringard avec des target blank tellement pratiques.

Ou plus précisément, quelle légitimité a exactement l'auteur de la page pour savoir si *toi* tu souhaites ouvrir de nouveaux onglets ou garder le même onglet de navigation sur ce site en question ?
->Mais, c'est simple : il est quand même chez lui ! Les visiteurs sont des invités de passage, point barre, hein, c'est pas le pape qui vient sur nos sites.
Et puis si on pousse le raisonnement (mais là c'est vraiment pour montrer qu'il est con, le raisonnement), on va en arriver à ce que ce soit le visiteur qui fasse ton site (: et pourquoi tu lui imposes telle palette de couleurs, et pourquoi telle police, et tel interlignage, et tel texte, etc. etc.)

Comme tu le dis très bien, il y a des sites sur lesquels tu veux continuer une navigation unique et d'autres pour lesquels tu veux pouvoir explorer des recoins annexes. Puisque tu sais faire un clic milieu pour les nouveaux onglets tout seul, à quoi sert-il donc de te forcer à une nouvelle fenêtre ?
->Je peux pas, le bouton central de ma souris est trop dure (microsoft, tsss).

Tout ce qu'on risque c'est de te forcer sur un site où justement tu voudrais l'autre comportement.
->Mais dans tous les cas il y a un truc. C'est qu'un site, et le visiteur a un CERVEAU, même un Français a un cerveau, petit certes, mais il existe.
Une bonne idée de l'ergonomie, ce n'est pas de continuellement se demander ce que veut le visiteur sinon tu n'en sors pas : ce n'est pas parce que tu as liens comme ceci ou comme cela qu'il reste/part, mais parce qu'il y a du contenu, c'est ça qui l'accroche, toujours. Règle unique : le contenu. La plupart des bons sites (avec valeur scientifique ajoutée) sont codés à l'ancienne avec des machins tout moches (http://www.chass.utoronto...).
Alors que j'en vois des tonnes de zolis dotclear vides comme une bouteille de champ à 1.00 du matin le 1 janvier, des sites, tu croirais une vitrine de Noel mais sans cadeaux à l'intérieur : du vent (je te donne pas les liens, ils viennent tous chez toi).

Ce n'est malheureusement pas en maniant la comparaison critique facile [tu le reconnais ?] et sans objet [tu le reconnais ?] que le sujet gagne en réflexion ou en argument. Merci d'éviter.
->pas de faute, j'aime bien polémiquer. Et je suis énervé par l'inversion du rapport forme/contenu : c'est le contenu qui devrait primer, et pas les feuilles de style, et vous ne faites rien pour changer cela : regarde tes rubriques : comment faire un site, formellement, rien sur les entrailles de la bête !

/ j'ai répondu.

Haut retour au début de la page

2005.02.04 @ 13:48 par Eric Daspet

Il va tout de même falloir que tu arrêtes de troller ici ;)

> je voulais dire qu'il faut faire un choix (à la
> place de quelqu'un) et mécontenter une partie des
> visiteurs

Peut être (quoique), mais si tu ne forces pas l'ouverture dans une nouvelle fenêtre il sera capable d'utiliser pleinement son navigateur. L'inverse n'est pas vrai : il n'y a pas de menu contextuel 'ouvrir dans la fenetre existante' si jamais tu lui forces la cible.


> Mais, c'est simple : il est quand même chez lui !
> Les visiteurs sont des invités de passage

Là on diverge sur la philosophie. Je fais du contenu pour les autres, pas pour moi. Dire que tu te fiche que ça ne convienne pas aux utilisateurs parce que c'est chez toi c'est oublier pour qui tu publies.

> pourquoi tu lui imposes telle palette de
> couleurs, et pourquoi telle police, et tel
> interlignage, et tel texte

Chanceux, c'est justement sur ce genre de problématiques que certains travaillent actuellement. Tu noteras tout de même que tous les navigateurs actuels ont des coches dans la configuration pour 'n'utiliser que les polices par défaut', 'ne pas utiliser les couleurs de fond', 'garder les couleurs de lien par défaut' ...
Certains ont même 'imposer une taille minimum de police', 'désactiver les styles et mises en forme' (je m'en sers souvent de celle là). Ils permettent aussi de redimensionner le texte avec la molette et plein d'autres choses marrantes.
Et mieux, le fonctionnement des polices permet même de laisser choisir l'utilisateur à quelle il veut voir le texte et ne définir que des proportions par rapport à cette taille de référence.
Le Web est fait pour permettre ce genre de choses, c'est son but à l'origine et il est toujours autant d'actualité.


> Je peux pas, le bouton central de ma souris est
> trop dure (microsoft, tsss)

La solution c'est de changer de souris ou dérouler le menu contextuel, pas d'inciter tout le monde à coder mal ;)

> mais parce qu'il y a du contenu, c'est ça qui
> l'accroche, toujours

On est d'accord, mais l'un n'empêche pas l'autre. Ce n'est pas moi qui ai besoin d'ouvrir des nouvelles fenetres pour être sur que mon visiteur restera sur mon site.
Mais bon, tu parles de contenu et tu ne le lis pas avant de le critiquer. Pour info, ce n'est pas mon site, ça n'a rien à voir avec les CSS, et celui là est loin d'être vide.
Tu te trompes de cible, et si le fait que le contenu de certains sites puisse parler de technique te gêne ... ne les lis pas.

Haut retour au début de la page

2005.03.29 @ 01:00 par Assié Nicolas

Bonjour,

J'ai trouvé l'article très intéressant pour ma part.
Il est vrai que c'est sujet à de nombreuses polémiques.

Moi pour ma part j'ai décidé de ne pas mettre d'attribut target et de passer en transitionnel ou d'essayer de coder pour que celà puisse se faire de façon 'standardisée'.
L'utilisateur si il souhaite ouvrir dans une nouvelle fenêtre peut le faire de lui même, il y a le clic droit de la souris ou le raccourci maj+click pour ça.

En revanche j'ai testé avec le validateur, en Xhtml 1.1 strict.. et les attributs targets sont passés au travers O_o .. j'ai pas compris pourquoi. Alors que quand je fais une analyse de la page spécifique de test le validateur me signalait bien les erreurs concernant l'attribut target.

Alors quand on pointe sur l'url de base du site ça fouille pas à fond dans tous les recoins ???

J'avoue être légèrement troublé par ces 2 validations différentes que j'ai obtenu. :/

Haut retour au début de la page

2005.03.29 @ 11:12 par Jonas

Bonjour,

J'ai l'impression qu'il y a un bug dans ce script quand le lien (que l'on souhaite ouvrir dans une autre fenêtre) se présente sous la forme d'une image. ex :
<a class='help' href='URL...'><img src='image.jpg' /></a>

Dans ce cas, quand on clique sur l'image, ca renvoie null sous firefox et sous IE ca affiche 'image.jpg' au lieu d'ouvrir le lien souhaité.

Si vous avez des idées pour corriger ce bug, je suis preneur :-)
(le problème doit se situer dans la fonction getStandardEvent() mais je n'ai pas trouvé comment corriger le pb)

Haut retour au début de la page

2005.06.05 @ 08:19 par Michel-Ange

Ce script ne fonctionne pas sur Mac OS X (Safari + Firefox).
Les utilisateurs Apple ne représentent certes que 3% des internautes, néanmoins, en privant ces utilisateurs d'un affichage corret des popup, pire, d'un affichage faisant planter la fenêtre principale, on passe à coté :
- des photographes
- des artistes,
- des designers
sont beaucoup utilisent des Macs.

P.S : Je ne prêche pas pour ma paroisse, concepteur de sites, je suis doublement équipé.

Si le sujet m'intrigue encore dans quelques temps, je revoierai le script.

Haut retour au début de la page

2005.07.10 @ 12:50 par Michel

bon, j'ai tout lu. c'est beau.... oui mais moi, je suis un bricoleur de sites (perso exclusivement). Avec Netlor Studio, j'en ai réalisé un. Jespère que Netlor fait du bon code. Enfin le résultat me plait bien.
Mais voici ma petite histoire...
Je cherche une location en Espagne, et je lance une recherche Google. 11500 résultats... je commence à visiter. Au quarante douzième, j'en trouve un qui me plait. Tout me convient et en plus il y a un petit lien 'syndicat d'initiative'. boff je me dis que je vais aller voir. click.... ben j'ai vu! Le site est si bien que j'ai fait le tour des webcams, visionné des circuits de promenades, relevé 5 ou 6 recettes de cuisine,je me suis penché sur le passé historique de toutes les villes avoisinantes... J'ai aussi fait un petit tour sur les liens (deux ou trois seulement)pour voir si je trouvais une meilleure location) Et quand j'ai voulu revenir pour réserver!!!
Bon 50 clics 'précédente' ou peut-être plus, en espérant ne pas dépasser et me retrouver sur les pages des sites que j'avais précedmment visité. ou alors, bien sur rechercher les dernières adresses: avec leur lot de pages de pub dans lequel je ne retrouve pas le nom de celle qui m'interesse: de toutes façons toutes les pages concernent des locations en Espagne bien sur.Et je me souviens plus du nom de la bonne 'http....' oui mais elles le sont toutes.

Ha si seulement en fermant la fenêtre j'avais pu revenir à la page d'origine.......

ben je l'ai jamais retrouvée et je vais passer mes vacances à la maison.
Vous allez me dire que je vais pouvoir en profiter pour affiner mon htlm strict. ben ça m'étonnerait et pour ne pas jouer un aussi mauvais tour à ceux qui visiteront mon site (si ça se trouve, ils ne seront pas tous aussi forts que vous) je vais mettre un bon gros append blank si jamais j'en trouve la syntaxe.(mais apparement pas chez les coupeurs de cheveux en quatre) .
c'est d'ailleurs pour la trouver que j'étais venu içi parceque cette histoire m'est réellement arrivée(sauf que j'avais l'adresse en favoris puisque je vérifiais mon site en ligne, mais j'ai réellement surfé sur le lien et j'ai abandonné, au vu du nombre de pages 'précedentes',le retour.
Allez, bien le bonjour, je vais chercher comment installer ça.
Au fait, si vous êtes vraiment passionnés de polémique, je vous conseille vivement le livre du docteur Rigolo 'de l'influence de l'homosexualité femelle sur le comportement du haneton migrateur' parceque le lien de votre contribution m'a emmené directement sur cette magnifique 'NOUVELLE FENETRE' (mais non, c'est pas un append blank.... oui, mais ça le fait. oui mais comme c'est pas écrit comme ça donc ...) bon vous voila repartis pour quelques jours les amis.Excusez-moi d'être le cheveu et affutez les scalpels.
Et encore mieux, un prévisualiser emmène encore sur une nouvelle fenêtre et quand on la ferme.... essayez donc, c'est édifiant. En tout cas j'aurais préféré un append blank qui me remmene directement ici plutot que de voir la fenêtre se fermer et me retrouver au menu général pensant que j'avais tout perdu. Mon coeur a battu bien fort jusquà ce que je me retrouve. Non pas que ce soit capital mais je souhaitais vous faire part de mes impressions et nulle envie de tout recommencer. Bon, maintenant je sais, dans cette nouvelle fenêtre il me fallait faire un page précédente(ha bon? après une prévisu?...) ça m'a pas paru évident dans une nouvelle fenêtre. La fermer pour revenir à l'origine m'aurait paru plus normal. Mais je pense que c'est ce que peut donner un bricolage de code alors que 'append blank' c'est tout simple et universel. comme un pop-up.
PS: comme j'emets des avis alors que j'y connais rien je vais surement me faire incendier. Tant pis, n'hésitez pas à améliorer ma culture, je mettrais des lunettes noires et des gants en amiante pour voir vos avis.

Haut retour au début de la page

2005.07.11 @ 06:19 par Eric Daspet

@Michel-Ange:

Possible, le script a été fait plus pour montrer comment ça marche que comme une solution prête à l'emploi. Si tu peux me pointer ce qui ne fonctionne pas je veux bien essayer de corriger mais sinon ça risque d'être difficile, n'ayant pas accès à un Mac moi-même.
Normalement les fonctions utilisées devraient passer sous Safari donc s'il y a une incompatibilité elle devrait être corrigeable facilement.

Sinon je suis très surpris que ça ne fonctionne pas sous Firefox/mac. Je penche plus vers un problème de ton coté que sur le script.

Haut retour au début de la page

2005.10.18 @ 09:40 par Nicolas

Bonjour et merci pour ce script très interressant :),

Pour ceux qui avait détecté une erreur lorsqu'une image est comprise dans le lien ex :

<a href='lienUrl'><img src='logo.gif' alt='' /></a>

Effectivement c'est l'image qui déclenche l'évènement, voici une modification de la fonction 'openLinkInPopupWhenClick' possible :

function openLinkInPopupWhenClick(e) {
  // gestionnaire d'evenement actif lors d'un clic sur les liens
  // ouvre le lien dans une popup et pas dans une page normale
  // e : evenement de clic
  e = getStandardEvent(e);
  var link = e.target;
  var addr = '';

  // Si c'est une image qui déclenche l'évènement
  if (lien.tagName=='IMG') {
     addr = link.parentNode;
  // Sinon c'est le cas standart
  } else {
     addr = link.getAttribute('href');
  }

  window.open(addr, '_blank', 'resizable=yes,width=200,height=300') ;
  e.preventDefault() ;
  return false ;
}

Haut retour au début de la page

2005.11.10 @ 14:52 par Symbolyk

On peut dire que tu as saisie le lecteur, voir même convaincu.
Avant de lire cet article et celui d'alsacreations, pour ne rien vous cacher, je ne connaissais même pas l'existence de la DTD.
Pur ma part et pour en revenir au sujet, j'utiliserais un target _blank pour les liens externes afin de ne pas perdre mon internaute.
Enfin je sai que pour revenir sur alsacreation je vais cliquer sur la petite fléche 'précédente', mais ce n'est pas le cas de tous le monde.
Je m'apprêter a opter pour le xhtml strict ton article me dis que je devrais plutôt opter pour du transitional.
Donc un grand MERCI a eric.
@+

Haut retour au début de la page

2005.11.17 @ 03:16 par Fred

même commentaires que Symbolyk..
j'étais venu sur ce site en passant par alsacreation, et en me disant: 'maintenant que je maitrise un peu mieux, et que je souhaite être respectueux des standards au sens strict, je vais faire en sorte de quitter le transitional'.

et donc, après la lecture de ce très bon article (et de la longue et intéressante discussion derrière!), la conclusion est que je vais surtout rester au transitional!!

je développe un intranet en html/php/mysql/javascript/css, et pour le confort de l'utilisateur, ya pas mieux (pour l'instant) que d'ouvrir des popup pour donner des infos complémentaires, pour remplir de petits formulaires, etc... et de mettre des liens du genre:
<a href='javascript:window.close()' onclick='window.opener.location.reload()'>Fermer</a> pour revenir à la page d'origine...
on peut sans doute contester le choix de ces langages pour une interface utilisateur web riche, mais c'est pas cher et bcp + de monde peut accéder au code source...

je vais qd même approfondir la question.
a+ merci

Haut retour au début de la page

2005.12.06 @ 08:02 par Alexandre

Bien !

Merci eric pour ce 'rappel à l'ordre' utile et formateur.

Mon site est encore loin d'être en XHTML Strict, mais j'espère y venir prochainement, et les RSS et web Services sont au programme des évolutions à venir...

Je tenais à ajouter quelques précisions car si on dit 'passer en XHTML c'est bien', certains n'y voit qu'un vague interet de 'code propre', organisation de projet, ou tentative de compatibilité pour ces navigateurs récalcitrants tenant à leurs différences...

Et bizarement, je répondrai en parti au problème des 'target'...

La problématique de dissociation
contenu / présentation / comportement
n'est pas toujours facile à mettre en oeuvre.

Première remarque, les zooms et aides contextuelles, sont un 'contenu'. Ils sont parfois inclus dans le document ou accessible dans un document externe. Dans un soucis de lisibilité on doit choisir un moyen de 'présenter' ce contenu.

Un webmaster pensera naturellement en priorité (voir exclusivement) à son public d'internaute utilisant un navigateur web dit 'standard'.

Le CSS propose à cet effet des calques dont la visibilité peut être activée à l'aide de 'comportements'. Ce même Webmaster utilisera vraisemblablement javascript pour gérer ce comportement.

Libre à lui, (ou à d'autres) ensuite d'appliquer de nouveau comportement pour acceder à ce 'contenu' depuis d'autres supports de diffusion, sachant que la 'présentation' sera elle même différente (on peut imaginer les calques d'aide mappés sur une sphère qui tournerait à la demande, idem pour les zooms).

La nouvelle fenêtre n'est donc ici nullement indispensable.

En revanche, les liens vers les sites externes posent à mon sens un autre problème, et l'apparition des onglets dans les navigateurs semble être là pour essayer de les résoudre.

Dire que l'utilisateur peut être perdu dans les 50 fenêtres ouvertes est une chose, mais y répondre par la solution des historiques est un peu dangereux. En effet, non seulement les utilisateurs débutant sont loins d'être tous familiers avec cette possibilité (à part éventuellement pour la page directement précédente), mais encore, il est souvent plus facile de réperer des fenêtres ouvertes quand elles ne sont pas trop nombreuses.
N'oublions pas non plus les sites déconseillant d'utiliser l'historique pendant un achat alors qu'on n'est plus sur d'avoir choisi le bon produit...

En Bref, le target blank n'est autre qu'un 'comportement' visant une forme de 'presentation'.

Pour bien comprendre cette notion et trouver comment l'adapter, le mieux est d'essayer de penser multisupport.
Les publicitaire de la télévision pleurent contre le zapping, et voilà que le principe même de la publicité sur Internet consiste à envoyer ses visiteurs voir ailleurs... Aucun problème quand l'économie du 1er site réside dans la publicité (il pourra en effet eventuellement toucher une commision sur les achats effectués par son visiteur sur le site pour lequel il l'a quitté).

Essayez d'imaginer votre site diffusé sur une télévision 'interactive'. Un clic pouvant correspondre à un choix dans un menu comme sur les DVD. Si vous proposez une référence à un autre film, le visiteur apréciera de pouvoir voir ce film par un lien que vous lui proposerez. Il apréciera également de trouver un moyen de revenir à votre contenu (et vous encore plus) d'un moyen ou d'un autre (touche menu de la telecommande pour revenir, mettre le doigt sur l'écran tactile dans le coin en haut à gauche où votre interface à été diminuée, ou où vous avez laissé un bouton de retour...)

Dans le cadre d'un lien vers un mini site de votre réalisation, il est facile d'y inclure une barre de navigation ou un menu permettant de passer d'un de vos sites à un autre (comme sur les web-ring).
Mais dans celui d'un lien vers un site que vous ne gérez pas... On voit parfois utilisé un système de frames (ne criez pas) avec un lien de retour vers le site d'origine dans la frame du haut (même google l'utilise pour la recherche d'images).

Maintenant, si on pousse le raisonnement jusqu'au bout et qu'on considère la visite du site exterieur comme une pause pub ou achat, ou un complement d'information de votre site, on peut revenir... aux calques...
Et oui c'est aussi simple... Le calque permet de proposer un espace pour visiter un site complémentaire du votre sur une information. A vous de bien gérer la taille de cette espace en fonction du support, il s'agira là alors uniquement de 'présentation'.

S'il n'y a aucun code dans ce commentaire, c'est qu'il n'est là que pour aider à faire abstraction du HTML tel qu'on le connaissait.

On pourrait résumer en disant, c'est tout bête, on oublie les nouvelles fenêtre et on utilise les calques. Mais la manière risquerait d'être baclée et on perdrait le potentiel de portabilité que permet le XHTML.

Commencez donc par construire votre 'contenu' en listant vos références extèrieures, textes d'aides, zoom, publicité...
Vous pouvez par exemple les regrouper en fin de document et y faire référence à l'aide d'ancre nommées.

Choisissez une ou plusieurs formules de 'présentation' de votre contenu et de ses références. Sachant qu'elle pourra toujours être personnalisable au choix, par le visiteur, en fonction du support, ou même du en fontion référent. Il peut être bon de prévoir d'être bien vu même inclu dans un calque.

Et terminez en gérant les 'comportements', en javascript, vbscript, actionscript, smil (désolé ;-))...

Pour terminer, essayez d'imaginer par exemple, comment un aveugle pourrait acceder à votre contenu, et... completez les blancs... Un texte étant plus facile à interpreter qu'une image les descriptions ne feront pas de mal...

Et pensez bien sur à nos chers téléphone et pdaphone sachant aujourd'hui atteindre des url.

Bonne chance !

Haut retour au début de la page

2005.12.09 @ 02:22 par Nicolas Gonot

Bonjour,

Après avoir posté un commentaire sur une amélioration de la fonction openLinkInPopupWhenClick(e), je me permet d'ajouter que dans les recommendations w3c ils nous donnent une façon finalement très simple d'arriver à faire ce genre de chose tout en étant compatible XHTML Strict.

<a href='url' onclick='window.open(this.href,'...','...');return false;>Titre du lien</a>

Si l'utilisateur à javascript activé cela lui ouvre une nouvelle fenêtre ou popup, et si c'est un utilisateur non voyant qui navigue sur votre site ou un utilisateur ayant désactivé javascript, le lien s'ouvre dans la même page.

Je trouve que cette solution est finalement beaucoup plus simple et nous encourage à passer à XHTML strict 1.0

Qu'en pensez vous ?

Haut retour au début de la page

2006.04.11 @ 03:05 par Ph. DMC

J'ai tout de même l'impression que cette histoire de ne pas ouvrir de nouvelle fenêtre est un peu sectaire. A-t-on vraiment des études quantifiées sur le sujet ? Bien sûr, on peut toujours faire un clic droit et s'arranger, mais je maintiens qu'un lien vers un autre site est presque toujours une bonne raison pour ouvrir une nouvelle fenêtre - sinon, ce serait comme une malhonnêteté, un plagiat. Et je ne suis pas sûr que la navigabilité en souffre.

Haut retour au début de la page

2006.05.09 @ 08:02 par Nicolas Gonot

Dans ce cas installe JAWS ou un autre synthétiseur vocal, va surfer sur quelques sites tout en fermant les yeux, et reviens nous mettre un petit commentaire. (si tu n'est pas déjà devenu fou ;)

Cependant la solution est simple comme indiqué dans mon dernier post. Utiliser javascript pour ouvrir une nouvelle fenêtre très simplement. La personne qui as désactivé le javascript ouvre la fenêtre dans la même page (cas des non voyants) sinon dans une nouvelle (la plupart des autres cas).

<a href='http://www.monsiteblabla.com' onclick='window.open(this.href,'');return false;'>Mon site blabla</a>

J'utilise ce simple morceau de code dans plus de 90 sites professionnels et je n'ais eu pour le moment aucun retour négatif ;)

Haut retour au début de la page

Les commentaires et trackbacks sont désormais fermés. Pour toute remarque, vous pouvez toujours nous contacter.

Pisteur (Trackback)

Carnet: Ouverture de liens vers une nouvelle fenêtre
Extrait: Eric Daspet a écrit un article (Liens et nouvelle fenêtre) t...
Weblog: [z720.blog]
Traqué le: 2004.11.05 @ 01:11