Comment supprimer la bordure (bleue) autour des images de lien ?

Personnelement j'utilise la balise <code> mais en allant sur les pages d'openweb et pompage, ils utilisent la balise <pre>.

Pas de remarque particulière, si ce n'est que la balise ADDRESS prend deux "D" (l'orthographe est correcte dans la citation que tu as dû copier de la page du W3C, mais pas dans ton texte et tes exemples).

En tout cas ces précisions sont intéressantes.

Merci Sylvain, je fais les corrections nécessaires ;)

j'utilise ADDRESS (mais plutot pour la snail mail que l'e- ) et CODE (pour les programmes et garder l'indentation)
par ailleurs la face sémantique de l'html me parait bien pauvre pour etre réellement utilisable au dela de ce qui est vraiment mise en page et structuration de document (h*, p, ...)

Pour répondre à ta question: c'est sûr que du code est toujours tapé au clavier, sauf s'il a été autogénéré. Je pense que <kbd> est plutôt utilisé pour les entrées au clavier dans un environnement interactif comme un shell, ou un programme en console qui demande de taper des choses de manière générale.
Ensuite, <tt> a très peu de valeur sémantique, donc pas là. Quant à <pre>, n'en parlons pas (même argument en pire).
Pas <var> pour tout le code, par contre pourquoi pas pour les variables à l'intérieur de ce code, ce qui permettrait une mise en évidence de celles-ci avec l'aide de la feuille de style.
L'utilisation de <samp> me paraît justifiable.

Au final mon coeur balance entre <samp> et <code>, avec l'utilisation sans hésitation de <var> autour des variables.

<code> et <pre> sont complémentaires :

<pre> est un élément-bloc : il permet de baliser une séquence de code répartie sur plusieurs lignes, en conservant son formatage original. Imaginez par exemple que vous vouliez montrer comment on doit se servir de l'indentation dans un code bien écrit : <pre> est loin d'être inutile ;)

<code> est son complémentaire en-ligne : il permet de baliser un bref extrait de code incorporé dans une phrase.

Employé dans ce contexte, <samp> ajoute un sens supplémentaire à <code> et à <pre>. On écrira :

Vous devez utiliser l'élément <code>h1</code> pour baliser votre texte. Par exemple <samp><h1>...</h1></samp>...

<var>, comme tu le faisais remarquer, se révèle pratique pour supporter économiquement une règle CSS mettant en valeur les noms de variable dans le code.

Concernant la balise dfn :
Es-tu sûr que cette balise s'applique à la *définition* d'un terme, et non pas plutôt à *ce terme lui-même* ? Ton exemple deviendrait :

un <dfn>blog</dfn> est un site Web personnel composé essentiellement d'actualités, publiées au fil de l'eau...

Par ailleurs, le texte encadré par dfn apparaît, en l'absence de stylage css bien sûr, en italique et non en gras.

Quel intérêt alors à utliser cette balise, direz-vous ? A mon sens, peut-être marquer qu'un terme va faire l'objet d'une définition dans la suite du texte. Ou, si cette définition n'est pas donnée dans le corps du texte, permettre de la donner dans un title associé à cette balise.

j'ai dernièrement utilisé la balise kbd pour indiquer les accesskeys dans une charte d'accessibilité ( ca me semble plutôt approprié )

raphaël >

dir indique le sens de lecture, bdo affiche son contenu dans la direction indiquée à la balise dir
<bdo dir="rtl" title="alsacreations.com">alsacreations.com</bdo>
différe et produit un affichage différent de :
<div dir="rtl" title="alsacreations.com">alsacreations.com</div>

( suis en train de faire un tuto sur la gestion des langues dans un document xhtml pour Incongru:LaNouvelleFaq, à paraitre peut-être à la fin du week-end )

@Laurent Denis > concernant SAMP et CODE, j'avoue que je suis sceptique : je n'interprête pas les spécifications comme toi apparemment. Selon ce que j'en ai lu, CODE est un code retranscrit entièrement alors que SAMP (échantillon, à ne pas confondre avec "exemple") ne serait qu'une partie d'un code et non un exemple comme dans ton utilisation. Question subsidiaire : dans quels cas utilises-tu TT ? ;)

