Un récent travail de collecte de retours d’expérience mené par un développeur web met en lumière les frustrations persistantes des concepteurs et intégrateurs face aux outils de mise en page en CSS. L’analyse, qui s’appuie à la fois sur les résultats du sondage State of CSS 2025 et sur un micro-sondage lancé sur des réseaux sociaux, révèle que si les modules Grid et Flexbox ont considérablement fait évoluer les possibilités de design, ils n’ont pas encore comblé tous les besoins concrets du développement.

Les points de douleur de CSS Grid

L’étude des réponses libres concernant les difficultés de mise en page avec CSS Grid montre un apprentissage perçu comme ardu. Les développeurs peinent à retenir la syntaxe, notamment les propriétés composées commençant par grid-template-*, et à intégrer les modèles mentaux de pistes, zones, grille implicite ou explicite. La distinction entre propriétés qui s’appliquent au conteneur parent et celles destinées aux éléments enfants est source d’erreurs fréquentes. Les incohérences de nommage, comme la différence entre justify-* et align-*, qui chevauchent par ailleurs celles de Flexbox, obligent même les développeurs expérimentés à consulter régulièrement la documentation.

Au-delà de l’apprentissage, l’utilisation quotidienne de Grid révèle des difficultés pratiques. Les mises en page courantes, telles que les interfaces pleine hauteur avec zones défilables, les tableaux de bord mêlant zones fixes et fluides, les carrousels alignés sur une grille, ou les systèmes de design réutilisables, restent complexes à réaliser. La gestion des grilles fluides, du nombre de colonnes responsives et de l’ajustement automatique des éléments nécessite des configurations élaborées. Le choix entre Grid et Flexbox est souvent source d’hésitation, leurs fonctionnalités se chevauchant mais leurs logiques différant. Les interactions entre ces deux modules, ainsi qu’avec d’autres modes de mise en page, sont perçues comme imprévisibles.

Parmi les frustrations les plus couramment citées figurent le centrage des éléments restants sur une dernière ligne, l’alignement sur des lignes de grille arbitraires, la gestion des espaces (gaps) et leur style, ainsi que la symétrie entre le chevauchement de lignes et de colonnes. L’intégration avec les requêtes de conteneur (container queries) et le subgrid sur plusieurs niveaux est également jugée insuffisante.

Les lacunes de Flexbox

De leur côté, les difficultés liées à Flexbox ne sont pas moindres. La syntaxe, selon les retours, ne devient pas naturelle avec la pratique : les combinaisons de propriétés doivent être recherchées encore et encore, et le recours à l’essai-erreur reste courant, même pour les développeurs chevronnés. Le modèle mental d’axe principal et d’axe secondaire, dépendant de flex-direction, est difficile à intérioriser, tout comme la logique directionnelle des propriétés de justification et d’alignement.

Si Flexbox est jugé simple pour les besoins de base, il montre rapidement ses limites pour des usages intermédiaires ou avancés. Le comportement de redimensionnement et de rétrécissement des éléments est particulièrement décrié : les interactions entre flex-grow, flex-shrink et flex-basis sont difficiles à anticiper, les éléments rétrécissant parfois en deçà de leur taille de contenu, ce qui oblige à des contournements comme min-width: 0. L’obtention de hauteurs ou largeurs égales avec du contenu dynamique est problématique, de même que le mélange de tailles fixes et flexibles. Les problèmes de débordement et de hauteur dans les mises en page imbriquées avec zones défilables sont fréquents, et l’interaction entre flex-basis, gap et les marges est jugée incohérente.

Les fonctionnalités toujours absentes

Le micro-sondage a permis de classer, par nombre de mentions, les fonctionnalités de mise en page qui font cruellement défaut à la CSS. En tête de liste (environ 12 mentions) arrive l’absence de détection du débordement ou du retour à la ligne (wrap). Il est actuellement impossible, uniquement avec CSS, de savoir quand le contenu déborde ou passe à une nouvelle ligne. Pour adapter la mise en page (par exemple, réduire des éléments de navigation qui ne tiennent pas, afficher un badge « +3 », ou ajouter des indicateurs de défilement), le recours à JavaScript reste indispensable.

La seconde demande (environ 5 mentions) concerne la fonctionnalité de régions CSS, qui permettrait de faire circuler du contenu textuel d’une boîte de mise en page à une autre, à la manière des cadres de texte liés dans les logiciels de PAO comme InDesign. Cela répondrait à un besoin pour les mises en page éditoriales avec citations détachées, barres latérales ou designs de magazines multi-colonnes.

Avec également environ 5 mentions, l’habillage de texte non rectangulaire (CSS Exclusions) est réclamé. Les développeurs souhaitent pouvoir enrouler du texte autour de toutes les faces d’un élément, l’épouser à l’intérieur d’une forme, ou le faire couler autour d’éléments dont le contour est défini par clip-path ou border-radius. Ces mises en page éditoriales, pourtant courantes en print, restent inaccessibles sur le web.

Enfin, le repositionnement d’éléments indépendamment de la structure du DOM (environ 5 mentions) est un besoin exprimé pour réordonner visuellement du contenu en fonction du support (par exemple, une table des matières dans une barre latérale sur ordinateur et au-dessus du contenu sur mobile) sans avoir à modifier le code HTML ni à dupliquer le balisage.