Alsacreations.com - Apprendre - Archives (juin 2026)

Les dernières ressources publiées sur Alsacreations.com

Le: 25 06 2026 à 14:37 Auteur: Raphael

Pendant plus d'une décennie, concevoir une mise en page de type « Pinterest », où des éléments de hauteurs variables s'imbriquent parfaitement les uns sous les autres sans laisser d'espaces vides, relevait du parcours du combattant. Il fallait soit capituler et charger une bibliothèque JavaScript (la célèbre extension Masonry.js de David DeSandro), soit se résoudre à utiliser des astuces CSS bancales comme les colonnes CSS (columns) au prix d'un ordre de lecture totalement inversé.

Bonne nouvelle : après de longues années de débats passionnés au sein du CSS Working Group, les planètes se sont enfin alignées. La spécification CSS Grid Layout Module Level 3 introduit officiellement une solution native sous le nom de Grid Lanes. Finies les contorsions de code, place à une approche robuste, performante et accessible.

Qu'est-ce que c'est, et quels besoins ça résout ?

Le concept de Masonry (ou mise en page en cascade) consiste à disposer des éléments les uns après les autres au sein de colonnes prédéfinies, mais de façon asynchrone sur l'axe vertical. Contrairement à une grille traditionnelle où chaque ligne impose sa hauteur à l'ensemble de ses cellules, le mode Masonry s'affranchit des contraintes de rangées rigides.

Les objectifs majeurs résolus par l'arrivée native de display: grid-lanes sont multiples :

  • Performance accrue : Aucun calcul JavaScript lors du redimensionnement (resize) de la fenêtre ou du chargement des images.
  • Respect de l'ordre du DOM : Les éléments se positionnent de manière fluide en suivant une logique ordonnée, sans nécessiter de conteneurs de colonnes rigides (qui cassent la sémantique HTML).
  • Souplesse du responsive : La possibilité de combiner la puissance des fonctions Grid (comme repeat() et auto-fit) avec un comportement fluide à hauteur variable.

Comparatif entre Grid et Grid Lanes

La compatibilité actuelle

Le paysage des implémentations s'est enfin stabilisé après l'adoption d'une syntaxe unifiée, mais à ce jour le support navigateur est infime. Il est nécessaire d'actviter un flag afin de pouvoir tester cette fonctionnalité.

Activer le flag expérimental

Pour tester display: grid-lanes dès aujourd'hui, vous devez activer le flag correspondant dans votre navigateur :

  • Chrome / Edge : ouvrez chrome://flags (ou edge://flags), recherchez CSS Grid Lanes, puis activez le flag et redémarrez le navigateur.
  • Firefox : ouvrez about:config, recherchez layout.css.grid-lanes.enabled, passez la valeur à true.
  • Safari : allez dans Safari → Réglages → Avancé → Afficher le menu Développement, puis dans le menu Développement → Fonctionnalités expérimentales, cochez CSS Grid Lanes.

Une fois le flag activé, la valeur grid-lanes pour display sera reconnue par le navigateur.

Stratégie d'amélioration progressive

Pour exploiter cette fonctionnalité dès aujourd'hui tout en garantissant un affichage de secours propre (fallback), la directive @supports est notre meilleure alliée :

/* Fallback pour les anciens navigateurs (affichage en colonnes CSS) */
.galerie {
  columns: 3 200px;
  column-gap: 1rem;
}

/* Modernité avec Grid Lanes */
@supports (display: grid-lanes) {
  .galerie {
    display: grid-lanes;
    grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
    gap: 1rem;
  }
}

La mise en œuvre et exemple simple

L'implémentation est déconcertante de simplicité. Il suffit d'appliquer la valeur grid-lanes à la propriété display du conteneur parent, puis de définir l'axe structurel (le plus souvent les colonnes).

Le code HTML

<div class="masonry-container">
  <article class="card">Contenu court.</article>
  <article class="card">Contenu beaucoup plus long qui va s'étendre verticalement…</article>
  <article class="card">Contenu moyen.</article>
</div>

Le code CSS

.masonry-container {
  display: grid-lanes;
  /* Définition automatique des couloirs verticaux */
  grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
  gap: 1rem;
}

.card {
  background: #ffffff;
  border: 1px solid hotpink;
  padding: 1rem;
  border-radius: 8px;
}

Dans cet exemple, le navigateur va calculer la hauteur réelle de chaque .card et positionner automatiquement la carte suivante dans la colonne qui dispose actuellement de l'espace vide le plus proche du sommet.

