5568 sujets

Sémantique web et HTML

Pages :
(reprise du message précédent)

Ah !!!

Je ne connaissais pas Smiley smile

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)
Ce "flux", à moins que tu ne lui en donne une définition personnelle, c'est simplement le contenu HTML. De <html> à </html> Smiley cligne

<edit>
En fait, plus exactement: d'avant <html>à </html> exactement : il peut y avoir un commentaire ou une instruction avant l'ouverture de l'élément html, mais pas après.
</>
Modifié par Laurent Denis (01 May 2007 - 16:10)
Laurent Denis a écrit :


Alors, citons nos classiques: Smiley cligne

<!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.
Ah oui effectivement, c'est déroutant tout ça! On en apprend décidément tous les jours...
Smiley ravi
Tiens, puisqu'on cite, citons le commentaire de Karl Dubost dans le billet où il exhumait cet exemple minimaliste, il y a 4 ans (déjà ? Au moins, ici, ce commentaire sera lu par tous les petits jeunes Smiley ravi ) :

Karl Dubost a écrit :

Conclusion 1 : La morale de cette histoire, c'est qu'il vaut mieux enseigner XHTML 1.0 que HTML 4.01. Pourquoi parce-que la syntaxe est plus stricte. Vous me direz que c'est moins souple donc. Et bien pas dans le cadre de l'enseignement, il est plus facile d'apprendre quelquechose quand le nombre de possibilités est réduite. Le modèle XHTML 1.0 est bien plus facile à retenir que celui de HTML 4.01.


Certes, la limite de la chose, quand on se penche cette fois sur les éléments eux-mêmes, et non plus seulement sur la syntaxe, c'est qu'XHTML1.0 est tout aussi imbittable et douteux qu'HTML4.01, ayant exactement le même stock d'éléments parfois... improbables. C'est pourquoi, effectivement, il y a des choses à ne pas trop creuser, sauf pour se faire plaisir Smiley cligne
Modifié par Laurent Denis (01 May 2007 - 16:23)
Laurent Denis a écrit :
Ce "flux", à moins que tu ne lui en donne une définition personnelle, c'est simplement le contenu HTML. De <html> à </html>


Ben non, ça va me prendre des heures pour tout relire, puisque c'est au format .txt, et en plus en anglais Smiley eek , mais c'est dans un autre grand classique que j'ai lu que le flow (moi je traduis flux) c'est ce qui est compris dans le body.

Même si ce dont il est question est un flux de niveau block et pas de niveau texte, et que là c'est vraiment très compliqué je trouve.
Modifié par Christian Le Bouler (01 May 2007 - 16:28)
Oui, "<body> est un flux (flow) de paragraphes, de listes et d'autres éléments" disait HTML2.0.

Mais head aussi est un flux d'éléments (parfaitement utilisables dans un rendu graphique, même si l'usage actuel qu'en font les navigateurs n'est pas celui-là).

C'est simplement la nature linéaire du HTML, qui n'est rattachée à aucun élément en particulier.
Modifié par Laurent Denis (01 May 2007 - 16:30)
Christian Le Bouler a écrit :

Même si ce dont il est question est un flux de niveau block et pas de niveau texte, et que là c'est vraiment très compliqué je trouve.


Perdu.

En HTML4.01 ou XHTML1.0 transitionnal, <body> peut contenir directement un texte anonyme. Même pas besoin d'élément inline autour Smiley cligne .
Laurent Denis a écrit :


Perdu.

En HTML4.01 ou XHTML1.0 transitionnal, <body> peut contenir directement un texte anonyme. Même pas besoin d'élément inline autour Smiley cligne .


OUi, oui je n'ai pas dit le contraire, je faisais juste remarquer la difficulté d'interprétation. C'est pour ça que j'utilise l'expression flux de niveau texte dans mes précédents posts, pour éviter l'ambiguité justement.

Mais je peux modifier si ça aide :

a écrit :

Même si ce dont il semble être question est un flux de niveau block et pas de niveau texte, et que là c'est vraiment très compliqué je trouve.


Mais bon on peut aussi considérer que c'est juste une aimable plaisanterie.
Modifié par Christian Le Bouler (01 May 2007 - 16:44)
Christian Le Bouler a écrit :

Mais bon on peut aussi considérer que c'est juste une aimable plaisanterie.


Pas du tout.

En revanche, en voici une:

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

A afficher et surtout regarder le HTML généré dans FF, IE, et Opera... Smiley ravi
Modifié par Laurent Denis (01 May 2007 - 17:54)
Bonjour,
j'intervient dans ce quasi-dialogue instructif (ça tombe bien le voulais justement savoir ce que signifiait exactement %flow) pour vous faire part de ma stupéfaction à la découverte dans les specs de ceci:
a écrit :
<!ELEMENT P - O (%inline;)* -- paragraphe -->

Alors comme ça les <p> ne serait pas des élément de type block??
Ou est-ce une boulette du HTML working group?
Il s'agit du type de contenu de l'élément, pas du type de l'élément lui-même : <p> a un contenu de type %inline.

(Attention, choc traumatique en vue : le fameux "<p> est un élément de type block" n'existe pas dans les DTD et ne relève que de l'approximation inutile et des confusions avec les types de boîtes CSS. Mais bon, ça n'a jamais empêcher de multiples forums de tourner et d'innombrables webmestres de webmestrer Smiley ravi )
Modifié par Laurent Denis (01 May 2007 - 18:28)
Pour le détail, et parce que c'est Hermann:

