Bastien Calou - Développeur front-end freelance

Cette page est 80 % moins lourde que la médiane des pages web

2025-01-17T00:00:00Z

C'est une constante depuis des lustres : le poids médian des pages web ne fait qu'augmenter. D'après le site HTTP Archive, cette augmentation se situe entre 5 et 10% par an et ne montre aucun signe de ralentissement.

Vers l'infini et au-delà !

On pourrait en explorer les causes et en déplorer les conséquences, mais ce n'est pas ce que je souhaite faire ici. Je veux simplement montrer tout ce que peut contenir une page web dont le poids serait 20% du poids médian actuel.

Le poids médian actuel sur desktop est 2 676 Ko. Notre objectif est donc 532 Ko. Moins de 10% des pages web sont aussi légères.

Que peut-on bien faire avec « si peu » de data ? Une pauvre page de connexion avec deux champs, peut-être ? Sans doute une page sans image, sans vidéo, sans interactivité, triste comme tout… Les autres pages ne sont pas si lourdes pour rien, si ?

Essayons voir.

Ce que contient cette page

Les bases : HTML / CSS / JS

Du texte, déjà. Vous êtes en train de le lire. C'est à la fois le plus important et l'une des ressources les plus légères. Ce texte est structuré au sein d'un document HTML, pour un total de 11 Ko (soit 2,1 % de notre budget).
Du style : le CSS qui met en forme tout ça et rend votre lecture un peu plus agréable. Il pèse 7 Ko (1,3 %).
Un fichier JavaScript, qui gère quelques interactions basiques et le formulaire de commentaire. Il fait gentiment ça pour le modeste poids de 3 Ko (0,6 %).

Fonts et médias

Une chouette font, « Euclid », pour les titres et sous-titres. Grâce au script glyphanger, qui permet de ne conserver que les caractères réellement utiles à ce blog, le fichier qui à l'origine pèse 44 Ko ne fait plus que 15 Ko (2,8 %).
Une photo de ma tête, qui communique avec élégance une forme de sympathie professionnelle rendant irrésistible l'envie de me contacter à de riches recruteurs. Elle pèse 4,5 Ko (0,8 %).
La capture d'écran du site HTTP Archive qui introduit l'article. Elle est affichée avec une largeur de 780px, mais si votre écran a une haute densité de pixels, le fichier servi est deux fois plus grand (1560px) pour le plaisir des yeux. Le format .avif, désormais très bien supporté, permet de limiter son poids à 22 Ko (4,1 %).
Un favicon, le petit truc bleu dans l'onglet du navigateur, là-haut. C'est important. Il représente 5 Ko (0,9 %).

Le nombre de requêtes compte aussi énormément dans la performance d'un site. Aujourd'hui, la médiane est de 76. Cette page en génère 31 (l'inclusion de CodePen déclenche une bonne moitié d'entre elles…)

Seulement 84 Ko ???

Ça ne va pas du tout. Ce post est déjà d'une longueur respectable, et pourtant, nous n'avons atteint que 84 Ko. 30 fois moins que la médiane. C'est intolérable.

Dois-je rappeler que l'objectif est 532 Ko ? Il va falloir se ressaisir. Ajoutons donc d'autres éléments à notre page.

Ci-dessous, voici un web component qui me permet de présenter les compatibilités de différentes fonctionnalités. Voici par exemple celle pour le format .avif évoqué précédemment.

Son inclusion et l'appel API associé représentent 24 Ko (4,5 %). On continue !

Une iframe CodePen ? Ce sera une des ressources les plus coûteuses de cette page avec un poids d'environ 85 Ko (6,3 %). Cela reste raisonnable compte tenu du service apporté.

Voir le code sur CodePen.

Une vidéo ? Puisqu'il le faut. 79 Ko (14,5 %).

Vidéo : un scroll vertical de la page, au fur et à mesure duquel les images sont chargées progressivement.

Un extrait de code ? En réalité, il ne rajoute que son poids en caractères. En effet, la coloration syntaxique est faite lors du pré-rendu côté serveur. Et les styles sont déjà dans l'unique fichier CSS inclus.

const images = await Image(`src/img/${fileSlug}.jpg`, {
  widths: [350, 700],
  formats: ["avif", "webp", "jpeg"],
  outputDir: "_site/img",
});

D'autres composants peuvent facilement être mobilisés « gratuitement », puisqu'il ne s'agit que du CSS déjà chargé. Allons-y, histoire de représenter l'ensemble des contenus présents sur le blog.

Une citation ?

Un poids de page élevé affecte disproportionnellement les personnes qui ne peuvent pas acheter des appareils haut de gamme et avoir accès à une connexion rapide et permettant une forte consommation de données.

Web Almanac 2024 (en anglais)

Un tableau ? Voici la répartition du poids des ressources sur une page web (les vidéos sont exclues car beaucoup de pages en sont dénuées).

Répartition du poids des ressources sur une page web (vidéos exclues)
Type de ressource	% du total
Images 🖼️	39,9 %
JavaScript ⚡	23,2 %
Fonts 🔤	5 %
CSS 💄	3 %
HTML ✍️	0,7 %

Source : Web Almanac 2024.

Ça devient lourd… mais pas assez

Me voilà rendu à seulement 272 Ko malgré tous mes efforts, et tous les types de contenus présents sur le blog sont déjà représentés. Je me demande si ce post était une bonne idée.

Pas le choix, on va jusqu'au bout : il va falloir remplir !

Une autre image ? Celle-ci rajoute 11 Ko (2,1%).

Un autre CodePen, peut-être ? Beaucoup des ressources nécessaires étant déjà chargées par la première iframe, il n'en coûtera que 18 Ko (3,6%).

Voir le code sur CodePen.

Note : mesurer le poids d'une page n'est pas une science exacte. Utiliser l'option « désactiver le cache » de l'inspecteur réseau peut être trompeur car certaines sources seront alors chargées (et comptabilisées) deux fois, comme CodePen sur cette page. Pour mes tests, j'utilise Firefox, sans extension. Dans les paramètres, j'efface les « fichiers et pages en cache temporaire ». Puis je charge la page avec l'onglet réseau ouvert, sans cocher « désactiver le cache ». Après l'avoir parcourue en entier, je relève son poids transféré.

On dira que ma vidéo était trop courte. En voici une autre ! Celle-ci est plus longue et est accompagnée de son. Là, ça devient sérieux : 224 Ko (42%). Mais n'oublions pas qu'une grande partie des sites ne contient pas de vidéo.

Vidéo : démonstration du jeu Blobby Zombie. Lorsqu'un ennemi est touché, la musique progresse en intensité.

Ça y est, nous y sommes parvenus… Cette page fait enfin 20% du poids médian actuel. Pas mal, non ?

Ce que ne contient pas cette page

Si cette page a un poids raisonnable, c'est parce que ce blog fait de son mieux pour éviter quelques « gouffres » de ressources, qui sont malheureusement communs sur bon nombre de sites :

iframe très gourmandes comme celle de Youtube ;
images mal optimisées ;
multiples typographies et variantes (ici, il n'y a qu'un seul fichier .woff2) ;
gros framework JavaScript des familles ;
vidéos longues et HD ;
scripts de tracking ;
widgets de réseaux sociaux ;
immense librairie d'icônes utilisée à 0,1 %…

Souvent, une seule de ces erreurs suffit à plomber le poids d'un projet entier. Mais tant que vous gardez un œil vigilant sur ce que mobilise votre page, je pense en avoir fait la démonstration : vous avez de la marge.

Idéaliste ? Pas sûr.

La légèreté n'est pas réservée aux simples blogs :

La page d'accueil de Wikipédia pèse 355 Ko, soit 14% de la médiane.
La page d'accueil de Maison Calme, que j'ai réalisé pour un studio de yoga, pèse 200 Ko. 8% de la médiane.
La page d'accueil de Low-tech Lab pèse 157 Ko. 6% de la médiane.
N'oublions pas le fameux Hacker News et ses 12 Ko. 0,5% de la médiane.

Les exemples sont nombreux. Malheureusement, le poids standard d'un site classique est aujourd'hui… comment être poli ? Embarrassant. La complexité intrinsèque du projet suffit rarement à justifier le manque flagrant d'optimisation des ressources et de choix de sobriété à leur sujet.

Le web est de plus en plus lourd, mais ce n'est pas une fatalité. Vous choisissez ce qui rentre dans votre page.

En attendant, vous pouvez faire grimper de quelques octets le poids de celle-ci en laissant un commentaire. Mais je ne pense pas que cela puisse rendre le titre de cet article mensonger : la médiane ne va-t-elle pas continuer à monter, elle aussi ?

Comment j'ai cassé la prod avec un innocent sélecteur CSS

2024-11-12T00:00:00Z

On passe toutes et tous par là, non ? Transformer une application en page blanche, en prod de préférence ? Non ? Ça viendra, je vous le souhaite. Ce sont de belles sensations grâce auxquelles on vit intensément l'instant présent.

Je vous raconte.

CSS est gentil

CSS a ceci de merveilleux qu'il « n'échoue pas ». Prenez ce sélecteur, par exemple :

form:has(textarea) {
  ...
}

Grâce à la pseudo-classe moderne :has, il cible les éléments form qui contiennent un élément textarea.

Aujourd'hui, :has est bien supporté par la plupart des navigateurs. Si un vieux navigateur tente d'interpréter ce sélecteur, il ne le comprendra pas et l'ignorera.

Ce mécanisme est essentiel à l'adoption rapide des nouvelles fonctionnalités CSS. À moins que les styles à appliquer ne soient absolument critiques, on peut admettre qu'une petite partie (en décroissance) des navigateurs n'en bénéficient pas. Tant que la page est lisible et utilisable, ce n'est généralement pas un problème.

Il en va de même pour HTML : une balise moderne telle que <search> sera interprétée comme une simple <div> sans signification par des navigateurs plus anciens. La sémantique peut être dégradée, et ce n'est pas anodin, mais c'est très différent que de risquer une page blanche...

Mon erreur : penser que `document.querySelector()` serait aussi sympa...

Tout change quand on entre dans le domaine de JavaScript. Chez lui, ça ne rigole pas, et il n'est pas question « d'échouer silencieusement ».

Le code suivant présente une faille potentielle :

const $form = document.querySelector("form:has(textarea)");

$form.addEventListener("submit", () => {...})

Si un élément correspond a sélecteur CSS fourni, $form contiendra un objet de type Element, sur lequel on pourra agir.

Mais si l'élément n'est pas trouvé, $form contiendra null. Et addEventListener sur null, ça fait boum. Et notre JS est joliment planté.

C'est simple à contourner : à moins d'avoir la certitude de la présence de l'élément, mieux vaut la vérifier avant de continuer, grâce à une condition :

const $form = document.querySelector("form:has(textarea)");

if ($form) { // C'est pas null, hein ?
  $form.addEventListener("submit", () => {...})
}

Ça, c'est la partie simple. Mon erreur, c'était de présumer du retour du sélecteur suivant. Lisez le bien :

const $form = document.querySelector("form:wow(textarea)");

Non, la pseudo-classe :wow n'existe pas, vous n'avez pas raté un chapitre de la folle histoire de CSS. Mais alors, que contiendra la variable $form ? Sera-t-elle null, de nouveau ?

Eh bien non : $form ne contiendra rien du tout. À la place, document.querySelector() va exploser en plein vol et nous jeter à la figure une erreur fatale :

Uncaught DOMException:
Document.querySelector: 'form:wow(textarea)' is not a valid selector

:wow n'existe pas, mais c'est aussi ce qui se passera sur un vieux navigateur qui ne comprend pas :has : il déclenchera une erreur.

Et cette erreur, si on la catche pas, elle va tout bonnement planter notre JS et tout ce qui va avec. Et si ce qui va avec, c'est une Single Page App générée en JS, le résultat sera une belle page blanche !

Et maintenant, cassons la prod

Conditionné que j'étais à penser que CSS ne me trahirait pas, j'ai passé un sélecteur contenant :has à la librairie React Joyride.

Le but de cette librairie est de générer un « parcours pas à pas » de bienvenue. Pour cela, il faut lui passer les sélecteurs qui lui permettront de cibler les éléments à mettre en valeur.

React Joyride en action.

Confiant dans l'usage de :has (qui m'évitait d'avoir à ajouter une classe conditionnelle à un élément), je pousse mon code. Le code passe la recette sans problème et atterit en production de ce site à quelques milliers de visites par jour 🙃

Quelques jours plus tard, surprise ! Quelques personnes semblent se plaindre d'atterir sur une page blanche... Leur point commun ? Utiliser une version de Safari dans laquelle :has n'était pas encore implémentée...

Je transpire un peu en réalisant mon erreur et pousse aussitôt un hotfix pour ne plus utiliser :has... Je comprends alors que la librairie est ma complice dans ce crime involontaire. Les erreurs de querySelector ne sont pas catchées.

Ou comment une fonctionnalité « annexe » de la plateforme devient soudain capable d'en crasher l'intégralité.

Un ticket Github et quelques temps plus tard, l'affaire est résolue dans le code source de la librairie. Je peux de nouveau utiliser des sélecteurs modernes tels que :has sans risquer l'intégrité de la page.

Schématiquement, si l'on revient à mon exemple de base, c'est aussi simple que ça :

try {
  const $form = document.querySelector("form:has(textarea)");

  if ($form) {
    $form.addEventListener("submit", () => {...})
  }
} catch (error) {
  console.error(error);
}

Morale de l'histoire

Deux erreurs ont été commises dans cette affaire :

de la part de la librairie, qui ne catchait pas les erreurs (quand ce genre de choses vous arrive, faites un ticket ! à défaut de contribuer directement, vous aiderez les autrices et auteurs) ;
de ma part : j'étais tellement convaincu de la résilience de CSS que j'ai oublié que je sortais du cadre strict de CSS et que je me trouvais en réalité en territoire JavaScript.

À l'avenir, une précaution simple : tester avec un sélecteur « impossible » tel que :uhoh pour m'assurer de la bonne prise en charge des cas invalides...

Cet article aurait pu être une simple phrase (mais où serait le plaisir ?) : CSS échoue silencieusement. document.querySelector(), non !

Ciao, X !

2024-10-22T00:00:00Z

Comme bien d'autres avant moi, je supprime mon compte Twitter / X (et succombe à la tentation d'en faire un post, désolé !).

Professionnellement, ce n'est pas anodin. Une dizaine d'années de partage de veille quotidienne, des milliers de tweets... X ne me donne pas directement du travail, mais il est fort possible que la façade que mon profil constitue y contribue un tout petit peu.

Moralement, c'est une évidence. Bien sûr, chacune et chacun choisira où mettre la limite de l'acceptable. En ce qui me concerne, elle est allègrement franchie : Elon Musk semble déterminé à faire de ce monde un endroit chaque jour un peu plus délétère. Faut-il attendre de savoir si tous ses efforts pour ramener Donald Trump à la Maison-Blanche vont payer pour décider de partir ?

Mentalement, c'est une nécessité. On ne se bat pas contre un algorithme conçu pour vous rendre accro. Peu importe les stratégies testées au fil des années, mon flux X est, loin de son objectif de veille technique, gangréné par des contenus violents, racistes ou débilitants, qui semblent dépeindre une société à feu et à sang. Une sorte de fin du monde en scroll vertical infini.

Alors, pour paraphraser : on se déconnecte et on se casse.

La suite, ça se passe où ?

Depuis presque deux ans, je partage ma veille sur mon profil Mastodon. Je ne vous en fait pas la pub, mais si ce post convainc ne serait-ce qu'une personne de m'y rejoindre, il n'aura pas été en vain.

Je relèverai un seul point : avec pourtant quatre fois moins d'abonnés sur Mastodon que sur X, j'y ai beaucoup, beaucoup plus d'interactions ! Face à X, qui ressemble de plus en plus à une foire d'empoigne remplie de vide, Mastodon est incroyablement rafraichissant.

Enfin, il y a ce bon vieux flux RSS. Personnellement, c'est grâce aux flux RSS de quelques dizaines de blogs ou sites spécialisés que je fais le principal de ma veille. Qu'est ce que c'est bien, de lire des contenus intelligents sur une plateforme qui n'est faite que pour ça... Comme lecteur, je recommande volontiers Feedly, à défaut d'en avoir testé d'autres.

Cette parenthèse Twitteresque de 13 années étant fermée, je vous dis à bientôt pour de nouveaux articles. Des vrais, cette fois-ci ;)

De l'aléatoire en CSS, c'est possible ! Enfin, presque...

2024-10-14T00:00:00Z

Pour la sortie de ce nouveau blog, il me fallait mettre en place un effet visuel renversant, qui impressionnerait la galerie et montrerait toute l'étendue de mes capacités.

Comme je n'avais pas le temps de faire cela, j'ai codé un effet rigolo de survol : lorsque la souris est passée sur ma photo, deux émojis parmi une centaine soigneusement sélectionnés apparaissent aléatoirement.

Vidéo : la souris survole ma photo. À chaque survol, deux émojis aléatoires recouvrent mes yeux.

Du grand art, je vous dis.

Cela a soulevé une question intéressante : quelle serait la meilleure méthode pour sélectionner l'émoji aléatoirement ? CSS suffirait-t-il ?

CSS : la roulette invisible

La roulette invisible, c'est le petit nom que je donne à cette technique que je n'ai pas inventée, mais qui est intéressante. Je vous explique.

Tout commence avec un pseudo-élément vide.

div::before {
  content: '';
}

Appliquons à ce pseudo-élément une animation emojis. Son but ? Changer le contenu de la propriété content pour y injecter nos émojis. Pour l'instant, trois suffiront.

div::before {
  content: '';
  animation: emojis 1s linear infinite;
}

@keyframes emojis {
  0% {
    content: "💥" / "";
  }

  50% {
    content: "🐸" / "";
  }

  100% {
    content: "🎉" / "";
  }
}

La syntaxe content: "🎉" / "" permet de définir, dans la seconde string, le texte alternatif pour ce pseudo-élément, qui pourra être lu par les technologies d'assistance. Quand on utilise un pseudo-élément à des fins décoratives, il est donc recommandé d'utiliser une chaîne vide pour éviter que le contenu de l'émoji ne soit interprété, par exemple par un lecteur d'écran.

Et voici le résultat :

Voir le code sur CodePen.

Maintenant, la même chose, mais avec 100 émojis ! Bon, on s'amuse bien mais on va utiliser une boucle SASS, on a pas que ça à faire...

$emojis: "💥", "💋", "🫀", "👓", "🐸", "👑", "🐰", "🐼", "👋", "🐤", "🐱", "🦊", "🐷", "🙈", "🐝", "🐌", "🐞", "🐠", "🐢", "🐫", "🦔", "🦚", "🌹", "🌼", "⭐️", "🔥", "👀", "🌈", "💧", "🍉", "🍓", "🍑", "🥝", "🍆", "🥦", "🥨", "🧀", "🍔", "🍕", "🍙", "🎂", "🍭", "🍿", "🍩", "🍺", "🍹", "🏀", "🥋", "🏆", "🎟", "🎭", "🎨", "🎬", "🎹", "🥁", "🎷", "🎸", "🪗", "🎲", "🎯", "🎰", "🎳", "🚨", "🚇", "🚀", "🛸", "🛟", "🗺", "⛱", "🌋", "💻", "🖨", "💾", "🕹", "💿", "📼", "📸", "📽", "📠", "📺", "🧭", "⏰", "⏳", "💡", "💵", "💰", "💎", "🔮", "🧬", "🧻", "🎁", "🎈", "🎉", "🪩", "📫", "📚", "🔎", "🩵", "💯", "🔔", "👁‍🗨";

@keyframes emojis {
  @for $i from 1 through list.length($emojis) {
    #{($i - 1) * (100% / (list.length($emojis) - 1))} {
      content: list.nth($emojis, $i) / "";
    }
  }
}

Et quand 100 émojis défilent en quelques secondes seulement, eh bien ça donne ça :

Voir le code sur CodePen.

Le plus dur est fait. L'astuce réside dans le fait d'arrêter cette roulette infernale au survol.

div:hover::before {
  animation-play-state: paused;
}

L'élément concerné sur le site étant un lien, je peux aussi appliquer l'effet lorsque ce dernier obtient le focus. Une personne naviguant au clavier « profitera » ainsi de l'effet.

Survolez l'élément : l'animation est arrêtée net, et un emoji est ainsi « sélectionné ».

Voir le code sur CodePen.

Vous l'aurez compris, l'aléatoire ici réside dans l'action de survol elle-même, et plus précisément dans son timing.

La touche finale, c'est bien sûr de cacher le pseudo-élément jusqu'à ce que le survol ait lieu :

div::before {
  opacity: 0;
}

div:hover::before {
  opacity: 1;
  animation-play-state: paused;
}

Notre roulette invisible est prête !

Voir le code sur CodePen.

En appliquant les mêmes règles au pseudo-élément after et quelques tests de positionnement plus tard, le résultat est là.

Invisible... et pourtant, elle tourne

Même si je trouve cette technique intéressante à partager, j'étais un peu gêné une fois la mise en place effectuée.

C'est qu'il y a quelque chose d'un peu contre-nature à changer de très nombreuses fois par seconde un contenu qu'on ne voit pas, non ?

Faisons une analyse de performance de la page, sur une minute, pour bien voir.

Chaque barre verticale est une opération sollicitant la carte graphique.

Le navigateur est au repos 99% du temps. Pas la fin du monde, donc. Mais ces milliers de petites barres vertes, ce sont des milliers d'opérations parfaitement inutiles, exécutées en permanence. Sur le principe, ça me gêne !

C'est un peu l'équivalent de préparer une pizza, de la jeter directement à la poubelle puis d'en préparer une autre, et ainsi de suite jusqu'à ce qu'un client ait enfin envie d'en profiter.

Alors, pour alléger un peu cette technique de gros bourrin, il y a une piste. Au lieu d'animer la propriété content, nous pouvons animer le contenu d'une variable CSS --emoji, et nous en servir pour générer le content uniquement lorsque l'élément est survolé.

div:hover::before {
  opacity: 1;
  animation-play-state: paused;
  content: var(--emoji);
}

