Dans la série des problèmes existentiels qui ponctuent la journée de l’intégrateur web, la question du marquage HTML des petites portions de texte est souvent de la partie. Pour la baseline par exemple, on peut justifier l’utilisation de la balise `blockquote` : c’est une « citation » de la marque, elle est souvent mise en italique ou entre guillemets.
Ca donne :
<blockquote id="baseline"><p>Ma baseline est plus belle que la tienne</p></blockquote>
En ce qui concerne les autres micro-contenus, je suis beaucoup plus partagé. Un paragraphe est un ensemble de phrases et on peut concevoir qu’en présence d’une seule phrase voire d’un seul mot, la balise `p` n’est pas la plus adaptée : on lui préfère d’ailleurs souvent la balise `div`.
Or, en l’absence de CSS — notamment sur les périphériques mobiles — les micro-contenus enveloppés avec `div` ne possèdent pas de marges, et visuellement, au mieux, c’est balot, au pire, c’est illisible (cf. le visionnage du flux friendfeed, par ex.) !
Dans ce contexte, vous privilégiez quoi entre :
<p id="copyright">copyright, copyleft ou copycenter ?</p>
et
<div id="copyright">copyright, copyleft ou copycenter ?</div>
A vous les studios !
Personnellement, le p, toujours. Mettre un contenu texte sans identification claire de balisage de contenu me semble toujours ou presque amateur.
Mais bon, c’est mon point de vue.
Perso, je pense qu’il ne faut pas sur-utiliser les balises DIV, je pencherai donc pour un P.
On a tendance à trop utiliser les DIVs et bien souvent à tord et à travers, et ce n’est pas forcément bon.
Sans hésiter le p
les div ont fait leur temps et m’ont prouvé bien trop souvent qu’elles étaient instables…
Bonjour,
le problème c’est de vouloir régler un comportement graphique avec du HTML.
Au user-agent de faire son taf.
p aussi. Je défini rarement une taille de caractères sur un élément autre que p, li, ou hx, donc…
Je suis assez tenté par le paragraphe, mais dans le cas présent de données brutes, il ne s’agit même pas d’une phrase avec sujet verbe et complément, un conteneur div ne me choquerais pas…
moi je met un p. les div, je les utilise uniquement pour les groupes d’éléments (un groupe de p par exemple).
semantique!
Vivement HTML 5 ^^
@mateao: les div ne sont pas instables, il s’agit juste d’utiliser un bon reset.css pour eviter les problemes cross browser
C’est un article pour chez moi ça ! 😉
Plus sérieusement, il me semble logique de placer un
<p>
pour ce type de contenu. Je ne vois aucun souci à n’en placer qu’un seul.Par contre pour les contenus très courts, type « actions », je m’étais plutôt tourné vers les listes.
Bref, quoiqu’il en soit, tant que je peux apporter un sens plus sémantique que le fameux
<div>
, je le fais.Pour ma part, j’utiliserai également la balise P, qui me semble nettement plus adapté à ce type de contenu. Les balises DIV sont trop utilisées, à tort et à travers, et souvent de façon inexplicable ! C’est tout vu : P !
P également, mais plutôt parce que c’est la balise qui me paraît sémantiquement adaptée pour afficher du contenu texte sans connotation particulière.
Moi aussi, ma préférence va pour l’élément p, n’y voyant qu’un simple paragraphe et considérant que div est un élément sémantiquement neutre.
le texte uniquement dans une balise div est a proscrire car non XHTML valide.
le p pourquoi pas, c’est ce qu’il me semble logique.
après, pour rajouter de la sémantique pk ne pas utiliser une balise « pre » ?
et même pk pas une dfn dans le p
ou en lieu est place du p une dl avec un dt copyright et dd valeur du copyright ?
@Luc : un texte dans un div reste valide syntaxiquement en XHTML (c’est du texte seul dans un élément body ou dans un élément inline enfant de body qui est invalide en HTML 4.01 et XHTML 1.0 Strict). 😉
Soit dit en passant, pourquoi ne pas entourer copyright, copyleft et copycenter d’un élément span muni d’un attribut lang (xml:lang pour XHTML 1.1) de valeur en ? 😉
<p>Copyright</p>
Et si tu es en html 5 http://dev.w3.org/html5/spec/Overview.html#the-small-element
<p><small>Copyright</small></p>
Les div je les réserves pour la structure de base :
header
content
footer
Question bête : la balise
<
p> c’est la balise du paragraphe, et un paragraphe c’est un texte sur plusieurs lignes non ?
Donc si je ne me trompe pas, quelle balise est la plus appropriée pour un texte d’une seule ligne ? ?
@manu :
Pour une seule ligne la balise Span est plus appropriée il me semble non ?
Et bien c’est ce que je disais, mais j’ai pas fais attention au fait que les balise étaient interprétées comme telle.
Je réitère donc ma question bête :
« p » c’est la balise du paragraphe, et un paragraphe c’est un texte sur plusieurs lignes non ?
Donc si je ne me trompe pas, quelle balise est la plus appropriée pour un texte d’une seule ligne ? « span » ?
J’ai du mal à vous suivre, une div n’est ni « instable » (je ne vois même pas ce que ça voudrait dire) ni difficile à styler (c’est même une des plus faciles vu qu’elle n’aucun style par défaut), ni syntaxiquement invalide, ni « mauvaise » en soi au point qu’il faille tenter de les éliminer, et non un span (élément en ligne) ne remplacera jamais un div ou un p (éléments de bloc).
Pour résoudre le problème posé j’avais dans mon temps posé une question bête : Vous trouvez un livre, dessus il y a le titre du livre, puis l’édition, puis la date. Comment qualifieriez-vous l’éditeur et la date ?
J’ai tenté, certains parlent de sous titre, certains (informaticiens) parlent de méta données, d’autres d’informations complémentaires. Aucun ne m’a parlé de paragraphe, informaticien ou non (alors que pour l’intérieur du livre c’est le terme que tout le monde choisissait quand on en montrait un).
Donc voilà, depuis j’ai tendance à partir sur un div et à laisser le paragraphe pour le contenu lui même ou au moins des parties rédigées. Je me suis donné comme règle perso « si j’ai tendance à mettre une majuscule et un point, c’est que ça peut aller dans un paragraphe si je le souhaite ». Dans tes deux exemples, aucun point, donc pas de volonté de rédaction. Quand bien même ça pourrait être une phrase correcte simplement en ajoutant le point, son absence est révélatrice de la façon dont tu considères réellement le contenu.
Il y a une autre raison qui me fait souvent écarter le paragraphe pour ces métadonnées affichables : elle contiennent parfois des choses très diverses et il m’est arrivé plus d’une fois de reprendre ma div pour y ajouter d’autres éléments associés à la méta données. Mon div c’est retrouvé en conteneur d’autres éléments de types blocs, ce que n’aurait pas pu être un paragraphe. Donc voilà, est-il vraisemblable de peut être mettre des éléments de type blocs ? (genre une balise adresse après le copyright pour le contact) si vous répondez « en théorie oui » ou que vous hésitez, ce n’est probablement pas un paragraphe que vous avez (ou éventuellement une division qui contient un paragraphe).
Merci à tous pour vos réponses. J’ai parlé de micro-contenus au pluriel, mais il faut garder en tête que le micro-contenu peut prendre la forme d’un seul mot, un lien ou même un champs de formulaire isolé de tout contexte sémantique. D’ailleurs, si je prends l’exemple du champs de recherche, il est souvent encadré d’une div et non pas d’une balise p.
@Aymeric Jacquet: C’est généralement mon point de vue, sauf que dans certains cas, la balise « p » n’est pas forcément une « identification claire de balisage ». J’aime beaucoup ta formule qui évite de parler de « sémantique » alors que sans y toucher, on est en plein dedans 😉
Comme micro-contenu, j’ai donné l’exemple d’une mention de copyright, mais il peut s’agir des mentions « page suivante et page précédente ou de « x commentaires ». Si les premières peuvent faire l’objet d’une liste, la deuxième est isolé sémantiquement des contenus alentour, comme c’est le cas sur ton blog, par exemple, où les informations liées au billet sont des paragraphes.
Là, j’aurais peut-être eu tendance à utiliser une liste
ul
pour regrouper la date, la catégorie et le nombre de commentaires au lieu de faire du nombre de commentaire un paragraphe du billet.@Victor Brito @Yves Van Goethem @Vincent @Manu: le problème du span ou autre small c’est qu’il s’agit d’éléments en ligne alors que je cherche plutôt un élément de type bloc pour placer un micro-contenu isolé sur la page 😉
@Eric:
“si j’ai tendance à mettre une majuscule et un point, c’est que ça peut aller dans un paragraphe si je le souhaite”
C’est tout à fait ça, seulement ça ne résout pas la question du « stylage » par défaut de la div (pas de marge) qui fait que l’affichage des données devient une vraie purée quand on l’affiche depuis un téléphone portable. Peut-être que html5 résoudra le problème en créant une balise dédiée à ces micro-contenus à mi-chemin entre le mot et la phrase…
J’utiliserai « p ». J’essaie toujours d’avoir le moins de div possible quand une autre balise peut les remplacer.
Salut Bruno !
Personnellement je suis entièrement de l’avis d’Eric. En ce qui concerne le stylisme sur téléphone portable, s’il ne s’agit que de la séparation nette des données, quoi de mieux qu’un « hr » pour marquer le footer (stylisable en CSS quand l’UA le permet) ?
Ceci est un exemple bien entendu, on peut s’amuser à trouver d’autres balises qui pourraient convenir dans d’autres situations (comme le lien vers les commentaires que tu cites toi-même).
Mais c’est là qu’on se rend compte qu’il n’y a pas énormément de balises block disponibles, encore moins pour ce genre de cas.
Pour reprendre l’exemple du lien « Commentaires », dans l’absolu, on pourrait utiliser une balise inline de type « em ». Si on imagine une structure où chaque article est inclus dans un « div », chaque paragraphe de l’article serait bien évidemment dans un « p », et à la fin une balise « em » en dehors de tout « p » pour mettre en exergue ces liens qui seraient de plus séparés du reste de l’article par la marge basse du « p » qui le précède.
Je pense qu’on peut débattre pas mal de temps sur le sujet, tant qu’il n’y aura pas de balise spécifique destinée à cet effet.
D’accord avec Eric également. J’ai fait les 2 écoles. Et j’ai calmé la dose de « p » que j’utilise désormais pour des paragraphes (au sens du dictionnaire).
@Josselin — Salut Jos ! Tu dis
et tu as bien raison.En réfléchissant sur cette question, j’ai regardé ces micro-contenus de plus près, et je me suis rendu compte qu’une bonne partie d’entre eux était composé d’injonctions pour que l’internaute accomplisse une ou plusieurs actions, comme : incription sur le site, laissez un commentaire, abonnez-vous au flux RSS, etc.
Dans ce cas, je pense qu’on peut utiliser la balise blockquote dans la mesure où ces injonctions émanent du site, et partant, peuvent être qualifiée de « citation ». C’est un peu tiré par les cheveux, mais voilà où tout cela m’a amené pour l’instant 😉
@nico — Très bien, mais qu’utilises-tu à la place de « p » alors ?
Alors pour ma part je vais appeler à éviter la sur-sémantisation. En gros: la sémantique HTML c’est limité, DIV ou P c’est kif-kif pour le type de cas soulevé, donc fais ce que voudra et ya basta.
La vraie sémantique c’est celle qui a une application concrète, pas celle qui consiste à chercher «le plus meilleur sémantico-philosophiquement parlant». Le plus meilleur sémanticotruc, on peut s’y attacher si on aime passer son temps à ça, ça peut éclairer les matins gris et fournir l’occasion de trolls réchauffent les longues soirées d’hiver (moi j’aime beaucoup), mais ça n’est pas important.
Et donc, pour revenir au concret, la sémantique HTML s’évalue à l’aune de ce qui est exploité (ou raisonnablement exploitable) par les aides techniques (accessibilité), par les navigateurs pour leurs styles par défaut éventuellement, et plus largement par tout agent utilisateur capable de reconnaitre et exploiter des données qualifiées (cf. microformats pour une surcouche sémantique au HTML). Dans la sémantique HTML, il y a donc des titres de section, des éléments «actifs» correctement balisés (liens, formulaires), des attributs tels que lang, des citations, des tableaux avec éléments et attributs de description des données (CAPTION, summary, TH, scope, à la rigueur id/headers, des listes, et c’est à peu près tout.
Le coup du «P c’est un paragraphe et son contenu doit donc correspondre à la définition littéraire du paragraphe», je trouve ça assez drôle. 🙂
(Et apparemment du côté du HTML Working Group aussi, cf. la définition du paragraphe dans HTML 5.)
Personnellement, j’utilise plutôt P pour les micro-contenus, mais c’est une préférence personnelle sans fondement sémanticochose.
Halljleuah! I needed thisyou’re my savior.
gOnhmY btnceujbyoim
cdugkl ltgctcnermnm