Display, vous connaissez ?

La propriété CSS Display est un puissant outil souvent mal connu et dont les possibilités réelles sont rarement utilisées. Il faut avouer que Internet Explorer y est pour quelque chose... espérons qu'il se mette à la page, vu les horizons ouvertes par cette propriété.

Sources et documentation :

La propriété Display admet 18 valeurs : inline, block, list-item, run-in, compact, marker, table, inline-table, table-row-group, table-header-group, table-footer-group, table-row, table-column-group, table-column, table-cell, table-caption, none et inherit.

Officiellement, Internet Explorer 6 reconnaît 7 valeurs pour Display : block, none, inline, inline-block, list-item, table-header-group et table-footer-group. Si cette restriction est comblée dans les futures version de IE, de belles choses sont à prévoir.

A noter que IE accepte une valeur qui n'est pas dans les standards CSS2 mais uniquement dans un CSS 2.1 à l'état de draft, 'inline-block' : Object is rendered inline, but the contents of the object are rendered as a block element. Adjacent inline elements are rendered on the same line, space permitting.

Certaines des ces valeurs ne sont d'ailleurs reconnues qu'approximativement comme l'explique le site de Blooberry [en]:

IE says it supports an "inline-block" value on this property, which would make a rendered block behave like an inline element box to the content surrounding it (eg, line-feeds in or caused by an element have no effect on surrounding in-line content.) But in testing, it does not work on elements that have an intrinsic "block" 'display' value (DIV, TABLE). It does work as expected on elements that have an intrinsic "inline" 'display' value (eg: SPAN.) If "inline-block" worked the way it should, then the explicit 'display' value would override an element's default 'display' value.

IE n'est pas le seul à avoir des rendus approximatifs : Netscape 6.x n'interprête pas correctement 'display: inline-block' et Opera 4+ a des défauts sur 'display: list-item'

Pour information, voici l'explication des différentes valeurs de Display, selon la traduction de Yoyodesign :

Block et Inline

Display : block et Display : inline sont les utilisations les plus fréquentes de la propriété Display.

block
Induit un élément à générer une boîte de bloc principale
inline
Induit un élément à générer une ou plusieurs boîtes en-ligne

Comme l'explique très bien OpenWeb, il existe principalement deux grands types de balises : les éléments en Bloc et les éléments en Ligne.

De ces deux groupes découlent des spécificités d'affichage :

  • les blocs se placent toujours l'un en-dessous de l'autre (saut de ligne, affichage à la verticale). Par exemple: une suite de paragraphes ou une liste
  • les inline se placent toujours l'un à côté de l'autre (ils restent dans le texte courant). Par exemple: la mise en gras d'une partie de texte à l'aide de la balise <strong>

Au niveau structurel et imbrications :

  • une balise bloc peut contenir une (ou plusieurs) balise bloc et/ou inline, et peut avoir une dimension (largeur, hauteur définies)
  • une balise inline ne peut contenir QUE une (ou plusieurs) balise inline, et n'a pas de dimension à proprement parler (il n'occupe que la place minimum nécessaire à son contenu)

Display : block et Display : inline permettent donc de passer d'une structure à l'autre, en modifiant le comportement d'un élément. L'exemple le plus courant est de vouloir donner une dimension et une image de fond à une balise <a> pour en faire un bouton. Par défaut, <a> est une balise Inline, il faut donc la passer en Block pour lui donner des dimensions et la sortir du texte courant.

List-item

