Salut à tous    
 
je veux afficher du code dans une page HTML et pour cela j'ai trouvé 2 moyens de le faire :
 
le 1er :

le 2eme :

 
Comme vous pouvez le voir le 1er est plus léger, mais le second est à mon sens plus logique sémantiquement parlant puisqu'il utilise les balises <code>.
 
Une alternative existe aussi :

Qu'en pensez-vous ?
 
Merci d'avance pour vos bons conseils.
 
 

<pre> n'a qu'un sens de présentation (police préformatée).
Il faudrait donc l'éviter pour des balises plus porteuses de sens comme <samp> ou <code>, voire <var>.
 
Plus d'informations sur ce billet et les commentaires qui en découlent :
http://blog.alsacreations.com/2004 [...] es-perdues
 
 

Oui il faut utiliser <code> et se servir des CSS pour la mise en forme (en particulier la propriété white-space pour retrouver le comportement de <pre> )

Merci à vous 2 pour vos réponses    
 
Effectivement la solution de gm_superstar consistant à utiliser la propriété white-space: pre; dans la CSS me convient tout à fait et correspond exactement à ce que je cherchais.
 
Honte à moi : je ne connaissais pas cette propriété    
 
 

Argggg !!!    
 
En n'utilisant pas la balise <pre> et en mettant white-space: pre; , quand les styles CSS sont désactivés évidemment tout le code s'affiche en ligne, tandis qu'avec <pre> cela s'affiche correctement.
 
D'où une autre interrogation, faut-il vraiment ne pas utiliser <pre> tout en gardant <code> ???

Tu as une raison particulière qui t'amènerait à désactiver les styles ?

Moi aucune, mais je pense à des internautes qui utiliseraient des navigateurs qui ne gèrent pas les CSS (à la réflexion je ne sais pas si çà existe)

Personnelement, c'est un point de vue de sémantique, mais je ne pense pas que le changement de comportement (bloc/en ligne) à tout va est particulièrement bon.
 
<code>, <var> et cie sont des éléments en ligne, je pense qu'ils doivent le rester. Dans la logique, c'est vrai que le sens de <pre> n'est pas très défini, mais n'exclue pas pour autant la possibilité d'accueillir du code.

Pas d'accord, pour afficher des codes complets c'est blockquote + pre, code sert à afficher du code inline genre noms de variables ou one-liners
 
Ou alors mais là il faut un traitement automatisé du code, <ol> en externe et un <code> dans chaque <li> pour chaque ligne de code.

Ben c'est soit les très vieux navigateurs graphiques mais bon, ceux-là on peut les oublier, soit les navigateurs texte mais dans ce cas, ils doivent pouvoir afficher ce qui est entre des balises <code> d'une manière différente pour indiquer à l'utilisateur qu'il sagit de code informatique...

OK    
 
Je vais donc en rester sur l'utilisation de la balise <code> avec la propiété white-space: pre; dans la CSS
 
 

withe-space: pre;
Niveau comportement, ça affiche les espaces et tabulations, ou c'est juste en rapport aux retours à la ligne ?

cela permet d'avoir un affichage comme çà :

En tapant çà :

Certes, mais il faut reconnaître que la défnition de <code> est imparfaite, voire imprécise. Ca me choque pas plus que ça que <code> puisse englober un contenu multi-lignes (On peut comparer le code à un poème : même s'il tient sur plusieurs lignes, il constitue une phrase unique)
 
Et puis bon, c'est pas la première fois qu'on utilise un élément en-ligne comme un bloc ou inversement... Les CSS peuvent aussi servir à palier les insuffisances du HTML pour peu qu'on reste cohérent sémantiquement.  

cf les specs
 

oui, oui, mais comme je le dis, c'est un point de vue, personnelement je trouve plus "propre" (c'est relatif) d'utiliser pre.
 
Pour white-space, c'est bien ce que je pensais, mais je sais plus pourquoi, j'avais gardé en tête que ça ne comptais que pour les retours à la ligne...

 
J'ai essayer les deux et c'est code qu'il faut prendre car code utilise une police fixe, je crois que c'est "Courier New".
 
Conclusion : code est un span/div qui utilise une police fixe.

On part dans un troll inutile.
 