Voir la démo interactive

Distribution verticale ou horizontale ?

Suivant l'axe que vous décidez de verrouiller, le comportement de Grid Lanes se décline en deux grandes variations visuelles.

Distribution verticale (waterfall)

C'est l'usage classique popularisé par Pinterest. On définit des colonnes rigides via grid-template-columns, et les éléments s'empilent librement du haut vers le bas dans l'axe vertical (le stacking axis est l'axe des blocs).

.container {
  display: grid-lanes;
  grid-template-columns: repeat(3, 1fr); /* Mode vertical (waterfall) */
}

Distribution horizontale (brick)

À l'inverse, si vous définissez des lignes fixes à l'aide de la propriété grid-template-rows, Grid Lanes bascule la distribution et les éléments se déploient horizontalement, de gauche à droite, en allant se loger dans la ligne la moins large, créant un alignement rappelant un mur de briques.

.container {
  display: grid-lanes;
  grid-template-rows: repeat(3, 1fr); /* Mode horizontal (brick) */
}

Orientation verticale ou horizontale de Grid Lanes

Le seuil de tolérance : flow-tolerance

L'algorithme de Grid Lanes cherche en permanence à combler le vide le plus haut possible. Cependant, une différence infime d'un seul pixel entre deux colonnes peut contraindre l'algorithme à propulser un élément dans une colonne inattendue, bouleversant l'ordre visuel global pour un détail technique invisible.

C'est là qu'intervient la propriété flow-tolerance. Elle permet d'indiquer au navigateur un seuil de tolérance (une marge d'erreur admissible). Si deux colonnes ont des hauteurs proches comprises dans cette fourchette, le navigateur considère qu'il y a "égalité" et choisit de respecter l'ordre naturel d'écriture du document plutôt que d'optimiser l'espace au pixel près.

.masonry-container {
  display: grid-lanes;
  grid-template-columns: repeat(3, 1fr);
  /* Si l'écart entre les couloirs est inférieur à 20px, on privilégie l'ordre logique source du HTML */
  flow-tolerance: 20px; 
}

Accessibilité et sens de lecture : reading-flow

C'était le talon d'Achille historique de Flexbox, Grid Layout et Masonry de manière générale : la déconnexion entre l'ordre visuel affiché à l'écran et l'ordre réel du code source HTML. Lorsqu'un utilisateur navigue au clavier (touche Tab) ou utilise un lecteur d'écran, le focus saute de manière chaotique d'une colonne à une autre en fonction de la façon dont l'algorithme a imbriqué les boîtes.

L'ordre visuel et l'ordre de lecture logique doivent concorder. Avec Grid Lanes, l'usage de reading-flow devient indispensable pour les conteneurs réordonnés.

.masonry-container {
  display: grid-lanes;
  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));

  /* Aligne l'ordre de navigation clavier et des revues d'écran 
    sur la disposition visuelle générée par la grille */
  reading-flow: grid-rows;
}

Grâce à reading-flow: grid-rows, la navigation séquentielle va suivre le rendu géométrique (de gauche à droite, ligne par ligne) offrant une expérience fluide et naturelle, balayant les anciens griefs liés aux interfaces asynchrones.

Conclusion

L'arrivée de display: grid-lanes marque une étape clé dans la maturité des modules de mise en page CSS. En combinant la rigueur d'un axe dimensionnel hérité de CSS Grid avec la flexibilité d'un empilement organique, cette évolution comble un manque historique sans sacrifier les impératifs d'accessibilité grâce au renfort de reading-flow et flow-tolerance.

À ce jour, cette fonctionnalité demeure expérientale. Elle est à tester sous couvert de flags navigateurs ou via l'amélioration progressive. Le CSS moderne continue de remplacer avantageusement les scripts lourds d'autrefois pour notre plus grand confort… et celui de nos utilisateurs !

Retrouvez l'intégralité de ce tutoriel en ligne sur Alsacreations.com

Le: 22 06 2026 à 11:00 Auteur: Raphael

RivieraDev 2026 se tiendra à Sophia-Antipolis (Skema Business School) du lundi 6 juillet au mercredi 8 juillet.

L'événement se présente comme "La conférence du Soleil dans la plus belle technopole d'Europe." ðŸ˜Ž

Durant trois jours intensifs de conférences, de sessions de Deep Dive et d'ateliers originaux, plus de 700 participants exploreront les dernières innovations technologiques et méthodologiques.

