Alsacreations.com - Apprendre - Archives (juin 2026)

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

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.

🐌 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

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.

Les places sont toujours sur billetweb.fr.

👉 Programme complet sur devlille.fr.

Publié par Alsacreations.com

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

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

Flux (rss): http://www.alsacreations.com/rss/apprendre.xml