Type block

Salut

Petites réflexions portées à votre perspicacité :

Une balise de type block est un marqueur qui induit un séquençage du flux de niveau texte. Une balise de type inline n'induit aucun séquençage de ce flux.

D'où il suit : Toutes les balises de type block sont des exceptions... ... Sauf <p> qui est la règle.

En conclusion : Si on ne comprend pas la fonction de la balise <p> alors c'est que l'on ne comprend rien au html.

Mal convaincu par l'excessive théorisation de la syntaxe HTML je suis.

Christian Le Bouler a écrit :

D'où il suit : Toutes les balises de type block sont des exceptions... ... Sauf <p> qui est la règle.

Non, car <p> ne joue (hélas ?) pas ce rôle de définition d'unsegment de contenu minimal signifiant, ce qui serait le seul intérêt de la chose.

Un cas-type: le vieux problème des liens <a> consultés hors contexte qui sont supposés y être toujours compréhensibles :
- le <span> aurait pu jouer ce rôle dans un autre HTML,
- les éléments de phrase sont vaguement supposés le faire dans le HTML actuel (c'est ce qui se rapproche le plus de ce que tu cherches, je crois), mais les règles de structuration trop vagues et la complexité d'usage rendent cela inopérant.
- en fait, nous n'avonspas d'élément qui détermine la séquence minimale ayant un sens, ni au niveau block, ni au liveau inline, ni aux autres (car il y a d'autres types de contenus dans les DTD, ce qu'on oublie très souvent, comme %phrase justement).

Par ailleurs, le séquençage se fait côté agents utilisateurs/périphériques de sortie de bien d'autres manières, parfois liées à la structure, parfois non; Deux exemples rapides:
- les boîtes de ligne CSS des moteurs de rendu graphiques, qui savent très bien vous casser le sens.
- les tablettes brailles et leurs fameuses plages de 20, 40, 80, etc. caractères...

Bien tenté. En tous cas, c'est un sujet très peu abordé mais très intéressant
Modifié par Laurent Denis (29 Apr 2007 - 11:41)

Salut,

bon déjà merci beaucoup de me répondre sur mes turpitudes de html addict

Florent V. a écrit :
Mal convaincu par l'excessive théorisation de la syntaxe HTML je suis.

Je ne parlais pas de la syntaxe html en fait. Mais de quelque chose que je placerais avant, c'est à dire la prise en charge minimale (et au passage non encore signifiante) du flux.
Un flux pur est à peu près incompréhensible, imaginons un texte de 10000 caractères écrit sur une seule ligne ou dit de manière continue avec une voix parfaitement monocorde (même si elle prend en compte la ponctuation).

Je ne sais pas moi, un copier/coller de 5 pages d'à "La recherche du temps perdu" sans aucun balisage consulté via Jaws par exemple.

Avant même que se pose la question de l'élaboration de la syntaxe html et des significations particulières qu'elle peut amener ce point doit être régler, séquencer le flux pour séquencer le flux et rien d'autre.

A Laurent > Le point sur lequel je ne te suis pas c'est justement la question de la signification. Avant d'être elle même caractérisée (je suis un en-tête de premier niveau de généralité, je suis un item de liste...) une balise block ne donne aucune signification, par contre elle séquence. Ah oui au fait, plutôt que le terme de signification je pense en terme de caractérisation.

Une balise de type inline est toujours une caractérisation d'un moment du flux mais jamais un séquençage ne celui ci.

Il n'existe qu'une seule balise de type block qui ne fait rien d'autre que séquencer le flux de niveau texte sans donner de particularisation et c'est la balise <p>.
<div>, au passage, n'est pas fait pour ça mais opérer un séquençage du flux de niveau déjà block.

<p> est la balise de type block elle même, toutes les autres balises block sont block + autre chose (une particularisation).

je refais, c'est pas passé apparemment

Christian Le Bouler a écrit :
Je ne parlais pas de la syntaxe html en fait. Mais de quelque chose que je placerais avant, c'est à dire la prise en charge minimale (et au passage non encore signifiante) du flux.

Il n'y a pas de prise en charge non encore signifiante du flux, en amont d'une seconde prise en compte qui, elle, serait signifiante. Il n'y a aucune raison qu'il y en ait une en fait: si elle n'est pas signifiante, à quoi servirait-elle ?

En d'autres termes, cette première prise en charge du flux, c'est tout bêtement l'établissement de l'arbre du document, nécessairement signifiant puisqu'il prend en compte immédiatement tous les noeuds éléments.

Ce n'est qu'après que l'arbre du document peut être exploité lui-même comme un flux séquencé de manière arbitraire (les exemples précédents des boîtes de ligne dans la structure de formattage CSS et celui es séquences brailles, auxquelx on peut aussi ajouter le passage au media paginé du print par exemple).

Christian Le Bouler a écrit :
séquencer le flux pour séquencer le flux et rien d'autre.

Hihi... Tu parles toi-même de séquencer le flux pour qu'il soit compréhensible, mais de le faire sans que ce soit signifiant : vois-tu mieux le problème, là ?

Christian Le Bouler a écrit :

<p> est la balise de type block elle même, toutes les autres balises block sont block + autre chose (une particularisation).

Sans compter que, aussi polysémique soit-il, ou aussi flou que soit sa définition formelle et variables les usages qui en sont fait, <p> a un sens et ne ne distingue en rien des autres éléments: c'est un "paragraphe".

Wouah c'est beau,

Je ne sais pas si d'un ordre général cela peux faciliter la compréhension de l'élément p mais c'est beau

Donc tout ça pour au final aboutir à cela non?

a écrit :
<p> a un sens et ne se distingue en rien des autres éléments: c'est un "paragraphe".

Mais je comprends que vous vouliez vous faire plaisir
Modifié par knarf (30 Apr 2007 - 23:51)

knarf a écrit :
Mais je comprends que vous vouliez vous faire plaisir

+1

knarf a écrit :

Je ne sais pas si d'un ordre général cela peux faciliter la compréhension de l'élément p

LOL

D'accord, et maintenant tu nous expliques pourquoi <p> ne peut pas contenir de balise <ul> sans faire annoner à tout le monde que c'est comme ça parce que ce n'est pas autrement et que c'est une exception et puis voilà quoi

Christian Le Bouler a écrit :
D'accord, et maintenant tu nous expliques pourquoi <p> ne peut pas contenir de balise <ul> sans faire annoner à tout le monde que c'est comme ça parce que ce n'est pas autrement et que c'est une exception et puis voilà quoi

De façon très pragmatique, je dirais que c'est parce que le balise de fermeture </p> est optionnelle en HTML.

Julien Royer a écrit :
De façon très pragmatique, je dirais que c'est parce que le balise de fermeture </p> est optionnelle en HTML.

Est ce que la fermeture de <li> est optionnelle en html ?

Christian Le Bouler a écrit :
Est ce que la fermeture de <li> est optionnelle en html ?

Oui, et alors ?

Alors ton explication pragmatique n'explique rien, <li> peut être conteneur d'éléments de type block et <p> non.

Pourquoi ?

Pourquoi cette différence ? Le critère n'est pas le caractère optionnel de la balise de fermeture en html puisqu'on vient de dire que ce caractère est partagé.
Modifié par Christian Le Bouler (01 May 2007 - 12:38)

Je crois que tu n'as pas saisi.

La fin d'un élément li est évidente : elle a lieu quand on rencontre une balise </li>, <li> ou </ul>.

Christian Le Bouler a écrit :
En doctype html quelles sont les balises de type block ayant une obligation de fermeture ?

Pour les éléments ayant des contenus de type %block et %flow, et sauf oubli, toutes sauf:

* p
* li
* dd
* tbody (dont les deux balises sont optionnelles, en fait)
* thead
* tfoot
* colgroup
* tr
* th
* td

Mais c'est en effet une simple question mécanique, Christian. Tout ce qu'on peut y trouver de remarquable est un petit poil de contingences historiques d'HTML, au fil des specs.

HTML... n'est qu'HTML

(Pour illustrer cet aspect mécaniqme: <table>, <ul, <ol> et <dl> doivent être fermés, simplement parce qu'ils contiennent chacun des éléments qui peuvent ne pas l'être ou qui peuvent être omis. En d'autres termes, <ul> doit être fermé sinon tout le reste du contenu au-delà de la liste sera dans le dernier <li> ouvert et non fermé).

<edit>

arf

Dans la lignée de tbody et des contingences historiques, j'oubliais les autres éléments totalement optionnels, dont la seule fermeture l'est donc également:
* html
* body
* head

On ne va pas citer une nouvelle fois le vieil exemple de la page HTML minimale valide, mais bon : tout cela n'est pas vraiment signifiant. Plutôt anecdotique et en tous cas amusant...
Modifié par Laurent Denis (01 May 2007 - 13:59)

En revanche, l'idée initiale de séquençage était vraiment intéressante.

knarf a écrit :
Mais je comprends que vous vouliez vous faire plaisir

Oui

Salut,

Avant d'aller plus loin (ben oui, ce n'est pas seulement que je suis têtu mais c'est surtout que pour l'instant vous ne m'avez en rien convaincu que je faisais fausse route. Sans en tirer la moindre conclusion, je m'empresse de le préciser)

Laurent Denis a écrit :


On ne va pas citer une nouvelle fois le vieil exemple de la page HTML minimale valide

Je n'ai pas compris.

Christian Le Bouler a écrit :

Je n'ai pas compris.

Alors, citons nos classiques:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">
<title</title<p>

Code surprenant, mais parfaitement valide en HTML4.01 transitionnal... sans qu'il n'y ait aucun enseignement sémantique, philosophique ou simplement utile à en tirer. Tout au plus quelques curiosités de la spécifications.
Modifié par Laurent Denis (01 May 2007 - 16:07)

Ah !!!

Je ne connaissais pas

C'est un peu bizarre parce que si le flux c'est ce qui est compris dans le body alors le fait que le body ne soit pas indiqué ça ne colle pas. Mais bon encore une fois je découvre l'anecdote.
Modifié par Christian Le Bouler (01 May 2007 - 16:08)