Côté Front-End, Raphaël d'Alsacréations montera sur scène pour présenter sa conférence : « Les aventures de CSS, saison 2026 », l'occasion idéale de décrypter les nouveautés et les coulisses du design web moderne.

L'équipe du staff RivieraDev

Les places sont toujours disponibles sur rivieradev.fr/subscribe.

👉 Programme complet sur rivieradev.fr/schedule.

Publié par Alsacreations.com

Le: 17 06 2026 à 14:37 Auteur: Raphael

Le paradigme du WYSIWYG (What You See Is What You Get) célèbre ses quarante ans de bons et loyaux services dans le design graphique et la mise en page. Face à lui, le modèle du document structuré et de la programmation régit le web (HTML/CSS) et l'édition scientifique. Longtemps opposées ou pensées séparément, ces deux philosophies connaissent aujourd'hui des hybridations passionnantes.

C’est tout l'enjeu du symposium « Quand le code rencontre l'interface : hybrider les outils du design graphique », qui se tiendra à Strasbourg et en retransmission directe les 25 et 26 juin 2026.

Au carrefour du design et du développement

Organisé conjointement par l'Université de Strasbourg (laboratoire ACCRA) et la HEAD de Genève, cet événement explore un territoire cher à la communauté Alsacréations : la zone d'intersection où les designers graphiques et les développeurs manipulent de concert le code, les interfaces visuelles et les structures de documents.