@keyframes emojis {
  @for $i from 1 through list.length($emojis) {
    #{($i - 1) * (100% / (list.length($emojis) - 1))} {
      --emoji: "#{list.nth($emojis, $i)}" / "";
    }
  }
}

Résultat ?

La carte graphique est beaucoup moins sollicitée, mais il y a toujours énormément d'opérations.

Côté performance, c'est maintenant à 99,6% du temps que le navigateur est au repos. Beaucoup mieux !

Mais, fondamentalement, cela revient au même : le navigateur doit suivre l'état de cette variable en permanence, provoquant des milliers d'opérations superflues. J'aimerais savoir s'il est possible d'obtenir une version « propre » de cette approche. Mais j'en doute.

La solution raisonnable

Mon cerveau est câblé depuis longtemps pour commencer par envisager une solution purement CSS à ce genre de problème. Même quand ça ne marche pas, je découvre toujours quelque chose.

Mais ici, c'est bien JavaScript qui nous apporte une solution simple et performante. Le code est sans grande surprise, en voici la partie principale :

const emojis = ["💥", "💋", "🫀", "👓", "🐸", "👑", "🐰", "🐼", ...];

function setRandomEmoji() {
  $target.style.setProperty(
    "--emoji",
    `"${emojis[Math.floor(Math.random() * emojis.length)]}" / ""`
  );
}

$target.addEventListener("mouseenter", setRandomEmoji);

Plus d'opérations inutiles !

Certes, CSS reste à privilégier lorsque c'est possible. Mais il ne faut surtout pas rester bloqué sur un langage ou un autre lorsqu'il devient évident qu'une meilleure solution est à chercher ailleurs.

CSS n'a pas dit son dernier mot

Et Houdini, alors ? Cette API native permet de définir, en JavaScript, des algorithmes de rendus invoquables par la suite en CSS.

Et effectivement, dans ce contexte-ci, l'aléatoire est possible !

Voici la définition d'une règle circle, qui va générer aléatoirement un cercle rouge ou vert.

registerPaint('circle', class {
  paint(ctx, geom) {
    const x = geom.width / 2;
    const y = geom.height / 2;
    const radius = Math.min(x, y);

    ctx.fillStyle = Math.random() > 0.5 ? "red" : "green";

    ctx.beginPath();
    ctx.arc(x, y, radius, 0, 2 * Math.PI);
    ctx.fill();
  }
});

On l'utilise ainsi :

div:hover {
  background: paint(circle);
}

Sympathique, car on laisse le navigateur s'occuper de la logique de survol, et les possibilités ouvertes par Houdini sont bien plus vastes que mon simple exemple.

Malheureusement, ni Firefox ni Safari ne supportent cette API à l'heure actuelle. Si vous êtes sur un navigateur compatible, vous pourrez voir le résultat en survolant le composant ci-dessous :

Voir le code sur CodePen.

Cela doit faire 5 ans que j'ai entendu parler d'Houdini, mais j'ai l'impression que le projet peine à se concrétiser pleinement. En tout cas, il semble avancer lentement. Il faut dire qu'un travail énorme a été effectué ces dernières années sur des aspects bien plus fondamentaux de CSS !

Pour ma petite animation, le support limité d'Houdini passe encore : c'est une fonctionnalité « bonus » dont personne ne souffrira de l'absence.

Bien plus embêtant, impossible de trouver comment rendre du texte, et encore moins un émoji. On dirait bien que cela est impossible...

`random-item()` en CSS : c'est prévu !

Les choses sont bien faites. Alors que je réfléchissais à cet article, je suis tombé sur cet article d'Alvaro Montoro, qui détaille les nouveautés à venir concernant les valeurs et les fonctions en CSS (le niveau 5 du module Values and Units).

Et vous l'avez compris : parmi tout un tas de fonctionnalités très prometteuses se trouve la tant fantasmée fonction random-item().

Voici à quoi pourrait ressembler mon code mis à jour :

div:hover:before {
  content: random-item(--x, "💥", "💋", "🫀", "👓", "🐸", "👑",...);
}

Si j'ai bien compris, le --x servira à « identifier » le générateur. Tous les appels à random-item() possédant le même identifiant et la même liste génèreront la même valeur sur la page.

Plus simplement, la fonction random() permettra d'obtenir une valeur aléatoire entre deux bornes :

div {
  width: random(0vw, 100vw);
}

Encore une très bonne nouvelle pour CSS, donc.

Quand cela sera-t-il disponible ? Pour nous autres mortels, cela aussi relève du domaine de l'aléatoire...

Cet article lance ce nouveau site !

Et vous pourrez suivre ses futures publications principalement via ce bon vieux flux RSS ou mon compte Mastodon.

« Toxic Data » : la menace de l'intermédiation algorithmique

2023-09-26T00:00:00Z

Je sors de la lecture de Toxic Data, ouvrage passionant de David Chavalarias, chercheur au CNRS, sur le rôle toxique que joue une grande partie des réseaux sociaux sur nos sociétés.

On aime ce jaune bien agressif.

Il met en mots simples un sentiment de malaise que nous sommes, j'en suis sûr, un grand nombre à partager. Pour ma part, ce sentiment est un moteur depuis quelques années pour adopter une attitude de grande méfiance à l'égard des réseaux en question, et en particulier à l'égard de ceux dont les contenus présentés sont régis par un algorithme opaque cherchant à maximiser les interactions sur la plateforme (c'est à dire beaucoup d'entre-eux).

J'ai le sentiment que ma participation active aux réseaux dans le passé (toujours existante, mais moindre), ainsi que celle d'une grande partie de la société, ont sérieusement altéré la relation que j'entretiens avec mon entourage, notamment dans la façon dont les débats ont tendance à être, sans exception, hautement inflammables.

Mais David Chavalarias le dit mieux que moi :

À l'ère numérique, les sujets de discussion sont susceptibles de se polariser autour de points de vue toxiques à l'échelle d'une société entière. Pouvons-nous au moins espérer que la cohésion sociale, même affaiblie, ne sera pas rompue, et que deux camps qui s'opposent sur un thème trouveront toujours un terrain d'entente sur un autre ? [...] Que deux voisins en désaccord sur la vaccination continueront à échanger sur des questions politiques, que deux amis en désaccord sur des questions politiques continueront à discuter sur les questions environnementales ? Nous avons l'habitude de vivre à l'intersection de plusieurs cercles relationnels qui reflètent la diversité de nos centres d'intérêt et de nos rôles sociaux. [...] Nous nous appuyons activement sur le contexte pour filtrer l'information à laquelle nous accordons de l'importance et pour choisir quel type d'information échanger. Nous n'abordons pas partout, ni n'importe comment, des thèmes tels que l'alimentation, l'éducation, le sport, la contraception ou l'immigration. [...] Bref, nous sommes capables d'orienter notre attention et d'adapter notre comportement en fonction du contexte social. [...] Les algorithmes ne font pas la distinction entre vos différents cercles relationnels et traitent indifférement vos sujets de préoccupation. [...] Facebook peut très bien vous bombarder de messages que l'une de vos connaissances a appréciés alors même que vous n'abordez jamais ce type de sujets avec elle. Ce bombardement intempestif vous amènera peut-être à adopter un point de vue auquel vous ne vous seriez pas exposé naturellement ou, au contraire, à rompre un lien social par overdose de contenus dissonants, alors que vous auriez très bien pu continuer à sympathiser sur d'autres sujets avec cette personne. [Il en résulte que] la structure de vos cercles sociaux est brouillée. [...] Vous êtes privé(e) des filtres contextuels que vous appliquiez dans vos interactions quotidiennes.

David Chavalarias, Toxic Data

Les effets vont bien au-delà de l'impact sur les personnes elles-mêmes :

Plus un réseau social se densifie avec l'ajout de liens, plus le nombre moyen d'intermédiaires entre deux personnes se réduit. Or les contenus négatifs ont tendance à se propager, de proche en proche, plus facilement que d'autres types de contenus. Dès lors qu'un certain seuil de densification est atteint, ces contenus négatifs sont donc les premiers à pouvoir toucher une très large fraction du réseau, même s'ils sont produits par un très petit nombre de personnes. Dernier effet potentiel à signaler : comme les mécanismes d'influence sociale ne respectent plus les frontières de vos cercles relationnels sur les réseaux sociaux numériques, les valeurs, les croyances et les comportements risquent de s'y aligner en passant d'un cercle relationnel à l'autre. Ce phénomène favoriserait ainsi une polarisation globale de la société, sur plusieurs dimensions à la fois (par exemple, aux États-Unis, en général, les antivax sont aussi climatosceptiques et républicains). Bien que cet effet n'ait pas encore été documenté, il pourrait expliquer la polarisation importante de nos sociétés actuelles et la formation concomitante de plusieurs lignes de fracture.

David Chavalarias, Toxic Data

Et l'auteur de lister toutes les applications qui structurent nos vies aujourd'hui, qu'elles soient professionnelles, relationnelles (jusqu'aux relations les plus intimes), relatives aux voyages, à la consommation d'images et de vidéos... C'est ce que l'auteur appelle l'intermédiation algorithmique.

La liste est longue, et un seul ouvrage ne suffirait pas à examiner l'ensemble des configurations sociales au sein desquelles le numérique s'est immiscé, les choix algorithmiques qui ont été faits et leurs conséquences sociales. Il y a néamoins un point commun à toutes ces plateformes : elles se mettent en tête de gérer une partie de nos relations à autrui. [...] En se posant en intermédiaires dans le flux des échanges sociaux et en modelant la perception que nous avons de notre monde social, les réseaux sociaux numériques se sont arrogé le pouvoir de modeler à leur avantage les piliers de la cohésion sociale.

David Chavalarias, Toxic Data

Connaît-on vraiment CSS lorsqu'on utilise un framework CSS ?

2022-12-09T00:00:00Z

Le sondage State of CSS de l'année 2022 propose un excellent outil appelé le Data Explorer.

Par exemple, voici un tableau croisant l'usage des propriétés scroll-snap avec l'usage de Bootstrap.

Cela peut sembler un peu compliqué, mais je vais clarifier dans quelques instants. Nous avons toutes et tous des idées préconçues sur CSS :

Si tu utilises Tailwind, c'est parce que tu ne veux pas apprendre CSS...

Mais Tailwind a résolu CSS, c'est LA bonne façon !

Comme toujours, la réalité est plus complexe, et j'ai trouvé que cet outil était une bonne opportunité pour explorer les relations entre les frameworks CSS et le CSS natif.

Peut-être pouvons nous commencer par nous mettre d'accord sur deux points :

Il n'est pas nécessaire de connaître chaque propriété CSS pour écrire un CSS de qualité. Ce qui compte est de construire un bon modèle mental du fonctionnement de CSS.
En même temps, il est utile de connaître une bonne quantité de propriétés CSS pour pouvoir s'en servir lorsque cela est nécessaire, comme une boîte à outils.

En espérant que cela ne soit pas controversé. C'est parti !

Bootstrap, la méthodologie

Bootsrap a déjà été utilisé par 81% des devs ayant répondu à ce sondage. Historiquement, c'est le framework CSS.

Définissons quelques catégories :

Relation des devs à Bootstrap
	Opinion	Nom de code
51,7 %	Ont utilisé, mais ne l'utiliseront plus	Les exs
29 %	Ont utilisé et utiliseront de nouveau	Les fans
16,3 %	Connaissent mais ne souhaitent pas essayer	Les « non merci »
2,7 %	Connaissent et souhaitent essayer	Les « pourquoi pas »
0,5 %	Ne connaissent pas	Les késako

Qui selon vous aura la meilleure connaissance du CSS natif ?

Regardons donc ce que le Data Explorer peut nous apprendre, avec l'exemple des propriétés scroll-snap. Voici un zoom sur une cellule spécifique :

Voici comment lire cette cellule : dans l'ensemble, 34% des devs a répondu avoir déjà utilisé les propriétés scroll-snap. Cependant, si l'on regarde uniquement les fans de Bootstrap, seulement 26% utilisent scroll-snap, soit 8 points de moins.

Voici donc ce que j'ai entrepris : dans un horrible document, j'ai répertorié ces variations pour les 54 propriétés CSS présentées et pour nos 5 profils.

Bootstrap, les résultats

Et voici nos 5 profils, du moins familier avec le CSS natif au plus familier :

Variation de connaissance du CSS natif en fonction de l'usage de Bootstrap
	Variation de connaissance du CSS natif
Les késako	🔴 -11 points
Les « pourquoi pas »	🔴 -9 points
Les fans	🟠 -2 points
Les « non merci »	Pas de variation
Les exs	🟢 +2 points

Les késako

