5568 sujets
Sémantique web et HTML
Bonjour,
Il n'y en a pas. La volonté des auteurs de HTML4 était de supprimer les frames, d'où disparition en HTML4 Strict de l'attribut target qui permet d'indiquer dans quelle frame ou éventuellement fenêtre un lien doit s'ouvrir. Je ne sais pas s'il y avait en plus une volonté de supprimer la fonctionnalité «ouvrir dans une nouvelle fenêtre», mais c'est l'effet produit.
Solutions, par ordre de préférence:
1. Ne pas ouvrir les liens dans une nouvelle fenêtre.
2. Utiliser target="_blank" en HTML4 Transitional, XHTML1 Transitional ou en HTML5.
3. Si on est en HTML4 Strict ou en XHTML1 Strict et qu'on n'a pas la possibilité de changer ou que ça ne se justifie pas... on utilise alors target="_blank" et ça fait une erreur de validation, tant pis.
Pas d'autre solution acceptable.
Modifié par Florent V. (28 Oct 2010 - 15:58)
ccom2a a écrit :
je recherche la ligne de code valide strict wC3 afin d'ouvrir un lien dans une nouvelle fenêtre.
Il n'y en a pas. La volonté des auteurs de HTML4 était de supprimer les frames, d'où disparition en HTML4 Strict de l'attribut target qui permet d'indiquer dans quelle frame ou éventuellement fenêtre un lien doit s'ouvrir. Je ne sais pas s'il y avait en plus une volonté de supprimer la fonctionnalité «ouvrir dans une nouvelle fenêtre», mais c'est l'effet produit.
Solutions, par ordre de préférence:
1. Ne pas ouvrir les liens dans une nouvelle fenêtre.
2. Utiliser target="_blank" en HTML4 Transitional, XHTML1 Transitional ou en HTML5.
3. Si on est en HTML4 Strict ou en XHTML1 Strict et qu'on n'a pas la possibilité de changer ou que ça ne se justifie pas... on utilise alors target="_blank" et ça fait une erreur de validation, tant pis.
Pas d'autre solution acceptable.
Modifié par Florent V. (28 Oct 2010 - 15:58)
(Je reprends ce message que Tony m'a tout cassé. C'est pas grave Tony, ça m'arrive tout le temps aussi.)
Donc, je disais que selon moi target="_blank" est une solution plus standard que window.open pour l'action «ouvrir ce lien dans une nouvelle vue» (on va pas dire fenêtre). Et que préférer "target=_blank" pour ça permet aux User Agents de gérer (par défaut ou par des préférences utilisateur) comment ils gèrent cette action.
Modifié par Florent V. (29 Oct 2010 - 11:10)
Donc, je disais que selon moi target="_blank" est une solution plus standard que window.open pour l'action «ouvrir ce lien dans une nouvelle vue» (on va pas dire fenêtre). Et que préférer "target=_blank" pour ça permet aux User Agents de gérer (par défaut ou par des préférences utilisateur) comment ils gèrent cette action.
Modifié par Florent V. (29 Oct 2010 - 11:10)
As-tu un exemple concret où il est plus facile de préciser à l'UA d'ignorer le target _blank plutôt que le window.open?
Je persiste à dire que c'est une solution valable, sinon plus que le target _blank. D'autant plus que l'ouverture d'une nouvelle fenêtre ou d'un nouvel onglet touche le comportement d'une page Web, ce qui est le rôle généralement réservé au Javascript.
P.S. J'ai bousillé le message à Florent. Désolé.
Modifié par Tony Monast (28 Oct 2010 - 19:21)
Je persiste à dire que c'est une solution valable, sinon plus que le target _blank. D'autant plus que l'ouverture d'une nouvelle fenêtre ou d'un nouvel onglet touche le comportement d'une page Web, ce qui est le rôle généralement réservé au Javascript.
P.S. J'ai bousillé le message à Florent. Désolé.
Modifié par Tony Monast (28 Oct 2010 - 19:21)
Tony Monast a écrit :
As-tu un exemple concret où il est plus facile de préciser à l'UA d'ignorer le target _blank plutôt que le window.open?
Oui, par exemple en utilisant l'extension TargetKiller dans Firefox. Cette extension n'est à priori pas assez sophistiquée pour gérer window.open et les cas particuliers que ça implique, ou bien ne souhaite pas le faire.
Gérer l'application de window.open au niveau d'un script utilisateur (et donc d'une extension Chrome, Safari, Opera 11, Jetpack, script GreaseMonkey ou extension Firefox simple) demande plus ou moins d'intercepter tous les appels de window.open, et de les filtrer en fonction de paramètres (dans certains cas il peut être utile de laisser passer ces appels). C'est possible (il me semble), mais plus compliqué que gérer les attributs target, et du coup peu de userscripts le font (voir par exemple "BlockTarget" pour Safari).
Au niveau des UA directement, c'est peut être mieux géré... quand ça l'est.
Firefox par exemple a des options avancées accessibles via about:config qui permettent effectivement de gérer l'ouverture dans une nouvelle fenêtre, et qui gèrent aussi bien target="_blank" (ou "_new") que window.open, avec même un peu de finesse:
http://kb.mozillazine.org/Browser.link.open_newwindow
http://kb.mozillazine.org/Browser.link.open_newwindow.restriction
Je ne sais pas trop pour les autres navigateurs. Vu que Firefox est un des plus paramétrables, je doute que la plupart proposent des options de ce genre. Donc on en revient aux userscripts, et à la facilité beaucoup plus grande de gérer l'attribut target plutôt que window.open. (Si tu ne me crois pas, je te laisse développer un userscript qui gère target, un autre qui gère window.open, et on compare?
)(Enfin, je rappelle que window.open n'est pas (encore) standard, la première tentative de le standardiser (en virant le paramètre "features" en passant) est dans HTML5.)
Merci Florent pour ces explications, cela me permet de mieux comprendre ta position.
Ce qui est intéressant, c'est que window.open n'est pas encore standardisé. Depuis le temps que cette fonction existe, je dois avouer que ça m'étonne beaucoup que ça ne fasse pas partie officiellement des standards. C’est donc un argument valable en faveur du target.
Concernant la facilité pour développer des scripts servant à bloquer le comportement des target _blank versus les window.open, je te crois sur parole. Je me doute bien que c'est plus compliqué avec window.open. Bien que je puisse admettre cet avantage sur le window.open, je reste dubitatif par rapport au fait que ce serait un argument solide pour exclure catégoriquement le window.open des solutions pour les nouvelles fenêtres. C'est quand même curieux de choisir une solution par rapport à sa facilité technique de désactivation par l'utilisateur. Si on fait tout pour que l'utilisateur puisse la désactiver facilement, aussi bien de ne pas mettre cette solution en place.
Ce que j’apprécie particulièrement d’une solution à base de Javascript est la séparation entre la structure et le comportement. Grâce à Javascript, on cible les liens qui nous intéressent, on ajoute un window.open et une information supplémentaire pour l’utilisateur pour lui indiquer le comportement du lien, comme une icône. Évidemment, on peut en faire autant en remplaçant le window.open par un target _blank, selon ses goûts personnels.
En vérité, je n’ai rien contre le target _blank en soi, et je ne crois pas non plus que le Javascript et window.open soit la meilleure des solutions, mais il n’y a à mon sens aucune raison assez importante pour exclure catégoriquement le window.open (ou le Javascript tout simplement) pour l’ouverture des nouvelles fenêtres.
Alors, je crois qu’en ordre de préférence, j’irais comme cela :
1. Ne pas ouvrir les liens dans une nouvelle fenêtre
2. Utiliser le doctype adéquat et target _blank
3. Conserver le doctype strict et utiliser un script qui ajoute window.open aux liens
Je ne suis pas d’accord d’ignorer les erreurs de validation en utilisant target _blank malgré un doctype strict. Ce n’est cependant qu’une question de principe personnel. Je préfère être valide jusqu’au bout, tant qu’à avoir fait l’effort pour le reste. Si par contre je n'aurais pas d'autres choix, j'en dormirais quand même bien la nuit.
Bon week-end!
Ce qui est intéressant, c'est que window.open n'est pas encore standardisé. Depuis le temps que cette fonction existe, je dois avouer que ça m'étonne beaucoup que ça ne fasse pas partie officiellement des standards. C’est donc un argument valable en faveur du target.
Concernant la facilité pour développer des scripts servant à bloquer le comportement des target _blank versus les window.open, je te crois sur parole. Je me doute bien que c'est plus compliqué avec window.open. Bien que je puisse admettre cet avantage sur le window.open, je reste dubitatif par rapport au fait que ce serait un argument solide pour exclure catégoriquement le window.open des solutions pour les nouvelles fenêtres. C'est quand même curieux de choisir une solution par rapport à sa facilité technique de désactivation par l'utilisateur. Si on fait tout pour que l'utilisateur puisse la désactiver facilement, aussi bien de ne pas mettre cette solution en place.
Ce que j’apprécie particulièrement d’une solution à base de Javascript est la séparation entre la structure et le comportement. Grâce à Javascript, on cible les liens qui nous intéressent, on ajoute un window.open et une information supplémentaire pour l’utilisateur pour lui indiquer le comportement du lien, comme une icône. Évidemment, on peut en faire autant en remplaçant le window.open par un target _blank, selon ses goûts personnels.
En vérité, je n’ai rien contre le target _blank en soi, et je ne crois pas non plus que le Javascript et window.open soit la meilleure des solutions, mais il n’y a à mon sens aucune raison assez importante pour exclure catégoriquement le window.open (ou le Javascript tout simplement) pour l’ouverture des nouvelles fenêtres.
Alors, je crois qu’en ordre de préférence, j’irais comme cela :
1. Ne pas ouvrir les liens dans une nouvelle fenêtre
2. Utiliser le doctype adéquat et target _blank
3. Conserver le doctype strict et utiliser un script qui ajoute window.open aux liens
Je ne suis pas d’accord d’ignorer les erreurs de validation en utilisant target _blank malgré un doctype strict. Ce n’est cependant qu’une question de principe personnel. Je préfère être valide jusqu’au bout, tant qu’à avoir fait l’effort pour le reste. Si par contre je n'aurais pas d'autres choix, j'en dormirais quand même bien la nuit.
Bon week-end!
Tony Monast a écrit :
C'est quand même curieux de choisir une solution par rapport à sa facilité technique de désactivation par l'utilisateur.
C'est pourtant un argument qui a été utilisé très souvent pour... CSS.
Ou encore pour le fait de développer le code JavaScript comme une surcouche. (Non-intrusive JS, progressive enhancement...)
Tony Monast a écrit :
Si on fait tout pour que l'utilisateur puisse la désactiver facilement, aussi bien de ne pas mettre cette solution en place.
Oh, ce n'est pas «tout faire pour», mais plutôt s'assurer qu'on utilise une technique standard qui permette ou facilite ce type d'option. Ça peut être d'autres traitements aussi: signaler les liens qui s'ouvrent dans de nouvelles fenêtres avec des styles utilisateur, par exemple.
Comme souvent avec cette logique «les standards d'abord», certains avantages décrits sont très théoriques. Mais ça reste des arguments intéressants.
Tony Monast a écrit :
Ce que j’apprécie particulièrement d’une solution à base de Javascript est la séparation entre la structure et le comportement.
Hmm. Pour moi ce comportement demandé fait partie du contenu. Je me méfie de la notion de «comportement» qu'on associe à JavaScript. La séparation contenu/mise en forme pour HTML/CSS est précise. Décrire JavaScript comme une couche «comportement» séparée est assez largement faux, car:
- HTML gère déjà du «comportement»: hyperliens, liens internes, frames (et chargement de contenu dans les frames via des liens), formulaires. Passé l'action de l'utilisateur, le traitement est fait directement par le navigateur sans qu'un script ne lui donne d'instructions, certes, mais on n'est pas dans du «contenu» à proprement parler.
- JavaScript permet de manipuler le DOM, donc le contenu. On peut générer tout le contenu en JavaScript sans jamais utiliser de syntaxe HTML. JavaScript permet aussi de faire des calculs, des traitements. Dans les deux cas on est loin du «comportement», qui se rapproche plutôt de la notion de programmation évènementielle dans un environnement où une partie des évènements sont déclenchés par un utilisateur.
Bref, dire «c'est du comportement donc c'est plus logique en JavaScript» est certes une vieille habitude, mais pour moi c'est un contresens.
L'attribut target c'est du comportement si on veut utiliser ce terme, mais au même titre que d'autres éléments ou attributs HTML. Je ne vois pas de raison impérative de remplacer ça par un équivalent JavaScript.
Le seul argument que j'aurais pour une solution JavaScript, c'est la possibilité pour l'auteur du site de désactiver ce comportement sur tout le site en changeant un script global (ou au contraire de l'activer). C'est vrai aussi pour target="_blank", mais de manière moins logique vu qu'il s'agirait de défaire ce qui est déjà fait dans le HTML (tandis qu'en comparaison une classe "new-window" ne dit rien, ce n'est qu'un repère pour un style ou un script).
(On coupe un peu les cheveux en quatre, mais c'est pas grave, on a le droit.)
Modifié par Florent V. (29 Oct 2010 - 20:19)
Florent V. a écrit :
C'est pourtant un argument qui a été utilisé très souvent pour... CSS.
Ou encore pour le fait de développer le code JavaScript comme une surcouche. (Non-intrusive JS, progressive enhancement...)
Ce n'est pas faux. En même temps, avec cette approche, on pourrait dire que l'utilisateur pourra encore plus facilement désactiver l'ouverture des nouvelles fenêtres si la solution est à base de Javascript. C’est vendredi, j’ai le droit!
Florent V. a écrit :
Oh, ce n'est pas «tout faire pour», mais plutôt s'assurer qu'on utilise une technique standard qui permette ou facilite ce type d'option.
Ça peut être d'autres traitements aussi: signaler les liens qui s'ouvrent dans de nouvelles fenêtres avec des styles utilisateur, par exemple.
Là tu gagnes beaucoup de points!
Florent V. a écrit :
Bref, dire «c'est du comportement donc c'est plus logique en JavaScript» est certes une vieille habitude, mais pour moi c'est un contresens.
L'attribut target c'est du comportement si on veut utiliser ce terme, mais au même titre que d'autres éléments ou attributs HTML. Je ne vois pas de raison impérative de remplacer ça par un équivalent JavaScript.
Mais c’est un peu là tout le but de mon intervention. Mon objectif n’est pas de dire qu’il faut impérativement remplacer le target _blank par une solution Javascript parce que c’est plus logique. Non, pas du tout! C’est plutôt de démontrer que c’est au minimum tout aussi logique et acceptable d’ouvrir les nouvelles fenêtres via Javascript que d’utiliser un bon vieux target _blank. Les comportements, c’est quand même une grande partie le rôle du Javascript, même si ce n'est pas exclusif à lui.
Bon maintenant que ce débat essentiel pour nos vies est terminé, on pourrait parler des menus en cascade exclusivement en CSS?
Florent V. a écrit :
(On coupe un peu les cheveux en quatre, mais c'est pas grave, on a le droit.)
Surtout que c’est vendredi! On peut se le permettre.
Bonne fin de journée Florent!
Modifié par Tony Monast (29 Oct 2010 - 21:12)
J'interviens juste sur le "1. Ne pas ouvrir les liens dans une nouvelle fenêtre.".
C'est un peu extrême à mon goût. Si c'est fait intelligemment (en stipulant dans le lien qu'il s'agit de l'ouverture d'une nouvelle fenêtre : cette indication ne doit pas se faire par CSS), ce n'est pas plus problématique que ça.
Hors extension (cité par Florent), il doit exister des raccourcis clavier pour gérer l'ouverture d'un lien à l'instar du "Cmd + Clic" (sous Firefox Mac) qui ouvre dans un onglet inactif. Ceci dit, ça n'empêche nullement le recours à une solution JS (si elle est implémentée correctement).
Pour le reste (débat attribut vs propriété JS), cela n'est basé que sur l'idée fumeuse que le Strict est supérieur au Transitional présente dans la tête de certains débutants.
Modifié par yodaswii (01 Nov 2010 - 10:24)
C'est un peu extrême à mon goût. Si c'est fait intelligemment (en stipulant dans le lien qu'il s'agit de l'ouverture d'une nouvelle fenêtre : cette indication ne doit pas se faire par CSS), ce n'est pas plus problématique que ça.
Hors extension (cité par Florent), il doit exister des raccourcis clavier pour gérer l'ouverture d'un lien à l'instar du "Cmd + Clic" (sous Firefox Mac) qui ouvre dans un onglet inactif. Ceci dit, ça n'empêche nullement le recours à une solution JS (si elle est implémentée correctement).
Pour le reste (débat attribut vs propriété JS), cela n'est basé que sur l'idée fumeuse que le Strict est supérieur au Transitional présente dans la tête de certains débutants.
Modifié par yodaswii (01 Nov 2010 - 10:24)
Bonjour,
Personne n'a dit le contraire non plus. C'est seulement une question de goût personnel. Pour certains, c'est l'option recommandée numéro 1, pour d'autres, la dernière. Puis ce n'est pas plus extrême que de systématiquement ouvrir les liens dans une nouvelle fenêtre sans demander l'avis à l'utilisateur.
Je ne suis pas certain de comprendre ce questionnement. Sur PC, un utilisateur peut ouvrir les liens dans une nouvelle fenêtre avec un clic-molette, avec le menu contextuel du lien ou encore CTRL+clic. Par contre, je ne sais pas si l'utilisateur peut faire l'inverse facilement, c'est-à-dire forcer l'ouverture du lien dans la fenêtre en cours même s'il y a un target _blank ou un window.open sur lui (sans extension).
En partie oui, car si les gens utilisaient le doctype Transitional pour utiliser le target _blank, les solutions alternatives à base de Javascript ne seraient sans doute jamais apparues. Il reste que le débat ne se limite pas qu'à ça. Un vendredi ennuyant, le débat peut aller jusqu'à déterminer qui doit avoir le rôle d'ouvrir des liens dans une nouvelle fenêtre : HTML ou le Javascript? La réponse n'est ni l'un ni l'autre : c'est l'utilisateur. Je dis ça en plaisantant, mais au fond, c'est une réponse sérieuse.
yodaswii a écrit :
J'interviens juste sur le "1. Ne pas ouvrir les liens dans une nouvelle fenêtre.".
C'est un peu extrême à mon goût. Si c'est fait intelligemment (en stipulant dans le lien qu'il s'agit de l'ouverture d'une nouvelle fenêtre : cette indication ne doit pas se faire par CSS), ce n'est pas plus problématique que ça.
Personne n'a dit le contraire non plus. C'est seulement une question de goût personnel. Pour certains, c'est l'option recommandée numéro 1, pour d'autres, la dernière. Puis ce n'est pas plus extrême que de systématiquement ouvrir les liens dans une nouvelle fenêtre sans demander l'avis à l'utilisateur.
yodaswii a écrit :
Hors extension (cité par Florent), il doit exister des raccourcis clavier pour gérer l'ouverture d'un lien à l'instar du "Cmd + Clic" (sous Firefox Mac) qui ouvre dans un onglet inactif. Ceci dit, ça n'empêche nullement le recours à une solution JS (si elle est implémentée correctement).
Je ne suis pas certain de comprendre ce questionnement. Sur PC, un utilisateur peut ouvrir les liens dans une nouvelle fenêtre avec un clic-molette, avec le menu contextuel du lien ou encore CTRL+clic. Par contre, je ne sais pas si l'utilisateur peut faire l'inverse facilement, c'est-à-dire forcer l'ouverture du lien dans la fenêtre en cours même s'il y a un target _blank ou un window.open sur lui (sans extension).
yodaswii a écrit :
Pour le reste (débat attribut vs propriété JS), cela n'est basé que sur l'idée fumeuse que le Strict est supérieur au Transitional présente dans la tête de certains débutants.
En partie oui, car si les gens utilisaient le doctype Transitional pour utiliser le target _blank, les solutions alternatives à base de Javascript ne seraient sans doute jamais apparues. Il reste que le débat ne se limite pas qu'à ça. Un vendredi ennuyant, le débat peut aller jusqu'à déterminer qui doit avoir le rôle d'ouvrir des liens dans une nouvelle fenêtre : HTML ou le Javascript? La réponse n'est ni l'un ni l'autre : c'est l'utilisateur. Je dis ça en plaisantant, mais au fond, c'est une réponse sérieuse.
Tony Monast a écrit :
Personne n'a dit le contraire non plus. C'est seulement une question de goût personnel. Pour certains, c'est l'option recommandée numéro 1, pour d'autres, la dernière. Puis ce n'est pas plus extrême que de systématiquement ouvrir les liens dans une nouvelle fenêtre sans demander l'avis à l'utilisateur.
C'est pas faux. Le message important que je voulais surtout faire passer reste de signaler cette ouverture à l'utilisateur (une présentation CSS ne suffit pas)
.Tony Monast a écrit :
Je ne suis pas certain de comprendre ce questionnement. Sur PC, un utilisateur peut ouvrir les liens dans une nouvelle fenêtre avec un clic-molette, avec le menu contextuel du lien ou encore CTRL+clic. Par contre, je ne sais pas si l'utilisateur peut faire l'inverse facilement, c'est-à-dire forcer l'ouverture du lien dans la fenêtre en cours même s'il y a un target _blank ou un window.open sur lui (sans extension).
Tu l'as très bien compris
: existe-t-il un moyen pour l'utilisateur de forcer l'ouverture d'un lien dans l'onglet / fenêtre courant (même si le concepteur a décidé que ce lien doit s'ouvrir dans un autre onglet / fenêtre) ?Tony Monast a écrit :
En partie oui, car si les gens utilisaient le doctype Transitional pour utiliser le target _blank, les solutions alternatives à base de Javascript ne seraient sans doute jamais apparues. Il reste que le débat ne se limite pas qu'à ça. Un vendredi ennuyant, le débat peut aller jusqu'à déterminer qui doit avoir le rôle d'ouvrir des liens dans une nouvelle fenêtre : HTML ou le Javascript? La réponse n'est ni l'un ni l'autre : c'est l'utilisateur. Je dis ça en plaisantant, mais au fond, c'est une réponse sérieuse.
Cela revient à la préférence 1 de ne pas ouvrir de fenêtre (je suis aussi cette tendance à vrai dire). Et après tes interventions, je dois avouer que, conceptuellement, l'approche JavaScript me semble plus pertinente ... l'attribut target et la validité impliquée fausse à mon goût la problématique
.