Le programme s'annonce particulièrement riche pour quiconque s'intéresse à l'évolution de nos outils de création :

  • Des tables rondes et panels thématiques autour du Web-to-print, de la libération des formats propriétaires (avec des sujets fascinants comme l'émancipation des fichiers InDesign) et de la conception de générateurs graphiques sur-mesure.
  • Une conférence de clôture (Keynote) exceptionnelle animée par Bert Bos (co-créateur de CSS) et César Fernández Acebal, intitulée « When Layout Meets the Web: The Long Road to CSS Grid ». Un retour aux sources indispensable pour comprendre comment la mise en page web s'est structurée.

Informations pratiques

  • Dates : Jeudi 25 juin (de 13h à 18h) et vendredi 26 juin 2026 (de 9h à 18h)
  • Lieu : Amphithéâtre de la MISHA (Maison Interuniversitaire des Sciences de l'Homme - Alsace), Université de Strasbourg.
  • Tarif : Entrée libre et gratuite.
  • En ligne : L'événement sera intégralement retransmis en direct.

👉 Toutes les informations, le programme détaillé ainsi que les liens de retransmission seront disponibles sur le site officiel : wysiwyg.ch/symposium-code-interface/.

Publié par Alsacreations.com

Le: 13 06 2026 à 13:00 Auteur: Rodolphe

Pour rappel <dialog> permet de créer des boîtes de dialogue (modales, popups, popins, elles ont tant de noms) en HTML sans plus avoir à tout gérer en CSS+JavaScript pour positionner un élément <div> en absolu.

Et on a aussi connu cela : une popin qui se ferme quand on appuie sur echap alors qu'on voulait forcer l'utilisateur à valider un formulaire, ou à l'inverse une modale qu'on ne peut fermer qu'avec un bouton alors qu'un clic en dehors serait tellement plus naturel. Jusqu'ici, la solution consistait à empiler du JavaScript pour gérer ça à la main.

Désormais, un simple attribut HTML suffit.

Mentionné par Una Kravets et Bramus Van Damme à la Google I/O 2026.

Comment ça marche ?

L'attribut closedby s'ajoute directement sur l'élément <dialog> et accepte trois valeurs :

  • any — le dialogue se ferme via la touche Échap, un geste natif (retour arrière sur mobile), ou un clic en dehors (correspond à ce qu'on appelle un light dismiss).
  • closerequest — fermeture via la touche Echap ou geste natif uniquement, pas de clic en dehors. C'est le comportement par défaut d'une modale ouverte avec showModal().
  • none — fermeture uniquement via code (bouton, soumission de formulaire…), aucune alternative native.

Exemples rapides :

<!-- On peut cliquer à côté pour fermer -->
<dialog closedby="any">
  <p>Aperçu rapide, fermable au moindre clic extérieur.</p>
  <button onclick="this.closest('dialog').close()">Fermer</button>
</dialog>
<!-- Aucune fermeture "accidentelle" possible -->
<dialog closedby="none">
  <p>Formulaire critique. On ne vous laisse pas esquiver comme ça.</p>
  <button onclick="this.closest('dialog').close()">Valider et fermer</button>
</dialog>

Et sans closedby ?

Si l'attribut est absent ou invalide, le navigateur applique un comportement automatique : - showModal() → se comporte comme closedby="closerequest" (Echap fonctionne). - show() ou attribut open → se comporte comme closedby="none" (rien ne ferme sans code).

Autrement dit, rien ne change pour vos éléments existants. Ouf la rétrocompatibilité.

Compatibilité navigateurs

À ce jour, le support atteint environ 70 % de couverture globale d'après Caniuse ce qui est encourageant mais insuffisant pour un usage en production sans y réfléchir.

Navigateur Support
Chrome / Edge ✅ depuis la version 134
Firefox ✅ depuis la version 141
Opera ✅ depuis la version 119
Safari (macOS & iOS) ❌ pas encore supporté

🐌 Safari reste en retrait... et tant que ce n'est pas supporté un fallback JavaScript pour le light dismiss peut faire l'affaire :

// Fallback pour les navigateurs sans closedby="any"
document.querySelectorAll('dialog[closedby="any"]').forEach((dialog) => {
  document.addEventListener('click', (e) => {
    if (dialog.open && !e.composedPath().includes(dialog)) {
      dialog.close();
    }
  });
});

Accessibilité

L'attribut closedby agit uniquement sur la fermeture, il ne modifie pas la sémantique de l'élément. Les bonnes pratiques habituelles restent donc :

  • closedby="any" : le clic en dehors ferme la boîte de dialogue, vérifiez que ce comportement est prévisible pour les utilisateurs de lecteurs d'écran. Un clic accidentel à côté d'un formulaire partiellement rempli peut surprendre. Réservez cette valeur aux interactions légères et non critiques (petites popups d'information ou de prévisualiation).
  • closedby="none" : si l'utilisateur ne peut pas fermer via la touche Échap ni en cliquant en dehors, il doit impérativement y avoir un bouton de fermeture, accessible au clavier et aux technologies d'assistance.
  • Gestion du focus : à l'ouverture, le focus doit aller dans la modale ; à la fermeture, il doit revenir sur l'élément déclencheur (qui a ouvert la modale, par exemple un bouton).
  • Libellé/titre : pensez à aria-labelledby (pointant vers le titre) et éventuellement aria-describedby pour les descriptions. L'élément <dialog> expose déjà le bon rôle ARIA, mais sans nom accessible les lecteurs d'écran annoncent une boîte de dialogue anonyme.

Publié par Alsacreations.com

Le: 06 06 2026 à 11:00 Auteur: Rodolphe

DevLille 2026 se tiendra au Lille Grand Palais. Anciennement connu sous le nom de DevFest Lille, cet événement s'est imposé comme un rendez-vous majeur de la tech dans le Nord de la France.

L'édition 2026 s'annonce dense : 1 500 participants attendus, 60 speakers, 44 conférences réparties sur 4 tracks en parallèle, le tout dans un espace de plus de 1 900 m².

Notre propre Raphaël sera de la partie ! Il interviendra le vendredi 12 juin avec sa conférence intitulée Les aventures de CSS, saison 2026, une session de 45 minutes à ne pas manquer pour les passionné·es de CSS.

Toutes les conférences sont sous-titrées en direct, et le lieu est entièrement accessible aux personnes à mobilité réduite. L'édition 2026 est également écoresponsable : repas préparés à partir de produits locaux, servis dans des contenants consignés, dans une démarche zéro déchet.

1500 participants, 60 speakers, 44 conférences, 4 tracks

Les places sont toujours sur billetweb.fr.

👉 Programme complet sur devlille.fr.

Publié par Alsacreations.com

Le: 02 06 2026 à 10:09 Auteur: Raphael

Le centrage vertical en CSS… C’est historiquement l’une des difficultés les plus célèbres du développement web, un sujet de plaisanterie classique qui fait sourire les développeurs back-end et désespérer les intégrateurs depuis l’époque de CSS2.

Pendant près de quinze ans, nous avons multiplié les détours techniques. Nous avons buté sur des vertical-align: middle capricieux réservés aux tableaux, ou des position: absolute combinés à des top: 50% et des transform: translateY(-50%) aussi magiques que fragiles.

Cette époque de savants calculs et de lignes de code superflues est désormais révolue depuis l'arrivée des modèles de positionnement Flexbox et Grid Layout.

Ceci dit, une petite révolution est passée quasi inaperçue, et pourtant elle simplifie tout : la propriété align-content fonctionne désormais dans le flux normal (Block layout). Plus besoin de déclarer un display: flex ou display: grid simplement pour aligner du contenu verticalement.

Le grand déblocage : align-content partout, pour tous

Jusqu’à récemment, align-content était une propriété exclusivement réservée aux modules Flexbox et Grid Layout. Elle permettait de distribuer l’espace entre les lignes ou d’aligner le contenu sur l’axe secondaire. Si vous tentiez de l’appliquer sur un simple bloc de texte (display: block), le navigateur l’ignorait superbement.

Grâce à une mise à jour majeure des spécifications CSS (CSS Box Alignment Module Level 3), align-content est désormais fonctionnel dans tous les modes d’affichage.

Un support universel et moderne

C’est une excellente nouvelle : ce comportement n’est pas une simple piste de réflexion, il est déjà pleinement supporté par tous les navigateurs modernes (Chrome, Firefox, Safari et Edge). Vous pouvez dès aujourd’hui l’utiliser en production pour simplifier considérablement vos intégrations.

Alors comment ça marche ?

Le principal avantage de cette évolution est l’économie de code et de structure HTML. Voyons cela à travers deux cas d’usage concrets.

1. Le centrage vertical parfait

Pour centrer un contenu verticalement dans un conteneur de hauteur fixe ou minimale, il suffit désormais de deux lignes de CSS sur le parent. Pas de Flexbox, pas de Grid, juste du bloc natif.

.hero-banner {
  display: block; /* Optionnel, c'est le comportement par défaut d'un div */
  min-height: 400px;

  /* La magie opère ici */
  align-content: center;
}

Ce qui change par rapport à Flexbox

Avec Flexbox, écrire align-items: center (ou align-content) nécessite impérativement un display: flex. Le problème, c’est que le passage en mode Flexbox modifie le comportement de tous les enfants directs (ils deviennent des flex items, se mettent en ligne par défaut, etc.). Avec align-content sur un bloc, les enfants restent des blocs normaux, conservent leurs marges et leur comportement natif dans le flux.

2. Aligner en bas de page

Vous souhaitez positionner un pied de carte ou un texte tout en bas d’un bloc sans avoir recours au positionnement absolu ? L’opération est tout aussi directe :

.card {
  min-height: 300px;
  align-content: end;
}

Vous pouvez bien sûr utiliser toutes les valeurs classiques de la propriété : start, end, center, space-between, space-around, space-evenly.

Tableau récapitulatif des valeurs courantes

Valeur Effet sur un bloc (display: block)
start / flex-start Aligne le contenu au début (haut) du conteneur.
center Centre le contenu verticalement.
end / flex-end Aligne le contenu à la fin (bas) du conteneur.
space-between Distribue l’espace résiduel entre les blocs enfants.

Et pour l'axe horizontal ? Le cas de justify-self

Si align-content règle magistralement la question de l'alignement vertical sur le parent, une autre propriété complémentaire pointe le bout de son nez pour l'axe horizontal : justify-self.

Appliquée cette fois directement sur un élément enfant au sein d'un bloc, elle a pour but de lui permettre de se positionner de manière autonome à gauche, à droite ou au centre de son parent (par exemple avec justify-self: center ou justify-self: end).

Pour le moment, le support actuel par les navigateurs reste encore trop partiel pour envisager une utilisation en production. Pour l'alignement horizontal d'un bloc individuel dans le flux normal, les bonnes vieilles marges automatiques (margin-inline: auto, etc.) ont donc encore de beaux jours devant elles.

Pourquoi ça change la vie ?

Au-delà du gain de temps, cette évolution CSS apporte une vraie rigueur sémantique et technique :

  • Lisibilité du code : Moins de conteneurs (div) superflus créés uniquement pour corriger des défauts d’alignement.
  • Performance cognitive : Le code est plus lisible. Quand on lit align-content: center, on comprend immédiatement l’intention, sans avoir à analyser si le display: flex associé ne risque pas de perturber le reste de la mise en page.
  • Respect du flux : On conserve la puissance et la prévisibilité du modèle de bloc traditionnel là où Flexbox ou Grid n’étaient finalement que des détours techniques pour un besoin simple.

Dix-quinze ans après les premiers débats enflammés sur les forums d’Alsacreations pour savoir s’il fallait utiliser les display: table-cell ou des hacks à base de lignes fantômes, le CSS moderne nous offre enfin l’outil ultime. Une seule propriété pour les gouverner toutes. Elle n’est pas belle, la vie d’intégrateur en 2026 ?

Publié par Alsacreations.com