@Ndeko > L'exemple que j'ai donné apparait sur l'une des sources citées, mais il se peut que cette source se trompe. Merci pour les rectificatifs, je vais les faire.

@simOn > Intéressante utilisation de KBD en effet. Merci également pour les explications concernant BDO

Ndeko a raison je crois : <dfn> encadre le terme qui est défini en ligne.


Concernant <samp>, je crois que c'est plutôt l'“output” d'un programme alors que <code> est la source.

Et on peut evidemment mélanger toutes ces balises pour encore plus de sémantique.
Exemple : "Tapez <kbd>!last <var>logiciel</var></kbd> pour obtenir la dernière version du logiciel..."

Pour DFN, le W3C n'est vraiment pas très loquace : www.la-grange.net/w3c/htm...
"Indique qu'il s'agit de l'instance définissante du terme englobé".

Je pense finalement que TOUT doit faire partie de la balise, par exemple :
<dfn>dfn : Permet de créer une définition</dfn>
Mais j'avoue que je ne trouve aucune source claire et précise... idem pour CODE et SAMP :-/

Laurent Denis> Je ne suis pas d'accord avec toi pour <pre> et <code>.

<pre> sert à afficher du texte formaté, mais ce n'est pas spécifiquement du code. Ça peut être n'importe quoi.

À ce titre, la sémantique des articles d'openweb n'est pas correcte. Cela devrait être :

<pre><code> le code... </code></pre>

pour les exemples de code.

Pour <ins> et <del>, je trouve ces balises loin d'être pratique , heureusement, XHTML 2.0 va simplifier tout ça:
www.w3.org/TR/xhtml2/mod-...

@Raphael > Pour CODE, la spécification HTML4.01 dit clairement "Désigne un fragment de code informatique", non un script complet. Maintenant, où est la limite entre le fragment et le code complet ... ;)

SAMP, lui, "Désigne un exemple...". Comme tu le faisais remarquer, ces balises font plus ou moins double emploi. Tout dépend de la nuance que l'on veut apporter sur telle ou telle portion de contenu. SAMP apporte la nuance "attention, ceci n'est qu'un exemple, cette syntaxe de code peut être modifiée..."

Pour DFN, "l'instance définissante" doit être balisée, mais pas la définition elle-même, qui se trouve dans le contexte. DFN est l'équivalent en-ligne de DT, pas de DT+DD. A la différence de DL, il permet juste de signaler dans le contexte d'un paragraphe, d'un élément de liste, d'un titre.. qu'un terme est accompagné de sa définition. Le terme défini est mis en valeur (hors CSS) en italique ou en gras (variable selon les navigateurs). La syntaxe donné par Ndeko est la bonne. Voir l'exemple similaire donné par la spécification.

Toujours selon la spécification, TT est un "élément de style de police" au même titre que B, I. Il n'y a pas d'apport sémantique, c'est un simple élément présentatif de texte. Autant procéder via CSS...

@Bobe > Pour PRE, mon explication est effectivement limitée au contexte de la question posée par Raphael. PRE a beaucoup d'autres usages en dehors du code, comme les textes poétiques (voir l'exemple donné par la spec HTML4.01).

Quant à utiliser <pre><code>, il faut tenir compte du contexte. Dans celui d'une page OpenWeb, le sens de <pre> n'a aucune ambiguïté puisqu'il n'est utilisé que pour du code. Donc <pre><code> serait inutilement lourd. Là encore, on peut choisir d'expliciter une nuance de sens au prix d'une balise supplémentaire, ou de s'en passer. Il en serait tout autrement dans une page qui mêlerait (???) poésie et code.

Sinon, pour VAR, il ne se limite pas au contexte "code" : on pourrait écrire: il y a <var>x</var>% d'utilisateurs d'IE, par exemple. Mais le gain sémantique est bien faible... A la rigueur, ceci pourrait aider un lecteur d'écran à prononcer correctement, mais Jaws, HPR, etc. ignorent ce genre de balises. Seul un utilisateur de Jaws passant dans le mode qui lui indique le balisage relèverait la différence.

Enfin, outre l'excellent exemple des touches accesskey, KBD permet de lever toute ambiguïté sur les caractères à entrer/les touches à utiliser : "taper <kbd>Alt</kbd>" désigne la touche, "taper Alt" peut désigner la touche ou la séquence de lettres... Un doigt de CSS sur <kbd> et le tour est joué ;)