list-item
Induit un élément (ex. l'élément LI en HTML) à générer une boîte de bloc principale et une boîte en-ligne pour un item de liste
Consulter la partie traitant des listes pour des informations et des exemples de mise en forme de celles-ci

Les éléments de liste ne sont ni des balises Bloc, ni des balises Inline. Ils ont un comportement différents. En passant un élément en Display: list-item, il pourra supporter les propriétés suivantes : 'list-style-type', 'list-style-image', 'list-style-position' et 'list-style'

Marker

marker
Cette valeur précise la qualité de marqueur du contenu généré apparaissant avant ou après une boîte. Elle ne devrait être employée qu'avec les pseudo-éléments :before et :after liés à des éléments de type bloc.
Dans certains cas, cette valeur est interprétée comme 'inline'.

Vous trouverez sur Yoyodesign des explications détaillées sur les Marqueurs.

None

none
Cette valeur fait qu'aucune boîte n'est générée par l'élément dans la structure de formatage (c.à.d., cet élément n'a pas d'influence sur la mise en forme du document). Les éléments qui en descendent ne génèrent pas de boîtes non plus ; on ne peut plus modifier leur comportement avec la propriété 'display'.
Noter qu'une valeur 'none' ne crée pas de boîte invisible, elle ne crée pas de boîte du tout. CSS comprend des mécanismes permettant la génération de boîtes dans la structure de formatage, boîtes qui influencent la mise en forme mais qui ne sont pas visibles.
Consulter la partie traitant de la visibilité pour les détails

run-in et compact

run-in et compact
Ces valeurs créent une boîte de bloc ou en-ligne, selon le contexte. Les propriétés s'appliquent aux boîtes compactes ou en enfilade en fonction de leur statut final (types bloc ou en-ligne). Par exemple, la propriété 'white-space' ne s'applique que si la boîte a un type bloc

Explication sur les termes de boites en enfilade et de boites compactes

Ces deux positionnements sont assez déroutants au premier abord car selon leurs position les uns par rapports aux autres, les boites deviennent soit bloc soit en-ligne.

Les valeurs de Tables

table, inline-table, table-row-group, table-column, table-column-group, table-header-group, table-footer-group, table-row, table-cell et table-caption
Ces valeurs donnent à un élément le comportement de celui d'une table (avec les restrictions décrites au chapitre sur les tables)

Actuellement, la valeur la plus intéressante est sans doute Display: table-cell. En effet, en donnant à un bloc le comportement habituel d'une cellule, le contenu de ce bloc va automatiquement se centrer verticalement dans ce bloc. Cette solution résoud tous les soucis d'alignement vertical que posent les mises en pages sans tableaux... malheureusement (est-il utile de le rappeler ?) Internet Explorer n'applique pas cette valeur.

Trackbacks

Aucun trackback pour le moment.

Les trackbacks pour ce billet sont fermés.

Evaluez ce billet

Commentaires

Le mercredi 9 juin 2004 à 11:49, par Antoine :: site :: #

Vachement interressant, je les connaissais pas toutes.
Décidement, ce blog est un véritable mine d'information. Merci Sib !

Le mercredi 9 juin 2004 à 13:34, par Eric Daspet :: site :: #

Attention, CSS 2.1 n'est pas en draft mais en CR (candidate recommandation). Et ce qui manque à une CR pour passer en version finale, c'est justement des implémentations intéropérables. Bref, MSIE et Opera ont raison de l'implémenter, c'est Gecko qui est à blamer sur ce coup là. D'autant que cette valeur peut être très utile pour l'organisation des layout.
Gecko manque aussi certaines valeurs de "display", visiblement c'est Opéra qui a le support le plus complet à ce jour.

Le mercredi 9 juin 2004 à 13:35, par Raphael Goetter :: site :: #

Merci pour ces précisions, Eric.

Le mercredi 9 juin 2004 à 19:14, par Laurent Denis :: site :: #

run-in et compact ne sont pas si déroutants que cela, en fait : dans les deux cas, on joue sur le display d'une boîte bloc pour la forcer à admettre sur la même ligne la boîte bloc qui la suit, sans recourir au float ni au position:absolute ou relative.

Si on retient bien qu'on vise le cas de deux boîtes blocs qu'on veut faire figurer sur la même ligne, il est logique que run-in et compact se comportent de manière variable :
- comme des boîtes en ligne particulières lorsqu'ils sont suivis d'une boîte bloc;
- comme des blocs lorsqu'ils sont suivi d'une boîte en ligne, puisque ce n'est pas le cas de figure visé.

La différence entre run-in et compact ?
- compact force simplement la boîte compact à admettre la boîte suivante sur sa ligne, si la largeur de celle-ci le permet, avec un mode de gestion des marges particulier;
- run-in transfère carrément la boîte run-in en tant que boîte en ligne *dans* la boîte bloc suivante (c'est simplement le comportement naturel des puces et des nombres dans les <ul> et dans les <ol>).

Sinon, j'avoue que j'ai de grosses réserves sur deux autres display exotiques, qui m'avaient dissuadé de les aborder dans l'article openweb que tu cites : les display qui simulent les tableaux et les listes. En effet, ils autorisent tous les abus de listes et de tableaux simulés... sans apporter grand-chose en propre.


Le mercredi 9 juin 2004 à 19:27, par Raphael Goetter :: site :: #

"En effet, ils autorisent tous les abus de listes et de tableaux simulés... sans apporter grand-chose en propre."
>>> list-item par exemple pour ajouter une puce en début d'un titre H1 ? Et table-cell pour le centrage vertical.

Le mercredi 9 juin 2004 à 20:56, par Laurent Denis :: site :: #

Non, ces propriétés exotiques n'apportent pas grand-chose qu'on ne devrait pouvoir obtenir par d'autres moyens. Pour reprendre tes deux exemples :
- la puce en début de titre s'obtient avec un :before et un boulet en content.
- pour le centrage vertical, la seule raison d'être tenté de passer par le détour du display: table-cell, c'est la mauvaise implémentation de height et de min-height....

Mais surtout... Je verrais bien Dreamweaver faire par défaut des pseudo-listes ou des pseudo-tableaux à grand coup de div, si l'implémentation était meilleure ;) Là, on serait bien embêté !

Le mercredi 9 juin 2004 à 21:17, par Fabrice Bonny :: site :: #

En fait, on peut très bien mettre le body en table et des divs menu, content, header et footer en cellule. Et hop, on simule une table et on tord le cou aux critiques des adeptes des tables en 3 secondes. Pourquoi on le fait pas? Un indice: la réponse commence par MS et finit par IE.

Le mercredi 9 juin 2004 à 21:30, par Laurent Denis :: site :: #

Bah... Oublions le trublion qui commence avec MS : pourquoi pas, en effet éliminer le box-model de CSS et tout remplacer par un modèle de table ? Au moins, tout le monde sera d'accord ;)
Dites, vous me laisserez la position fixe, quand même ? :D

Le jeudi 10 juin 2004 à 02:09, par Raphael Goetter :: site :: #

C'est vrai qu'on en ferait des choses si seulement MS le voulait bien :songeur:

Ajouter un commentaire

Les commentaires pour ce billet sont fermés.

  • CSS2
  • Memento XHTML
  • Le zen des CSS
  • CSS
  • Web accessible