Salut,
 
J'espère que je ne lance pas un nouveau troll... C'est pourquoi je vous avertis tout de suite : j'ai lu la FAQ et je sais comment remédier au target manquant
 
Mais je me pose quand-même les questions :  
Pourquoi l'attribut target n'est-il pas autorisé en XHTML ?  
Pourquoi est-ce mal ?  
En quoi est-ce mieux de bidouiller et de passer par javascript (désactivé chez 11% des internautes) ?
 
(finalement, je crois que je tiens un troll quand-même   )

target servait à 2 choses :
 
- ouvrir des nouvelles fenêtre. Tu manipules donc des éléments du navigateur, c'est donc le rôle de JavaScript ;
- accéder à des frames. Vu qu'il n'y a plus de frames en XHTML 1.1, plus besoin de target pour ça.
 
Conséquence de ça : suppression de target.

Ben moi je veux simplement faire un lien de mon site vers le site du W3C... je trouve un peu dommage d'avoir recours à du js pour ça

Il faut comprendre à quoi sert le XHTML. Le XHTML va être amené à être affiché sur des médias tels que des PDA, des téléphones mobiles, des navigateurs vocaux ou des portes de frigo ( ), bref des tas de navigateurs où la notion de fenêtre n'existe pas forcément. Partant de là, il n'y a aucune raison que du code XHTML contienne une information spécifique à UNE catégorie de navigateurs.
 
Si tu veux ouvrir une nouvelle fenêtre, tu dois utiliser une méthode propre au navigateur qui supporte l'ouverture de fenêtres. JavaScript sert à ça et doit être utilisé.

Une technique avec la DTD qui va bien ?
http://www.zeldman.com/daily/0503a [...] lyspeaking

Ben disons que philosophiquement, j'accroche pas :
 
- X(HT)ML est sensé être multi-compatible sur tous les supports... même un PC, enfin j'espère !!!
Or là, si je dois utiliser du js, ce sera moins accessible qu'avant puisqu'une bonne partie des internautes n'ont pas js activé.
 
Je veux bien que mon code soit compatible sur un frigo ou autres browsers sans fenêtres... mais il n'en demeure pas moins que la plupart des internautes surferont à partir de leur PC et si le XML ne tient pas compte de ça, c'est un grave manquement à l'accessibilité puisqu'il prive une large majorité à cette fonction

Normalement c'est l'utilisateur qui doit décider s'il doit ouvrir une nouvelle fenêtre.
Perso j'aime pas quand ça le fait d'office
J'aime mieux choisir entre un Tab, une fenêtre ou le tab courant.
En plus, en observant des utilisateurs lambda en train de surfer, j'ai remarqué qu'une bonne partie étaient perdus quand le "Précédent" était désactivé, suite à une ouverture de nouvelle fenêtre.

 
si le JS est fait par un porc, oui
Sinon ils auront juste un lien qui s'ouvre dans la même fenêtre, et donc ne perdront rien :
 
<a href="bidule.html" onclick="window.open('bidule.html';return false;">bidule</a>
 