Le profil késako (qui ne sait pas ce qu'est Bootstrap) est corrélé avec une plus faible connaissance du CSS natif : 🔴 -11 points.

Théorie personnelle : Bootstrap est tant utilisé que si vous ne le connaissez pas (seulement 0,5% des réponses), vous êtes probablement en train de découvrir CSS. Il est donc logique que vous ayez encore une connaissance du CSS lacunaire.

Note : Merci de garder à l'esprit que les théories personnelles sont des théories... et qu'elles sont personnelles.

Les « pourquoi pas »

Le profil « pourquoi pas » (qui est intéressé par la découverte de l'outil) est également corrélé avec une plus faible connaissance du CSS natif : 🔴 -9 points.

Théorie personnelle : ces profils pourraient également être ceux de personnes débutantes n'ayant pas encore eu le temps de tester Bootstrap. Elles souhaiteraient l'essayer car c'est un outil très utilisé et qu'il est encore trop tôt pour elles pour décider ou non de s'en passer.

Les fans

Le profil des fans (qui ont utilisé Bootstrap et l'utiliseraient de nouveau) obtiennent un bien meilleur résultat, mais toujours 🟠 -2 points en-dessous de la moyenne.

Théorie personnelle : ces personnes ont bien plus de connaissances que les késako et les « pourquoi pas » car elles ont peut être codé avec Bootstrap (entre autres outils) depuis des années et accumulé des savoirs en cours de route. Cela étant dit, l'usage de Bootstrap ne facilite pas la découverte de nouvelles fonctionnalités CSS, ou Bootstrap est suffisant pour ce qu'elles font et elles ne se préocuppent pas tant que ça des nouveautés (ou n'en ont pas le temps !)

Les « non merci »

Les « non merci » (qui connaissent Bootstrap mais ne souhaitent pas l'utiliser) obtiennent un résultat dans la moyenne.

Théorie personnelle : décider qu'un outil n'est pas pour vous requiert une compréhension suffisante des challenges posés par CSS. D'autres outils pourraient également récupérer l'attention de ces profils, mais cela ne semble pas gêner la découverte de fonctionnalités CSS natives pour autant.

Les exs

Les exs (qui ont utilisé Bootstrap mais ne souhaitent plus l'utiliser) font mieux que la moyenne : 🟢 +2 points.

Théorie personnelle : apprendre à maîtriser un framework puis décider d'en arrêter l'utilisation est un processus long, ces personnes ont donc une expérience substantielle. Elles ont abandonné Bootstrap car leur approche du CSS a évolué (et CSS aussi, permettant ce départ pour certaines personnes). Elles ont peut être même été témointes de la longue transformation de CSS au cours des années. Elles ont décidé que Bootstrap n'était plus pour elles et d'utiliser le CSS natif davantage. Par ailleurs, on ne choisit pas toujours ses outils : elles ont peut être été contraintes d'utiliser Boostrap pour un employeur ou un client, tout en investissant dans le CSS natif en parallèle.

Voici les détails groupés par catégories :

Le plus grand écart (-8 points) entre les exs et les fans se situe au niveau des fonctionnalités d'interaction (scroll-snap, interactions tactiles, overscroll-behavior...).

Je pense qu'il faut aussi noter que les catégorie des fans est correlée avec une moins bonne connaissance des fonctionnalités liées à l'accessibilité (-5 points par rapport aux exs).

Tailwind, la méthodologie

Parlons maintenant du nouveau roi de la récré.

D'abord, nos 5 profils :

Relation des devs à Tailwind
	Opinion	Nom de code
36,4 %	Ont utilisé et utiliseront de nouveau	Les fans
25 %	Connaissent mais ne souhaitent pas essayer	Les « non merci »
25 %	Connaissent et souhaitent essayer	Les « pourquoi pas »
9,8 %	Ont utilisé, mais ne l'utiliseront plus	Les exs
4,1 %	Ne connaissent pas	Les késako

D'après-vous, qui aura le meilleur score cette fois-ci ?

Tailwind, les résultats

L'ordre a changé ! En effet, les fans obtiennent maintenant un meilleur résultat que les « pourquoi pas ».

Et les résultats eux-même ont aussi fortement changé.

Variation de connaissance du CSS natif en fonction de l'usage de Tailwind
	Variation de connaissance du CSS natif
Les késako	🔴 -9 points
Les « pourquoi pas »	🔴 -5 points
Les « non merci »	🟢 +1 point
Les fans	🟢 +2 points
Les exs	🔥 +6 points

Les késako

Le profil késako (qui ne sait pas ce qu'est Tailwind) est correlé avec une faible connaissance du CSS natif : 🔴 -9 points.

Théorie personnelle : comme pour les personnes qui ne connaissent pas Bootstrap. Si vous ne connaissez pas Tailwind, vous êtes possiblement en train de découvrir l'écosystème CSS. Mais vous pourriez aussi avoir des années d'expérience et ne pas être au courant des dernières actualités CSS, ce qui pourrait expliquer pourquoi ce profil n'est « que » 9 points en dessous de la moyenne (tandis que pour Bootstrap, c'était 11).

Les « pourquoi pas »

Le profil « pourquoi pas » (qui aimerait découvrir Tailwind) est correlé avec une baisse de 🔴 -5 points par rapport à la moyenne.

Théorie personnelle : c'est une baisse moins importante que pour Bootstrap (-9 points), mais la logique pourrait être la même. Si vous n'avez pas utilisé cet outil très répandu ou que vous n'avez pas encore le recul nécessaire pour décider de vous en passer, vous êtes peut-être en phase de découverte de CSS, il est donc logique que vous ne connaissiez pas le CSS natif parfaitement non plus. C'est tout de même un meilleur score qu'avec Bootstrap. Si vous avez entendu parler de Tailwind, cela signifie que vous vous intéressez aux évolutions récentes de CSS, tandis que vous pourriez avoir entendu parler de Bootstrap il y a longtemps de cela.

Les « non merci »

Le profil « non merci » (qui a entendu parler de Tailwind mais n'est pas intéressé) dépasse legèrement la moyenne : 🟢 +1 point.

Théorie personnelle : comme pour Bootstrap. Ces personnes ont assez d'expérience pour juger qu'un outil leur correspond ou non. Cette expérience s'accompagne d'une bonne connaissance du CSS natif, juste au dessus de la moyenne. Mais...

Les fans

Les fans (qui ont utilisé Tailwind et l'utiliseront de nouveau) sont dans une position très différente. Avec Bootstrap, ces personnes connaissaient moins de CSS natif (-2 points), mais avec Tailwind, elles en connaissent plus : 🟢 +2 points ! Encore mieux que les « non merci ».

Théorie personnelle : contrairement à ce que l'on lit parfois, aimer Tailwind n'est pas corrélé avec une moindre connaissance du CSS natif. Tout d'abord, rappelons-nous qu'avec ses classes utilitaires, Tailwind utilise une approche plus proche du CSS natif que Bootstrap. Les devs Tailwind connaissent par exemple les concept tels que flex, là où les devs Bootstrap utiliseraient une classe column (qui utilise en réalité flexbox en coulisse et n'a rien à voir avec les vraies colonnes CSS...) Enfin, il y a le fait que Tailwind soit un outil récent. Si vous lisez des articles sur Tailwind, il est presque impossible que vous ne lisiez pas aussi des articles sur les améliorations natives de CSS. Tailwind fait partie de l'écosystème moderne. Ceci étant dit...

Les exs

Le profil des exs (ayant utilisé Tailwind mais ne souhaitant plus l'utiliser) fait bien mieux que la moyenne : 🔥 +6 points.

Théorie personnelle : bien que les devs utilisant Tailwind fassent partie de l'écosystème moderne et connaissent leur CSS, les devs ayant tourné leur dos à Tailwind semblent en savoir plus. Premièrement, Tailwind ne résoud pas et ne couvre pas tout (ni ne prétend le faire). Certains fonctionnalités modernes, comme :has, les container queries, les cascade layers, les @supports queries... nécessitent de les connaître nativement pour les utiliser à leur plein potentiel. Cela ne signifie pas que les fans de Tailwind ne les connaissent pas et ne peuvent pas utiliser les deux, mais les personnes déçues par l'approche de Tailwind semblent simplement investir plus de temps dans la compréhension du CSS natif. Cela n'en fait pas de meilleures personnes, mais leur boîte à outil semble un peu plus étendue.

Voici le détail des résultats par catégories de fonctionnalités :

Ici, le plus gros écart entre les exs et les fans (-8 points) concerne la catégorie des sélecteurs, qui contient ::marker, :has et :where. Les fans de Tailwind ne les utilisent pas beaucoup.

Encore une fois, il y a un gros écart au rayon accessibilité : si les personnes utilisant Tailwind font mieux que la moyenne (+2 points), les exs font bien mieux avec +9 points.

Conclusion

J'espère que cette petite expérience était intéressante. Ce n'est pas une publication scientifique revue par les pairs, alors prenez-là avec du recul, mais j'ai fait de mon mieux avec ce que j'avais. N'oublions pas le biais d'échantillonnage : les personnes répondant à un sondage sur CSS ne peuvent pas représenter tout le monde.

Voici quelques conclusions que je vous soumets :

À propos de Bootstrap

Bootstrap est sur le déclin, et ce n'est peut être pas bien grave. Il a fait partie du voyage de nombreuses et nombreux devs, mais l'utiliser aujourd'hui est correlé avec une moindre connaissance de précieuses fonctionnalités CSS natives. Ce n'est pas un mauvais outil et il a sauvé bien du monde par le passé, mais il a aujourd'hui du mal à rester pertinent.

Je ne souhaite pas que les gens abandonnent Bootstrap si l'outil leur convient : la seule chose qui compte est la qualité de ce qu'on construit. Il faut juste être conscient que CSS est bien plus étendu que cela aujourd'hui (et beaucoup le sont déjà, j'en suis sûr).

À propos de Tailwind

Non, l'utilisation de Tailwind ne rend pas quelqu'un ignorant vis-à-vis du « vrai CSS ». Ces personnes utilisent un outil moderne et ont accumulé une connaissance substantielle de CSS au cours de leur apprentissage. Elles ont peut être appris le CSS natif récemment et pourraient être plus à jour que quelqu'un qui connaissait bien CSS il y a dix ans mais n'est pas resté à jour.

Cependant, elles devraient être conscientes que maîtriser Tailwind n'est pas et ne peut pas être maîtriser CSS, si une telle chose existe. Certaines fonctionnalités ne se transposent tout simplement pas à Tailwind. Cela n'empêche pas d'écrire du CSS de qualité mais réduit la taille théorique de la boîte à outils. Les personnes apprenant Tailwind et désireuses de continuer à apprendre pourraient réinvestir cette motivation et continuer à découvrir des fonctionnalités CSS natives, qui sont là pour durer et se transféreront d'un outil à un autre.

À propos du CSS natif

2022 a été une excellente année pour CSS et je pense que connaître ses capacités natives est un atout puissant. Bien sûr, cela ne remplace pas une compréhension profonde de la logique CSS, qui n'est pas juste une liste de propriétés, mais cela fournit une vaste boîte à outil dans laquelle piocher pour faire face à divers obstacles.

Pour Bootstrap et Tailwind, les personnes connaissant le plus de CSS natif étaient celles qui avaient testé le framework. Alors ne rejetez pas forcément tous ces outils par idéologie : découvrir de nouvelles façons d'écrire du CSS – même pour réaliser qu'elles ne vous conviennent pas au final – est potentiellement précieux et pourrait donner un nouvel éclairage à la façon dont vous écrivez du CSS natif.

Que pensez-vous de tout cela ? Si vous parvenez à des conclusions différentes, n'hésitez pas à les partager (en respectant tout le monde, ce n'est que du CSS !).

Paris Web 2022 — Jour 2, le récap !

2022-10-14T00:00:00Z

Suite et fin de mes aventures chez Paris Web, avec les 8 conférences du deuxième jour (et toujours des petites étoiles subjectives pour démarquer mes préférées).

1. Bien doser l'utilisation d'ARIA pour éviter les catastrophes ⭐⭐

Une première présentation donnée par deux personnes : une voyante et une non-voyante (utilisant pour la présentation une barette braille).

Nous sommes collègues. Il nous arrive souvent de regarder le même site mais de ne pas voir la même chose.

Note : Les citations sont basées sur ma prise de notes. Elle reflètent le propos mais la formulation exacte peut varier.

Sophie et Bart définissent ARIA comme un moyen permettant de modifier l'accessibility tree (que vous pouvez voir dans le dev tools au même titre que le DOM tree).

Mais son utilisation est bien souvent maladroite : aria-label qui masque le contenu réel, aria-live sur un carrousel qui interrompt en permanence le flux normal de lecture...

Jusqu'au paroxysme : le site d'un hôpital belge dont le body possédait un attribut aria-hidden...

Dans les audits, on demande plus souvent d'effacer de l'ARIA que d'en ajouter.

Et donc un énième rappel : ARIA complète les informations du HTML, mais c'est bien la bonne écriture de ce dernier à la base qui garantit la bonne accessibilité.

Voir la conférence sur YouTube

2. DesignGouv : insuffler une culture du design au sein de l'État ⭐

L'occasion d'abord de découvrir le nouveau site présentant le référentiel général d'amélioration de l'accessibilité, beaucoup plus sympathique que l'ancien.

Une autre ressource intéressante : l'observatoire de la qualité des démarches en ligne.

Depuis 2021, l'équipe de DesignGouv est intervenu sur 112 projets, auprès de 14 ministères. Une belle performance dont on aurait aimé voir plus de détails concrets.

Et un rappel simple mais important :

Plus on créé de nouveaux outils, plus il y en a à maintenir.

Un passage à noter lors des questions-réponses : le gouvernement recommande-t-il les outils de surcouche d'accessibilité (que certains spécialistes avait osé critiqué, avant d'être poursuivis par les éditeurs) ? La réponse est donnée : non. Applaudissements nourris.

Voir la conférence sur YouTube

3. Le making-of du RGESN : tout savoir sur le référentiel d’écoconception des services numériques ⭐⭐

Une conférence très spécifique, non pas sur ce nouveau référentiel lui-même, mais sur les coulisses de sa conception.

Plus de cent bénévoles, des centaines de critères ramenés au nombre final de 79, pour une version 1 qui devrait sortir ce mois-ci (en voici la version bêta).

Le format est très proche du RGAA (le référentiel pour l'accessibilité), et pour cause : les deux projets ont des intervenants communs.

La loi visant à réduire l'empreinte du numérique en France de 2021 n'impose pas encore le respect de ce nouveau référentiel. Il n'y a encore aucune obligation légale à ce sujet.

Et enfin, pour vous donner une idée, le nouveau site de l'ADEME (Agence de la transition écologique) respecte ce référentiel à 70%.

Voir la conférence sur YouTube

4. Designer l'urgence ⭐⭐⭐

Designer dans l'urgence en mode pompier VS designer l'urgence avec des pompiers.

Une conférence drôle et passionnante pour répondre à une question très sérieuse : comment aborder le design lorsque des vies sont en jeu ?

Pour reprendre en main le système d'information des pompiers, Julien s'est immergé dans le métier, et après son témoignage, vous ne pourrez plus dire que la recherche UX est trop difficile à mettre en œuvre dans votre secteur.

Le monde de l'urgence est fait de contraintes physiques et mentales imctibles. Sous le choc d'un accident, même une interface applicative d'apparence simple (« êtes-vous témoin ou victime ? ») n'a plus rien d'évident.

L'occasion également de tordre le cou au mythe du « produit minimum viable » (MVP). Une méthode excellente dans nombre de cas, mais tout simplement inapplicable lors de la refonte d'un service aussi critique : quand on sauve des vies, on ne peut pas commencer par la « version simple ».

Move fast and don't break things.

Voir la conférence sur YouTube

5. Comment Canal+ travaille et intègre l’accessibilité numérique ? ⭐

Depuis un an, Amélien a eu la délicate tâche de sensibiliser les équipes de Canal+ aux enjeux et aux techniques de l'accessibilité.

Les améliorations sont là, mais on ne peut s'empêcher de constater que même dans une si grosse entreprise, les bases ne sont pas acquises : comment peut-on encore être en charge de l'intégration d'un service massivement utilisé tel que myCanal sans se soucier des problèmes de focus, une des bases de l'accessibilité ? Le chemin est long et le recrutement (et donc les formations) doivent évoluer.

Enfin, je suis interpellé par ce rôle étrange chez Canal+ : Legal Product Manager, en charge de la vie privée, l'accessibilité et l'éco-conception. Une si grosse entreprise pense-t-elle que ces trois domaines, qui n'ont de commun que l'obligation légale et/ou l'image de l'entreprise, ne mérite pas au moins 3 emplois distincts ?

Force et courage à Amélien, donc ;)

Voir la conférence sur YouTube

6. Numérique et éthique : l'impossible équation ? ⭐⭐

Même si Audrey et Agnès avouent prêcher un public déjà convaincu (« c'est la première fois qu'on m'applaudit parce que je critique Amazon »), le sinistre tour d'horizon offert ici est nécessaire et percutant.

200 composants, 50 minerais et 75 kilos de matière première pour produire un téléphone (la production représente 75% des émissions), téléphone dont la durée de vie atteindra en moyenne 2 ou 3 ans et ne sera probablement pas recyclé... Sans parler du travail des enfants.

Et ce n'est que la partie production : saviez-vous que même si vous n'avez pas de profil Facebook, vous possédez malgré tout un shadow account ? Que des drônes étaient capables de suivre des manifestants jusqu'à leur domicile, en France ? Que Facebook, encore lui, a joué un rôle déterminant dans le génocide des Rohingya ? Et la liste semble sans fin.

L'invervention se clôture avec quelques conseils élémentaires : gardez votre téléphone (au moins 7 ans, idéalement). Utilisez le nouvel indice de réparabilité lors d'un achat. Réparez, et, si vraiment vous devez vous séparer de votre appareil encore en fonctionnement, ne le laissez pas traîner dans un tiroir : vendez ou donnez-le.

Voir la conférence sur YouTube

7. Thémiser un design system ⭐

Nous atteignons la fin d'après-midi de ce deuxième jour et je ne vous cache pas que mon cerveau commence à se transformer en compote. 16 conférences, c'est beaucoup.

En écoutant Matthieu, développeur responsable du design system des outils Proton (Mail, Drive...), je réalise à quel point mon propre travail (puisque je fais la même chose, à plus petite échelle) est difficile à expliquer techniquement.

Car oui, les variables CSS sont géniales, mais quand on rajoute à cela des valeurs par défaut, des valeurs optionnelles, des valeurs configurables par les utilisateurs... Ça devient complexe !

Matthieu a ainsi théorisé un modèle pour les noms de variables :

--usage-location-state-impact-property

Une idée m'a particulièrement parlé : un design system est une « rationalisation » du design, et devient ainsi un outil objectif pour challenger toute nouvelle modification des designers ou managers. Pas pour stagner, mais pour assurer au projet de ne pas partir dans tous les sens, ce qui est essentiel à cette échelle.

Voir la conférence sur YouTube

8. URL ; reprenons les bases ⭐⭐

Là, il n'y a plus personne dans ma boîte crânienne, ou plutôt il y a trop de choses, mais cette dernière conférence va fournir son lot d'informations passionnantes.

Même si vous connaissez les 5 parties d'une URL, les subtitilités d'écriture de chacune d'entre elles réservent des surprises.

Quels sont les pièges tendus aux utilisateurs grâce aux homoglyphes ? Pourquoi Chrome devrait gentiment s'abstenir de modifier les URLs affichées ? Qu'est ce que le test du bouton du milieu de la souris ?

On réfléchit rarement aux URLs, qu'on prend pour acquises, mais elles constituent la base du web et on a tendance à minimiser leurs capacités.

Voir la conférence sur YouTube

8 bonnes raisons de venir à Paris Web 2023

Les conférences (une trentaine !) sont de top qualité, j'ai appris beaucoup.
Le choix des conférences par les équipes est savamment équilibré entre design, accessibilité et technique pour vous tenir en haleine.
Les orateurs et oratrices viennent de tout horizon, vous n'entendrez pas 10 patrons de start-ups à la suite.
Une accessibilité remarquable, en cohérence avec le contenu : traduction LSF, vélotypie, traduction de l'anglais vers le français... Et cela a effectivement permis à de nombreuses personnes en situation de handicap d'être présentes.
Le prix est plutôt accessible pour un événement de ce type (surtout si vous demandez à votre boîte de participer).
Pardonnez-moi d'être terre à terre, mais l'on y mange très bien, même en tant que végétarien, et ce n'est pas négligeable pour mobiliser toute cette concentration.
Vous serez en immersion parmi tout un tas de gens qui veulent bien faire comme vous, et ça fait du bien.
On pourra se dire bonjour :)

À l'année prochaine !

Paris Web 2022 — Jour 1, le récap !

2022-10-12T00:00:00Z

Il y a pile une semaine, c'était mon premier Paris Web, et quelle journée ! 8 conférences (parmi les 16 proposées) passionnantes et variées.

En voici un récap à chaud, partiel et partial, qui j'espère vous donnera envie pour l'année prochaine !

J'ai mis des petites étoiles pour faire ressortir mes conférences préférées, mais c'est tout à fait biaisé par mes propres intérêts : je suis impressionné par la qualité de l'ensemble.

1. On se lève et on se casse : tour d’horizon d’un travail sans capital ⭐⭐

Ça commence fort dès le matin avec la présentation politique de la journée.

Je ne sais pas qui fait 35h par semaine dans la salle, mais moi cela m'est tout à fait insupportable.

Note : Les citations sont basées sur ma prise de notes. Elle reflètent le propos mais la formulation exacte peut varier.

Au-delà des phrases (et du titre) chocs, Maïtané et Thomas ont créé toute une série de visualisations astucieuses pour créer le débat et comparer différentes formes d'activités : salariat, portage salarial, micro-entreprise, coopérative d'activité et d'emploi...

Dans quelle structure peut-on parler d'argent sans tabou ? Dans laquelle choisit-on ses clients, ou ses collaborateurs ? Quelle structure participe le mieux au bien commun ? Et, pour répondre à cette notion de « sans capital », dans quelles structures les bénéfices nous reviennent-ils le plus directement possible ?

Pour ma part, une confirmation que le salariat, ce n'est pas trop pour moi, mais aussi un rappel qu'il n'y a pas que le freelance en face !

Voir la conférence sur YouTube

2. Concevoir des services éco-responsables en alliant Design de Services et Éco-conception Numérique ⭐

Cela fait 12 ans que je conçois des services, et 12 ans que je les conçois sans me poser la question de l'impact sur la planète.

La conception centrée sur les utilisateurs est devenue une telle religion qu'il est difficile de le faire entendre : tout ce qui est bon pour les clients et le chiffre d'affaire ne l'est pas forcément pour notre écosystème.

Une évidence ? Dans certains secteurs, oui, mais pas nécessairement dans le numérique et son illusion de dématérialisation.

Le design centré sur l'utilisateur est centré sur l'utilisateur... au dépend du reste. Il est temps de prendre un sacré recul pour inclure la conception des services dans une démarche beaucoup plus globale.

Et pour convaincre les entreprises qui n'y verraient que des contraintes, un seul axe : soit vous prenez le train, soit vous restez passifs face à une évolution inexorable.

Voir la conférence sur YouTube

3. Animating the Impossible ⭐⭐

C'était une forte promesse, et c'est un succès !

Je ne connaissais pas la méthode FLIP, qui permet de réaliser des transitions visuelles complexes entre deux états, avec un état final difficile à prévoir (notamment la position exacte de l'élément relativement au point de départ, l'élément pouvant atterrir dans un autre endroit du DOM).

L'idée géniale est donc la suivante, en 4 étapes (FLIP) :

First : stocker la position et les dimensions de l'élément actuel.
Last : placer instantanément l'élément dans sa position finale dans le DOM pour en trouver les dimensions et la position finale (ceci se passe dans la phase de layout, on ne sollicite pas la phase de paint et donc c'est invisible !).
Invert : Inverser l'animation prévue à la base en calculant la différence entre les états First et Last.
Play : jouer l'animation finale.

Je ne sais pas si j'explique bien, mais c'est à ça que sert la vidéo, non ?

Voir la conférence sur YouTube

4. L'industrialisation des designers du web ⭐⭐

Salle comble, c'est manifestement un sujet qui parle à beaucoup.

25 ans après la phase d'effervescence joyeuse du web, le constat n'est pas réjouissant : les écoles n'enseignent plus les bases des arts plastiques et appliqués. La SNCF mobilise 200 designers pour réaliser une application médiocre. L'esthétique, le sensible et la narration sont mis de côté face à l'assemblage de blocs.

Et c'est Figma qui va en prendre pour son grade. L'outil révolutionnaire pour les designers est aussi un outil de contrôle idéal pour les managers, assimilable à une ligne de montage surveillée.

Les designers sont presques dépossédés de leur métier : c'est désormais tout le monde qui peut « chuchoter au curseur du designer » de déplacer ceci, d'agrandir cela.

Laissez-nous commiter !, demande Cécile, dans un excellent parallèle avec le processus de développement et ses phases de réflexion solitaires. Figma, c'est parfois un peu comme si les collègues de votre agence vous indiquaient que vous n'avez pas fermé la parenthèse de votre fonction alors que vous êtes encore en train de coder...

Voir la conférence sur YouTube

5. Illectronisme et numérisation des services publics ⭐

L'administration française donne-t-elle les moyens aux citoyens d'accéder à leurs droits et de réaliser leurs démarches obligatoires ?

Avec 9% de français n'ayant aucun équipement pour accéder à Internet et 7% d'illetrisme en France, il est clair qu'une administration totalement numérique (et même si les services en ligne continuent à s'améliorer) ne répondra pas seule au problème.

Selon Raphaël, il faut se méfier du tout-numérique, qui cache le fantasme d'un citoyen modèle, qui se fond dans le moule et remplit gentiment son formulaire en ligne. Vision laissant sur le carreau tous les cas particuliers (et ils sont nombreux) et pouvant être source d'une perte d'autonomie et d'humiliation.

Voir la conférence sur YouTube

6. Lost in translation ⭐⭐⭐

Manuel me prend par les sentiments avec un sujet cher à mon cœur : HTML, et plus précisément le mystère de l'incompétence globale pour utiliser correctement ce langage.

Quelle que soit la stack, React ou intégration native, la plupart des erreurs d'accessibilité viennent du HTML. 20 ans à répéter les bases, et pourtant !

C'est précisément parce que la syntaxe de HTML est simple que ce langage est mal maîtrisé. Car la complexité ne vient pas de la syntaxe : elle vient de la compréhension des structures, de la sémantique, de tout ce qui est invisible dans un design. Et cela, c'est bien plus complexe.

Some people just don't care.

Certaines personnes s'en fichent-elles tout simplement ? J'ai bien peur qu'il ait raison, mais Manuel ne se veut pas fataliste pour autant. Une conférence très drôle sur le langage du web.

Voir la conférence sur YouTube

7. Transferts de données : est-ce que je peux encore utiliser des fournisseurs américains ? ⭐⭐

Non.

Autant le contenu de la conférence est technique pour le profane, autant la conclusion est sans appel. Même si les entreprises naviguent dans un flou règlementaire, soupesant les bénéfices et les risques d'une petite entrave à la règle, la fête est finie.

L'administration Bush a signé un mandat simple : il permet de faire usage aux USA comme bon leur semble de toute donnée présente (ou transmise) sur leur territoire, même celles récoltées par « hasard » (oui, c'est le mot utilisé).
Alors, votre prestataire des USA (ou travaillant lui-même avec les USA) pourra vous fournir toutes les précautions contractuelles du monde, cela ne change pas grand chose : face aux contrats, c'est la loi qui gagne.

Et si une société hors USA a des liens quelconques avec le pays, ce dernier se réserve aussi l'exploitation des données qu'ils pourra récupérer. Les ramifications sont vertigineuses.

Bref, exit Google Analytics, Mailchimp et les autres. Un petit séisme, en somme.

Comme dit le diction :

Il ne faut pas se demander si on va se faire hacker. Il faut se demander quand on va se faire hacker.

Voir la conférence sur YouTube

8. Objectifs 2025 de l’accessibilité : quels défis nous attendent ? ⭐

Fin de journée morose, pas à cause des intervenants mais du constat dressé : accessibilité, on n'y est pas, et loin de là.

Ne faites pas accessible, vous ne serez jamais inquiété.

Avec une obligation récente (2021 pour le secteur public et très grosses entreprises privées) ou même future (2025 pour le reste du secteur privé) et peu ou pas d'amendes conséquentes pour le moment, le chemin pour un web accessible ne fait que commencer.

Seules 20% des 250 démarches les plus utilisées par les français sont accessibles alors que c'est imposé depuis 2012.

Le sujet est profond et culturel : est-on prêt, en tant que société, à investir là-dessus ? Les actes ne le prouvent pas actuellement.

Une remarque est révélatrice : l'un des intervenants estime qu'une personne avec des compétences en la matière n'a pas spécialement plus de chances d'être recrutée qu'une autre. Un bonus sympathique, tout au plus.

Oui, le sujet est de plus en plus abordé. Mais c'est encore beaucoup trop anecdotique.

Toutes les grosses boîtes ont un budget sécurité énorme, et le budget accessibilité ?

Voir la conférence sur YouTube

Une musique de jeu évolutive grâce à JavaScript

2022-04-07T00:00:00Z

Le week-end dernier, j'ai eu le plaisir de composer la musique de Blobby Zombie, un jeu créé en 48h seulement par mon ami Simon et son camarade Pierre-Yves, lors d'une Game Jam organisée par Hitbox Makers.

Concevoir et coder un jeu en 48h n'étant visiblement pas assez difficile, ils ont créé un jeu multijoueur en ligne fonctionnel. Bravo à eux !

Pour jouer, c'est par ici !

Il faut être plusieurs, chacun sur un ordinateur, et tout le monde partage la même partie. Les règles et commandes sont disponibles ici.

De mon côté, ces deux jours se sont divisés ainsi :

7h le premier jour pour la composition de la bande-son ;
7h le deuxième jour pour la "programmation musicale".

La musique

Le jeu repose sur un mécanisme de dernier survivant. Il va donc falloir monter en pression progressivement pour que ruissellent les gouttes de sueur des joueuses et joueurs.

Avec un brief aussi complet que les trois mots « arcade », « horreur » et « fun », je me lance.

Écouter « Blobby Zombie » sur SoundCloud

Anticipant sur la programmation à venir, j'utilise une structure la plus simple possible : une boucle de 4 accords. À chaque nouveau cycle, un instrument se rajoute.

Voici un schéma, c'est important pour la suite, et j'aime les schémas.

Les instruments s'empilent de cycle en cycle pour faire monter la pression.

Mais comment adapter cette montée en pression de plusieurs minutes à une partie qui pourrait se dérouler beaucoup plus vite ?

La programmation

Commençons par une adaptation simple : j'avais choisi 130 BPM pour la bande son. Passer à 128 BPM est un changement quasi-inaudible qui me permet en revanche d'obtenir des cycles de 15 secondes exactement, ce qui sera bien plus sympathique pour coder et déboguer. C'est toujours ça de pris.

Bon, il nous faut un moyen de sauter de cycle en cycle, par exemple lorsqu'un nouveau joueur se transforme en zombie.

Passer d'une section à l'autre permet d'adapter la situation à l'évolution du jeu.

Puisque mes cycles font 15 secondes, c'est assez facile à calculer.

Si je suis au cycle 2 et que je souhaite avancer au cycle 3, je peux calculer qu'il faut avancer à 30 secondes dans le morceau (le cycle 1 commençant à 0 seconde, et le cycle 2 à 15 secondes).

C'est exactement ce que fait cette première démo. À chaque fois que vous cliquerez sur le bouton « Sauter », vous sauterez au début de la section suivante :

Voir le code sur CodePen.

Fludifier les sauts de cycles

Si vous jouez un peu avec, vous pouvez probablement entendre que le résultat n'est pas très satisfaisant.

Il y a deux raisons à cela :

sauter au début du cycle interrompt le rythme que vous pouvez entendre dès le début et tout au long du morceau (cette note unique et répétitive) ;
sauter au début du cycle suivant interrompt la progression d'accords et la fait recommencer au début, ce qui n'est pas du tout naturel.

La progression d'accords, c'est simplement l'enchaînement des 4 accords qui donne sa structure au morceau. On entend cette progression à partir du deuxième cycle.

Voici un cycle au complet : 4 accords qui font peur s'enchaînent sur 8 mesures.

On va simplifier un peu (beaucoup) le nom des accords et les appeler C, G, C et F (do, sol, do et fa).

On peut ainsi mettre à jour notre schéma, pour représenter cette progression à partir du deuxième cycle :

À l'exception de la note unique à la basse et de la batterie qui est uniquement rythmique, chaque nouveau cycle se base sur la même progression d'accords.

Le problème, donc, c'est que si nous passons du milieu du cycle 3 au début du cycle 4, par exemple, nous risquons de faire ça :

On saute du deuxième accord de la section 3 vers le premier accord de la section 4.

Patatra, la progression d'accords est cassée. Alors que nous nous préparions à entendre C puis F pour finir le cycle 3, nous reprenons la progression au départ : C, puis G à nouveau ! Et si on enchaîne vite les cycles, on entend quasiment le premier accord en permanence.

Or le cerveau est très doué pour s'habituer à une progression d'accords bien spécifique, et toute déviation est troublante pour l'auditeur (ce que certains compositeurs peuvent utiliser à leur avantage, mais c'est une autre histoire).

Pour remédier à cette violation rythmique et harmonique intolérable à l'oreille, le remède est simple : il ne faut pas aller au début du cycle suivant, mais à l'instant du cycle suivant qui correspond à l'instant actuellement joué.

Cette fois, on part du deuxième accord du cycle pour arriver sur le deuxième accord du suivant.

Techniquement, c'est presque plus simple que la première version : au lieu de calculer le début de la section suivante, nous allons ajouter 15 secondes – la durée d'un cycle – à la position de lecture.

Par exemple, si la musique a commencé depuis 5 secondes, nous pouvons sauter jusqu'à 5 + 15 = 20 secondes (alors que le début du cycle 2 est à 15 secondes).

Essayez et comparez. Le résultat vous semble-t-il moins abrupt ?

Voir le code sur CodePen.

Alors, attention, j'ai dit que les transitions étaient moins abruptes, pas parfaites ! Selon le moment où vous avancez, l'arrivée de tel ou tel instrument peut tout de même sauter aux oreilles. Mais la structure rythmique et harmonique est sauve, et c'est déjà beaucoup.

Masquer la transition

Pour améliorer encore l'effet, voici la botte secrète : un bon gros son bien énergique, qui va venir déguiser notre saut dans le morceau, en plus d'annoncer à tous les joueurs qu'il vient d'y avoir du grabuge.

Ce son, c'est ce que j'appelle le hit. En jouant le hit au bon moment, ce dernier occupe tout l'espace sonore et va permettre aux sauts de s'effectuer « discrètement ». Tous les coups sont permis...

Voici le résultat.

Voir le code sur CodePen.

Ce n'est pas encore parfait, mais compte tenu du timing serré, c'est déjà pas mal !

Harmoniser le hit

Finissons avec une petite touche cosmétique.

Actuellement, le hit est toujours le même son. Ce ne sont pas n'importe quelles notes qui sont jouées : elles correspondent précisément à celle du premier accord de la progression.

Autrement dit, elles sonnent très bien sur le premier accord.

Sur les autres accords, le rendu n'est pas choquant, car le hit est un élément bien séparé du reste de la musique. Mais qu'est ce que ça donnerait si le hit était harmonisé avec l'accord actuellement joué ?

Pour cela, j'ai exporté 4 hits différents. Ensuite, il suffit de faire correspondre le hit avec l'accord courant. Si on est dans le dernier quart d'un cycle, c'est qu'il faut jouer le hit qui correspond au dernier accord.

C'est parti !

Voir le code sur CodePen.

Cette amélioration passe sans doute inaperçue, c'est d'ailleurs son but, mais je pense qu'elle rajoute une petite couche de satisfaction auditive à l'ensemble.

Musique + code = ❤️

Voir un extrait du jeu sur YouTube

C'est la première fois que je combine ma passion pour la musique et mes connaissances en programmation, et en seulement 48h j'ai pu voir à quel point les possibilités étaient grandes.

C'est l'occasion de recommander une excellente chaîne YouTube : 8-bit Music Theory. Je ne comprends pas la moitié de ce qu'il raconte, mais ses analyses de bande-sons vidéoludiques me fascinent et m'ont fortement influencé pour cette petite expérience.

Quelques liens pour finir :

L'ère du no-hacks CSS

2022-03-28T00:00:00Z

Si vous avez appris CSS n'importe quand avant 2020, il y a fort à parier que vous avez collecté tout un tas d'astuces (ou hacks) en cours de route. Vous savez, ces choses comme le centrage vertical, les styles pour les éléments de formulaire, le dimensionnement des images, les retours à la ligne... De la magie noire. Des comportement incroyablement spécifiques que vous recherchez dans Google, espérant que quelqu'un a déjà écrit un article à ce propos, et qui ruineront votre journée dans le cas contraire.

Beaucoup de mes collègues regardent CSS avec une grande méfiance, car ils ont dû s'y frotter il y a 10 ans, avant de se diriger vers le back-end, la gestion de projet, le design ou même le « front-end pur JS ».

Beaucoup de gens vont jusqu'à regarder les développeurs utilisant CSS comme d'étranges créatures, ceux qui sont parvenu à dompter le monstre, ceux qui ont pu voir au travers de la jungle impénétrable des hacks et donner du sens à tout cela aux dépends de leur propre sanité d'esprit.

Mais la réalité est la suivante :

Nous n'aimons pas les hacks CSS

Personnellement, je les déteste. Ils peuvent être amusants à montrer à quelqu'un qui se débat face à un étrange comportement de mise en page (tadaaaa !), mais je les méprise, car ce ne sont que des contournements, ou d'horribles façon non-standards d'utiliser des propriétés qui n'ont jamais été faites pour cela. Ces codes sont énigmatiques, un cauchemar de maintenance, et, probablement le pire, ils créent une méfiance envers CSS qui au bout du compte fait du mal à l'ensemble de l'écosystème.

Et c'est ainsi que naissent les memes de Petter Griffin se battant contre le CSS, les blagues sur l'alignement vertical... Fichtre, j'ai même l'ironique mug CSS is awesome comme bannière Twitter.

Ces blagues nous ont aidé à supporter la dure réalité de CSS pendant des années, mais le fait est qu'elles sont désormais périmées. En réalité, les utilser reviendrait presque à dire :

J'ai appris CSS il y a 10 ans, j'ai détesté cela et je n'ai jamais ré-essayé ! (insérez la présentation d'une librairie CSS-in-JS miraculeuse ici)

Oui, il est temps que cette bannière Twitter s'en aille...

2022 sera-t-elle le début de l'ère du no-hacks CSS ?

Beaucoup de choses se passent autour de CSS ces temps-ci, et je pense que 2022 pourrait être l'année où l'on se débarasse des hacks CSS, ou du moins où l'on cesse de les considérer comme du « CSS normal ».

Jetez un oeil à ce tweet, par exemple :

Source : X

Les choses avancent vite est CSS devient un langage mature. Même la communauté des navigateurs s'organise pour faire évoluer CSS de la meilleure façon possible, avec par exemple l'initative Interop.

L'exemple de accent-color

La propriété accent-color est plutôt simple et l'une de mes nouveautés préférées.

Son seul but est de vous permettre de changer la couleur des inputs natifs : checkboxes, boutons radios, ranges... Voyez plutôt :

:root {
  accent-color: crimson;
}

Voir le code sur CodePen.

Une ligne de CSS et zéro hack.

Pendant des années (oserai-je dire des décennies ?), les développeurs CSS ont réalisé cet effet en cachant l'input réel en en montrant un input factice possédant l'apparence désirée. Les deux étaient liés par la bonne vieille pseudo-classe :checked. Ce code n'a jamais été du code normal. C'était du code sale, propice aux bugs, attendant patiemment d'être remplacé par une solution propre.

Laisser tomber les hacks est aussi votre responsabilité

La propriété accent-color est également un bon exemple de cela. En effet, elle est nouvelle et n'est pas supportée par tous les navigateurs.

Eh bien comme dirait l'autre, je n'en ai cure.

CSS étant génial, il ignorera simplement accent-color sur les navigateurs plus vieux et utilisera les couleurs par défaut. Ce qui est tout à fait acceptable (faites simplement attention à tester le contraste si votre fond n'est pas blanc).

Encore mieux, le temps passant, de plus en plus de gens utiliseront un navigateur supportant cette fonctionnalité et verront le design initialement voulu. Voici la magie de l'amélioration progressive : votre site web s'améliore alors que vous n'êtes même pas en train de travailler.

Le fait que je ne m'en soucie pas ne veux pas dire que ce sera le cas pour tout le monde. Un designer ou un manager décidera peut-être qu'il est important que les inputs respectent la couleur de la marque, même sur les vieux navigateurs, et je respecte cela. Mais ce n'est pas qu'une question de design, il y a des coûts et des bénéfices.

Je défendrais donc la position que bidouiller le CSS (une bidouille qui peut bugger) pour une fraction de l'audience (une fraction qui aurait une très bonne solution alternative et dont la taille diminuera avec le temps) n'en vaut pas la peine dans la plupart des cas.

J'adore également la propriété gap pour flexbox, qui rend la gestion des espacements si simple :

body {
  display: flex;
  flex-wrap: wrap;
  gap: 1rem;
}

Voir le code sur CodePen.

Une fraction en diminution des navigateurs ne supporte pas cette fonctionnalité et ne montrera aucun espace entre les éléments. Que vous soyez prêt à utiliser un hack de marges négatives ou non est un autre débat sur lequel il vous faudra trancher.

J'ai commencé à faire la paix avec le fait qu'une petite fraction (et encore une fois, en diminution) des utilisateurs n'aura pas les espaces. Tant que le contenu est parfaitement lisible, cela ne me dérange pas.

Mise à jour 2024 : la propriété gap est désormais supportée pour flexbox sur l'ensemble des navigateurs majeurs. 🎉

Adieux les hacks

Bien sûr, j'utilise toujours des hacks, de temps en temps. Mais j'ai cessé de les considérer comme du CSS commun.

CSS rattrape son retard sur nos bidouilles et est en train d'éradiquer les hacks en proposant des fonctionnalités standards et robustes. Si vous utilisez (et défendez) les techniques d'amélioration progressive grâce auxquelles vous savez que votre contenu sera toujours accessible sans chaque ligne de CSS désirée, vous pouvez utiliser ces nouveautés à volonté. Vous vivrez libre, plus longtemps et, je le crois, ferez de meilleurs sites web.

Partagez cet article à un ou une collègue qui déteste CSS ;) Si c'est votre cas, je ne peux pas vous blâmer. Mais nous sommes en 2022 et CSS a changé.

Calculs CSS infernaux à partir de données physiques

2021-06-18T00:00:00Z

Côté CSS, je suis assez satisfait de l'effet renversant (j'exagère un peu) de survol que j'ai mis en place (voir sur le site).

Vidéo : lorsque le curseur survole un livre, ce dernier pivote avec un effet 3D.

Il s'agit en fait d'une adaptation d'un projet open source, 3dbook.xyz.

L'intérêt de cette adaptation réside dans le fait que j'ai utilisé les variables CSS pour faire le lien entre des données concrètes, comme le nombre de pages, et le rendu CSS final.

Car tout ça est subtil. L'épaisseur du livre, par exemple, va dépendre bien sûr du nombre de pages, mais aussi de la taille du livre. Un livre de poche de 200 pages vu de près pourra paraître aussi épais qu'un gros livre de 400 pages vu d'un peu plus loin...

Cela nécessite donc quelques calculs !

Les données

Voici les données concrètes qui nous intéressent, par exemple pour le livre Clyde Fans :

---
width: 17
height: 23.5
pages: 488
offset: true
---

Respectivement :

la largeur et la hauteur du livre en centimètres ;
le nombre de pages ;
offset: true pour préciser que les pages sont plus petites que la couverture elle-même, ce qui est parfois le cas pour les gros livres (voir le gif ci-dessus).

Passer les données à l'élément

Grâce au langage de templating liquid, je pourrais alors générer des styles inline à partir de ces variables :

<img style="width: {{ item.data.width * 10 }}px" />

Dans cet exemple, un livre faisant 20cm de large dans le monde physique fera 200px sur mon site.

On peut faire en réalité bien plus propre et flexible, en passant ces paramètres aux composant sous forme de variables CSS.

Voici ce que ça donne :

<div
  class="book {% if item.data.offset %}book--offset{% endif %}"
  style="
    --width: {{ item.data.width }};
    --height: {{ item.data.height }};
    --pages: {{ item.data.pages }};
  "
></div>

La variable offset, si elle est présente, permet d'ajouter une classe supplémentaire à l'élément .book.

Les 3 autres variables sont passées grâce à l'attribut style, et sont maintenant disponibles pour chaque élément .book.

Note : Les variables CSS sont scopées. Chaque élément .book possède désormais ces 3 variables qui ne sont accessibles qu'à lui-même et ses enfants.

Les variables sont désormais disponibles dans le scope CSS de l'élément.

CSS : let the fun begin

Maintenant, nous pouvons utiliser ces variables pour mettre en forme notre livre. Ici, ça se complique et il ne faut pas lésiner sur les commentaires.

Je vais expliquer seulement quelques lignes du code. On commence avec quelques définitions.

.book {
  /* The books will be contained inside a square of this dimension */
  --base-size: 250;
  --base-size-rem: calc(var(--base-size) * 0.0625rem);

  @include medium {
    --base-size: 350;
  }
}

Je souhaite que les livres soient contenus dans un carré de 250 pixels de côté (--base-size). Je décline ensuite cette valeur en rem (mieux que les pixels), grâce à une petite multiplication.

La mixin @medium est une media query qui me permet d'agrandir la taille de base sur des écrans plus larges.

Notez comme je ne redéclare pas --base-size-rem dans la mixin @medium. En effet, --base-size-rem est dynamiquement calculée à partir de --base-size. Quand l'une change, l'autre aussi, y compris à l'intérieur d'une media query.

On continue :

.book {
  --is-portrait: clamp(
    0,
    calc((var(--height) - var(--width)) * 999),
    1
  );
}

Cette syntaxe du démon permet de savoir si le livre est en format paysage ou portrait, et de stocker cette info dans la variable --is-portrait (ça fait ça de moins à saisir dans la « base de données »).

Pas très clair ? On décompose.

clamp est une fonction CSS qui va me donner une valeur entre deux bornes (le premier et le troisième paramètre).

Par exemple :

clamp(0, 0.2, 1); /* 0.2, car c'est entre les bornes */
clamp(0, -15, 1); /* 0, car le chiffre du milieu est trop petit */
clamp(0, 4, 1); /* 1, car le chiffre du milieu est trop grand */

Notre valeur du milieu à nous, en simplifiant la syntaxe, ressemble à ça : (height - width) * 999.

Si le livre est au format portrait, la hauteur est plus grande que la largeur, et donc (height - width) est positif. La multiplication par 999 va nous faire obtenir un nombre très grand, transformé en 1 par les bornes du clamp.

À l'inverse, on obtiendra un nombre négatif si le livre est au format paysage, qui sera ramené à 0 par les bornes du clamp.

Et voici comment on obtient un booléen en CSS 🙃 À manier avec précaution, nous sommes d'accord...

Je peux ensuite utiliser ce booléen pour obtenir d'autres valeurs.

Si tous les livres font la même hauteur, ceux qui sont en paysage comme Panthère deviennent beaucoup trop gros. D'où l'intérêt du booléen is-portrait pour la suite.

Quelle devrait être la hauteur d'un livre s'il est en portrait ? La hauteur du conteneur, soit --base-size-rem. S'il est en paysage, au contraire, cela devrait être dépendant de largeur, qui elle sera --base-size-rem.

Note : L'usage de object-fit: contain pour contenir l'image n'est pas suffisante ici, car d'autres éléments et pseudo-éléments constitutifs de l'effet final ont besoin de connaître les dimensions exactes.

Et c'est ainsi que l'on parvient à des atrocités de ce genre :

.book {
  /* Height is base size if portrait, based on size ratio otherwise */
  --height-rem: clamp(
    calc(var(--is-portrait) * var(--base-size-rem)),
    calc(var(--base-size-rem) / (var(--width) / var(--height))),
    var(--base-size-rem)
  );
}

Allez, on s'accroche une dernière fois, promis. clamp, on connaît déjà, alors regardons nos bornes. Que remarque t-on si le livre est en mode portrait ? La première borne :

var(--is-portrait) * var(--base-size-rem)

Cette valeur devient simplement --base-size-rem, puisque is-portrait vaut 1. Et c'est aussi la valeur de la seconde borne. Si les bornes sont identiques, peu importe la valeur du milieu, le résultat sera --base-size-rem.

Et c'est que l'on souhaite. Pour les livres portrait, la hauteur est la taille du conteneur, tout bêtement.

Au contraire, pour un livre paysage, la borne du bas deviendra 0 grâce à notre booléen. Et donc la valeur du milieu pourra entrer en action. La voici :

var(--base-size-rem) / (var(--width) / var(--height))

On prend la valeur de base (qui sera donc la largeur), on divise par le ratio entre largeur et hauteur, et hop, on obtient notre hauteur.

Les livres en paysage font désormais une taille raisonnable, car leur dimension principale devient leur largeur.

Support navigateur

Quelques navigateurs dignes d'être considérés (Edge 18, Safari 13...), ne prennent pas en charge l'opération CSS clamp.

La mixin suivante permet de détecter ce support, pour mettre en place une solution de fallback avec des calculs un peu moins fins.

@mixin supports-clamp {
  @supports (width: clamp(0px, 1px, 2px)) {
    @content;
  }
}

Pour reprendre notre calcul du dessus, on l'utilise ainsi :

.book {
  --height-rem: var(--base-size-rem);

  @include supports-clamp {
    /* Height is base size if portrait, based on size ratio otherwise */
    --height-rem: clamp(
      calc(var(--is-portrait) * var(--base-size-rem)),
      calc(var(--base-size-rem) / var(--ratio-width-height)),
      var(--base-size-rem)
    );
  }
}

Si clamp n'est pas supporté, le navigateur utilisera la première ligne et ignorera tout le reste. Pour quelques utilisateurs, le rendu sera un peu moins subtil, mais le contenu reste lisible et c'est l'essentiel.

Mise à jour 2024 : clamp est désormais supporté par tous les navigateurs majeurs.

Vers un CSS plus adapté aux calculs visuels ?

Le code CSS complet du composant est disponible.

Tout cela est bien stimulant, mais guère lisible, y compris pour moi-même quelques mois après l'avoir écrit.

Pour un projet perso, c'est bien sympathique, mais la scalabilité n'est pas au rendez-vous.

Cela reste pourtant la solution qui me paraît la plus élégante, car elle se repose sur des informations physiques concrètes et ne nécessite pas de manipulations JavaScript qui seraient par nature moins performantes. On peut donc espérer que la syntaxe CSS continue d'évoluer pour permettre ce genre d'opérations avec plus de fluidité.

Peut-être grâce à Houdini ?

En attendant, il faudra faire fonctionner nos petites cellules grises... Et commenter, beaucoup commenter !

Optimisation agressive des performances d'un site statique

2021-06-16T00:00:00Z

Grâce au pre-rendering d'Eleventy, Lighthouse donne déjà à notre site le vénérable score de 100 points en performance 💪. Mais si nous essayions d'aller plus loin ? Le simple calcul d'un outil n'est pas une excuse pour ne pas mieux faire !

Voici les techniques, certaines banales, d'autres plus exotiques, que j'ai l'habitude d'utiliser.

Lazy loading des images

C'est désormais d'une simplicité absolue en HTML :

<img loading="lazy" />

Ainsi, les images sont chargées au fil du scroll. HTML mon amour.

Vidéo : un scroll vertical de la page, au fur et à mesure duquel les images sont chargées progressivement.

Un autre attribut a récemment fait son apparition, que je m'empresse d'ajouter :

<img loading="lazy" decoding="async" />

L'attribut decoding="async" autorise le navigateur à traiter en parallèle le rendu de la page et celui de l'image, ce dernier devenant donc non bloquant.

L'impact sera faible sur mes images de taille moyenne, mais ça ne mange pas de pain.

Picture, source & srcset

Pour les couvertures, trois formats d'image cohabitent : avif, actuellement supporté par Chrome & Opera, webp, désormais très bien supporté, et jpeg, pour les navigateurs un peu à la traîne.

Mise à jour 2024 : Le format avif est désormais supporté par tous les navigateurs majeurs !

Le navigateur peut choisir son format préféré grâce au tag picture, qui contient un tag source pour chacun des trois formats d'image. Il contient également un tag img qui sera le seul interprété si le navigateur ne comprend pas picture. On tire ici parti de la solidité du HTML, qui va simplement ignorer ce qui n'a pas de sens pour lui.

Notez que les attributs loading, decoding et alt se trouvent sur la balise de fallback, mais qu'ils seront bien pris en compte.

<picture class="book__cover">
  <source
    type="image/avif"
    srcset="dist/smile_350.avif 350w, dist/smile_700.avif 700w"
    sizes="(min-width: 32em) 21.875rem, 15.625rem"
  />
  <source
    type="image/webp"
    srcset="dist/smile_350.webp 350w, dist/smile_700.webp 700w"
    sizes="(min-width: 32em) 21.875rem, 15.625rem"
  />
  <source
    type="image/jpeg"
    srcset="dist/smile_350.jpg 350w, dist/smile_700.jpg 700w"
    sizes="(min-width: 32em) 21.875rem, 15.625rem"
  />
  <img
    loading="lazy"
    decoding="async"
    src="dist/smile_350.jpg"
    alt="Couverture de Smile"
  />
</picture>

Chaque couverture est donc proposée en avif, webp et en jpeg, mais également avec deux largeurs différentes : 350px et 700px. C'est ce qui est proposé au navigateur grâce à l'attribut srcset.

Enfin, l'attribut sizes permet au navigateur de connaître la taille d'affichage des images (il faut lui dire, car il ne peut pas le deviner à partir du CSS, pour des raisons d'implémentation).

Le contenu de l'attribut s'interprète ainsi : au dessus de 32em de large pour le viewport, l'image fera 21.875rem de large. Sinon, elle fera seulement 15.625rem de large.

Le navigateur connaît la taille du viewport et en déduit la taille de l'image affichée.

Grâce à toutes les informations à sa disposition, le navigateur peut finalement choisir quelle image utiliser, en fonction des formats supportés, de la taille du viewport, du pixel ratio de l'écran, du cache, de la qualité de connexion...

Voici le poids des dix images en fonction du format et de la dimension :

Poids des images en fonction de leur format et dimension
	avif	webp	jpeg
350px	🌟 147Ko	252Ko	321Ko
700px	249Ko	459Ko	624Ko

On varie donc du simple au quadruple ! Avec des images plus grandes, la différence sera encore plus importante.

Générer les images avec Eleventy

Plutôt être forcé à regarder la saison 29 de Plus belle la vie que de produire à la main toutes les images nécessaires à cette optimisation.

Pour rappel, on parle de 10 livres × 3 formats × 2 tailles, doit 60 images !

Non, je souhaite prendre l'image de la meilleure qualité possible, et laisser la machine faire le reste. Et là, merveille : Eleventy propose exactement ce qu'il me faut.

Nous allons créer un helper bookImage, que nous appellerons pour chaque item :

{% bookImage item %}

Un helper est une fonction qui retourne un template. Elle se déclare ainsi, encore une fois dans le fichier .eleventy.js.

eleventyConfig.addLiquidShortcode("bookImage", bookImage);

async function bookImage(book) {
  return "<p>Hello world !</p>";
}

Rappel important : Eleventy étant un générateur de site statique, ce JavaScript est exécuté une fois pour toutes lorsque le site est généré, et non pas au runtime côté client. Le but est toujours d'avoir un HTML statique au final.

Dans notre helper, nous allons utiliser le plugin officiel Image. Ça se passe comme ça :

const images = await Image(`src/img/${book.fileSlug}.jpg`, {
  widths: [350, 700, null],
  formats: ["avif", "webp", "jpeg"],
  outputDir: "_site/img",
});

Si nous passons un objet book et que nous avons bien un fichier image correspondant dans src/img/, cette fonction va générer les 6 images nécessaires.

Seule bizarrerie à mentionner, le null dans la liste des largeurs, nécessaire au cas où l'image source fait moins de 700px (la grande taille sera alors la taille originale de l'image, par exemple 579px).

Ensuite, et je vous passe les détails d'implémentation, nous allons retourner le template correspondant. Vous savez, le gros bout de code décrit plus haut avec toutes les sources, srcset...

return `<picture class="book__cover">
  ${sources}
  <img
    src="${url}"
    alt="${alt}"
    loading="lazy"
    decoding="async"
  />
</picture>`;

Peut-être l'avez vous remarqué, ce helper a de formidable qu'il fait deux choses très importantes à la fois :

il génère les images nécessaires ;
il renvoie le markup associé.

La séparation de ces deux processus est fréquente. Qu'ils soient ici si intriqués facilitera certainement la maintenance.

Une autre façon de le dire, c'est que le template génère à la volée les images dont il a besoin !

Vidéo : les images sont générées dans un dossier. Le processus peut être désactivé en développement pour gagner du temps.

CSS critique inline

Actuellement, la cascade du site ressemble à ça :

J'ai utilisé une simulation « slow 3G » pour forcer le trait.

On voit nettement les deux ressources bloquantes que sont le CSS et le JavaScript.

Contrairement aux images, le CSS et le JavaScript bloquent l'affichage de la page tant qu'ils ne sont pas chargés, parsés et exécutés.

Le client récupère le HTML, puis effectue deux nouvelles requêtes pour récupérer le CSS et le JavaScript. Il ne se passera rien d'autre pendant ce temps. La page restera blanche et les images ne commenceront pas à se charger. Quel gâchis !

Une bonne solution serait d'utiliser un server push, pour envoyer ces ressources avant même que le navigateur ne les ait demandé. Mais il faut pour cela avoir accès au serveur.

Alors me vient une pensée impure :

Mon CSS ne fait que 4ko, qu'est ce qui m'empêche de le mettre directement dans le HTML lors du build ?

Il s'agit en réalité d'une technique très efficace appelée Critical CSS Inline, qui consiste à placer le CSS nécessaire au rendu de ce que l'on voit en premier directement dans le HTML. On charge ensuite le reste du CSS en asynchrone, sans bloquer la page.

Dans mon cas, le CSS critique représente la quasi totalité de ma petite page, mais la technique n'en est pas moins intéressante.

Je vais ici faire appel au plugin eleventy-critical-css, qui cette fois n'est pas officiel mais créé par la communauté.

Je n'ai pas grand chose à dire sur l'utilisation tant elle est directe :

if (prod) {
  eleventyConfig.addPlugin(criticalCss, {
    assetPaths: ["_site/index.html"],
    minify: true,
  });
}

C'est tout !

Le CSS critique est extrait puis directement inclus dans l'index.html.

En plus d'inclure le CSS critique, le plugin ajoute la ligne suivante :

<link
  href="./css/styles.css"
  rel="stylesheet"
  media="print"
  onload="this.media='all'"
/>

Cette technique permet de charger le reste du CSS en asynchrone. En effet, le navigateur charge les CSS associées au media print en asynchrone par défaut. Une fois ceci fait, la destination de la feuille de style est mise à jour de print vers all grâce à onload="this.media='all'. Habile.

Et le JavaScript ?

Quand au JavaScript, qui sert uniquement à gérer l'ouverture fluide des éléments details sur mobile, l'attribut async sera idéal :

<script async src="./dist/script.js"></script>

Si l'utilisateur venait à cliquer sur un élément details avant que le script ne soit chargé, il s'ouvrirait alors sans transition, soit son comportement par défaut. Quand le JavaScript arrive, on utilise donc l'approche d'amélioration progressive sur ces éléments pour améliorer l'expérience.

Résultat, nous n'avons plus aucune ressource bloquante !

Nous avons ainsi drastiquement amélioré le chemin critique, soit cet instant crucial entre la requête et l'affichage de la page.

En une seule requête, notre utilisateur verra un contenu.

Mon petit projet effectue désormais un chargement initial de 128k et s'affiche en moins d'une seconde.

Un site performant, c'est forcément moche ?

Il n'y a rien de plus faux ! Il n'y a aucune corrélation entre la beauté d'un site et sa performance. Si vous avez les bons designers et les bons développeurs, les deux sont parfaitement compatibles.

Ne me croyez pas sur parole : voici une liste d'autres sites générés avec Eleventy, qui atteignent les 100 points sur tous les critères, tout en étant bien plus riches que le mien.

Ces 100 points ne sont d'ailleurs qu'un point de départ : mon petit projet les atteignait avant même les optimisations décrites dans cet article. Ils ne doivent donc pas nous empêcher d'aller plus loin !

Eleventy — Pour un web simple, performant et accessible

2021-06-14T00:00:00Z

Et si nous gardions Vue, React et ses compagnons pour les web app vraiment complexes ? Et s'ils devenaient l'exception à la règle, plutôt que d'être notre modèle mental par défaut ?

Tant de sites ne sont pas si complexes que ça ! Portfolios, sites vitrines, documentation en ligne, blogs... Ce web là mérite bien mieux que la complexité et les coûts qu'engendrent l'utilisation de nos frameworks JS favoris.

Une des ces nombreuses alternatives s'appelle Eleventy. Il s'agit un générateur de site statique, dont je suis totalement tombé sous le charme pour sa simplicité et son efficacité.

Le site sur lequel vous lisez cet article est fait lui aussi avec Eleventy !

Ça sert à quoi ?

Pour découvrir la bête, j'ai réalisé un site tout simple présentant mes 10 livres préférés de l'année (entends-je une remarque sur mon sens inestimable du design ?).

C'est pas moche, c'est sobre.

Le site est totalement statique : à cette adresse se trouve un fichier HTML, accompagné d'un peu de CSS et de JS. Pour la performance, on ne fait pas mieux.

Les scores des divers outils en ligne ne se substituent pas à l'analyse humaine, mais permettent de vérifier que l'essentiel est là.

Certes, le site est basique, mais j'aurais tout aussi bien pu le générer grâce à un appel GraphQL, une boucle React et autres joyeusetés. Sauf qu'on ne bat pas la simplicité. Boring code is good code, qu'ils disent.

Pour autant, je ne me suis pas amusé à écrire à la main les 770 lignes de ce fichier, très redondantes (10 répétitions du composant permettant d'afficher un livre et sa description).

C'est ici qu'Eleventy entre en scène.

Comment ça marche ?

Si on voulait résumer grossièrement, on pourrait présenter Eleventy ainsi :

données + templates = ♡ HTML ♡

Markdown, la « base de données »

Chaque livre représenté dans le site est un fichier markdown (d'autres formats, tels que JSON sont possibles). Voici par exemple celui pour le livre Dune :

---
tags: book
title: Dune
author: Frank Herbert
year: 1965
width: 10
height: 17
pages: 896
color: "#cf5441"
publisher: Pocket
link: https://www.lisez.com/livre-de-poche/dune/9782266320481
description: Ce pavé a la réputation d'être un peu chiant, et oui, bon, peut-être, faut rentrer dedans comme on dit...
---

Les trois tirets au début et à la fin permettent de définir une table. Le reste est assez direct.

Note : Il serait formidable de pouvoir typer les objets, avec chaque type de champ et des champs optionnels...

Voici donc ma belle liste de livres :

Si nous sommes très, très loin d'une base de données telle qu'on l'entend habituellement, cette simplicité vient avec ses avantages : il est ultra simple de mettre à jour le contenu.

Je n'ai qu'à modifier le fichier (potentiellement directement sur Github), et le process automatique de build que je décris plus loin se mettra en action. Corollaire : les données sont versionnées et il devient difficile d'en perdre.

On ne pourra certes pas faire du relationnel bien avancé, mais pour notre exemple, c'est parfait !

Rendre disponible les données

Par défaut, il est déjà possible de boucler sur cette collection de livres, qui sera ordonnée par date de création des fichiers markdown.

C'est bien pratique pour les posts d'un blog, mais dans mon cas je souhaite avoir une collection ordonnée par ordre alphabétique. Il faut alors la déclarer dans un fichier dédié, .eleventy.js :

eleventyConfig.addCollection("itemsAscending", (collection) =>
  collection.getFilteredByGlob("src/items/*.md").sort((a, b) => {
    if (a.data.title > b.data.title) return 1;
    else if (a.data.title < b.data.title) return -1;
    else return 0;
  })
);

Un peu de travail manuel, certes, mais en contrepartie, une grande liberté.

Je pourrais trier par année, par auteur, ou même créer une sous-collection contenant uniquement les livres de moins de 100 pages. Après tout, ce n'est que du JavaScript : on fait exactement ce qu'on veut.

Important : Ce JavaScript n'est pas exécuté côté client, mais bien lors de la génération du HTML statique, que je détaille ensuite.

Templating

De nombreux langages de templating sont compatibles. J'ai choisi liquid pour une raison qui a totalement disparu de mon esprit (probablement parce qu'il n'y avait aucune raison).

Voici donc la boucle du fichier index.liquid qui va générer les livres :

<main class="items">
  {%- for item in collections.itemsAscending -%}
    {% include src/partials/item %}
  {%- endfor -%}
</main>

Dans le fichier item.liquid dont voici un extrait, la syntaxe parle d'elle-même :

<h2 class="item__title">{{ item.data.title }}</h2>
{% if item.data.subtitle %}
  <h3 class="item__subtitle">{{ item.data.subtitle }}</h3>
{% endif %}

C'est simple, c'est bien 👌

Vous prendrez bien un peu de CSS / JS ?

Oui, mais à condition de pouvoir utiliser SASS et du JavaScript moderne !

Pour satisfaire ces besoins, Eleventy utilise un système de plugins très simples à utiliser.

Encore une fois, ça se passe dans le fichier de configuration .eleventy.js. Pour le CSS, d'abord :

const prod = process.env.ELEVENTY_ENV === "prod";

eleventyConfig.addPlugin(sass, {
  watch: "src/styles/**/*.scss",
  outputDir: "_site/css",
  cleanCSS: prod,
  sourcemaps: !prod,
});

Le booléen prod nous permettra de minifier le CSS uniquement en production, et de générer des sourcemaps uniquement en développement.

Même système pour le JavaScript :

eleventyConfig.addPlugin(babel, {
  watch: "src/js/script.js",
  outputDir: "_site/js",
  uglify: prod,
});

Il n'y a pas grand chose à ajouter. Si je peux éviter de tout câbler à la main à chaque projet, tant mieux (je t'aime toujours, Gulp).

Action !

Tout est en place. Voici la commande que j'utilise pour lancer le serveur de développement :

eleventy --input=src --serve

Les données markdown sont injectées dans les templates, eux-même transformés en bon vieux HTML.

--input=src désigne le dossier dans lequel j'ai placé tout mon code source (liquid, markdown, css...).

Le flag --serve vous créera un petit live server à rechargement automatique. À chaque fois que vous changez un fichier, le HTML final est régénéré, en un dixième de seconde de mon côté.

Et voici la commande de build :

ELEVENTY_ENV=prod eleventy --input=src

En utilisant un service tel que Netlify (pour qui travaille le créateur d'Eleventy, tout est lié), il ne vous reste plus qu'à renseigner la commande à lancer et le dossier généré à servir (_site pour Eleventy).

La commande build contient l'appel à Eleventy.

Le projet Netlify étant lié au projet Github, chaque push ou modification du code sur Github mettra à jour le site en une poignée de secondes.

Un meilleur web ?

À nouveau, il est évident qu'un outil tel qu'Eleventy n'est pas adapté à des applications à forte complexité métier, et ce n'est pas le terrain sur lequel il joue.

En revanche, nous avons désormais un site :

léger, car rien ne peut battre du HTML ;
performant, le CPU n'étant pas sollicité par une montagne de JavaScript ;
accessible, pour peu que le HTML soit écrit correctement bien sûr ;
explorable par les moteurs de recherche ;
prédictible, dans le sens où la complexité se situe côté serveur ;
aisément modifiable et rapidement déployable.

Bref, des objectifs parfois mis à mal lorsqu'on utilise des outils inadaptés, mais des objectifs essentiels...

Voici un web qui me plaît !

Retrouvez le code complet de ce projet sur Github.

La Jamstack

Eleventy fait partie de l'approche Jamstack, qui se définit par des termes souvent obscurs, mais dont le point le plus important est sans doute la génération en avance des sites côté back : le pre-rendering.

Beaucoup de générateurs sont d'ailleurs disponibles. Eleventy a la réputation de faire partie des plus simples, ce que j'ai largement pu vérifier par moi-même.

J'aime particulièrement le fait qu'il ne soit pas lié à un langage ou un framework en particulier. Bref, Je le conserve précieusement dans ma boîte à outils.

La prochaine fois, ne vous demandez pas Quel framework JS vais-je choisir ?, mais bien Suis-je dans l'absolue nécessité d'en utiliser un ?.

Que se passe-t-il lorsque vous écrivez un sélecteur CSS invalide ?

2020-12-07T00:00:00Z

J'aimerais parler d'un comportement très spécifique de CSS qui pourrait vous causer quelques maux de tête si vous n'en avez pas connaissance.

Créons un bouton :

<button>Click me</button>

Je souhaite que ce bouton change de couleur lorsqu'il est pressé. Avec la pseudo-classe :active, c'est facile.

button:active {
  background-color: black;
  color: white;
}

Voir le code sur CodePen.

Jusqu'ici, tout va bien.

Pour améliorer l'accessibilité, je veux appliquer le même effet lorsque le bouton est ciblé à l'aide du clavier ou d'une technologie d'assistance (et ne rien faire de spécial si le focus vient de la souris).

Cela est possible grâce à la nouvelle pseudo-classe :focus-visible. À l'heure où j'écris ces lignes, elle est supportée sans préfixe par Chrome et Edge.

Mise à jour 2024 : La pseudo-classe est désormais supportée par tous les navigateurs majeurs 🎉.

button:active,
button:focus-visible {
  background-color: black;
  color: white;
}

Voir le code sur CodePen.

Si vous utilisez Chrome ou Edge, vous pouvez essayer de cibler le bouton avec la touche Tab. Vous devriez alors voir les styles appliqués par le sélecteur :focus-visible.

Vidéo : un bouton obtient le focus du navigateur et ses couleurs s'inversent.

Ceci est d'une grande aide si vous n'utilisez pas la souris.

Mais il y a un problème

Pouvez-vous deviner ce qui se passera sur des navigateurs plus vieux ? Bien entendu, les styles associés à :focus-visible ne s'appliqueront pas, mais un effet de bord, peut-être ?

On perd aussi les styles de la pseudo-classe :active !

Vidéo : le bouton est préssé, mais il ne change pas de couleur.

Les styles associés à la pseudo-classe :active ne s'appliquent pas sur Firefox, bien que ce navigateur comprenne parfaitement ce sélecteur. Tristesse infinie.

Le problème vous paraît peut-être évident si vous le connaissez, mais lorsque j'ai dû le débugger au sein d'un fichier CSS bien plus complexe, il m'a ennuyé pour quelques bonnes minutes. Et je ne pense pas que ce soit un fait très connu des débutants.

Comment dire ?

Si quelconque partie du sélecteur échoue, la totalité du sélecteur échoue

En d'autres termes, si un navigateur ne connaît pas le sélecteur :focus-within, il ignorera la totalité de votre règle, y compris la partie concernant le sélecteur :active.

On pourrait dire que CSS est légèrement susceptible. S'il n'aime pas le type d'olive que vous avez mis sur la pizza, il n'envisagera même pas de la manger.

Voici la spécification du W3C :

Lors de l'interprétation d'une liste de déclarations, une syntaxe inconnue à quelconque position provoque l'arrêt du parser. Ce dernier avance jusqu'à ce qu'il trouve un point-virgule (ou la fin du bloc). Il recommence alors à zéro avec la déclaration suivante.

W3C, Error-handling

Et voici donc le correctif qu'il vous faudra utiliser : séparer les styles « sûrs » des styles plus exotiques.

button:active {
  background-color: black;
  color: white;
}

button:focus-visible {
  background-color: black;
  color: white;
}

Voir le code sur CodePen.

Maintenant, le sélecteur :focus-visible pourrait être ignoré, mais ne dérangera pas le sélecteur :active.

Mais pourquoi ce comportement ?

Pas si robuste pour un langage qui devrait s'adapter à autant de situations, n'est-ce pas ?

CSS est cassé ! JS seul peut nous sauver !

Il se trouve qu'il y a en réalité une bonne raison pour cela, qui est expliquée dans un vieux document à propos de CSS 2 :

CSS 2.2 donne un sens particulier à la virgule (,) dans les sélecteurs. Cependant, puisque nous ne savons pas si la virgule pourrait acquérir de nouveaux sens dans de futures versions de CSS, l'ensemble de l'instruction devrait être ignorée s'il y a une erreur où que ce soit dans le sélecteur, même si le reste du sélecteur semble acceptable en CSS 2.2.

W3C, Rule sets, declaration blocks, and selectors

Les concepteurs de CSS ont fait preuve d'une impressionnante capacité d'anticipation. En effet, voici quelques sélecteurs CSS que nous pourrons utiliser tôt ou tard (et pour certains, c'est déjà le cas) :

/* h1.title, h2.title, h3.title */
.title:is(h1, h2, h3) { }

/* exclusions multiples */
.title:not(h1, h2) { }

/* sélecteur de parent */
section:has(img, figure) { }

Ces sélecteurs contiennent des virgules, mais ces virgules ne séparent pas des sélecteurs de premier niveau.

Si un navigateur ne comprend pas :is et essaie de séparer notre premier exemple, cela pourrait donner quelque chose de ce genre :

.title.is(h1 : c'est quoi ce truc ? Je passe à la suite.
h2 : ciblons tous les h2, même ceux qui n'ont pas la classe .title !
h3) : hein ?

Astuce

Certains développeurs ont même utilisé ce comportement comme une astuce pour discriminer un navigateur précis.

Vous voulez appliquer un style à tous les navigateurs sauf à Internet Explorer ? Vous n'avez qu'à ajouter un sélecteur moderne simplement destiné à ce qu'Internet Explorer ignore la règle.

.covfefe:not(div),
h1 {
  color: red;
}

Tadaa, le h1 sera rouge seulement si le navigateur comprend :not.

Avec la bonne combinaison de sélecteurs, vous pourriez cibler ou exclure n'importe quelle version spécifique d'un navigateur. Ce qui, bien entendu, est très sale, et je l'espère plus nécessaire aujourd'hui 🙏.

Flexbox : les marges négatives à la rescousse

2020-11-02T00:00:00Z

Mise à jour 2024 : Bonne nouvelle, la technique décrite dans cet article est devenue pratiquement obsolète grâce au large support de la propriété gap par les navigateurs modernes.

La gestion des espaces avec flexbox n'est pas aussi simple qu'elle en a l'air. Voici une simple astuce que j'ai beaucoup utilisée ces derniers temps.

Le problème

Voici notre HTML pour cette démo :

<article>
  <h1>Hello World</h1>
  <ul>
    <li>HTML</li>
    <li>CSS</li>
    <li>JavaScript</li>
    <li>Front-end dev</li>
    <li>Web</li>
  </ul>
  <p>Lorem ipsum...</p>
</article>

C'est un article avec une liste de tags. Avec un peu de CSS basique, voici à quoi il ressemble.

Voir le code sur CodePen.

Nous souhaitons que la liste des tags soit un conteneur flex, avec la possibilité d'un retour à la ligne. Allons-y !

ul {
  display: flex;
  flex-wrap: wrap;
}

li {
  margin-right: 2em;
}

Comme vous pouvez le voir, j'ai aussi ajouté de l'espace après chaque élément <li>, 2em étant égal à 32px pour un texte basique (avec l'avantage de s'adapter aux préférences de l'utilisateur et à la taille de font de l'élément lui-même).

Et voici le résultat :

Voir le code sur CodePen.

Cela peut sembler assez bien, mais le diable est dans les détails.

Regardez le coin inférieur droit de l'article : je l'ai rendu redimensionnable pour que vous puissez simuler un redimensionnement du navigateur.

Il y a deux problèmes principaux. Pouvez-vous les repérer ?

Le problème horizontal

Le premier problème est qu'à cause de sa marge à droite, le dernier élément passe à la ligne trop tôt.

Vidéo : l'article est réduit en largeur jusqu'à ce que le dernier tag de la liste passe à la ligne.

Remarquez-vous comme le dernier élément aurait suffisamment d'espace pour aller plus loin à droite avant de revenir à la ligne ? Comparez cet espace à l'espace à gauche du premier élement.

Il serait possible de corriger ce problème en excluant le dernier élément de cette règle :

li:not(:last-child) {
  margin-right: 2em;
}

Voir le code sur CodePen.

Mais le problème est le même : tous les autres élément reviennent à la ligne trop tôt.

Vidéo : l'article est réduit en largeur et les tags passent les uns après les autres à la ligne.

Désormais, le dernier élement peut aller plus loin vers la droite, mais les autres provoquent un retour à la ligne prématuré.

Bon, si margin-right ne convient pas, que dire de margin-left ? Essayons de l'utiliser sur chaque élément, à l'exception du premier, qui ne devrait pas être précédé par un espace.

li:not(:first-child) {
  margin-left: 2em;
}

Voir le code sur CodePen.

Est-ce mieux désormais ? Prenez un moment pour essayer de deviner quel pourrait être le problème.

Puisqu'il n'y a plus de marge à droite, le retour à la ligne a lieu exactement quand il le faut. Mais maintenant, notre problème est ailleurs :

Vidéo : l'article est réduit en largeur et le dernier élément passe à la ligne, avec un décalage vers la droite par rapport au premier de la ligne du dessus.

Nous ne sommes pas vraiment en position de nous plaindre. Nous avons demandé à CSS que tous les éléments sauf le premier aient une marge à gauche, et c'est ce qui se passe.

Comme il serait agréable de pouvoir exclure les éléments étant les premiers de leur ligne ! Mais il n'y a pas de sélecteur magique comme celui-ci :

li:not(:first-flex-row-item) {
  /* N'existe pas */
}

Un tel sélecteur hypothétique pourrait causer une dépendance circulaire. Par exemple, je pourrais dire que le premier élément d'une ligne a une petite taille de font. Cela pourrait permettre à l'élément de retourner sur la ligne précédente (car il prendrait moins de place). Il ne serait donc plus ciblé par le sélecteur, reprendrait sa taille originale, reviendrait sur la seconde ligne et... 🤯

Les dépendances circulaires sont une des raisons principales pour lesquelles nous n'avons pas encore accès aux container queries. Mais c'est une autre histoire.

Mise à jour 2024 : Après des années d'effort, les containers queries sont désormais bien supportées !

L'astuce de la marge négative

Voici donc la solution : d'abord, tous les éléments reçoivent un margin-left.

li {
  margin-left: 2em;
}

Voir le code sur CodePen.

Nous devons maintenant nous débarrasser de l'espace à gauche du premier élément, et nous pouvons faire cela à l'aide de marges négatives.

Les marges négatives ne sont pas considérées comme faisant partie des bonnes pratiques, et je pense qu'il faut les éviter autant que possible, car elles peuvent rendre la logique de votre code plus difficile à comprendre.

Ceci étant dit, elles sont autorisées par le w3c et offrent un très bon support navigateur.

Et dans notre cas, elles nous sauvent la mise :

ul {
  display: flex;
  flex-wrap: wrap;
  margin-left: -2em;
}

li {
  margin-left: 2em;
}

Voir le code sur CodePen.

Une bordure bleue sur l'élément ul révèle l'astuce.

Et l'axe vertical ?

Devinez quoi, c'est la même chose !

Il est impossible de cibler tous les éléments en excluant ceux qui sont sur la première ligne.

Il faut donc donner à tout le monde une marge supérieure.

li {
  margin-left: 2em;
  margin-top: 1em;
}

Voir le code sur CodePen.

À cause de cet ajout, la liste apparaît plus bas que ce que nous souhaitons.

Il serait possible de retirer la propriété margin-bottom: 1em du titre pour compenser.

Retirer la marge sous le titre (zone jaune) compenserait le nouvel espace à l'intérieur de l'élement ul (bordures bleues).

Mais j'essaie de toujours garder mes éléments indépendants du contexte. La liste pourrait apparaître sous un autre élément quelque part ailleurs. Ou le titre pourrait être suivi par autre chose que cette liste.

Nous devons donc utiliser la même astuce et appliquer une marge négative à notre liste :

ul {
  display: flex;
  flex-wrap: wrap;
  margin-left: -2em;
  margin-top: -1em;
}

Et voici notre version finale. Elle fonctionne sur tous les navigateurs qui supportent correctement flexbox, y compris Internet Explorer 11.

Et la propriété `gap` ?

Les articles tels que celui-ci deviendront obsolète lorsque la propriété CSS gap sera largement supportée.

Mais ce n'est pas encore le cas. À l'heure où j'écris ces lignes, le support navigateur est de 70%. Pas super, comparé au support à 99% de flexblox lui-même – Safari serait-il devenu le nouvel Internet Explorer ?

Mise à jour 2024 : Après ce qui a semblé être une petite période de flottement, Safari s'est repris en main et a rattrapé une bonne partie de son retard sur ses concurrents. Ce cliché n'a plus lieu d'être.

Tous les autres navigateurs modernes devraient vous montrer le même résultat avec le code suivant, sans astuce !

ul {
  display: flex;
  flex-wrap: wrap;
  gap: 1em 2em; /* row-gap + column-gap */
}

/* Plus de style sur les items eux-mêmes */

Voir le code sur CodePen.

Le point embêtant est qu'il n'est pas possible de détecter le support de cette propriété. Prenez le code suivant :

@supports (gap: 1em 2em) {
  /* Désactiver les astuces et utiliser la solution propre */
}

La syntaxe @supports permet d'appliquer des règles uniquement si le navigateur comprend ce qui se trouve entre les parenthèses.

Le problème est que gap est également une propriété utilisée pour les grilles CSS, avec un bien meilleur support de 92%. Mais cela ne signifie pas que la propriété fonctionnera pour flexbox.

Le problème est étudié par le CSS Working Group.

En attendant, vive les marges négatives.

Et maintenant, avec des variables ✨

Nous pouvons améliorer notre code et le rendre plus générique si besoin. J'aime séparer mon CSS produisant des éléments BEM sémantiques et mes classes utilitaires. Je vais donc créer une classe utilitaire u-flex.

Je ne suis pas un grand fan du fait d'avoir des classes orientées style dans mon HTML, et je pourrais donc utiliser une mixin SASS pour parvenir au même résultat, mais vous saisissez l'idée.

Utilisons les variables CSS, qui sont très bien supportées (95%). En CSS, il est possible d'obtenir l'opposé d'une valeur en la multipliant par -1. Voici un exemple :

div {
  --size: 2em;
  width: calc(-1 * var(--size)); /* -2em */
}

Voici donc notre classe utilitaire :

.u-flex {
  display: flex;
  flex-wrap: wrap;
  margin-top: calc(-1 * var(--row-gap));
  margin-left: calc(-1 * var(--column-gap));
}

.u-flex > * {
  margin-top: var(--row-gap);
  margin-left: var(--column-gap);
}

J'aime utiliser le sélecteur d'enfant direct (> *) avec flexbox et grid. Il s'accorde très bien avec la relation parent/enfants de ces fonctionnalités et fonctionnera à tous les coups.

Et voici comment je l'utiliserai :

<ul class="u-flex">
  <li>HTML</li>
  <li>CSS</li>
  <li>JavaScript</li>
  <li>Front-end dev</li>
  <li>Web</li>
</ul>

ul {
  --row-gap: 1em;
  --column-gap: 2em;
}

Voir le code sur CodePen.

Le pouvoir des variables CSS nous permet de définir des espaces différents pour chaque élément ciblé. Nous pourrions même définir des valeurs par défaut pour l'ensemble du document :

:root {
  --row-gap: 1em;
  --column-gap: 2em;
}

Ainsi, nous n'avons besoin de changer les variables localement que si nous souhaitons une valeur différente.

Mise à jour 2024 : Plutôt que des variables à la racine, l'utilisation d'une valeur par défaut serait plus appropriée, par exemple : var(--row-gap, 1em);

Mauvaises pratiques

Nous connaissons toutes et tous un tas de mauvaises pratiques : !important est une autre qui me vient à l'esprit. Mais comme les marges négatives, même !important a des cas d'usages légitimes.

Cet astuce de la marge négative est un rappel pour moi : les choses que l'on apprend à éviter pourraient nous être bien utiles un jour ou l'autre. Tout dépend du contexte.

HTML n'est pas un langage de programmation et c’est sa plus grande qualité

2020-10-21T00:00:00Z

Mise à jour 2024 : Mon avis sur la question a évolué. HTML n'est certes pas un langage de programmation impératif, mais les arguments pour le considérer comme un langage de programmation déclaratif me semblent tout à fait fondés.

Je ne souhaite pas modifier l'article car il correspond à mes vues de l'époque, mais gardez cette disctinction sémantique en tête : j'ai utilisé le terme « langage de programmation » incorrectement à la place de « langage de programmation impératif ».

Les autres points sont toujours d'actualité !

J'adore HTML. Plus j'en apprends à son sujet, plus je trouve que c'est un travail de génie. Par dessus tout, j'adore qu'il ne s'agisse pas d'un langage de programmation.

Les langages de programmation sont nuls. Ils plantent en permanence (je vous jure, j'écris toujours mon JavaScript parfaitement du premier coup, et pourtant il persiste à planter !?).

Pire, quand ils plantent, la plupart du temps, l'ensemble du programme s'écrase ! Autant essayer d'empiler des cure-dents sur un viaduc par plein vent.

Mais comparez cela à la beauté qu'est HTML :

<nav>
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="products.html">Products</a></li>
    <li><a href="about.html">About</a></li>
  </ul>
</nav>

Ceci est un magnifique et sémantique bout de HTML5. Il contribue à l'accessibilité, à la lisibilité, à l'application des styles, à la découverte du contenu par les robots.

Et il ne plante pas.

Si un vieux navigateur ne connaît pas HTML5, il traitera l'élément <nav> comme une bonne vieille <div>, et cela fonctionnera.

Si un développeur ou un utilisateur avec un éditeur de code (par exemple dans l'administration d'un WordPress) écrit nax au lieu de nav, cela fonctionnera toujours.

Prenons un autre exemple :

<details>
  <summary>HTML</summary>
  HTML is an acronym for HyperText Markup Language.
  It was created by Tim Berners-Lee in 1989.
</details>

Tout le monde ne connaît pas l'élément <details>, voici donc ce qu'il produira dans un navigateur moderne :

Voir le code sur CodePen.

Je n'ai pas programmé ce comportement (les développeurs de navigateur l'ont programmé). J'ai décrit le contenu du document et fait confiance au navigateur pour l'afficher du mieux qu'il pouvait. Et je pense que cela est très, très sympa.

Et cela fonctionnera aussi avec les vieux navigateurs : il n'y aura pas d'interactivité, mais le contenu sera affiché et c'est bien le plus important.

Restez calme et arrêtez de programmer

Je ne veux pas programmer. Je dois souvent le faire, quand HTML n'est pas suffisant pour décrire ce que mon site devrait faire. Et comme beaucoup d'entre nous, mon quotidien tourne autour des frameworks JavaScript, et j'aime beaucoup certains d'entre eux.

Mais quand je pense à l'utilisateur, je sais que la pire chose que je puisse faire est de programmer.

À chaque fois que je programme, j'ai l'impression de signer une étrange décharge dans mon esprit :

Par la présente, je reconnais que j'introduis un comportement non-standard dans ce site web, déchargeant le navigateur de sa responsabilité d'assurer une expérience fiable pour chaque utilisateur. Je fais cela en ayant consience de ma connaissance partielle des technologies web, de l'existence de limites dans mes implémentations, temporelles et techniques, qui ne peuvent être estimées. Je réalise que ce que je fais échouera probablement à un certain moment ou dans certaines situations. Mais je n'ai pas le choix et je promets de ne pas merder.

À l'inverse, quand j'utilise HTML et les standards du web, je me repose sur la connaissance partagée de développeurs de navigateurs expérimentés et des décennies de débats ayant pour but de faire du web une plate-forme de qualité.

Et c'est pour cela qu'une connaissance profonde du HTML est infiniment précieuse : cela apporte tout simplement de la qualité à l'utilisateur, ce qui au bout du compte est la seule chose d'importance.

Résilience

Dans une de mes meilleures lectures de cette année, Jeremy Keith nous raconte comment nous avons presque perdu l'un des aspects les plus puissants de HTML à cause de XHTML 2.0 :

[XHTML 2.0] avait aussi pour but d'implémenter la draconienne gestion des erreurs de XML. S'il y a la moindre erreur dans un document XML – un attribut sans guillemets ou un slash de fermeture manquant – alors le parser doit s'arrêter immédiatement et refuser de rendre quoi que ce soit.

Jeremy Keith, Resilient Web Design

Dieu merci, nous sommes passés à côté de cela.

XHTML 2.0 est mort prématurément. Sa pureté théorique fut fermement rejetée par les personnes qui vivaient de la création de sites web.

Jeremy Keith, Resilient Web Design

Source : https://speakerdeck.com/elkraneo/html5

HTML est-il difficile ?

Bien sûr, pour qu'HTML soit un si bon langage, vous devez le connaître. Je veux dire, vraiment le connaître.

La sémantique, l'accessibilité, le référencement, les compatibilités navigateurs et les styles par défaut, les nouvelles balises et les balises obsolètes, les attributs spécifiques liés au langage et au temps, les formulaires, l'optimisation des performances, les métadonnées, les médias...

Même sans parler des « soupes de balise » générées par certains frameworks, il y a une grande différence entre un bon code HTML et un code HTML excellent.

Ce serait une erreur de considérer HTML (et CSS) comme la partie facile du développement web. Le problème est qu'il faut bien connaître ces langages pour réaliser cela.

JavaScript est difficile. Pourquoi tout le monde sait-il cela ? Parce qu'avant de réussir à faire fonctionner quoi que ce soit, vous devrez affrontez une avalanche d'erreurs rouges bloquant votre projet entier. Seul un pénible débuggage vous permettra d'avoir un code fonctionnel.

On ne peut pas échouer avec HTML. On peut écrire de la soupe de balises, des mauvais formulaires et ne suivre aucune bonne pratique, mais cela n'échouera pas, à cause de la résilience fondamentale de HTML.

La première fois que l'on écrit du JavaScript, cela semble être un sacré bazar. La première fois que l'on écrit du HTML, on se sent comme un génie du web.

Ce n'est qu'avec le temps et les connaissances que l'on réalise que le génie, ce n'est pas soi : les concepteurs d'HTML sont les génies, et ils nous ont donné un superbe outil qui nécessite beaucoup de pratique et de patience pour s'en servir vraiment correctement.

La permissivité d'HTML a donné l'opportunité à beaucoup de personnes de contribuer au web et n'est sans doute pas pour rien dans l'expansion de l'invention de Tim Berners-Lee. Mais pour les développeurs professionnels, cette permissivité vient avec la responsabilité de ne pas se reposer sur cette simplicité apparente et de vraiment apprendre à maîtriser ce puissant langage.

La crise d'identité des langages web

La manière dont nous nommons les choses est importante. Il est très frustrant de voir la partie HTML/CSS d'un projet dévaluée si souvent lorsqu'on en connaît l'aspect critique. Il est insoutenable d'entendre des développeurs déclarer qu'ils ne se préoccupent pas du CSS, alors qu'afficher des pixels sur un écran est quasiment la définition de notre métier.

Peut-être qu'appeler HTML un langage de programmation le rend plus digne d'attention pour certaines personnes ? Il serait naïf d'ignorer les biais salariaux et même le sexisme liés à cette affaire. Car oui, HTML/CSS est la partie présentation et cela est plus... féminin ?

D'un autre côté, je comprends que lire que HTML est un langage de programmation peut ennuyer certains, moi compris. Pas parce que je pense que les langages de progammation sont meilleurs. Parce que je ne veux pas qu'HTML soit un langage de programmation.

Nous construisons juste des choses

Durant mes cours, j'utilise souvent le terme « langage de développement ». Je ne le vois pas beaucoup utilisé en anglais, mais je trouve que c'est un très bon terme.

Avec cette appellation, on peut réunir HTML, CSS et JavaScript sans que tout le monde ne crie au scandale. D'après le dictionnaire :

Développer : inventer quelque chose ou donner vie à quelque chose.

Cambridge dictionnary

Alors que le débat autour d'HTML/CSS étant ou non des langages de programmation semble pouvoir durer jusqu'à la fin des temps, le fait qu'ils sont utilisés, parfois aux côtés de JavaScript, pour donner vie à quelque chose, ne semble pas être matière à controverse.

Qui se soucie de si vous programmez ou non ? La seule chose d'importance est la qualité de ce que vous construisez.

Il va falloir remettre la non-programmation à la mode.

Pourquoi vous devriez toujours déclarer une background-color

2020-06-03T00:00:00Z

Raphael Schweikert a commenté le premier article de cette série avec quelques points particulièrement intéressants :

Je me souviens des années 1990 où la plupart des navigateurs avaient une couleur de fond grise. Internet Explorer était le seul à avoir un fond blanc par défaut. Les autres ont suivi.

Raphael Schweikert, Commentaire sur l'article « Quelle est la couleur d'une page blanche ? »

Même si comme moi vous n'avez pas connu cette époque, vous avez probablement déjà croisé ces aperçus grisâtres du passé.

Internet Explorer a donc pris une décision fondatrice pour le web tel que nous le connaissons aujourd'hui : le blanc.

Et aujourd'hui ?

Raphael a aussi expliqué que cette couleur pouvait être modifiée. Dans Firefox, c'est simple :

ouvrez la page about:config ;
cherchez le paramètre browser.display.background_color ;
la valeur par défaut est #ffffff. Changez-la !

Ce n'est pas une option secrète de développeur : toutes les options mentionnées dans cet article peuvent être configurée par n'importe qui, en utilisant une interface plus sympathique.

Le panneau de configuration des couleurs sous Firefox.

Tous les navigateurs ne gèrent pas cela de la même façon : Chrome, par exemple, vous encourage à utiliser des extensions et des thèmes. Dans tous les cas, voici l'idée : l'utilisateur n'aura pas nécessairement un arrière-plan de navigateur blanc. Comme toujours, nos présuppositions sont nos ennemies. Nous ne savons rien.

Que se passe-t-il lorsque l'arrière-plan du navigateur n'est pas blanc ?

Imaginons que je sois fan des modes sombres et que je définisse la couleur de l'arrière-plan de mon navigateur en utilisant la valeur #000000.

Le premier effet, c'est que lorsque rien n'est montré, car je suis en train de passer d'un site vers un autre en cours de chargement, mon écran est noir.

Vidéo : le passage d'un site à un autre. Pendant le temps de chargement du second site, l'écran est noir.

Un utilisateur de Reddit a expliqué cette astuce dans un post intitulé « Comment ne pas être aveuglé à l'ouverture d'un nouveau site ? » C'est en effet une amélioration immédiate, mais l'histoire n'est pas si simple.

Un autre post dont j'adore le titre complète le tableau : « J'ai changé l'arrière-plan pour du noir. Je ne vois plus rien. »

Oups ! En utilisant du noir pour la couleur d'arrière-plan, cet utilisateur a rendu le web... invisible.

Rappelons-nous de ce qu'explique le W3C :

Si l'arrière-plan du canvas n'est pas opaque, ce qui est visible en dessous dépendra de l'agent utilisateur.

W3C, The Canvas Background and the HTML <body> Element

Cela signifie que si vous ne donnez pas de couleur d'arrière-plan à votre page (couleur qui remplira le canvas), le fond du navigateur sera visible.

Il est possible de voir le fond du navigateur si le canvas est transparent à cause de l'absence d'une couleur de fond sur la page.

Bien qu'une majorité de site déclare explicitement une couleur de fond blanche, ce n'est pas toujours le cas, et c'est ainsi que le web peut devenir invisible.

Voici ce à quoi TechCrunch ressemble avec le fond de mon navigateur en noir :

Le correctif est très simple :

body {
  background-color: white;
}

Et voici donc un conseil de Raphael :

J'ai donné à mon navigateur une couleur d'arrière-plan grise pour vérifier si je n'ai pas accidentellement oublié de déclarer background: white sur une page qui devrait avoir un fond blanc.

Raphael Schweikert, Commentaire sur l'article « Quelle est la couleur d'une page blanche ? »

Cela semble être une très bonne astuce et m'a donné envie d'écrire ce nouvel article.
Le désavantage est que vous verrez un fond gris sur TechChrunch et les autres « sites transparents » (sauf si vous utilisez un environnement différent pour le développement et la navigation classique, bien sûr).

Y a-t-il beaucoup de sites transparents ?

Bien que cela ne soit pas représentatif du « web », j'ai testé les 100 sites les plus visités, et 14% d'entre eux ont un canvas transparent, laissant apparaître la couleur de fond jaune que j'ai utilisée pour mener mon enquête.

Une couleur de fond pas si bonne que ça pour la santé.

Parmi eux : le Wall Street Journal, Paypal, Vimeo, AOL, la BBC...

Cela fait quelques jours que je garde cet horrible fond jaune comme arrière-plan et ce chiffre de 14% me semble cohérent avec ma navigation quotidienne. Je peux vous assurer que lire du texte sur ce fond est une excellente motivation pour terminer cet article.

Et l'utilisateur, alors ?

Vous pensez peut-être :

Si l'utilisateur décide d'avoir du noir en tant que couleur d'arrière-plan, peut-être a t-il ses raisons et peut-être ne faut-il pas interférer ?

C'est compliqué. Qui peut bien changer ce fond blanc « universel » ?

Cela pourrait être l'utilisateur. Cela pourrait être l'agent utilisateur lui-même (qui pourrait être un ordinateur, un téléphone, mais aussi tout un tas d'autres choses).

Il est peut-être impossible d'avoir des statistiques à ce propos, mais nous pouvons être sûr d'une chose : une fraction indeterminée d'utilisateurs n'aura pas un fond blanc. Et un site transparent ne s'affichera pas correctement.

Sauf si l'utilisateur ou le navigateur change également la couleur par défaut du texte. Dans Firefox, c'est simple : il faut changer le paramètre browser.display.foreground_color.

Tous les textes dont la couleur n'est pas spécifiée en CSS utiliseront cette valeur. Retournons sur TechCrunch :

Ce n'est pas génial. Oui, une partie du texte est désormais affichée en blanc. Mais il ne s'agit que du texte dont la couleur n'a pas été spécifiée en CSS. Et comme il est courant pour le texte d'avoir une couleur légèrement différente du noir, il y a toujours une grande partie du contenu qui ne peut être lue.

Pour que cela fonctionne, il faudrait un site sans couleur de fond ni couleur de texte explicite.

Il n'y a pas de CSS sur motherfuckingwebsite.com, cela fonctionne donc très bien.

Notez que vous pouvez également définir la couleur des liens, du texte recevant le focus, etc... Mais la même règle s'applique : cela ne fonctionnera que si aucun CSS ne s'applique, ce qui est improbable sur la plupart des sites. Un clash de couleur est inévitable.

Nous avons donc deux solutions :

ne rien spécifier et avoir un design extrêmement simple qui s'adaptera aux couleurs définies par le navigateur ;
spécifier une couleur de fond et une couleur de texte.

C'est pourquoi vous pourriez vouloir ajouter les lignes suivantes à votre kit de base :

body {
  background-color: white;
  color: black;
}

Cela me semble rentrer dans la catégorie des situations « très spécifiques mais si simples à résoudre qu'il serait bien dommage de ne pas le faire ». On ne sait jamais sur quelle étrange combinaison de caractéristiques navigateur notre site va tomber.

Alors quel est l'intérêt de changer les couleurs du navigateur ?

Je suis un grand partisan du fait de respecter les choix de l'utilisateur (ou de son navigateur). Le CSS que nous écrivons ne devrait pas être une série d'ordres impératifs pour générer une page au pixel près, mais un ensemble d'indications que le navigateur peut utiliser, entre autres choses, pour savoir à quoi doit ressembler le résultat.

D'un autre côté, il me semble avoir établi qu'il est plus sûr de « forcer » la couleur de l'arrière-plan et du texte d'un site, sans quoi il pourrait rapidement devenir illisible.

Heureusement, les deux approches peuvent être réconciliées, car nos navigateurs sont malins. Et c'est le dernier paramètre que je souhaite aborder : browser.display.document_color_use.

Quand ce paramètre vaut 2, Firefox supplantera toutes les couleurs CSS et utilisera celles définies par l'utilisateur ou Firefox lui-même. En d'autres termes :

Je me fiche de ton CSS, utilise ces couleurs !

Essayons à nouveau ce mode sombre improvisé en donnant à Firefox un arrière-plan noir et des textes blancs. Cette fois, le CSS ne pourra pas écraser nos choix, grâce au paramètre document_color_use.

Cela fonctionne enfin ! J'ai même changé la couleur des liens pour utiliser quelque chose qui me convient mieux. Le CSS n'a pas changé, mais Firefox l'a supplanté.

Maintenant que le navigateur ne peut qu'utiliser l'ensemble de couleurs que nous avons défini, il est plus probable que les sites s'affichent de façon convenable.

J'ai testé les 14 sites transparents du top 100, et chacun d'entre-eux s'affichait correctement. J'estime qu'environ 95% du contenu présentait une très bonne lisibilité avec mes couleurs customisées. Mais bien sûr, cela n'est pas parfait.

La page d'accueil de Vimeo présente une bonne lisibilité... Avec des exceptions notables pour le logo et les liens en haut à droite.

Notez que lorsque vous utilisez le paramètre document_color_use, tous les sites sont impactés, pas seulement les transparents.

Le site dev.to a une couleur d'arrière-plan, qui est supplantée par mes paramètres Firefox.

Cela ne remplacera pas un mode sombre intégré (et dev.to en possède un), mais la plupart du temps le résultat est correct.

De manière plus générale, cette option est également très intéressante pour l'accessibilité. Voici TechCrunch avec le paramètre document_color_use activé et les couleurs par défaut de Firefox :

Wow, ça fait beaucoup de liens. Presque tout le texte se trouve dans une balise <a>, d'où la couleur bleue. Scrollons un peu et comparons l'original avec ce que nous avons désormais :

En haut : l'affichage par défaut. En bas : les couleurs par défaut de Firefox.

Quand les couleurs par défaut de Firefox sont imposées, on voit du pur noir pour le texte (au lieu du gris léger du design original) et du bleu pour les liens. C'est un peu brutal mais excellent pour l'accessibilité.

En fait, c'est ce que fait automatiquement Windows si vous activez le mode « contraste élevé » du système d'exploitation. Aucune manipulation sur le navigateur n'est nécessaire.

Ceci étant dit, cela ne peut pas remplacer un design pensé pour l'accessibilité. On pourrait dire que c'est parce que le web n'est pas très accessible que de telles options sont nécessaires.

Montrez toujours votre vraie couleur

Voici donc ce que nous avons appris :

toujours spécifier une couleur de fond et une couleur de texte sur les pages car les « valeurs universelles » n'existent pas ;
si un utilisateur ou un appareil a besoin de les supplanter, ils le peuvent et c'est très bien !

Quant à moi, je jure que je ne regarderai plus le moindre pixel blanc de la même façon.

Le problème avec Chrome, les iframes et mix-blend-mode

2020-05-26T00:00:00Z

Mise à jour 2024 : le bug décrit dans cet article semble ne plus exister. La probabilité que cet article soit d'un quelconque intérêt s'approche donc dangereusement de zéro. Adieu petit bug.

Dans cet article, je vais décrire un bug très spécifique de Chrome, et explorer ce qu'il nous apprend sur le comportement du canvas, que j'ai décrit dans l'article initial.

Si vous le pouvez, je vous recommande d'utiliser Chrome pour la lecture de cet article, afin de voir ce qu'il se passe.

Quel est le bug ?

Dans Chrome, au sein d'une iframe, un élément ne peut pas se mélanger avec le canvas de l'iframe.

Pour montrer cela, CodePen est parfait : en effet, tout ce que vous voyez dans un CodePen se trouve à l'intérieur d'une iframe.

Reprenons l'exemple du post original, dans lequel nous souhaitons mélanger le h1 vert avec l'arrière-plan blanc du body :

body {
  background-color: white;
}

h1 {
  color: green;
  mix-blend-mode: difference;
}

Ce CSS est valide et devrait produire un titre rose (rose étant la différence entre vert et blanc).

Voir le code sur CodePen.

À l'heure où j'écris ces lignes (mai 2020) :

Firefox passe le test (titre rose) ;
Safari passe le test (titre rose) ;
Chrome échoue (titre vert) – je l'ai fait fonctionner dans le post original avec une astuce que j'expliquerai par la suite.

D'après ce que nous avons appris dans l'article initial, voici ce qui se passe :

le body est transparent (white est défini dans le CSS, mais la valeur est « volée » par le canvas) ;
le html est transparent (valeur par défaut de background-color) ;
le canvas est blanc (la valeur est issue du body).

Dans Firefox et Safari, le h1 n'a aucun problème pour se mélanger au canvas blanc. Mais cela ne fonctionne pas sous Chrome.

Comme je l'ai précisé, cela se produit car CodePen présente notre code dans une iframe : le même code fonctionne très bien en isolation.

Comment corriger cela ?

C'est très simple. Mais c'est ce que ce correctif révèle qui m'intéresse. Vous rappelez-vous du mécanisme du canvas « volant » l'arrière-plan du body, et du body ne repeignant pas la même couleur, finissant donc transparent ?

Le fond de l'élément racine devient le fond du canvas. L'élément racine ne peint pas son arrière-plan de nouveau, ce qui signifie que la valeur effective de son arrière-plan est transparente.

WC3, The Canvas Background and the Root Element

Il se trouve que Chrome n'a pas de problème pour mélanger un élément avec l'arrière-plan du body de l'iframe. Mais le vol de l'arrière-plan par le canvas provoque une erreur.

Peut-on empêcher le canvas de commetre un tel crime ?

Oui, en donnant une couleur de fond à l'élément html également :

html,
body {
  background-color: white;
}

Voir le code sur CodePen.

Cela fonctionne désormais partout !

J'avais déjà utilisé ce correctif, mais je comprends seulement maintenant pourquoi il fonctionne : c'est parce qu'il empêche le canvas de voler l'arrière-plan du body.

Vous rappelez-vous de notre petit algorithme ?

if (le html possède une background-color) {
  on l'utilise pour peindre le canvas
}
else if (le body possède une background-color) {
  on l'utilise pour peindre le canvas
}
else {
  le canvas demeure transparent
}

Cela va à l'encontre des bonnes pratiques dictées par le W3C, mais si vous donnez une couleur de fond à l'élément html, elle sera utilisée par le canvas. Le body sera laissé tranquille.

Voici donc ce qui se passe :

le body est blanc (valeur spécifiée en CSS. La valeur ne peut plus être volée, grâce au html faisant office de leurre) ;
le html est transparent (white spécifiée en CSS, mais volé par le canvas) ;
le canvas est blanc (valeur récupérée du html).

En quelque sorte, nous posons un appât avec la couleur du fond du html, pour que le body puisse conserver son propre arrière-plan et que le titre puisse se mélanger correctement.

Un point contre-intuitif est que n'importe quel fond fera l'affaire, même un fond quasiment invisible :

html {
  background-color: rgba(255, 255, 255, 0.01);
}

body {
  background-color: white;
}

L'arrière plan déclaré avec rgba est pratiquement invisible, mais le résultat est le même.

Voir le code sur CodePen.

Cela était assez confus pour moi. La valeur n'a pas d'impact ?

Il est plus facile de comprendre pourquoi, désormais. La valeur n'a aucune importance : la seule chose qui compte, c'est qu'il y ait une valeur, et que cette valeur distrait le canvas, qui ne viendra pas voler celle du body.

Penchons-nous maintenant sur un cas encore plus spécifique et voyons ce qu'il peut nous apprendre sur la relation entre le body et le canvas.

Ça va trop loin

Le correctif de la couleur de fond sur l'élément html est simple, mais il y a un cas intéressant que ce correctif ne couvre pas.

Ajoutons un pseudo-élément avec une position absolute à notre titre :

h1::after {
  content: "Hello from the other side";
  position: absolute;
  bottom: 50px;
  right: 50px;
}

Comme vous pouvez le voir, le pseudo-élément va atterir en bas à droite de notre page, en dehors des éléments body et html. Je ne pense pas que les dieux du CSS aient voulu cette situation, mais oups, je viens de la produire.

Quelle sera donc la couleur du pseudo-élément ?

Voir le code sur CodePen.

Si vous utilisez Chrome, vous pouvez voir que l'élément est vert. Cela illustre bien le bug : à l'intérieur d'une iframe, un élément peut se mélanger au body, mais pas au canvas, bien que les deux soient blancs.

Et maintenant, la touche finale : vous pouvez clairement voir la distinction entre le body blanc et le canvas blanc en redimensionnant le viewport pour amener le pseudo-élément au dessus du body.

Vidéo : lorsque l'élément flotte en dehors du body, la fusion n'est pas appliquée et il reste vert. Lorsque la hauteur de la fenêtre est réduite et que l'élément ré-intègre le body, la fusion fonctionne et il devient rose comme prévu.

Analysons la situation :

le texte se mélange avec le body (valeur white dans le CSS) ;
le texte ne se mélange pas avec le html (valeur white dans le CSS volée par le canvas, donc transparent) ;
le texte ne se mélange pas avec le canvas, bien qu'il soit blanc, à cause du bug de l'iframe sous Chrome.

Pourquoi cela m'importe-t-il tant ?

Il peut paraître exagéré de se pré-occuper de situations si extrêmes. Ce n'est pas le genre de problème que vous risquez de rencontrer au quotidien. Pensez-y : pour reproduire ce que montre le gif ci-dessus par accident, il vous faudrait :

utiliser Chrome ;
utiliser une iframe (créée par CodePen, par exemple) ;
utiliser mix-blend-mode ;
l'utiliser sur un élément dont tous les parents sont dépourvus d'arrière-plan ;
l'utiliser sur un élément en position absolute ;
travailler avec un body suffisamment petit pour que l'élément en position absolute passe en-dehors.

Eh bien, croyez-le ou non, c'est exactement ce qui m'est arrivé il y a quelques temps.

J'aidais un de mes étudiants à créer un effet avec mix-blend-mode. J'ai innocemment créé une démo sur CodePen, en utilisant Firefox. Tout était parfait. Affaire classée. Jusqu'à ce que mon étudiant m'informe que cela ne fonctionnait pas sous Chrome.

Je ne suis plus digne d'être ton professeur.

Il m'a fallu pas mal de temps pour comprendre tout ce que j'ai expliqué dans ces deux articles. Pour être honnête, j'ai d'abord fonctionné en mode « corriger maintenant, comprendre plus tard ». J'ai ajouté une couleur d'arrière-plan à l'élément html, forcé la hauteur du body à 100vh, et voilà !

Quelques mois plus tard, je me pose pour analyser le problème... Et me voilà pris dans cette spirale infernale.

Améliorer les choses

Bien que le correctif de la couleur de fond sur l'élément html soit simple, et bien que la situation décrite plus haut est hautement improbable, il s'agit toujours d'un bug.

En réalité, il s'agissait même d'un bug qui se produisait en dehors des iframes ! Un ticket Chromium a été ouvert en 2017. Il a été marqué comme résolu en 2020.

Réalisant que le bug se produisait toujours dans les iframes, je me suis permis de le signaler dans un commentaire, ce qui a conduit à la création d'un ticket dédié.

Méfiez-vous de vos habitudes de test

Je suis amoureux de CodePen. Je pense que je n'ai pas besoin d'expliquer pourquoi. Je m'en sers presque tous les jours.

Mais dans ce cas précis, CodePen m'a mis dans une situation qui n'était pas la même que celle que je tentais de débloquer. J'aidais un étudiant à créer une page qui ne contenait pas d'iframe. En utilisant un outil présentant mon code dans une iframe, j'ai changé les conditions initiales. Et comme nous l'avons vu, c'est un changement non négligeable lorsqu'on parle de Chrome et de mix-blend-mode.

Notez que CodePen n'est pas à blâmer : c'est Chrome qui est en faute ici, et CodePen n'a pas d'autre choix que de présenter mon code dans une iframe – sauf si vous utilisez la vue debug !

Utilisez la vue debug pour éxécuter votre code dans une vraie page – sans iframe !

Je suis aussi à blâmer : j'avais une telle confiance aveugle en CodePen que j'ai inconsciemment écarté l'hypothèse que l'utiliser pouvait affecter mon résultat.

Alors, comme disait l'autre : ne tombez pas amoureux de vos outils. Rien ne vaut un vrai test.

Quelle est la couleur d'une page blanche ?

2020-05-22T00:00:00Z

Imaginez le HTML suivant dans votre tête :

<html>
  <body>
    <h1>Hello World</h1>
  </body>
</html>

Vous ouvrez ce HTML dans votre navigateur. Quel est la couleur de la page ?

Vous pouvez penser que c'est une question piège, car le blanc n'est pas réellement une couleur, mais la page n'est de toute façon pas blanche : elle est transparente. Oui, le navigateur est blanc, mais la page présentée au sein du navigateur est transparente.

Prouve-moi que la page n'est pas blanche, car elle me semble tout de même pas mal blanche

Mode philosophe activé :

Qu'est ce qu'une page ?

Deux éléments doivent être considérés :

l'élement body ;
l'élement html.

Si l'on souhaite obtenir un fond jaune, on utilise la propriété background-color sur le body :

body {
  background-color: yellow;
}

Voir le code sur CodePen.

À partir de cet exemple, on peut imaginer que le body remplit l'intégralité du viewport, car désormais tout est jaune.

C'est faux. Ajoutons une bordure au body :

Voir le code sur CodePen.

Vous pouvez voir qu'en réalité le body n'utilise que l'espace dont il a besoin pour afficher le contenu « Hello world ».

Mais alors, pourquoi tout ce jaune ?

Il faut demander cela au w3c :

L'arrière-plan de l'élément racine devient l'arrière-plan du canvas et sa zone de peinture s'étend pour couvrir le canvas en entier.

W3C, The Canvas Background and the Root Element

Traduction humaine : vous spécifiez une couleur de fond sur le body. Le navigateur l'utilisera comme couleur de fond du canvas.

Le canvas, dites-vous ?

Le canvas du document est la surface infinie sur laquelle le document est rendu.

W3C, Backgrounds of Special Elements

Une surface infinie, rien que ça.

La notion de canvas est absente de la plupart des cours dédiés au CSS (y compris du mien, dois-je avouer), bien qu'il s'agisse d'un composant très important du navigateur. Comme nous venons de le voir, en se basant sur le body, il fourni un arrière-plan pour l'ensemble du viewport.

Avec cette nouvelle information, nous pouvons mettre à jour notre représentation mentale de la page, de haut en bas :

l'élément body ;
l'élément html ;
le canvas.

Pendant longtemps, j'ai pensé que le canvas était jaune parce que le body était le canvas. Mais non : le canvas ne fait qu'utiliser une information provenant du body et peut être bien plus grand que le body lui-même.

Il est intéressant de noter que bien que l'on demande au body d'être jaune, il est en réalité transparent. Comme l'explique le W3C :

Le fond de l'élément racine devient le fond du canvas. L'élément racine ne peint pas son arrière-plan de nouveau, ce qui signifie que la valeur effective de son arrière-plan est transparente.

WC3, The Canvas Background and the Root Element

Il est inutile pour le navigateur de peindre le body, qui a la même couleur que le canvas : il est donc traité comme étant transparent.

En d'autres termes, lorsque vous donnez une couleur de fond au body, vous stylisez en réalité le canvas (qui ne peut pas être ciblé directement en CSS). Le canvas « vole » la valeur du body.

Au-delà du body

Mode philosophe activé :

Qu'est ce que le body ?

D'après le W3C, le body représente les contenus du document.

Si le body est le contenu, il semble honnête de dire que ce qui est en dehors du body n'est pas le contenu.

Dans ce cas, utiliser background-color sur l'élément html ne devrait pas avoir d'effet, puisqu'il ne fait pas partie du contenu ?

Pensez-y un instant : à quoi ressemblerait notre page avec ce CSS ?

html {
  background-color: green;
}

body {
  background-color: yellow;
}

Quelle est la couleur de la page maintenant ? Est-elle verte, est-elle jaune, est-elle les deux ? Bien sûr qu'elle est les deux.

Voir le code sur CodePen.

Que voyons-nous ?

le jaune est désormais limité au body ;
l'élément html semble remplir l'ensemble du viewport.

Faux ! Une fois de plus, nous sommes trompés par les apparences.

Mais si, il remplit le viewport, toute la page est verte !

Je sais. Mais ajoutons des bordures à l'élément html pour comprendre ce qui se passe :

Voir le code sur CodePen.

Il est intéressant de noter que le navigateur n'a pas de problème pour appliquer des styles (tels que nos bordures) en dehors du body. Mais continuons.

Donc, en réalité, le html se comporte comme le body : il ne prend que la place nécessaire à la présentation de son contenu, c'est à dire le body et ses 8px de marge, qui viennent des styles par défaut du navigateur.

Mais alors pourquoi tout ce vert ?

Même réponse du W3C :

Le fond de l'élément racine devient le fond du canvas.

WC3, The Canvas Background and the Root Element

On apprend également que l'élément racine peut être le body ou le html :

Il est recommandé aux auteurs de documents HTML de spécifier le fond du canvas sur l'élément body plutôt que sur l'élement html.

W3C, The Canvas Background and the HTML <body> Element

Bien que le W3C recommande de ne pas utiliser l'élément html pour faire cela, c'est ce que l'on vient de faire, et c'est de là que le canvas tire sa couleur verte.

Comme dans le premier exemple, l'élément html est traité come transparent : son vert est « volé » par le canvas.

Nous avons maintenant l'algorithme complet que le navigateur utilise pour choisir la couleur du canvas :

if (le html possède une background-color) {
  on l'utilise pour peindre le canvas
}
else if (le body possède une background-color) {
  on l'utilise pour peindre le canvas
}
else {
  le canvas demeure transparent
}

Bien, cela fait un mystère de résolu, et ce n'est pas si étrange, finalement. Il est même assez heureux que nous n'ayons pas à donner des dimensions explicites à l'élément racine pour que la couleur de fond remplisse le viewport.

Pourquoi est-ce important ? Et c'est quoi cette histoire de blanc VS transparent ?

Comprendre qu'il y a une différence entre blanc et transparent, bien que les deux situations semblent identiques, est clé dans la compréhension de certains mystères du CSS.

Amusons-nous avec mix-blend-mode. Cette propriété CSS nous permet de définir comment un élément devrait se mélanger visuellement avec son parent. On en parle parfois comme de « Photoshop dans le navigateur ». Que cela soit une éxagération ou non, les possibilités sont extraordinaires.

Quelques exemples d'utilisation de mix-blend-mode.

Commençons avec un exemple simple : notre h1 sera vert, et nous souhaitons changer son apparence avec mix-blend-mode: difference.

h1 {
  color: green;
  mix-blend-mode: difference;
}

La valeur difference signifie que la couleur du texte sera la différence entre la couleur originale (vert) et la couleur de l'arrière-plan.

La différence entre vert et blanc est rose. On espère donc que notre titre sera rose.

Voir le code sur CodePen.

Il n'est pas rose. Je répète, il n'est pas rose.

Mais il devrait devenir rose, l'arrière-plan est blanc !

Non, il n'est pas blanc. Il est transparent.

La différence entre vert et transparent est vert, et c'est pour cela que la couleur du titre reste inchangée.

Récapitulons :

le body est transparent (valeur par défaut de background-color) ;
le html est transparent (valeur par défaut de background-color) ;
le canvas est transparent (aucune valeur fournie par html ou body).

Notre pauvre titre n'a donc rien avec quoi se mélanger.

Le correctif est facile : donnez un arrière-plan blanc au body !

body {
  background-color: white;
}

Et maintenant, ça fonctionne !

Voir le code sur CodePen.

Récapitulons à nouveau :

le body est transparent (white est défini dans le CSS, mais la valeur est « volée » par le canvas) ;
le html est transparent (valeur par défaut de background-color) ;
le canvas est blanc (la valeur est issue du body).

Et c'est ainsi que notre titre vert se mélange au canvas pour devenir rose. Ce titre pourrait bien sûr être une image, une vidéo, quoi que ce soit. Le body (ou n'importe quel élément contenant notre cible) doit posséder un arrière-plan (on pourrait également donner une couleur de fond à l'élément html pour y parvenir, mais ce n'est pas standard).

Notre périple touche à sa fin, mais une question demeure...

Quelle est la couleur d'un canvas vide ?

Notre modèle mental d'une page est ainsi :

l'élément body ;
l'élément html ;
le canvas.

D'après ce que nous venons d'apprendre, si le body et le html sont transparents, le canvas sera transparent aussi.

Mais comment la dernière couche peut-elle être transparente ? Si c'était le cas, on verrait le bureau et les autres fenêtres au travers du navigateur, tu es fou !

Laissez-moi vous expliquer. Et s'il y avait une autre couche, réellement blanche, plus bas que le canvas ?

Encore une fois, le W3C nous donne la réponse :

Si l'arrière-plan du canvas n'est pas opaque, ce qui est visible en dessous dépendra de l'agent utilisateur.

W3C, The Canvas Background and the HTML <body> Element

Traduction humaine : il y a quelque chose derrière le canvas. Vous pouvez voir cette chose si le canvas est transparent. Ce que vous voyez dépend du navigateur.

Sur tous les navigateurs auxquels je peux penser, cette dernière couche est blanche. Mais théoriquement, elle pourrait aussi montrer l'image d'un cheval en train de manger une pizza à l'ananas. Quel web étrange cela serait.

Bref, cela m'a conduit à me poser une question : y a-t-il un moyen de vraiment voir la différence entre un canvas blanc et un canvas transparent ? Peut-on obtenir la preuve que le canvas est transparent par défaut ? Je demande pour un ami.

L'indice de l'iframe

Revenons à un CSS très simple :

html,
body {
  border: 3px dashed black;
}

Voir le code sur CodePen.

Incluons cette page dans une autre grâce à une balise <iframe> :

<iframe src="..." width="100%" height="300px"></iframe>

Voici ce que l'on obtient :

Voir le code sur CodePen.

La question est donc : l'iframe possède-t-elle un canvas transparent ou blanc ?

Nous pouvons obtenir la réponse en donnant un arrière-plan à la page parente :

body {
  background-color: lightblue;
}

Voir le code sur CodePen.

Comme vous pouvez le constater, l'iframe est transparente. Son body, son html et son canvas. On peut voir la page parente au travers.

Cela prouve-t-il vraiment que le canvas est transparent ? Peut-être que les iframes n'ont pas de canvas ?

C'est une question légitime. Pour y répondre, ajoutons un fond blanc à l'élément body de l'iframe :

body {
  background-color: white;
}

Voir le code sur CodePen.

Si l'iframe n'avait pas de canvas, la zone en dehors de son élément body ne serait pas remplie. Mais grâce au mécanisme du canvas, la couleur de fond du body peut être utilisée pour couvrir l'ensemble du viewport de l'iframe.

Et c'est ainsi que l'on montre que sur n'importe quelle page, le canvas par défaut n'est pas blanc mais transparent.

Ce que vous voyez quand vous ouvrez une page vide n'est donc pas un canvas blanc. C'est juste le « fond » du navigateur, l'arrière-plan du logiciel, en dehors du monde du CSS, qui n'interagit aucunement avec quoi que ce soit.

Et voici donc notre modèle (final ?) de ce que nous voyons :

l'élément body (transparent par défaut) ;
l'élément html (transparent par défaut) ;
le canvas (dépend du html et du body, donc transparent par défaut) ;
les fondations innaccessibles du logiciel (souvent un fond blanc).

Oh, et j'ai essayé d'en faire un dessin :

It's a small Hello World after all.

C'était sympa, ce petit voyage. Et oui, j'ai une vie.

CSS tourne beaucoup autour de ce que l'on voit, mais aussi beaucoup autour de ce que l'on ne voit pas.

Je ne suis pas « artisan développeur »

2019-08-03T00:00:00Z

Il y a quelques jours, j'ai reçu un message dans ma boîte de réception LinkedIn. Cette fois, pas d'offre sous forme de poème, pas de blagounette pseudo-disruptive. Même pas de Ninja ou de Rockstar developer à l'horizon. Mais un terme que je ne connaissais pas : celui de software craftsmanship (comprenez « artisanat du développement »).

Après m'être imaginé quelques instants artisan développeur, accueillant les touristes dans ma petite boutique à Saint-Paul-de-Vence (Entrez messieurs dames, attention où vous mettez les pieds, il y a des frameworks un peu partout je n'ai pas encore eu le temps de ranger !), j'ai quand même demandé à Google ce qu'il en pensait.

Et là, il y avait une fiche Wikipédia. Et si c'est sur Wikipédia, c'est bien que ça existe et que ça n'est pas une invention de RH en manque de sensations fortes. Quand on remonte à la source, on trouve un manifeste : celui des artisans du logiciel.

Le manifeste, publié en 2009 d'après le texte, 1450 d'après le design.

Ce qu'il est important de dire d'entrée de jeu, c'est que je suis parfaitement d'accord avec les principes énoncés ci-dessus. Je suis à peu près sûr que vous aussi. Alors pourquoi me fendre d'un article, me direz-vous ?

Prenez une seconde pour les lire. Avez-vous sourcillé une seule seconde ? Je parie que non. Est-ce que ce n'est pas étrange, un manifeste aussi évident ? Est-ce que ça ne cache pas un petit malaise quelque part ?

Pour moi, c'est simple : si ce manifeste est si banal, c'est parce que nous savons tous qu'il énonce ce que devrait être le développement tout court, et que l'artisanat n'a rien à faire là-dedans. Nous savons tous que si nous travaillons sans suivre ces principes, notre code ne vaut pas un clou.

Ce manifeste est un aveu d'échec : il prend acte de la situation médiocre de l'industrie, et invente un terme tout beau tout nouveau pour déplacer les bonnes pratiques dans un monde mythologique où les développeurs vivent en harmonie avec le client, les tests unitaires, le vaisseau de la Vierge Marie et le Christ Cosmique.

Qu'est ce qui peut bien amener une industrie à se voiler autant la face ? Ce n'est pas sur ce manifeste que j'ai envie de tirer, car je serai bien malhonnête de prétendre que je n'ai pas fantasmé moi-même sur ce terme d'artisan développeur. C'est plutôt sur ce qu'il dit de la situation.

Du calme les gens s'il-vous-plaît, ce n'est pas un logiciel c'est la volute d'un violoncelle, faut redescendre là.

Intéressons-nous au premier point, qui stipule le niveau de qualité attendu :

Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus.

Manifeste pour l'artisan logiciel

Une recherche ~~approfondie~~ Wikipédia nous permet de préciser ce qui est ici entendu : clean code, refactoring, tests automatiques, domain driven developement... Beaucoup de choses que peu de développeurs avec un minimum d'expérience remettront en cause.

Par exemple, les tests, c'est bien. C'est doux. C'est soyeux, même. Si vous n'êtes pas d'accord, on peut en discuter, mais on ne va pas en discuter, parce que vous êtes d'accord, non ?

Maintenant, deux situations personnelles :

Des fois, ça se passe bien

J'ai travaillé sur un projet de développement front de plus d'un an, donc nécessairement assez complexe, avec des règles métier dans tous les sens, 12 zillions d'interfaces... Mais un client au top, qui savait reconnaître l'investissement temporel (et donc financier) nécessaire à l'élaboration d'une telle structure.

Et ce n'est pas facile de trouver un client qui accepte pendant quelques mois, au début, de ne pas voir grand chose, parce qu'un tiers du temps est passé à mettre en place des fondations solides, un autre tiers à écrire des tests, et qu'il ne reste qu'un tiers pour faire émerger le produit « visible ».

Et donc des tests, j'en ai écrit des centaines. J'ai profité de ce contexte pour en faire une contrainte forte du projet. Pas un seul composant ne serait écrit sans être accompagné de sa batterie de test (il faut aussi savoir ne pas être dogmatique, en vertu de la loi de Pareto, mais c'est une autre histoire).

J'ai quitté le projet il y a un an, et son développement suit son cours, avec plus de 2000 tests au compteur. Bien sûr je ne dis pas que les tests seuls font la qualité d'un projet, c'est un exemple. Mais dans ce cas précis, ils ont permis d'atteindre une vitesse de développement élevée une fois la mise en place effectuée, et surtout d'assurer la stabilité du produit.

Le projet n'a pas explosé quand je suis parti, même si j'ai fait quelques incantations sur le côté pour me rassurer, il est vrai. Il n'a rencontré, à ma connaissance, aucune régression majeure. Et les personnes qui l'ont repris ont le confort de savoir que, malgré l'ampleur du projet, si les tests passent, c'est qu'elles n'ont probablement rien cassé. Elles peuvent continuer à le faire évoluer dans les conditions les plus saines possibles.

Cette image vient d'un site sur Dieu, mais pour moi Dieu et 2000 tests au vert c'est pareil, donc ça passe.

Des fois, ça se passe moins bien

J'ai travaillé sur un projet (comprendre : plusieurs projets) où les contraintes étaient telles que tout cela n'avait aucune chance d'émerger. Où chaque deadline était remplacée par une autre, où tout ce qui ne contribuait pas à facturer le client au plus vite était vu comme un mal au mieux nécessaire, au pire dispensable.

Ce genre de situation où, vous le savez bien, les tests sont les premiers sacrifiés. Où mentionner la possibilité d'en écrire, bien que ce soit notre responsabilité professionnelle, semble blasphématoire, et nous poserait presque en ennemi du livrable, en ayatollah de la qualité, en fauteur de troubles.

On osera peut-être vous répondre que les tests seront écrits plus tard, ce qui doit convaincre principalement ceux qui n'en n'ont jamais écrit. On osera peut-être remplacer dans votre esprit le Père Noël par ce fameux « sprint de stabilisation », mais si, il existe j'en suis sûr, il faut juste être patient.

Bref, ces situations existent, pour mille raisons, et il faut alors s'accrocher à son slip, car tests ou pas (et encore une fois ce n'est qu'une mince partie des bonnes pratiques), un rendu de qualité est attendu. Et donc ces bonnes pratiques, on jongle rapidement avec.

Si j'ai vite compris que certains projets ne feraient pas de place aux tests, j'ai pour ma part fait « vœu » de ne rien lâcher vis-à-vis des code review approfondies, dernier rempart contre le spaghetti code à mes yeux. Chacun sa technique pour sauver la qualité du projet en situation extrême.

Source : Geek and Poke

Spoiler alert

La première situation semble malheureusement bien rare. Et des projets frustrants qui ne me permettront pas d'appliquer ce que je sais sur les tests, le clean coding, la performance, l'accessibilité... Il y en aura bien d'autres.

Étais-je pour autant « artisan » développeur dans une situation, simple développeur dans l'autre ? Aurais-je dû être payé différement ? Étais-je meilleur ? Je ne crois pas.

À lire mes collègues, il semblerait que notre industrie ait le chic pour créer ces situations ubuesques, où la qualité est attendue côté résultat sans être considérée côté production. Alors forcément, il est tentant de fantasmer sur un monde meilleur, et ce n'est pas parce que j'attaque ce terme que j'attaque ceux qui l'ont inventé : j'ai bien l'impression qu'ils partagent mon sentiment.

Mais quand même, je vous avais dit que ça allait trop loin cette histoire.

Développeur, un noble terme ?

Mais non, je ne suis pas artisan développeur. Je suis développeur, et mon métier est de réaliser des applications dans des contextes parfois difficiles, mais sans jamais perdre de vue la qualité.

Et je pardonnerai les codes les plus sales à un développeur, car je connais les conditions qui le produisent, et peut-être même qu'un git blame révélera que j'en étais l'auteur, et que mon cerveau traumatisé aura effacé ce souvenir, par dignité.

Je pardonnerai moins le fatalisme, le jemenfoutisme, le relativisme, tous les trucs en « isme ».

De toute façon, vu le projet…

Non.

Le projet, il est peut-être réalisé dans des conditions apocalyptiques, mais c'est notre travail. C'est notre protégé, c'est ce PNJ qu'on doit amener en sécurité, même s'il se prend un coup de sniper toutes les 30 secondes, même si on a envie de lui tirer dessus nous-même.

Je ne suis pas fier de tous les projets que j'ai réalisés, mais je n'ai pas à rougir de l'effort que j'y ai mis et des objectifs de qualité que j'ai toujours gardé près de moi (sauf une fois mais j'avais mal dormi).

Peut-être que l'industrie va mal – je n'en sais rien, j'ai peu de repères. Mais tant qu'il y aura des articles de blog, des discussions à la machine à café pour savoir quel est le meilleur design pattern qu'on n'utilisera jamais, des sondages Twitter pour connaître la meilleure convention de codage, des conversations à rallonge sur Github, bref, tant que cette industrie continuera à employer des gens qui veulent bien faire parce qu'ils aiment cela, il y aura de l'espoir.

Le slogan des artisans développeurs est Élever le niveau. Alors oui, élevons-le, tous ensemble, pour que le développement garde ses lettres de noblesse et reste, qu'il soit artisanal, industriel, rigolo, ennuyeux, innovant ou profondément inutile, synonyme de qualité.

Amis développeurs, artisans ou non, unissez-vous !

Layout CSS : empêchez les frameworks d'englober vos composants

2019-06-26T00:00:00Z

CSS est difficile, à ce qu'il paraît. Mais avez-vous déjà essayé d'écrire du CSS en vous battant contre un framework qui modifie votre DOM ?

Le problème

Je travaille sur une interface simple : header, contenu, footer. Le header et le footer ont une taille fixe, et je souhaite positionner le contenu au centre de l'espace restant.

Ah, flexbox, mon vieil ami, ainsi nous nous retrouvons !

Moi-même (pas vraiment, c'est juste pour l'ambiance)

Me voilà donc avec cette implémentation simple :

<body>
  <header></header>
  <main></main>
  <footer></footer>
</body>

body {
  display: flex;
  flex-direction: column;
  justify-content: space-between;
}

Chacun des trois descendants directs du body a une bordure bleue. Jusqu'ici, tout va bien.

Je suis donc heureux, comme tout développeur front quand les choses s'alignent correctement.

Mais alors que l'application grandit, je réalise que je vais avoir besoin d'englober le main et le footer à l'intérieur d'un composant Angular unique, pour des raisons structurelles propres à l'application.

C'est alors que ma belle page se brise, et vous pouvez comprendre pourquoi en regardant la structure générée par l'apparition de ce nouveau composant :

<body>
  <header></header>
  <my-component>
    <main></main>
    <footer></footer>
  </my-component>
</body>

Hélas ! Flexbox ne s'intéresse à rien d'autre qu'à ses propres enfants directs, qui sont maintenant header et my-component.

Regardez les bordures bleues : le body n'a plus que deux enfants directs.

Ma première idée fut de faire de my-component un conteneur flex lui-même, mais je n'allai pas très loin avec cette idée.

my-component {
  flex-grow: 1;
  display: flex;
  flex-direction: column;
  justify-content: space-between;
}

my-component est un conteneur flex lui-même... Mais cela ne centre pas le bloc main pour autant.

Pensez-y un instant : comment vous y prendriez-vous ?

Une méthode douteuse

Je sais que vous n'y avez pas pensé un instant et que vous avez continué votre lecture. Je ne vous en veux pas.

Une méthode à laquelle je n'avais pas pensé avant d'écrire cet article est d'ajouter un pseudo-élément à my-component :

my-component::before {
  content: "";
}

my-component a désormais trois enfants : le pseudo-élément before, le main et le footer.

Voici le résultat en action !

Voir le code sur CodePen.

Il n'y a qu'à remplacer le contenu du pseudo-élément par une chaîne vide, et voilà ! Parfois, une solution un peu sournoise comme celle-ci est si simple qu'elle en devient attractive...

Une méthode plus propre

Mais ajouter un pseudo-élément juste pour tromper flexbox ne me paraît pas extrêmement propre !

Il y a quelques semaines, j'ai lu cet excellent article de Rachel Andrews : Digging Into The Display Property: Box Generation.

En lisant les informations à propos de display: content, j'avais deux pensées parallèles :

Ça alors, c'est fort intéressant...
...mais je ne vais jamais m'en servir.

Mais en travaillant sur mon problème de layout, l'article me revint à l'esprit. En voici un extrait :

La valeur display: contents retire la boîte (box) à laquelle elle est appliquée de l'arbre des boîtes (box tree), de la même façon que display: none, mais en laissant les enfants en place.

Rachel Andrews, Digging Into The Display Property: Box Generation

En d'autres termes, cela sera équivalent (dans notre cas !) à ce qu'il se passerait si l'on commentait l'élément (mais pas ses enfants) :

<body>
  <header></header>
  <!-- <my-component> -->
  <main></main>
  <footer></footer>
  <!-- </my-component> -->
</body>

Et voici comment procéder dans les faits :

my-component {
  display: contents;
}

Note : En réalité, certaines propriétés CSS (font-size, color...) appliquées à l'élément impactent toujours ses enfants. Donc commenter l'élément n'est pas strictement équivalent, mais vous avez l'idée.

Donc... Cela signifie-t-il que du point de vue de flexbox, main et footer sont de nouveau des enfants directs du body ? Oui ! my-component n'a plus besoin d'être un conteneur flex lui-même. La propriété justify-content: space-between appliquée au body fonctionne de nouveau.

C'est la solution la plus courte présentée dans cet article : un sélecteur et une propriété. Presque magique.

Voir le code sur CodePen.

Notez que la bordure bleue qui entourait my-component a disparu : en effet, la boîte n'est plus rendue, donc les propriétés correspondantes (margin, padding, border...) n'ont plus d'effet.

Bien que j'aime la belle simplicité de cette solution, display: contents possède ses inconvénients.

display: contents peut provoquer des problèmes d'accessibilité, car l'élément est caché de l'arbre d'accessibilité. Si vous l'utilisez sur un élément ul, l'information qu'il s'agit d'une liste sera perdue dans de nombreux navigateurs.

Ce n'est pas un problème dans notre cas, cependant, puisque my-component ne véhicule pas de sens sémantique particulier. Mais l'on pourrait toutefois se méfier du support navigateur, qui est dans cette zone grise que j'appelerai la zone meh....

Mise à jour 2024 : display: contents est désormais largement supporté, bien que caniuse.com rapporte toujours de nombreux problèmes d'accessibilité. À juger au cas par cas, donc.

Une méthode encore plus propre

Voici donc la technique margin: auto.

Ce n'est qu'en rédigeant cet article que je me suis souvenu d'un autre article, un des meilleurs que j'ai lu sur le sujet: Flexbox's Best Kept Secret, de Sam Provenza. Il date de 2015 et j'ai utilisé ce « secret » un grand nombre de fois depuis.

Quatre ans plus tard, je ne suis pas sûr qu'il soit bien connu. Mais vous pouvez utiliser margin-left: auto, pas exemple, pour « pousser » un élément flexbox aussi loin que possible vers la droite.

Voyez plutôt ce Codepen. L'élément de prix possède la propriété margin-left: auto.

Voir le code sur CodePen.

C'est extrèmement utile ! Avec cette technique, il devient possible de pousser un élément dans n'importe quelle direction, horizontale ou verticale.

Mais il y avait une partie de l'article que j'avais oubliée :

Si vous ne spécifiez pas de direction et que vous appliquez simplement margin: auto, l'élément distribura l'espace disponible des deux cotés, équitablement.

Sam Provenza, Flexbox's Best Kept Secret

Ainsi, le « secret » fonctionne aussi avec plusieurs marges auto.

Et la voici donc, cette merveilleuse solution à notre problème : faire de my-component un conteneur flex de nouveau, et utiliser margin: auto 0 sur l'élément main.

Mise à jour 2024 : Utiliser la propriété logique margin-block: auto nous éviterait d'avoir à spécifier le 0, qui m'a toujours un peu gêné...

my-component {
  flex-grow: 1;
  display: flex;
  flex-direction: column;
  justify-content: space-between;
}

main {
  margin: auto 0;
}

Et voici le résultat en action.

Voir le code sur CodePen.

L'espace libre est distribué équitablement entre le dessus et le dessous de l'élément main.

Pas de pseudo-élément magique. Moins de risque d'accessibilité et de compatibilité. Simplement la majestueuse et toute puissante flexpower™.

L'épopée du centrage vertical ne s'achève jamais.