Cet après-midi, à l’occasion d’une réunion d’échange hebdomadaire, j’ai présenté flexbox à mes collègues.

Flexbox est une technique de positionnement CSS, introduite en CSS3. Chez nous, c’est un peu le sujet troll du moment : j’ai utilisé des flexbox pour mettre en page le « tableau de bord » affiché dans nos locaux… et comme je découvrais, j’ai intégré un peu de travers et il y a pas mal de bugs de rendu, notamment avec les images. Lalala.

L’objectif de la réunion était de présenter très rapidement comment fonctionne flexbox, mais surtout l’intérêt que ça présente, ce que ça résout comme problèmes, etc.

J’ai préparé la présentation en une petite demi-heure, car j’avais tout oublié ou presque depuis la dernière fois que j’y avais touché (l’intégration front n’est pas mon occupation principale, même si j’adore ça, et je commence à dater un peu).

J’ai relu le très vieil article d’Alsacréations à propos des flexbox, écrit à l’époque où c’était encore tout beau tout neuf. J’ai approfondi avec le récapitulatif de CSS-tricks…

Et surtout, j’ai expérimenté les différentes valeurs avec des pages de test… Firebug et les outils de développeur vous permettent de modifier les styles CSS à la volée, il faut en profiter !

J’ai fait ma démonstration en modifiant quelques pages web via Firebug pour donner une idée des différents effets. J’ai aussi joué avec Flexplorer, et j’ai découvert display: inline-flex; à ce moment-là, en direct devant les collègues.

La conséquence immédiate de cette petite réunion, c’est qu’on est au moins trois à vouloir réécrire tout le CSS de nos sites. J’ai eu une journée un peu longue1, donc je ne vais pas forcément tout vous détailler, mais flexbox résout pas mal de problèmes de positionnement régulièrement rencontrés par les développeurs. En général on pouvait les résoudre avec des inline-block, des <table>, des float… Mais pas toujours. Certains problèmes insolubles, comme le centrage vertical, sont pliés dans la joie en deux ou trois lignes de CSS. La mise en page avec en-tête et pied de page « fixed mais pas vraiment » a rencontré un certain succès également. Je ne trouve plus le lien, par contre…

Au-delà du contenu technique que j’ai pu (re)découvrir aujourd’hui, je voulais en remettre une couche sur le principe de la réunion où un développeur partage son expérience avec ses collègues. En effet, c’est toujours intéressant de travailler un peu un sujet, même si on a l’impression que c’est à l’arrache, dans l’objectif d’expliquer et de convaincre. On ne retient pas aussi bien quand on se contente d’étudier « pour soi »…

Donc, instaurer une réunion fréquente (3 à 4 fois par mois) où un développeur explique aux autres un sujet technique de son choix, c’est une bonne idée. L’assistance découvre des choses, évidemment, mais l’orateur progresse indéniablement aussi. Ma boîte actuelle est la deuxième où on a droit à des réunions de ce genre. Copiez l’idée dans la vôtre ! Vite !

  1. On avait piscine. Il y avait du soleil et on a mangé des sushis. C’est dur, un peu, nos conditions de travail. #not ↩