(stop aux boolays qui mettent <a href="#"> , parce que ça on peut pas l'ouvrir dans un tab manuellement)

 
"target" n'est pas non plus valable en XHTML 1.0 Strict (en HTML 4 je ne sais pas), et pour un site avec des frames, c'est lourd

 
bah les frames sont interdites en 1.0 strict donc ça me paraît logique
En Transitionnal il est permis

 
Ca se met pas dans un DTD Frameset les déclarations de frames ?  

ha ouais, bhen tu mets ton doc en transitionnal alors pour avoir le target

Oui mais XHTML ça ne sert qu'à structurer des données. C'est tout. Point. Terminé. Rien d'autre. Nada. Niet.
Tout ce qui concerne la présentation (et l'ouverture dans une nouvelle fenêtre concerne la présentation) ça n'a RIEN à faire dans le code XHTML.

Tu te méprends sur le terme "accessible". Ouvrir un lien dans une nouvelle fenêtre est tout sauf accessible. D'où la nécessité, si on veut utiliser JavaScript, de bien écire les liens (voir le post de HotShot, aka W3CCompliant sur Clubic)
 
S'ils ont désactivé JavaScript on peut raisonnablement penser qu'ils ne souhaitent pas voir apparaître de nouvelles fenêtres. Si le lien est bien écrit ils pourront quand même accéder à la page.

Oui, c'est a priori une solution très élégante, mais vu que les navigateurs ne tiennent pas compte des DTD ajoutées, leur comportement demeure incertain

 
Je vois pas le probleme ? On n'a pas attendu le js pour faire des liens en HTML que je sache ? Et puis je suis comme beaucoup d'autres ici : je ne supporte pas que ce soit le concepteur du site web qui decide de la facon dont JE dois naviguer.
 

Kristoph > je suis entièrement d'accord sur le principe et je déteste les popups également.
 
Mais là, la question est différente : sur mon site, je parle des stats du W3C et je propose mes sources en lien.
Je trouve ça très peu pratique de rester dans la même fenêtre.
En étant utilisateur, je trouverais plus pratique que le lien s'ouvre dans une nouvelle fenêtre, afin de ne pas empêcher ma visite du site initial.

 
bhen libre à toi de le faire
menu contextuel dans IE, combinaison de touches ou autre bouton de souris dans les vrais browsers

OK, donc quoi qu'il arrive, ce que dit le W3C c'est bien  

Dans cette idée, il y a cette méthode que se base sur l'attribut "rel" mais ça fait appel à JavaScript quand même. Mais c'est pas mal car on fait la différence entre liens internes et liens externes : http://www.sitepoint.com/article/1041

Bouhouhou j'ai pas été convaincant

 
Pour chaque erreur au validateur ils abattront un membre de ta famille.  

 
Ce serait déjà mieux, mais je ne pense pas que ce soit suffisant. Faire une présentation differente résoud un problème mais en crée un autre : l'utilisateur lambda risque de ne plus reconnaitre les liens sur ton site. Dans le meilleurs des cas, il va confondre les liens dans une nouvelle fenètre avec les liens déjà visités.
 
Pour l'attribut title, ce n'est pas une bonne idée non plus à cause du délai obligatoire entre le moment ou tu pointes sur le lien et le moment ou le tooltip apparait.
 
Une bonne solution je pense serait de fournir un lien en 2 parties : le lien normal plus une petite icone juste après qui elle ouvre une nouvelle fenètre. Mais serieusement, trouvez vous un vrai navigateur et plus besoin d'artifices comme ça ! ( click milieu de souris sous Mozilla rules )

ouais, un truc avec la pseudo class before.
 
ah merde non, IE la gère pas

 
 
L'objet du post me semble étrange...
 

ce topic...
 
le mec demande en substance pkoi le XHTML lui interdit de faire :  
1) du code sale
2) des popups chiants

 
Hey, tapez pas si fort !    Je rappelle que je suis tout à fait POUR le principe des standards et de l'accessibilité, d'ailleurs j'essaye moi-même de m'y mettre.
 
Par contre, C'EST SUR CE POINT PRECIS que je n'accroche pas.
 
1) En quoi l'attribut Target est-il sale lorsque l'internaute est au courant que son lien va s'ouvrir dans une autre fenêtre ?
 
2) Popup ? As-tu lu ce que je voulais faire ?
 
Imaginons que je sois un lecteur assidû...
Je suis en-train de lire un livre.
Dans ce livre, je trouve une citation intéressante ainsi que la source. Je veux en savoir plus.
Il me parait logique d'aller chercher mon dictionnaire (un autre livre) pour avoir mes infos.
 
Dans l'idée, c'est exactement ce que je veux faire. En quoi est-ce sale ?
 
PS : pitié, pas le goulag ! Je préfère encore assister à un concert de Rika Zaraï !  

C'est simple. Tu vas écrire sur une feuille 200 fois la phrase suivante :
 
     "Le XHTML ça ne sert qu'à structurer un document."
 
Et tu verras la lumière apparaître
 
 
Je ramasse les copies demain.

 

 
J'addore cette analogie

Mais dans ton exemple, tu "ments" à ton visiteur en lui faisant croire que les annexes se trouvent dans ton bouquin.  
 