Comme le dit gm, le HTML n'a pas pour vocation d'être exhaustif et n'a pas prévu de balise précise pour chaque usage précis... seulement des ensembles généraux.
Bref, Internet a commencé par être très axé "code", et HTML2 et 3.2 ont introduit des balises appropriées comme samp, code, pre, var, kbd, etc.
 
Il ne faut pas être plus royaliste que le roi et ne pas chercher la petite bête : utiliser ces balises pour leur usage *général* convient tout à fait.
 

Aucun rapport avec la sémantique. La structure (HTML) de la balise reste toujours la même (bloc ou enligne), même si CSS peut modifier son comportement apparent avec display.
En clair : je veux faire un bouton de lien. J'utilise logiquement la balise <a> à qui je donne un comportement bloc (display block) afin de lui donner des dimensions. Mais ma balise <a> restera en ligne et ne pourra pas contenir de blocs.
Le document HTML n'est en rien modifié par le comportement CSS.
 

blockquote ? une faute d'inattention sans doute ? que vient faire une citation ici ?
noms de variables : normallement c'est <var> qui doit être privilégié
 

en fait, dans l'absolu, cela peut être n'importe quel support. Je ne t'apprends rien.
Le message (HTML) doit pouvoir être véhiculé sur n'importe quel type de sortie (actuel ou futur). Il faut donc que la couche *visuelle* CSS puisse s'en détacher complètement pour assurer que la restitution puisse se faire quel que soit le support.
 

Je crois que ça conclut assez bien le débat : le W3C ne couvre pas tous les cas possibles, évitons d'inventer de la pseudo-sémantique lorsqu'elle n'existe pas.
 

Dans la pratique, oui. Mais <code> a un sens qui n'a pas été donné à <span>.
Sinon, on peut dire que <h1> c'est un <h2> en plus grand

Genre t'as testé
 
Beau mytho, mais <pre> utilise par défaut une police à chasse fixe

Non, pas de faute, poster un code c'est citer un code externe, ça n'appartient pas à la page même c'est une "pièce rapportée"

 
<pre> peut-être mais white-space: pre non (en tout cas dans Firefox 1.0.7)
 

J'm'en tape de whitespace: pre, où j'ai parlé de whitespace: pre?

Ou la la, alors là on va très très loin !
Je n'irai pas jusque là, sans être complètement outré    Les specs sont effectivement larges, mais si on doit se mettre à utiliser des citations pour chaque pièces rapportées (images d'un autre site, etc.), ça peut vite dévier.
 
Et du coup, pour donner du sens, il faudrait théoriquement cumuler 3 éléments :
- <blockquote> (je "cite" un code externe, s'il est externe)
- <pre> (balise de mise en forme mais nécessaire puisque <blockquote> ne peut être parent que de blocks)
- <code>, <var>, <samp>, etc. (pour ici donner le sens du contenu)
 
Bref, ça devient de l'enc* de mouche. Autant rester large.
 
EDIT : bon, sur ce, je remarque que non seulement ça part en troll, mais en plus ça devient agressif. Donc sans moi. Bonne journée et à bientôt pour de nouvelles aventures

Comme je l'ai dit, c'est ça ou utiliser une imbrication <ol><li><code> (parce qu'une ligne de code, c'est d'abord une ligne et ensuite du code), surtout quand on poste sur des sites ne permettant pas de modifier la CSS mais permettant des posts en HTML brut.

Je veut bien croire que du code, c'est une liste de ligne, mais si on part sur cette base alors on va se retrouver avec des listes partout et pour n'importe quoi.
Aprés les tableaux de présentation, aprés les div qui remplacent tout, voilà, les listes qui font revenir à la ligne.  

Non pas du tout. Les specs HTML n'indiquent pas comment ce qu'il y a entre les balises <code> doit être rendu visuellement. En pratique les navigateurs utilisent une police à espacement fixe (pas forcément Courier d'ailleurs) mais rien ne les y oblige.
 
On ne choisit pas <code> parce que ça produit une police fixe mais parce que ce qu'il y a dedans est du code. Une démarche sémantique donc.
 
L'aspect visuel doit être géré par les CSS et en toute rigueur on devrait indique à <code> une propriété "font-family: monospace;"

Sinon pour le blockquote, oui pourquoi pas. C'est rare qu'on code directement dans une page HTML Et donc le code en question est forcément importé d'ailleurs. Une citation donc.
 
De toute façon il faut bien un bloc conteneur, donc autant que ce soit quelque chose qui ait du sens.