5568 sujets
Sémantique web et HTML
Raphael a écrit :
En fait :
- <p> fait partie du groupe d'éléments nommé %bloc (dans les specs HTML)
- <p> a un display CSS dont la valeur par défaut est "block"... mais qui dépend du bon vouloir du navigateur.
Ben oui forcément si un élément est de type block on peut quand même s'attendre à ce que son display par défaut soit block et aucun agent utilisateur ne va se mettre à le traiter en display par défaut inline.
Si <p> séquence alors cela doit être rendu d'une manière ou d'une autre. Ce rendu devant effectivement être en accord avec les modalité de présentation du type de media plus sans doute de certain choix. Même si tout cela à quand même tendance à être normalisé au niveau des navigateurs graphique je trouve.
Un display inline par défaut reviendrait à viser un rendu d'élément qui ne séquence pas pour un élément qui séquence, dans le cadre d'une css auteur on a sans doute tous eu l'occasion de le faire de manière ponstuelle. Mais une telle valeur du display dans une css par défaut ce serait un peu surréaliste, enfin moi je trouve.
Raphael a écrit :
Christian a évoqué le constat qu'il existait deux types d'éléments : ceux qui permettaient de séquencer le flux, et ceux qui ne le permettaient pas... sans forcément introduire de notion de sémantique là dedans.
Oui c'est ça, et je pars ensuite dans la réflexion suivante :
Les éléments qui ne séquencent pas le flux sont les éléments de type inline.
Les éléments qui séquencent le flux sont les éléments de type block.
Tous les éléments block séquencent donc le flux, seulement ils ne font pas que ça, ils ont en plus chacun une détermination particulière, mais ce n'est pas cette détermination qu'il les rends block, c'est déjà fait puisqu'il séquencent.
Alors il y a deux questions qui me tracassent :
. Curieux quand même qu'il n'y ait pas d'élément qui ne soit que block et rien d'autre et qui nous met au niveau texte sans détermination quelconque. le modèle même de la balise block.
. Et parallèlement : mais qu'est ce que cette fichu règle qui interdit de mettre un élément block dans un <p> (alors que dans un <li> on peut)
Voilà, ma réflexion et mon hypothèse toute personnelle est que les deux question se rejoignent :
<p> ne peut contenir d'élément block parce que <p> est bien cet élément qui nous amène au niveau texte et rien d'autre, donc sans aucune détermination particulière.
Du coup je le formule ainsi :
Si <p> ne peut contenir que du inline ce n'est en rien une exception, c'est simplement parce que <p> est le modèle basique lui même des balises block.
Julien Royer a écrit :
Au risque de me faire lyncher, ces entités (%block et compagnie) ne seraient-elles pas héritées de HTML 3.2, où elles avaient bien un sens puisque les CSS n'étaient pas supportées ?
Il me semble que les CSS existent depuis les tous débuts de HTML (1994, donc avant les brouillons de HTML 3.2 en tout cas - HTML 1.0 = 1993)
Modifié par Raphael (03 May 2007 - 17:57)
Bien le bonjour tout le monde ... 
Je suis avec beaucoup d'intérêt le débat actuel qui me permet de parfaire mon savoir imparfait.
Si je peux me permettre une petite remarque cependant, je trouve qu'il serait vachement plus lisible d'employer le caractère % devant block, inline ou flow lorsqu'il est question des spécifités HTML...
Car sinon, on ne sait jamais s'il est question de la propriété display ou du type de la balise.
Merci pour la suite
Christian Le Bouler a écrit :
Les éléments qui ne séquencent pas le flux sont les éléments de type inline.
Les éléments qui séquencent le flux sont les éléments de type block.
Je suis avec beaucoup d'intérêt le débat actuel qui me permet de parfaire mon savoir imparfait.
Si je peux me permettre une petite remarque cependant, je trouve qu'il serait vachement plus lisible d'employer le caractère % devant block, inline ou flow lorsqu'il est question des spécifités HTML...
Car sinon, on ne sait jamais s'il est question de la propriété display ou du type de la balise.
Merci pour la suite
Raphael a écrit :
Il me semble que les CSS existent depuis les tous débuts de HTML (1994, donc avant les brouillons de HTML 3.2 en tout cas - HTML 1.0 = 1993)
Sachant que HTML 3.2 n'incluait pas les attributs id, class et style, je suis quand même assez sceptique sur le fait que cette version d'HTML soit prévue pour fonctionner avec les feuilles de style.
Pour la date de publication des CSS, je croyais me souvenir de l'année 1997. En vérifiant la spécification CSS 1, on peut lire ceci :
Première publication le 17 décembre 1996, donc.
a écrit :
Cascading Style Sheets, level 1
W3C Recommendation 17 Dec 1996, revised 11 Jan 1999
Première publication le 17 décembre 1996, donc.
Cygnus a écrit :
Si je peux me permettre une petite remarque cependant, je trouve qu'il serait vachement plus lisible d'employer le caractère % devant block, inline ou flow lorsqu'il est question des spécifités HTML...
Car sinon, on ne sait jamais s'il est question de la propriété display ou du type de la balise
Je crains que ce ne soit pas spécialement une bonne idée car il ne faudrait que peu de temps pour que la confusion s'installe entre %block qui indique le niveau de contenu admis par un élément et type block qui indiquerait (pour autant que cela ait du sens, et c'est ce point que Laurent Denis invite à relativiser) le type de l'élément lui même.
Pour éviter les confusions entre type et propriété css c'est assez simple en fait, il suffit lors d'un travail sur le html de donner aux css le statut qu'il convient
> Absentes et pas du tout attendues
Et lors d'un travail sur les css de donner au html le statut qu'il convient
> Présent et toujours prééminent.
Bon j'ai bien dit que c'était simple et pas du tout que c'était facile si je peux me permettre cette petite subtilité sémantique
Par contre c'est une discipline nécessaire je trouve, et personnellement je m'y astreint toujours avec la plus grande rigueur, que ce soit quand je développe ou que ce soit quand je parle de développement.
Christian Le Bouler a écrit :
il ne faudrait que peu de temps pour que la confusion s'installe entre %block qui indique le niveau de contenu admis par un élément et type block qui indiquerait le type de l'élément lui même.
Je pense qu'il s'agit de capillotraction inutile :
Si %inline désigne le contenu d'un élément <p>, alors les éléments concernés (<a>, <em>, etc.) sont bien désignés comme étant des %inline.
Donc %inline désigne bien un type de contenu et un type de conteneur, même si cela n'est pas explicitement spécifié.
On a bien une différence entre :
- le type d'un élément (<a> fait partie des éléments de type %inline puisque contenu dans un <p>)
- le rendu d'un élément (qui dépend de la valeur de "display")
Modifié par Raphael (04 May 2007 - 10:26)
Bonjour,
Merci Raphael pour ton compte rendu qui clarifie un peu les choses.
je rebondis sur une une remarque d'Arsene concernant la logique de titrage:
Si XHTML2 est retenu comme successeur du XHTML1, on aura quelquechose dans ce genre:
Voir cet article qui fait une comparaison entre HTML5 et XHTML2.
Ceci dit celui-ci n'est pas daté, il n'est donc pas impossible qu'il soit un peu périmé.
Modifié par Hermann (04 May 2007 - 13:00)
Merci Raphael pour ton compte rendu qui clarifie un peu les choses.
je rebondis sur une une remarque d'Arsene concernant la logique de titrage:
Arsene a écrit :
Il y aurait probablement plus de cohérence si une structure de type <h3><p>lorem ipsum</p></h3> était possible mais ça n'est pas le cas.
Si XHTML2 est retenu comme successeur du XHTML1, on aura quelquechose dans ce genre:
<h>...</h>
<p>...</p>
<section>
<h>...</h>
<p>...</p>
<h>...</h>
<p>...</p>
<section>
<h>...</h>
<p>...</p>
<section>
<h>...</h>
<p>...</p>
</section>
<h>...</h>
<p>...</p>
</section>
<h>...</h>
<p>...</p>
</section>
Voir cet article qui fait une comparaison entre HTML5 et XHTML2.
Ceci dit celui-ci n'est pas daté, il n'est donc pas impossible qu'il soit un peu périmé.
Modifié par Hermann (04 May 2007 - 13:00)
Hermann a écrit :Bonjour.
Voir cet article qui fait une comparaison entre HTML5 et XHTML2.
Ceci dit celui-ci n'est pas daté, il n'est donc pas impossible qu'il soit un peu périmé.
Il n'est pas périmé et cela peut être simplement vérifié en suivant le lien en bas de page qui mène à la spécification en construction du XHTML 2 ce qui est bien sûr le meilleur moyen de s'informer quand on n'est pas mauvais en anglais.
Modifié par CNeo (04 May 2007 - 18:48)
Ça arrive à tout le monde ...
En me basant sur le comparatif je trouve la première chose dommage que je vois c'est l'attribut "edit" qui je pense devrait permettre l'insertion de la date pour suivre les différentes versions du document. Il me semble que ce serait particulièrement intéressant pour les wikis.
En me basant sur le comparatif je trouve la première chose dommage que je vois c'est l'attribut "edit" qui je pense devrait permettre l'insertion de la date pour suivre les différentes versions du document. Il me semble que ce serait particulièrement intéressant pour les wikis.
Arsene a écrit :
Il y aurait probablement plus de cohérence si une structure de type ceci <h3><p>lorem ipsum</p></h3> était possible mais ça n'est pas le cas.
Non, au contraire.
partons du flux :
Je vais parler de ceci. blablabla blablabla blablabla, blablabla blablabla, blablabla blablabla blablabla. Bliblibli bliblibli, bliblibli biblibli bliblibli. et je vais parler de cela. blablabla blablabla blablabla, blablabla blablabla, blablabla blablabla blablabla. Bliblibli bliblibli, bliblibli biblibli bliblibli.
Bon maintenant on séquence histoire de faire un peu le ménage, on ne précise rien, juste on séquence :
<p>
Je vais parler de ceci.
</p>
<p>
Blablabla blablabla blablabla, blablabla blablabla, blablabla blablabla blablabla.
</p>
<p>
Bliblibli bliblibli, bliblibli biblibli bliblibli.
</p>
<p>
Et je vais parler de cela.
</p>
<p>
Blablabla blablabla blablabla, blablabla blablabla, blablabla blablabla blablabla.
</p>
<p>
Bliblibli bliblibli, bliblibli biblibli bliblibli.
</p>
Ah ben voilà c'est beaucoup mieux.
... Oui mais...
La première séquence
<p>
Je vais parler de ceci.
</p>
Ce serait bien de préciser qu'en fait elle annonce les deux séquences qui suivent.
Et pareil pour celle là
<p>
Et je vais parler de cela.
</p>
Pour le dire autrement ce serait bien d'en faire un <p_ligne_en_tete> c'est à dire un <p> avec juste une signification particulière.
Pas de problème, il n'y a qu'à faire ça, et l'appeler <hn>
Dans ce cas on a :
<hn> = <p_ligne_en_tete> = <p>
Et écrire
<h3><p>lorem ipsum</p></h3>
C'est tout simplement écrire
<p><p>lorem ipsum</p></p>
Tiens, j'ai une question.
Si on prend un flux textuel non séquencé (c'est à dire un texte simple, déjà « séquencé » à la base par sa ponctuation, voire sa construction logique, mais pas séquencé au niveau du code HTML), et qu'on le divise non pas en élément p, mais en éléments div. En prenant le postulat que l'on n'imbrique pas les div. Alors quelle différence avec une série d'éléments p ?
Si je t'ai bien compris, Christian, tu dis que seul l'élément p se contente de séquencer le flux textuel brut, tandis que tous les autres éléments décrits par la spécification HTML 4 comme étant « de type bloc » (block-level elements) apportent une information supplémentaire. C'est évident dans le cas des titres de section hN, mais quid de div ? Après tout, les DTD HTML 4.01 et XHTML 1.0 n'obligent pas à utiliser div comme conteneur de plusieurs éléments. On ne peut donc pas affirmer que div serait porteur d'une information supplémentaire, qui serait « je contiens un flux séquencé » (c'est à dire : je contiens un flux lui-même divisé en plusieurs éléments, donc séquencé), vu que ce type d'utilisation n'est pas systématique, car pas syntaxiquement obligatoire.
L'utilisation de div uniquement comme conteneur d'un flux séquencé et non pas comme conteneur « final » correspond donc plus à une pratique de conception. On utilise p plutôt que div en bout de course, car p est le seul élément de type bloc qui ne peut pas contenir de flux séquencé... mais cette pratique n'a rien d'obligatoire.
Si on prend un flux textuel non séquencé (c'est à dire un texte simple, déjà « séquencé » à la base par sa ponctuation, voire sa construction logique, mais pas séquencé au niveau du code HTML), et qu'on le divise non pas en élément p, mais en éléments div. En prenant le postulat que l'on n'imbrique pas les div. Alors quelle différence avec une série d'éléments p ?
Si je t'ai bien compris, Christian, tu dis que seul l'élément p se contente de séquencer le flux textuel brut, tandis que tous les autres éléments décrits par la spécification HTML 4 comme étant « de type bloc » (block-level elements) apportent une information supplémentaire. C'est évident dans le cas des titres de section hN, mais quid de div ? Après tout, les DTD HTML 4.01 et XHTML 1.0 n'obligent pas à utiliser div comme conteneur de plusieurs éléments. On ne peut donc pas affirmer que div serait porteur d'une information supplémentaire, qui serait « je contiens un flux séquencé » (c'est à dire : je contiens un flux lui-même divisé en plusieurs éléments, donc séquencé), vu que ce type d'utilisation n'est pas systématique, car pas syntaxiquement obligatoire.
L'utilisation de div uniquement comme conteneur d'un flux séquencé et non pas comme conteneur « final » correspond donc plus à une pratique de conception. On utilise p plutôt que div en bout de course, car p est le seul élément de type bloc qui ne peut pas contenir de flux séquencé... mais cette pratique n'a rien d'obligatoire.
Florent V. a écrit :
car p est le seul élément de type bloc qui ne peut pas contenir de flux séquencé
Non pas du tout, à commencer par la série des <hn> et ce n'est pas les seuls.
a écrit :
Après tout, les DTD HTML 4.01 et XHTML 1.0
Je n'ai jamais parlé de DTD
a écrit :
On ne peut donc pas affirmer que div serait porteur d'une information supplémentaire, qui serait « je contiens un flux séquencé »
C'est un autre sujet et cela aurait pu constituer un 2ème épisode sympa.
Pour ma propre réflexion ce sera le cas, pour le reste jj'ai vraiment des doutes tellement j'ai un mauvais feeling sur la façon dont ce que j'écris peut être considéré. La critique même très catégorique ça me va parfaitement, mais l'agression ad hominem BRRRRRRRrrrrrrrrrrr...
Mais bon, oui pointes très bien le problème. Il y a un saut entre <p>, <hn>, <blocquote>, <adress> et des éléments qui ont vocations à être des conteneurs d'un flux de niveau block et non de niveau texte. Ce n'est peut être pas une obligation mais c'est bien leur vraie utilité.
On peut donc bien utiliser des <div> pour faire un pur séquençage neutre du flux texte (au passage j'aurais assez tendance à considérer <p> comme neutre dans le sens où on dit que <div> est neutre). Mais dans ce cas :
1. On n'utilise pas la balise qui est faite pour ça = <p>
2. On gomme son utilité particulière, j'ai déja eu l'occasion de dire, ailleurs, que considérer <div> comme étant simplement la balise block neutre, ce que tout le monde fait assez allègremment je trouve, c'était complètement passer à coté de sa fonction comme conteneur block de conteneurs block. Ou dit dans une perspective lègèrement différente : séquenceur d'un flux de niveau block sans déterminations autres.
C'est étonnant d'ailleurs, ça rejoint une discussion assez ancienne maintenant sur comment baliser un lien isolé qui ne serait pas compris dans une phrase.
. Liste d'un item : <ul><li></li></ul>
. <p>
. <div>
La conclusion était, en gros, une liste d'un item c'est idiot, un contenu aussi court que l'intitulé d'un lien dans un paragraphe c'est pas bien non plus, reste div puisque block et neutre.
Bon ben aujourd'hui je dirai nettement que si l'on savise de ce que <p> est aussi neutre que div en signification, alors c'est bien <p> qu'il faut choisir et qu'il faut arrêter de fixer sur le fait que p renvoit au mot du langage courant paragraph (de même que div renvoit au mot du langage courant division).
Modifié par Christian Le Bouler (05 May 2007 - 20:32)
Christian Le Bouler a écrit :
Non pas du tout, à commencer par la série des <hn> et ce n'est pas les seuls.
Ah oui tiens, suis malin moi...
Christian Le Bouler a écrit :
au passage j'aurais assez tendance à considérer <p> comme neutre dans le sens où on dit que <div> est neutre
Après réflexion, moi de même.
Christian Le Bouler a écrit :
alors c'est bien <p> qu'il faut choisir et qu'il faut arrêter de fixer sur le fait que p renvoit au mot du langage courant paragraph
Oui, pour ma part c'est ce que je fais : j'utilise systématiquement (ou du moins généralement) p en « bout de course », et div comme conteneur d'autres éléments de type bloc. Pas par obligation, mais parce qu'ainsi ça me parait plutôt clair.
Et il faut effectivement faire attention à la focalisation excessive sur les mots utilisés dans la spécification. Le fait que la spécification dise « The P element represents a paragraph » n'est pas à prendre trop au sérieux. De même pour les listes : toute série d'items n'est pas à coder avec une liste ul, et toute liste ul utilisée n'a pas besoin de correspondre à 100% au concept de liste.
Le fait est que les éléments disponibles en HTML sont très peu nombreux. Forcément, marquer « sémantiquement » un contenu demandera de nombreuses approximations, sur lesquelles il serait idiot de se focaliser.
Mais c'est un autre débat.
Christian Le Bouler a écrit :
Je n'ai jamais parlé de DTD
...
C'est étonnant d'ailleurs, ça rejoint une discussion assez ancienne maintenant sur comment baliser un lien isolé qui ne serait pas compris dans une phrase.
. Liste d'un item : <ul><li></li></ul>
. <p>
. <div>
Hihi... C'est justement là qu'il faut reparler de DTD: les DTD transitional autorisent les contenus anonymes et les éléments de type %inline dans le contenu de body... Il n'y a donc rien à baliser du tout avec le choix approprié de DTD
Laurent Denis a écrit :
Hihi... C'est justement là qu'il faut reparler de DTD: les DTD transitional autorisent les contenus anonymes et les éléments de type %inline dans le contenu de body... Il n'y a donc rien à baliser du tout avec le choix approprié de DTD
LOL
Choisir son doctype en fonction du traitement des liens isolés.
Par contre j'ai un doute là.
c'est les doctypes html qui autorisent des enfants directs inline pour body contrairement aux doctypes xhtml ?
Et non les doctypes transitional par rapport aux doctypes stricts ?
Modifié par Christian Le Bouler (05 May 2007 - 21:00)
a écrit :
Pour ma propre réflexion ce sera le cas, pour le reste jj'ai vraiment des doutes tellement j'ai un mauvais feeling sur la façon dont ce que j'écris peut être considéré. La critique même très catégorique ça me va parfaitement, mais l'agression ad hominem BRRRRRRRrrrrrrrrrrr...
Tu ne te pose pas la question du pourquoi on en est arrivé là?
Réfléchis un peu à certains de tes comportements, plus fin certes, donc moins visibles mais tout aussi blessant pour certains.
C'est d'ailleurs pour cela que j'interviens que très rarement maintenant sur le forum accessibilité pourtant étant un de ceux que je préfère.
Modifié par knarf (06 May 2007 - 01:25)