5568 sujets
Sémantique web et HTML
Bonjour,
Option 1 : Changer le doctype pour un qui supporte l'attribut target (Transitional).
Option 2 : Passer par du Javascript. Il y a des scripts disponibles qui font très bien le travail et de ton côté, tu n'as qu'à ajouter une classe aux liens ou alimenter leur attribut rel.
Modifié par Tony Monast (21 Sep 2010 - 23:05)
Option 1 : Changer le doctype pour un qui supporte l'attribut target (Transitional).
Option 2 : Passer par du Javascript. Il y a des scripts disponibles qui font très bien le travail et de ton côté, tu n'as qu'à ajouter une classe aux liens ou alimenter leur attribut rel.
Modifié par Tony Monast (21 Sep 2010 - 23:05)
a écrit :
Ah bah je ne validerais que les options 1 et (surtout la) 3... parce que la 2, c'est un peu de l'esbrouffe, non?
Je plussoie . J'ajouterai que si il s'agit d'une contrainte forte, le minimum reste de signaler aux utilisateurs que le lien provoque l'ouverture d'une nouvelle fenêtre (ça restera un peu moins dérangeant de fait).
koala64 a écrit :
Ah bah je ne validerais que les options 1 et (surtout la) 3... parce que la 2, c'est un peu de l'esbrouffe, non?
Non, ça dépend de ce que tu souhaites faire et c'est plutôt une pratique courante. Avec le script, tu cibles les liens qui doivent s'ouvrir dans une nouvelle fenêtre via leur class, leur parent ou leur attribut rel. Ensuite, dynamiquement, tu leur attaches l'événement window.open, tu leur ajoutes un joli petit icône d'ouverture dans une nouvelle fenêtre et tu peux même ajouter un petit texte (dans le title, à côté ou sous le lien pour indiquer que le lien s'ouvre dans une nouvelle fenêtre).
Je trouve au contraire cela très complet et efficace, tout en facilitant les mises à jour de ce comportement. Suffit de modifier le script central et puis c'est tout!
et pouf!
À noter que je n'utilise pas cette solution même si je la trouve très pertinente. Étant nouvellefenêtrophobe, je n'en ai pas réellement besoin.
Modifié par Tony Monast (23 Sep 2010 - 13:21)
Ah oui mais on ne s'est pas compris; je ne remettais pas en cause cette technique !
C'est plutôt le fait de rester en XHTML Strict pour, tout compte fait, faire du Transitional dans ton JS. Autant passer le doctype directement en Transitional dans ce cas. (C'est en çà que je disais que c'était de l'esbrouffe )
C'est plutôt le fait de rester en XHTML Strict pour, tout compte fait, faire du Transitional dans ton JS. Autant passer le doctype directement en Transitional dans ce cas. (C'est en çà que je disais que c'était de l'esbrouffe )
koala64 a écrit :
l'éthique même du XHTML Strict qui est justement fait pour laisser plein pouvoir à l'utilisateur.
Je ne crois pas que le XHTML Strict est là pour suivre une éthique au point de vue ergonomique. C'est plutôt le rôle des normes de qualité, et non du doctype. Je dirais même que ça n'a rien à voir du tout.
Après, je n'aime pas non plus imposer l'ouverture d'une nouvelle fenêtre, mais dans le cas où je n'aurais pas le choix de le faire, le script serait tout à fait adéquat.
Modifié par Tony Monast (23 Sep 2010 - 17:24)
J'extrapole peut-être un peu trop, certes , n'ayant eu l'occasion d'assister aux discussions du pourquoi on autorise ou non, au travers d'un doctype, l'inclusion de tel élément ou attribut.
Cela dit, ça me semble tout de même lié car j'imagine que les concepteurs d'un nouveau doctype ont bien pris des décisions en fonction de divers critères, dont l'ergonomie me semble pouvoir faire partie.
Si ce n'est pas le cas, pourquoi ne pas avoir laissé des éléments comme "marquee" ou des attributs comme "target" en strict ? Il devait bien s'agir de volontés allant, aussi, dans ce sens.
Le doctype, au final, n'est là que pour dicter des règles mais ces règles ont bien été définies selon certains principes.
Cela dit, ça me semble tout de même lié car j'imagine que les concepteurs d'un nouveau doctype ont bien pris des décisions en fonction de divers critères, dont l'ergonomie me semble pouvoir faire partie.
Si ce n'est pas le cas, pourquoi ne pas avoir laissé des éléments comme "marquee" ou des attributs comme "target" en strict ? Il devait bien s'agir de volontés allant, aussi, dans ce sens.
Le doctype, au final, n'est là que pour dicter des règles mais ces règles ont bien été définies selon certains principes.
À mon avis, et j'extrapole certainement aussi, le doctype strict n'autorise pas les frames et framesets. Hors, il me semble que l'attribut target était spécialement utile pour ces éléments. Ce qui expliquerait l'absence du target pour ce doctype.
J'ai davantage l'impression que les éléments qui ont été retiré de ce doctype l'ont été pour que tout ce qui est comportement soit géré par Javascript : window.open au lieu de target, animations en Javascript au lieu de marquee, etc..., et aussi pour ce qui est de la mise en page -> CSS.
L'éthique dont tu parles pour le XHTML Strict est plutôt pour séparer :
- comportement
- mise en page
- Structure et contenu
Ce n'est qu'une impression que j'ai, je n'ai pas non plus étudié pourquoi ces éléments avaient disparus. Disons qu'on jase pour jaser!
Je crois que Florent V serait en mesure de donner plus de précisions à ce sujet, lui qui imprime régulièrement les pages du W3C pour se faire un sandwich.
Modifié par Tony Monast (23 Sep 2010 - 18:13)
J'ai davantage l'impression que les éléments qui ont été retiré de ce doctype l'ont été pour que tout ce qui est comportement soit géré par Javascript : window.open au lieu de target, animations en Javascript au lieu de marquee, etc..., et aussi pour ce qui est de la mise en page -> CSS.
L'éthique dont tu parles pour le XHTML Strict est plutôt pour séparer :
- comportement
- mise en page
- Structure et contenu
Ce n'est qu'une impression que j'ai, je n'ai pas non plus étudié pourquoi ces éléments avaient disparus. Disons qu'on jase pour jaser!
Je crois que Florent V serait en mesure de donner plus de précisions à ce sujet, lui qui imprime régulièrement les pages du W3C pour se faire un sandwich.
Modifié par Tony Monast (23 Sep 2010 - 18:13)
Hello en retard,
Aucune idée sur le pourquoi de l'absence de l'attribut target en HTML 4.01 Strict. Peut-être, comme le suggère Tony, à cause de l'absence de frames (ni FRAME ni IFRAME) en Strict, donc jugé inutile. Peut-être aussi par condamnation implicite de l'usage de target="_blank" pour ouverture dans une nouvelle fenêtre. Mais 1998 ça commence à faire loin et je suis pas sûr que le motif de la décision soit documenté.
L'explication de Tony a une certaine logique vu la définition de target, quand même:
http://www.w3.org/TR/REC-html40/present/frames.html#adef-target
Quant à HTML5, la spec enterre les FRAME mais conserve IFRAME, et du coup dé-déprécie l'attribut target:
http://dev.w3.org/html5/markup/a.html#a.attrs.target
Le comportement de target="_blank" n'a pas l'air des masses défini (à l'inverse de toutes les autres valeurs possibles...). HTML5 dit en gros que les UA doivent créer un nouveau browsing context (avec un nom, un historique), mais ne dit rien sur le comportement exact: nouvelle fenêtre, nouvel onglet, etc., ce qui est plutôt logique. Pour finir, la spec encourage aussi les éditeurs à fournir aux utilisateurs une option pour que les liens s'ouvrent toujours dans la fenêtre en cours (les termes exacts parlent là aussi de browsing context).
Aucune idée sur le pourquoi de l'absence de l'attribut target en HTML 4.01 Strict. Peut-être, comme le suggère Tony, à cause de l'absence de frames (ni FRAME ni IFRAME) en Strict, donc jugé inutile. Peut-être aussi par condamnation implicite de l'usage de target="_blank" pour ouverture dans une nouvelle fenêtre. Mais 1998 ça commence à faire loin et je suis pas sûr que le motif de la décision soit documenté.
L'explication de Tony a une certaine logique vu la définition de target, quand même:
http://www.w3.org/TR/REC-html40/present/frames.html#adef-target
Quant à HTML5, la spec enterre les FRAME mais conserve IFRAME, et du coup dé-déprécie l'attribut target:
http://dev.w3.org/html5/markup/a.html#a.attrs.target
Le comportement de target="_blank" n'a pas l'air des masses défini (à l'inverse de toutes les autres valeurs possibles...). HTML5 dit en gros que les UA doivent créer un nouveau browsing context (avec un nom, un historique), mais ne dit rien sur le comportement exact: nouvelle fenêtre, nouvel onglet, etc., ce qui est plutôt logique. Pour finir, la spec encourage aussi les éditeurs à fournir aux utilisateurs une option pour que les liens s'ouvrent toujours dans la fenêtre en cours (les termes exacts parlent là aussi de browsing context).
Salut, et pourquoi pas conserver un Doctype strict avec l'attribut target à partir du moment ou ça n'entraine aucun problème pour l'utilisateur? Vous le savez tous la validité n'est pas une fin en soi, juste un outil. A mon avis, mieux vaut passer directement au HTML5 si on veut rester valide que retrograder avec un doctype transitionnal et toute sa logique d'implémentation dépassée (tout comme le HTML4 strict d'ailleurs) et qui remonte à 1999.
Modifié par Hermann (04 Oct 2010 - 13:53)
Modifié par Hermann (04 Oct 2010 - 13:53)
Tony Monast a écrit :
AzRaElDGT,
[...] le Javascript ajoute l'attribut target _blank au document, ce qui au final rend le document invalide. [...]
Je t'avouerais que je suis plutôt septique la... Pour moi ca passe au validateur, car c'est du javascript qui s'exécute sur onclick on en revient au même qu'avec windows.open qui ne pause pas de problème de validation, Mais cette méthode à le gros avantage de conserver la balise a et le href dont les moteur de recherche sont si friand.
Le validateur est là pour détecter les erreurs dans le code HTML. Si le Javascript vient modifier le code HTML à la volée, le validateur ne le sait pas, donc ne détecte aucune erreur.
Si tu récupères le code HTML généré après le traitement du Javascript et que tu le passe au validateur, il va hurler.
Ce n'est pas du tout comme le window.open.
Modifié par Tony Monast (06 Oct 2010 - 22:33)
Si tu récupères le code HTML généré après le traitement du Javascript et que tu le passe au validateur, il va hurler.
Ce n'est pas du tout comme le window.open.
Modifié par Tony Monast (06 Oct 2010 - 22:33)
Tony Monast a écrit :
Si tu récupères le code HTML généré après le traitement du Javascript et que tu le passe au validateur, il va hurler.
Ce n'est pas du tout comme le window.open.
Pas vu pas pris....
Non je rigole... Je dois reconnaitre que ton raisonnement tien la route. Toute fois si je n'ai pas le choix c'est quand même cette solution que je préfère (pour le référencement), et il me semble que le target allé redevenir valide...
Az
Alors pourquoi ne pas tout simplement utiliser ceci :
C'est parfaitement valide, avant et après le traitement de Javascript. Il y a même des scripts disponibles où tu peux faire un truc comme :
et le script se charge d'attacher le onclick (window.open) à la volée sur les liens ayant cet attribut. Tu peux aussi cibler les liens selon leur classe ou leur parent.
Je dirais même : Pourquoi ne pas utiliser le doctype adéquat pour utiliser le target _blank, et éventuellement le changer pour le nouveau doctype HTML5 qui permet le target _blank?
<a href="tonlien.htm" onclick="window.open(this.href);return false;">Texte</a>
C'est parfaitement valide, avant et après le traitement de Javascript. Il y a même des scripts disponibles où tu peux faire un truc comme :
<a href="tonlien.htm" rel="external">Texte</a>
et le script se charge d'attacher le onclick (window.open) à la volée sur les liens ayant cet attribut. Tu peux aussi cibler les liens selon leur classe ou leur parent.
Je dirais même : Pourquoi ne pas utiliser le doctype adéquat pour utiliser le target _blank, et éventuellement le changer pour le nouveau doctype HTML5 qui permet le target _blank?