Ben c'est justement la différence : moi je ne "ments" pas à l'internaute, je lui indique simplement ma source de ma citation. Il me paraît logique qu'en cliquant dessus, il trouve le dico ... et il n'est pas surpris puisque c'est lui qui décide d'aller ouvrir le dico
 
Du coup, en ouvrant le dico à l'intérieur de mon livre, le visiteur voudra peut-être voir quelques autres citations et devra cliquer 10x sur précédente pour revenir au livre. Super ergonomique !
 
Autre chose : si mon bouquin contient une partie annexe avec plein de références bibliographiques, il faudrait que tous les livres soient contenus DANS mon bouquin ? Wouaw !

Ben oui, mais en quoi l'attribut Target t'empêcherait de "structurer" ton document ?
 
Bon allez, j'abandonne : le W3C tout puissant a parlé : "Target c'est mal"
 
C'est logique, pratique et ergonomique pour ce que je veux faire... mais c'est mal. Point

 
il n'empèche pas, il est en plus, or le "Le XHTML ça ne sert QU'à structurer un document."
 
c'est peut-être plus clair comme ça

Et de forcer la taille des polices, ça ne modifie pas le comportement et ce n'est pas anti-accessible ?    
Ah bon, c'est autorisé par le W3C ?  

ca c'est du CSS, pas du XHTML

hotshot et gizmo >
 
Alors là il va falloir être très explicite avec moi :
 
Dans ma naïveté, je croyais que XHTML servait à séparer la structure de la mise en forme... et qu'il était donc intimement lié aux CSS.
 
Comment peut-on faire (proprement) du XHTML sans CSS ?
 
Question subsidiaire : si le target est interdit en XHTML, il ne le serait pas en CSS, j'ai bien suivi ?

 
bah tu n'as pas de mise en forme dans ce cas
 

 
Y a pas de rapport avec le CSS
XHTML -> contenu/structure
CSS -> mise en forme
JS -> comportement du browser et de ses objets (ouvrir une nouvelle fenêtre en fait partie)

Heu.... je crois qu'on ne s'entend pas sur le sens du mot "structurer". Structurer un document c'est définir des sections, des titres, des paragraphes et surtout dire dans quel ordre le tout doit s'afficher sans aucune présentation CSS.
 
Toi tu sous-entends qu'il devrait y avoir une strucure entre un document A et un document B en lien de A. Ce n'est pas de ça qu'il s'agit. La structure de A concerne A et lui seul. Idem pour B.

Mouais, la solution avec JavaScript n'est guère plus lourde hein :
 

 
Et je répète ceux qui ont désactivé JavaScript ne veulent sûrement pas entendre parler de popups... Donc tout est bien qui fini bien

hotshot > je parlais bien évidemment d'un document AVEC mise en forme

Cette explication me convient bien
En clair : chacun a son rôle et personne ne marche sur les plates-bandes de l'autre.
Même si vous aviez tous essayé de me l'expliquer, je comprend mieux avec cette méthode : le target n'a pas été "interdit", il est simplement passé d'une partie à une autre.
 
Ce que je ne comprenais pas, c'était que js faisait partie d'un document XHTML...
 
Merci pour votre baby sitting en commun, je vais bien mieux à présent  

 
- les balises <hx> servent à la mise en forme des titres
- les balises <p> servent à la mise en forme des paragraphes
etc...
 
Maintenant, tu par mise en forme, tu entends la mise en forme que TU veux, alors là non, et c'est justement à quoi sert le CSS.
 
Le XHTML est un squelette sur lequel vient se greffer le corps du message. Tu es fait comme tu es. Maintenant, si tu veux te teindre les cheveux en rouge ou te faire un tatouage, c'est TOI qui fait la démarche, pas la nature.
Pour le XHTML, c'est pareil.

Oui, mais c'est parce qu'elles sont déjà pré-formattées (taille de police, interlignes), non ? (c'est un peu comme si elles possédaient leur CSS de base)
Je dirai qu'elles servent plutôt à la structure qu'à la mise en forme... mais je ne veux pas lancer un nouveau sujet chaud