Chaque élément est défini dans une DTD avec, grosso modo:
- son nom
- son balisage (balise ouvrante/fermante obligatoires/optionnelles)
- son type de contenu
- ses attributs obligatoires/optionnels.

Il ne lui est nulle part donné de type unique en lui-même et pour lui-même.

En revanche, pour écrire plus aisément les types de contenus de chaque élément sans avoir à énumérer tout le détail élément par élément, la DTD utilise des entités qui rassemblent plusieurs éléments dans un type défini.

%inline et %block, dans les DTD HTML et XHTML1.0, sont simplement des entités, c'est à dire de simples écritures racourcies, sans portées sémantiques.

Il y a bien d'autres entités, à commencer par %flow (disons, %block + %inline), ou %heading (les titres h1 à h6). Le contenu d'un élément peut également être %block + un ou deux éléments spécifiques (<body> contient du %block plus <del> et <ins> en strict, par exemple).

Certains éléments n'apparaissent que une seule définition d'entité, d'autres dans plusieurs entités.

Il faut arrêter de se fixer sur ces notions d'éléments de type machin...
Modifié par Laurent Denis (01 May 2007 - 18:42)
Ah d'accord, bon ça me rassure! Merci Laurent.
Alors les <p> sont vraiment appart... Ce serait seulement un
élément sémantique dont la CSS de l'agent utilisateur en fait
une boîte de bloc.
Modifié par Hermann (01 May 2007 - 18:41)
Hermann a écrit :
Ah d'accord, bon ça me rassure! Merci Laurent.
Alors les <p> sont vraiment appart...


Si ça se référe à ce qu'a dit laurent non pas du tout.

Certes il y a bien :
Laurent Denis a écrit :
le fameux "<p> est un élément de type block" n'existe pas dans les DTD


Mais il y a aussi et surtout :
Laurent Denis a écrit :


Chaque élément est défini dans une DTD avec

...

Il ne lui est nulle part donné de type


Et il y a enfin :
Laurent Denis a écrit :

Il faut arrêter de se fixer sur ces notions d'éléments de type machin...


Donc Laurent ne parle pas du tout de <p> mais de l'idée même de typage de quelque balise que ce soit.


<hs>
Laurent Denis a écrit :

en lui-même et pour lui-même.

Je m'en doutais, tu es hegelien... Smiley lol
(c'est juste pour rire Smiley confused )
</hs>
Modifié par Christian Le Bouler (01 May 2007 - 21:49)
@Laurent. Je n'avais pas vu ta dernière réponse. Merci pour ces éclaircissements, notamment sur la notion de type de contenu que je ne connaissais pas. Ceci dit, je savais déja lire en partie la première ligne de ce qui caractérise un élément au niveau de la DTD.
Laurent Denis a écrit :
Il ne lui est nulle part donné de type unique en lui-même et pour lui-même.

Christian Le Bouler a écrit :
mais de l'idée même de typage de quelque balise que ce soit.

Je ne suis pas sure que ça soit très clair... Affirmer que tel élément
est de type block (exception faite de certains éléments dont <p>) voudrait
alors dire que c'est un élément pouvant contenir des éléments de niveau block
(typé en boîte de boc par la CSS)?
Laurent, juste une question : c'est voulu dans ton exemple de page minimaliste que la balise title ne soit pas correctement ouverte ni fermée, ou est-ce une faute de frappe ?
QuentinC a écrit :
Laurent, juste une question : c'est voulu dans ton exemple de page minimaliste que la balise title ne soit pas correctement ouverte ni fermée, ou est-ce une faute de frappe ?
Visiblement c'est voulu, étant donné que le validateur l'accepte. J'avoue que je ne connaissais pas cette possibilité...
Alors si j'ai bien compris :

- il n'y a pas d'élément de type bloc (block) ou d'élément de type en-ligne (inline) en HTML ;
- il y a, dans les DTD, des raccourcis d'écritures qui forment de sortes de familles d'éléments, dont une famille %block et une famille %inline, sans que cela ait de conséquence sémantique ou pratique pour tel ou tel élément (qui se fiche bien d'avoir été mis dans telle ou telle famille-raccourci d'écriture) ;
- on a par contre, en CSS, des rendus (display) de type bloc (block), en-ligne (inline), tableau (table), item de liste (list-item), etc. ;
- enfin, les styles par défaut des navigateurs attribuent un type de rendu par défaut à chaque élément.

Ça va, j'ai juste ?
QuentinC a écrit :
Les noms dans la DTD n'ont quand même sûrement pas été choisis au hasard.

Oui, ce sont des noms évocateurs. Mais toujours si j'ai bien compris, ces noms ne confèrent pas de propriété particulière aux éléments ainsi regroupés. C'est donc juste une convention d'écriture dans la DTD, parce qu'il est plus simple de faire une famille %block plutôt qu'une famille %tartiflette.

(Mais faut peut-être que j'arrête de supputer de potentielles bêtises... Smiley confused )
Modifié par Florent V. (02 May 2007 - 20:58)
Florent V. a écrit :
Mais toujours si j'ai bien compris, ces noms ne confèrent pas de propriété particulière aux éléments ainsi regroupés.

Tu as bien compris. Smiley cligne
Pages :