5568 sujets

Sémantique web et HTML

Bloc / inline : problème à la lecture d'un article de Raphaël

Bonjour,

Je viens de lire un article de R. Goetter sur alsacréations et je viens de comprendre que ce qui est exposé est sensiblement différent de ce que je pensais.

Dans le fond, ça ne change rien puisque je n'ai pas de soucis de mise en page, mais ça me gêne beaucoup car je voyais ça tout autrement.

L'article (Comprendre la structure HTML et le rendu CSS des balises : bloc et en-ligne indique qu'il y a des éléments de rendu bloc et des éléments de rendu inline.

Déjà, pour moi, c'était tout le contraire puisque j'associais ce type à l'entité %bloc et %inline (ainsi que %flow.)
Et c'était bien plus clair car un élément est défini non par son aspect mais son comportement, c'est-à-dire ce qu'on peut trouver sans le DTD. Son aspect, c'est CSS qui s'en charge.

Aussi, si un élément inline, par exemple, est défini par son rendu, il me suffit de le mettre en display: block, de lui mettre un width et voilà, je me retrouve avec un élément bloc (sur la forme). Alors que sa définition propre ne change pas : je ne pourrais théoriquement toujours pas mettre un <em> directement dans le <body>.

De même, j'ai lu par ailleurs qu'un élément inline n'avait pas de marge propre. Pourtant, un margin fonctionne très bien, et ceci sans le déclarer en display: bloc.

Donc pourriez-vous m'expliquer le raisonnement à avoir ?

Merci.
talvins a écrit :
Donc pourriez-vous m'expliquer le raisonnement à avoir ?

Le raisonnement à avoir est le suivant: arrivé à un certain niveau de connaissance de HTML et CSS, se rendre compte que les concepts d'«élément de type bloc» et d'«élément de type en-ligne» ne sont rien d'autre que des raccourcis pédagogiques, qui comportent leur lot d'imprécisions et de contre-vérités techniques, comme tout raccourci pédagogique.

Ce raccourci n'est pas fait uniquement par tel ou tel article, mais directement par la spécification HTML 4. On pourra la relire pour s'en assurer (en anglais, on parle de «block-level elements»).

Ensuite, quand on s'intéresse à l'aspect technique des choses, on a d'un côté:

1. Dans les DTD, les entités (entities), qui sont uniquement des raccourcis d'écriture (c'est à dire que quand on doit indiquer quels éléments peut contenir un élément donné, écrire %block ou %flow ça va plus vite que de marquer tous les éléments en question). Ces raccourcis n'ont rien à voir avec des propriétés particulières des éléments, et ne recouvrent pas forcément des concepts utilisés dans la spécification. Par exemple, H4 appartient à %heading qui appartient à %block qui appartient à %flow. TABLE appartient à l'entité %block, mais sauf erreur de ma part les éléments THEAD, TBODY, TFOOT, TR, TH et TD n'appartiennent à aucune entité.

Conclusion pour les entités indiquées dans la DTD: on s'en fout royalement, en dehors des questions de «cette imbrication d'éléments est-elle valide?».

2. Côté CSS, la propriété display accepte un certain nombre de valeurs. Citonsen quelques unes en vrac: "bloc", "inline", "table", "table-cell", "list-item", etc.
Chacun de ces types d'affichages est spécifié. La spécification CSS propose également une feuille de styles par défaut pour HTML qui indique que tel élément HTML devrait avoir un rendu de type machin (Appendix D de CSS 2.1)... mais cette feuille de style proposée n'est pas normative, et si un Agent Utilisateur décide que les LI auront un affichage de type "block" et pas "list-item"... ben voilà.

Conclusion pour les types d'affichage CSS: mieux vaut savoir quel est le type d'affichage «consensuel» pour un élément HTML donné. En général, ça suit les styles par défaut proposés par l'Appendix D (qui correspondent aux indications de mise en forme que l'on trouve de-ci de-là dans la spécification HTML 4, même si moins fortement que dans HTML 3 il me semble... il faudrait que je vérifie).

Tiens, j'ai bien envie de les citer ces styles par défaut proposés:
html, address,
blockquote,
body, dd, div,
dl, dt, fieldset, form,
frame, frameset,
h1, h2, h3, h4,
h5, h6, noframes,
ol, p, ul, center,
dir, hr, menu, pre   { display: block }
li              { display: list-item }
head            { display: none }
table           { display: table }
tr              { display: table-row }
thead           { display: table-header-group }
tbody           { display: table-row-group }
tfoot           { display: table-footer-group }
col             { display: table-column }
colgroup        { display: table-column-group }
td, th          { display: table-cell }
caption         { display: table-caption }
input, select   { display: inline-block }
(il y a là toutes les propriétés display pour cette feuille de styles proposée).