En conclusion, ces éléments sont très "historiques", remontant au temps où HTML était surtout utilisé par les informaticiens pour parler de code. Leur plus-value sémantique est parfois réel, mais parfois nulle au contraire. On peut regretter le maintien de tout le lot, alors qu'un contenu aussi essentiel que les dates ne bénéficie encore d'aucun balisage spécifique...

Merci à tous de contribuer à ce "débat" ma foi très intéressant.

@Laurent Denis > comme tu le signales, la plupart de ces balises "exotiques" sont apparues dès le HTML2 et on parcouru les âges.

Je suis entièrement d'accord avec toi pour dire que, vu le manque de clarté dans leurs définitions, certaines sont redondantes voire inutile... Pourquoi les avoir conservées dans ce cas ? Comme tu le dis, d'autres balises mériteraient leur apparition dans le HTML.

Laurent => En ce qui concerne la balise < dfn > SELFHTL nous dit: "formate un texte et signifie "ceci est une définition" ". Le programmeur HTML 4 lui nous indique: "permet de faire ressortir un terme dans le texte". Qaunt à allhtml: " Le texte entre < dfn >< /dfn > est affiché comme une définition". Alors faut-il inclure le terme à définir dans ces balises ... c'est assez confus. Personnelement je pense que c'est plus censé de l'inclure. Aussi ce balisage pourrait servir aux moteur de recherche. "Je cherche la définition d'une marguerite" et le moteur irait chercher les définitions compris dans dfn

Pour les < kbd >, c'est en visitant le site de firebird (a l'époque) qui utilise cette balise largement. Voir par exemple : texturizer.net/firefox/ke...

ps: bobe => quelle horreur cette police (mono) sur w3c working draft :-(

Laurent : SAMP, lui, "Désigne un exemple..."."

--> Je pense que tes sources sont celles des traductions de La Grange (www.la-grange.net/w3c/htm...
Les sources originelles du W3C disent :
SAMP : "Designates sample output from programs, scripts, etc."

Je voudrais simplement signaler que "sample" ne se traduit pas du tout par "exemple", mais signifie "échantillon", ce qui n'est pas la même chose (je pense d'ailleurs que La Grange a peut-être fait une erreur de traduction).
Dans cette optique, je pense qu'il n'est pas tout à fait correct d'écrire "Par exemple <samp><h1>...</h1></samp>..."

En résumé, SAMP est un échantillon de code alors que CODE est un fragment de code... si quelqu'un dans l'assistance veut bien m'expliquer la nuance je suis preneur (je pense que Bobe est le plus près de l'interprêtation correcte).

Autre question : si je veux baliser un exemple qui n'est PAS du code (exempe : la blague de toto), dois-je utiliser une balise générique comme TT ou pas du tout ?

> SAMP : "Designates sample output from programs, scripts, etc."

Il ne faut pas négliger le terme « output », SAMP servirait pour montrer un extrait de la sortie d'un programme, script, etc. et non le code source.

C'est en tout cas une bonne coïncidence que de tomber sur cet article alors que je m'étais posé la question il y a quelques semaines et que j'y reviens aujourd'hui pour fignoler un article.

Raphael : La réponse est également dans ta citation : "Designates sample *output* from programs, scripts, etc."

Autrement dit, rien à voir avec le code utilisé par le programmeur, c'est ce que voit l'utilisateur après avoir effectué une action.

Exemple :
Pour afficher la liste des fichiers du répertoire courant, entrez la commande <kbd>dir</kbd>. Si le répertoire est vide, le système vous répondra <samp>No files found.</samp>

@ Hervé et Benoit > oui, ça rejoint ce que soulignait Bobe... je vais rajouter cette précision dans le billet.

