La tête dans le Flux !

Le saviez-vous ? display est inutile sur un élément flottant

J’ai envie aujourd’hui de revenir sur une idée reçue de longue date : le mélange du positionnement flottant (float) et de la propriété display.

Associer float et display: block (ou inline)

C’est parfaitement inutile.

Tout simplement parce que les deux schémas de positionnement ne peuvent pas cohabiter : un seul sera interprété, le flottant.

Pourtant, bon nombre de feuilles de styles cumulent les deux propriétés sur le même élément, sous prétexte de pouvoir lui attribuer une largeur width ou une hauteur height.

Eh ben non, c’est inutile.

La seule exception acceptable est celle d’employer display: inline pour corriger un bug identifié sur IE6 sous le nom de double-float margin bug.

Ah mais oui puisqu’un flottant devient un élément de rendu block !

Non.

Float n’a aucune influence sur la valeur de display d’un élément. Pour preuve, un élément qui sort du flux de quelque manière que ce soit (float, position: absolute ou fixed) occupe par défaut la largeur de son contenu et non la largeur de son parent. Donc pas du tout le comportement d’un bloc.

Par contre, un élément qui sort du flux bénéficie d’un avantage commun aux display block : celui de pouvoir supporter les propriétés de dimensionnement (largeur, hauteur).

Cumul des mandats ?

Les spécifications W3C admettent l’éventualité de cumuler différents schémas de positionnement.
Voici exactement comment cela se passe pour éviter les règles contradictoires :

1. Si display: none est appliqué, alors l’élément ne crée pas de boîte et les propriétés position et float ne sont pas employables.
2. Sinon, si une propriété position est appliquée et a pour valeur absolute ou fixed, ce schéma devient prioritaire, la valeur de la propriété float est forcée à none (elle devient inutile) et l’élément est placé selon les éventuelles valeurs de top, right, bottom et left.
3. Sinon, si une propriété float est appliquée avec la valeur left ou right, l’élément devient flottant et display devient inutile
4. Sinon, l’élément est disposé selon son mode de rendu par défaut inhérent à la propriété display (inline, block, list-item, etc.).

En résumé : si les propriétés float et display apparaissent au sein du même bloc de déclarations, alors display (à l’exception de display none) doit être purement et simplement ignorée par les navigateurs. Elle devient inutile.

De même, si position absolute, float et display cohabitent, ces deux dernières doivent être ignorées par les navigateurs.

Pour élargir le débat, je vous invite à consulter cet article dédié au positionnement flottant : http://www.alsacreations.com/article/lire/972-float-le-grand-bluff.html

Un polyfill pour background-size cover et contain

CSS3 propose deux valeurs très pratiques pour la propriété background-size : cover et contain.

Ces valeurs permettent de couvrir des surfaces tout en conservant le ratio de l’image de fond, comme le montre ce petit exemple personnel.

Le seul hic de ces valeurs est (un peu de suspense)… le manque de support sur les anciennes versions d’Internet Explorer (IE6 à IE8 inclus).

Louis-Rémi Babé, développeur de talent, s’est amusé à concevoir et mettre en partage une alternative (polyfill) via jQuery que j’ai pu tester avec bonheur.

Le dossier de téléchargement ainsi que la page de démonstration sont en libre service (licence MIT), servez-vous :)

table-cell et responsive design

Il y a quelques jours, Vincent de Oliveira (futur orateur de notre presque célèbre Kiwi Partÿ) s’est amusé avec display table en vue de créer un gabarit “responsive”, c’est à dire qui s’adapte aux différentes résolutions d’écran.

Sa conclusion fut que l’exercice n’est pas aussi simple que prévu, et qu’en production il faudrait cumuler les imbrications d’éléments.

Étant un grand fan des tableaux, j’ai bien évidemment été frustré par ce verdict. Il n’en fallait pas plus pour me titiller et j’ai pris ça pour un défi à relever.

Le modèle d’affichage de type “display: table” a des particularités extraordinaires. L’une d’entre-elles est d’automatiquement générer des conteneurs anonymes. Par exemple, si un élément de type display: table-cell n’a pas de parent physique sous forme table-row ou table, il l’invente.

Le mécanisme des ancêtres anonymes est pour le moins complexe et alambiqué, mais va bien nous arranger pour relever le défi lancé.

En fait, je ne vais pas faire durer le suspense : il suffit de changer le rendu d’un seul élément en table-cell sans intervenir sur ses frères.

Vous verrez le résultat sur cette page de test.

Explications :

• En mode grand écran, chaque élément est affiché en mode de rendu “table-cell”. Il s’affichent donc 3 colonnes.
• En mode “tablette”, un seul des éléments passe en table-cell. Il se crée alors un contexte anonyme autour de lui (il s’invente un parent de type “table-row” et un grand-père “inline-table” ?) qui conduit à un affichage sous forme de 2 colonnes.
• En mode “mobile”, les éléments sont affichés sous forme de blocs, les uns sous les autres pour ne former qu’une seule colonne

Je vous disais bien que les tableaux de mise en page, c’est bien ! :)