On remarquera que cette feuille de style par défaut à l'air de considérer que le rendu par défaut (lorsque non précisé ci-dessus) est "inline". Le html.css de Firefox a l'air de faire de même.
talvins a écrit :
De même, j'ai lu par ailleurs qu'un élément inline n'avait pas de marge propre. Pourtant, un margin fonctionne très bien, et ceci sans le déclarer en display: bloc.

Heu... les éléments en display: inline ne peuvent pas avoir de marges verticales, mais pour les marges horizontales il me semble que c'est OK.
Florent V. a écrit :

Le raisonnement à avoir est le suivant: arrivé à un certain niveau de connaissance de HTML et CSS, se rendre compte que les concepts d'«élément de type bloc» et d'«élément de type en-ligne» ne sont rien d'autre que des raccourcis pédagogiques, qui comportent leur lot d'imprécisions et de contre-vérités techniques, comme tout raccourci pédagogique.


Je pense que la solution à ma question est finalement là. Ce qui est d'ailleurs un problème que je rencontre depuis quelque temps.

Je lis beaucoup d'articles de gens qui ont une assise certaine. Non pas qu'ils soient prétentieux, mais simplement qu'ils présentent les faits comme établis : on ne lit pas des interprétations, des conseils mais ce qui semble être des axiomes.

Or, comme je cherche toujours à apprendre, j'assimile tout ça comme vérité absolue.

Mais il s'avère que parfois, tout est pourtant question de point de vue (par exemple, les commentaires de Joe Clark sur les WCAG 2 en était une très bonne illustration.)

Ce qui tu dis pour bloc et inline me parait très juste. Pour ma part, je faisais une distinction uniquement en fonction des entités %bloc, %inline et %flow comme je le disais, et surtout par habitude.
Mais comme je lis partout cette distinction, appuyée dans l'article que j'évoque par le fait qu'on ne devrait pas dire "élément de type bloc" mais "élement de rendu bloc", je me suis dit que je devais vraiment louper quelque chose. Mais non.

Enfin bref, merci pour ta réponse, ça me convient Smiley cligne
Administrateur
talvins a écrit :
par le fait qu'on ne devrait pas dire "élément de type bloc" mais "élement de rendu bloc", je me suis dit que je devais vraiment louper quelque chose. Mais non.

Hello,

J'interviens de façon très (trop) rapide pour préciser cette partie.
Ce n'est pas qu'on "ne devrait pas dire élément de type bloc", c'est simplement qu'en le disant, on se trompe généralement de cible :
- un "élément de type bloc" c'est simplement un élément %bloc dans la dtd
- un "élement de rendu bloc" c'est ce qu'on appelle généralement (et à tort) le "type bloc", c'est à dire le rendu CSS (display: block)

Selon les navigateurs, les préférences personnelles ou autre, un élément "de type bloc" n'est pas forcément un élément "de rendu bloc".

L'article avait justement été remanié pour expliquer ce genre d'erreurs fréquentes.

C'est plus clair ainsi ?

Comme le dit Florent, on se fiche plutôt de savoir de quel "type" est l'élément (%bloc, %flow ou autre n'est utile que pour connaître ses imbrications possibles). Par contre le "rendu" de l'élément est important à maîtriser (la valeur de "display").
Modifié par Raphael (06 Dec 2007 - 17:32)
Oui, c'est bien ce que j'avais finalement cru comprendre, mais comme tu parles de "rendu bloc" et qu'un rendu c'est un type particulier d'affichage, je ne voyais plus le lien avec les entités %bloc et %inline.

Mais comme le faisait justement remarquer Florent, je crois que je cherche trop en détail des révélations sur des sujets que je connais déjà.
C'est ça d'avoir un nom célèbre dans les CSS : tu écris un article, je le lis en espérant y comprendre la création du monde Smiley smile

Mais je crois que tout a été dit et redit sur HTML4.01 et CSS2(.1). Du moins ce qui est supporté par les UA.

Ah non ! Personne n'a répondu à mon message sur la relation rev. Et je n'ai également jamais trouvé de bonnes docs sur les profiles de meta et l'attribut scheme de head.
Sujet clos
Aller à