Oui, <samp> désignerait plutôt une sortie, comme par exemple l'affichage de la sortie d'un script dans une console. (euh, par contre, je n'ai pas fait référence à <samp> dans mon premier message. Tu confonds avec Laurent non ?)

Par ailleurs, l'exemple "<samp><h1>...</h1></samp>" ne serait de toute façon pas valide, <samp> étant une boite en-ligne ne peut contenir de boites de type bloc.

P.S: La prévisualisation des messages ne tient pas compte des sauts de ligne.

Bobe : "La prévisualisation des messages ne tient pas compte des sauts de ligne."

>>> oui, mais je n'ai pas assez de connaissances dans le moteur PHP de Dotclear pour remédier à cela :-/

@ katsoura > Pour DFN : Ah ! Comment dire ? Essayons ceci : une "instance" d'un terme est une occurence, une apparition de celui-ci dans le contenu. C'est donc le terme qui doit être balisé, non sa définition. Essayons aussi avec l'exemple donné dans le WD XHTML2.0 du W3C (je ne retrouve plus l'exemple pour HTML/XHTML1.x) :
"An <dfn id="def-acronym">acronym</dfn> is a word formed
from the initial letters or groups of letters of words in a set phrase or series of words." (www.w3.org/TR/xhtml2/mod-...

@ Raphael > SAMP, échantillon ou exemple ? CODE, fragment ? La nuance sémantique est franchement très faible. Un exemple de code est un échantillon. Un échantillon peut avoir une valeur exemplaire... Bref, c'est à peu près du même niveau que le vieux troll abbr v. acronym : des discussions passionantes, certes, mais un enjeu sémantique quasi négligeable ;) D'où la traduction retenue en français.
Pour ma part, je ne vois aucun inconvénient à utiliser SAMP au sens de <exemple>, même hors du contexte "sample output from programs", en me basant sur le "etc" qui conclut la phrase dans la spécification. J'écris donc froidement:
"le patois morvandiau use volontier du "y", comme dans <samp>il faut y voir</samp>" ;)

@ Bobe > Il fallait comprendre évidemment la source HTML
<samp>&lt;h1&gt;...&lt;/h1&gt;</samp>, dans le contexte d'une page expliquant comment utiliser la balise <h1> et donnant un exemple de code avec la balise h1.

Au passage, l'usage peut faire évoluer bien des choses, mêmes les sacro-saintes spécifications, lorsqu'elles commencent à être "datées" ;) Il serait bon que l'usage fasse évoluer ce stock de vieilles balises présentatives...

Oups ! J'oubliais, pour SAMP. Jetez un oeil sur le code source de la spécification HTML4.01. Vous y trouverez de nombreux SAMP... tout à fait en contradiction avec le "Il ne faut pas négliger le terme «output», SAMP servirait pour montrer un extrait de la sortie d'un programme, script, etc. et non le code source."
Exemple, dès le sommaire détaillé :

Les phrases : les &eacute;l&eacute;ments <samp class="einst2">EM</samp>,
<samp class="einst2">STRONG</samp>...

En revanche, le chapitre consacré à ces éléments (www.la-grange.net/w3c/htm... ne fait pas une seule fois usage de <code>, utilise systématiquement <pre> pour les exemples bloc et ne balise aucun exemple en ligne...

;)

Katsoura : Tu ne crois pas si bien dire en écrivant :
"Aussi ce balisage pourrait servir aux moteur de recherche. "Je cherche la définition d'une marguerite" et le moteur irait chercher les définitions compris dans dfn"

Google le fait : En précédant le terme d'une recherche par la mention "define:", sans els guillemets, Google renvoie une liste de pages où des définitions du terme sont proposées. Google établit ce résultat en tirant parti des balises dd, dt, et... dfn !

Cf : www.google.com/help/featu...

@ Ndeko > Je connaissais l'utilisation des listes de définition <dl> par Google, mais je n'au rien trouvé pour les <dfn> : aurais-tu une source plus précise ?
A propos de Google:define, un petit bookmarklet bien pratique: google-apps.com/definitio...

@ Laurent :
J'ai lu ça sur le Journal du Net :
developpeur.journaldunet....
tutoriel/dht/040514-html-balises-semantiques.shtml

Le lien en un seul tenant :
developpeur.journaldunet....
(z'avais pas vu que les liens trop longs sont ici remplacés par des points de suspension !)

Pour l'utilisation de DFN par Google Definitions, l'article du JDN (qui cite explicitement DFN comme support de l'application) donne un exemple : la recherche Google "define: semantic". Celle-ci produit 4 résultats lisibles (et 2 erreurs 404). Ces 4 résultats ont un trait commun amusant : les définitions sont balisées sur le modèle :
<p><b>Semantic</b> etc.</p>

(Et , en passant, toute information publiée dans JDN éveille systématiquement chez moi une franche paranoïa et une grosse crise de scepticisme ;) )

Je ne connaissais pas JDN de très près. Me voilà averti ! Merci à toi.

Mes résultats sur w3c montrent que cela fonctionne en partie sur les listes de définition. Y a des tableaux, des blockquote, des span en veux tu en voilà, ... bref c'est pas au point. Ce qui est amusant c'est que je lui ai demandé des pages en français et sur la 30aine de liens affichés aucun n'est dans cette langue.

> quelle(s) balise(s) allez-vous utiliser entre CODE, SAMP, TT, KBD, VAR et PRE ???

Elles ne sont pas exclusives. Je suis d'accord avec Bobe : si j'ai un bloc de code préformaté j'utilise <code> à l'intérieur de <pre>.

> Dans celui d'une page OpenWeb, le sens de <pre> n'a aucune ambiguïté puisqu'il n'est
> utilisé que pour du code. Donc <pre><code> serait inutilement lourd.

Quelle horreur : pas d'ambiguité pour qui ? Mon titre en <p><b>Bonjour</b></p> n'a pas non plus d'ambiguité pour le lecteur. Par contre pour la machine qu'est ce qui lui permet de faire la différence entre le source (préformaté) d'un email et un bloc de code ?
Le balisage est justement là pour répondre au problème du "c'est implicite pour l'humain mais pas pour la machine". Sinon on peut retirer les titres (même sans mise en forme on reconnait les titres), les paragraphes, les listes, les <blockquote> (la citation est introduite ou évidente, pas besoin de baliser), pas de <code> (on sait bien que c'est du code) ... bref on revient à du texte pur avec mise en forme.
Si on a besoin de comprendre le texte ou le contexte pour savoir que <pre> contient ou pas du code c'*est* que <code> est nécessaire dans le balisage, même avec <pre>.

Les deux exemples sont nettement différents:

- <p><b>Bonjour</b></p> ne donne aucune information spécifique sur le contenu. Et aucune autre information accessible à la machine ne peut lui permettre de deviner ce qui est ici effectivement totalement implicite.

- En revanche, <pre>_Ici du code_</pre> ajoute au contenu une information spécifique : texte dont le pré-formattage doit être conservé car il a un sens. Y a-t-il vraiment une autre information à y ajouter ? Le fait que ce soit du code et pas du mail ou autre-chose ? Mais le contexte d'un article sur la syntaxe XHTML (par exemple) est accessible à la machine via d'autres éléments comme les metas DC utilisés pour OpenWeb. Un "gain" sémantique est possible avec <pre><code>, mais est-il suffisant pour le justifier ?

AMHA, la question est plutôt : estime-t-on nécessaire que la machine puisse faire la différence entre des <pre> contenant du mail et des <pre> contenant du code ? Autrement-dit, quelle exploitation sémantique est-elle susceptible d'en être faite ? Difficile de trancher à l'heure actuelle : tout ceci est encore beaucoup trop théorique en l'absence d'applications sémantiques ;)

> Mais le contexte d'un article sur la syntaxe XHTML (par exemple) est accessible à la
> machine via d'autres éléments comme les metas DC utilisés pour OpenWeb

Ce contexte est basé sur la compréhension du titre et de la description, éventuellement de la catégorie. Bref, ce n'est pas quelque chose de traitable par la machine de façon générique

D'ailleurs, un article sur XHTML ne pourrait-il pas contenir du préformaté avec autre chose que du code ? par exemple un email

> Un "gain" sémantique est possible avec <pre><code>, mais est-il suffisant pour le justifier ?
> estime-t-on nécessaire que la machine puisse faire la différence entre des <pre>
> contenant du mail et des <pre> contenant du code ? Autrement-dit, quelle exploitation
> sémantique est-elle susceptible d'en être faite ?

Ça c'est une autre histoire. Que gagnes t'on avec <code> ? difficile à dire. Mais le gain est strictement le même quand il est enfermé dans un <pre> ou pas. Je me vois mal justifier l'utilisation dans un cas et pas dans l'autre.