Nico’s dreams - Blog et pensées d'un intégrateur/développeur web - Nicolas Hoffmann

De l’importance de rapports comme l’Accessibility Report 2026 de l’Email Markup Consortium

contact@nicolas-hoffmann.net (Nico) — Thu, 06 Aug 2026 17:16:22 +0200

Je ne saurais trop vous recommander de jeter un œil à l’Accessibility Report 2026 de l’Email Markup Consortium.

Chaque année, ce rapport passe en revue des milliers d’emails HTML et dresse un état des lieux de leur qualité, notamment du point de vue de l’accessibilité.

Le résultat est riche d’enseignements. On y trouve des erreurs très fréquentes, parfois étonnamment simples à corriger, qui peuvent pourtant améliorer significativement l’expérience des personnes utilisant des technologies d’assistance… et pas que.

Des corrections parfois très simples

Un exemple : les tableaux utilisés uniquement pour la mise en page devraient porter l’attribut role="presentation" (ou role="none").

Cela permet notamment aux lecteurs d’écran de ne pas annoncer inutilement la structure tabulaire et de restituer un contenu beaucoup plus naturel. C’est une modification assez simple dans le code HTML et peu risquée, mais qui améliore immédiatement l’expérience de lecture.

En parcourant les emails envoyés chez Proton, je me suis rendu compte que nous avions nous aussi ce problème.

J’ai commencé à le corriger progressivement. Aujourd’hui, tous les nouveaux templates respectent cette règle. Tout n’a pas encore été totalement repris, mais au moins, tous les futurs templates partiront désormais sur de bonnes bases.

Ces rapports ne servent pas qu’aux concepteurs de newsletters

À première vue, ce rapport s’adresse surtout aux personnes qui conçoivent des newsletters ou des campagnes marketing.

Mais il est également utile lorsque l’on travaille… sur un client mail, comme moi !

Une découverte inattendue

En parcourant le classement des erreurs les plus fréquentes, la première m’a interpellé.

Il s’agit de l’absence d’attribut lang sur les éléments html ou body.

Par curiosité, je m’envoie alors un email de test contenant ces attributs. Et là… horreur et putréfaction : je constate que Proton Mail Web les supprime lors du rendu.

Autrement dit, on pénalise les rares bons élèves. L’erreur n’était bien évidemment pas volontaire. Le correctif était relativement simple.

Il est déployé depuis quelque temps maintenant. Vous n’avez donc plus d’excuse pour oublier l’attribut lang… en tout cas chez Proton Mail.

Pourquoi j’aime ce type de rapport

Ce que j’apprécie particulièrement avec ce genre de rapports, c’est leur ancrage dans le réel. Bienvenue dans les ruines de la réalité !

Des points faciles à corriger et des infos qui permettent de voir là où je peux avoir beaucoup d’impact en peu de temps… c’est top, encore !

scrollbar-gutter: stable… qui ne l’est pas vraiment

contact@nicolas-hoffmann.net (Nico) — Wed, 05 Aug 2026 18:00:54 +0200

Je m’amuse depuis quelques temps avec scrollbar-gutter, cela me résout quelques soucis d’alignements et de stabilité d’interfaces dans des applications comme Proton Mail et d’autres.

`scrollbar-gutter`, c’est quoi t’est-ce ?

Depuis des années et pour des besoins de designs bien léchés si j’ose dire, certains cherchent à éviter les décalages de mise en page provoqués par l’apparition ou la disparition des barres de défilement. La solution historique consistait à forcer :

html {
    overflow-y: scroll;
}

Cracra, insupportable et disgracieux. Avec scrollbar-gutter, on pouvait enfin écrire :

html {
    scrollbar-gutter: stable;
}

L’idée semblait simple : réserver l’espace de la barre de défilement afin que la largeur de la page reste constante, notamment si une barre de défilement apparait dans une zone d’une interface.

Enfin… c’est ce que je pensais.

Une découverte étonnante

En utilisant cette propriété, un curieux quiproquoi (= un quiproquo et le dev dit « kewaaaa ? ») m’est arrivé. Tout fier de mon travail d’alignements divers et variés dans l’interface sur laquelle je travaille, j’envoie en test… et on me signale que l’alignement n’y est pas. « Kewaaaa ? »

En creusant un peu et en la faisant courte, j’ai remarqué un comportement étrange sur macOS. Avec une souris branchée, tout fonctionne comme prévu : la page réserve un espace pour la barre de défilement.

Puis je débranche la souris. Instantanément, toute la mise en page s’élargit d’une quinzaine de pixels. Pourtant, le CSS n’a pas changé, scrollbar-gutter est toujours appliqué.

Et pourtant… l’espace réservé a disparu. « Kewaaaa ? »

Le test

En regardant les dimensions du viewport, on obtient ceci.

Avec une souris connectée :

window.innerWidth                    // 1680
document.documentElement.clientWidth // 1665

La différence de 15 pixels correspond à l’espace réservé pour la barre de défilement. Okay.

Après avoir débranché la souris :

window.innerWidth                    // 1680
document.documentElement.clientWidth // 1680

La différence disparaît. Le viewport vient de gagner 15 pixels.

Toute la mise en page est recalculée. « Kewaaaa ? »

Ce n’est pas un bug d’un navigateur

Le plus surprenant est que le phénomène est reproductible dans :

Safari
Chrome
Firefox

Les trois navigateurs se comportent de la même façon. Plus moyen de pester contre l’un ou l’autre, c’est un complot. Plus sérieusement, cela suggère qu’ils suivent tous le comportement fourni par macOS.

Pourquoi ?

Le diable se cache dans les détails, en l’occurence, dans la spécification de scrollbar-gutter.

scrollbar-gutter: stable ne signifie pas :

« Réserve toujours un espace pour la barre de défilement. »

Cela signifie plutôt :

« Réserve un espace lorsque des classic scrollbars existent. »

Or macOS utilise deux types de barres de défilement :

les classic scrollbars, qui occupent de l’espace dans le layout ;
les overlay scrollbars, qui sont dessinées par-dessus le contenu.

Et macOS peut passer dynamiquement de l’une à l’autre.

Par exemple lorsque l’utilisateur branche ou débranche une souris, si le réglage système est « Afficher les barres de défilement : automatiquement selon la souris ou le trackpad ».

Lorsque le système passe en mode overlay, le gutter n’a plus de raison d’exister selon la spécification.

Le navigateur le supprime. La page change alors de largeur.

Le problème

Le mot stable est, selon moi, trompeur. En tant que développeur, je comprends naturellement :

« Si j’utilise cette propriété, ma mise en page ne bougera plus à cause des barres de défilement. »

En réalité, ce n’est vrai que tant que le système continue d’utiliser des barres de défilement classiques.

Le moindre changement de mode peut provoquer un recalcul complet de la largeur du viewport. Cela entraîne :

des layouts qui se décalent horizontalement ;
des éléments centrés qui changent de position ;
des calculs basés sur la largeur du viewport qui évoluent ;
des interfaces qui « sautent » sans que le CSS n’ait changé.

Et surtout du travail supplémentaire pour moi… vous me voyez coder en branchant et débranchant ma souris régulièrement ????

Autrement dit, scrollbar-gutter: stable n’est pas réellement stable dans tous les cas. Et quand on doit gérer des alignements fins entre éléments qui sont dans des zones scrollables ou non… point de salut ainsi, il faut trouver des solutions plus tordues.

Que pourrait-on faire ?

Je comprends pourquoi la spécification a été écrite ainsi. Mais je pense qu’il manque aujourd’hui une façon d’exprimer une intention différente :

« Je souhaite réserver un espace pour la scrollbar, quel que soit le mode utilisé par le système. »

Par exemple avec une valeur comme :

scrollbar-gutter: always;

ou tout autre mécanisme permettant de garantir que la largeur du viewport de mise en page ne changera jamais. Aujourd’hui, ce n’est tout simplement pas possible, en tout cas pas avec scrollbar-gutter. Tristitude.

Conclusion et à suivre

Bref, j’ai sacrifié un châton innocent, et ouvert un ticket auprès du CSS Working Group, pour savoir s’il serait pertinent d’introduire une manière de demander un gutter réellement… stable.

CSS is awesome, je me tape des scrollbars de rire.

CSS et faire de l'UI, c'est facile

contact@nicolas-hoffmann.net (Nico) — Wed, 25 Jun 2025 16:10:28 +0200

Je retrouve de vieilles notes et autres pensées, je les complète et je les publie petit à petit. Ici c’est un thread que j’avais posté sur feu Twitter, je le reposte ici.

Bah, CSS et faire de l’UI c’est facile, c’est même pas un vrai métier :

tu as testé en dark mode ?
en « light » mode ?
si ça respecte les préférences de l’utilisateur en dark/light mode ?
avec un fort zoom ?
avec un fort zoom texte ?
avec une combinaison des précédents ?

On respire.

si ton viewport est petit ?
si ton viewport est immense ?
si ton viewport est large mais très peu haut ? (mortel celui-là)
si ton viewport est étroit mais haut ?
de manière générale, quel que soit le viewport, ça passe côté responsive ?
sur tous les navigateurs ?
sur tous les systèmes ?
sur Safari Mobile ?
sur Android ?
sur Palemoon ? (NON)

On respire…

sur des périphériques improbables, consoles de jeux, liseuses, etc. ?
avec des contenus utilisateurs totalement improbables ?
si la structure change ou est reprise ailleurs, ça pète ?
si les effets de bords de ta modif font des dégâts ?
à propos, c’est scopé correctement ?
si ça passe à l’impression ?
si en « high contrast mode » ça déconne pas ?
si ton composant se retrouve dans n’importe quel contexte ?

Mais il est fou.

si ton composant se retrouve imbriqué dans un autre ?
et au fait, le code CSS est léger ?
et compréhensible ainsi que maintenable ?
et ça déclenche pas trop de reflow/repaint au fait ?
et ça s’affiche vite ?
et bien sûr, les contenus cachés ne sont plus focusables ?
les anims sont fluides ?
les transitions aussi ?
et les contenus cachés par transitions/animations ne sont plus focusables ?
et si on désactive les animations, ça le prend en compte ?
et c’est skinnable si jamais ?

Si si.

et le(s) fichier(s) générés sont légers et rapides ?
et ça matche avec les directives CSP ?
et si on change la langue de l’interface, ça ne déconne pas ?
au fait, en RTL, ça passe ?
et en mixant des contenus LTR et RTL, ça passe ?
et avec des caractères à la con qui inversent la direction du texte, ça passe ? (mortel celui-là)
et ton interface passe bien quand il y a tous les composants dans le pire des cas ?
et quand il y a rien ?
et ton interface avec beaucoup de contenus/très peu de contenus, ça roule ?
etc.

On est d’accord : tout n’est pas strictement nécessaire ni même souhaitable, mais toutes ces petites choses peuvent faire partie du métier. Je ne les ai pas toutes listées, mais je me suis déjà frotté à chacune, et certaines ne sont vraiment pas faciles.

Et arriver à les faire toutes, c’est un vrai challenge, vous invitant à énormément d’humilité.

Pour les gens qui pensent que ça n’est pas un vrai métier, je vous pisse au cul avec une paille de 500 mètres sans toucher les bords.

Un coup de sang salvateur

contact@nicolas-hoffmann.net (Nico) — Thu, 15 May 2025 19:14:43 +0200

Je retrouve de vieilles notes et autres pensées, je les complète et je les publie petit à petit.

Comme vous avez pu le voir, je me suis quelque peu éloigné de Twitter depuis un temps certain, principalement pour des raisons de santé mentale.

Je me posais des questions :

fermer ou pas mon compte,
supprimer ou non mes tweets (plus de 46 000 quand même),
etc.

Sans compter environ 3 000 followers, et qu’une bonne partie de mon réseau s’est fait sur Twitter, même si j’avais l’impression que le reach (la capacité à atteindre ces followers) était vraiment devenu naze depuis quelque temps. Bref, incapable de prendre une décision ferme, hormis celle que j’avais déjà prise : m’en éloigner.

Quoi qu’il en soit, je ne suis pas trop du genre à suivre les gros mouvements de mode, genre « on va quitter telle plateforme, et se retrouver sur telle autre », qui inévitablement va devenir une réplique peu ou prou de la plateforme honnie — en général les mêmes consommateurs produisent les mêmes conséquences — ni à avoir de gros coups de sang.

Et soudain, je tombe un matin à la fraiche… sur le double salut nazi.

Autant le dire de suite, je suis entré dans une rage comme j’en ai rarement eu ! En 5 minutes, la décision ferme de tout virer de ce réseau était prise, et je n’ai pas pu calmer cette colère avant que la suppression soit effective. Après plusieurs essais infructueux, je me suis tourné vers le logiciel Cyd, qui a magnifiquement fait le job.

Le 21 Janvier 2025, j’ai brûlé sans aucun répit plus de 46 000 tweets accumulés sur des années, dans un feu de joie salvateur. Je crois qu’il en reste 4 ou 5 dont un annonçant mon départ, que je virerai d’ici quelque temps. J’hésite à finir de clore le compte, principalement pour des usurpations d’identité.

Que garder de cet épisode ?

Je ne sais pas si c’est partagé, mais vous pouvez encore une fois voir qu’il est possible de décider de dégager. Vous avez toujours le choix. Et quoi qu’on en dise, auto-héberger vos contenus comme je le fais ici ne vous rendra pas tributaire de ces aléas.

Je ne suis pas totalement opposé aux réseaux sociaux, mais évidemment, je deviens beaucoup plus méfiant pour ce qui est d’y investir mon temps. Qu’est-ce qui me prouve que l’un ou l’autre ne va pas devenir un dépotoir possédé par un naze ? Réfléchissez bien avant de me dire « oh, ça n’arrivera jamais », Twitter était quand même un monument où tout se passait. Regardez ce que c’est devenu.

On ne m'empêchera pas de penser que ces réseaux nous font plus travailler qu'ils ne travaillent pour nous, parfois avec l'aliénation incluse. Allez donc faire un tour sur LinkeDingue, le bullshit débilitant y atteint des niveaux stratosphériques (faudrait que je fasse un billet dessus un de ces jours).

Et à ceusses qui trouvent des excuses à l'autre naze, ce n'est même pas la peine de venir discuter, c'est pitoyable (soutien aux partis d'extrême-droite, saluts nazi, etc.). Et autant vous dire que je ne suis pas près d'acheter Tesla et consorts. Pire, ceux qui le glorifient devraient sérieusement revoir leurs idoles.

Une petite surprise à propos de max en CSS

contact@nicolas-hoffmann.net (Nico) — Tue, 04 Mar 2025 15:11:37 +0100

Je partage une petite mésaventure qui m’est arrivée en CSS, il est fort probable que je ne sois pas le seul qui puisse commettre de bonne foi cette erreur (un piège facile en sorte).

L’autre jour, je me retrouve à utiliser max en CSS pour effectuer une adaptation de Proton Calendar pour des écrans gigantesques (ou si on dézoome fortement).

Grosso modo, le code en question est (le détail de la valeur n’est même pas important) :

block-size: max(3rem, calc((100lvh - 3.75rem - 4.75rem) / 24))

En clair, prends-moi la valeur maximum entre les deux valeurs, ce qui m’assure que si l’écran n’est pas gigantesque, l’élément en question fera au moins 3rem quoi qu’il arrive. Rien de bien extraordinaire, je me dis que c’est même assez bulletproof — en anglais dans le texte, construit ainsi en amélioration progressive. Personne ne trouve à redire.

Quelques jours plus tard, je reçois des retours, quelques utilisateurs ont des soucis. J’investigue un peu, et je me rends compte que ce sont de vieux navigateurs qui pêchent (des Firefox/Chrome 87 ou des Safari 15.x). Là, j’avoue que je suis surpris : cette syntaxe me parait pourtant à l’épreuve des balles. Quand bien même les navigateurs ne supporteraient pas l’unité lvh, max entre 3rem et un truc pas supporté, c’est 3rem qui gagne, logiquement.

Je fouille un peu dans la spécification, ouvre une question sur le CSS Working group, et là… surprise motherf***** !

En fait, si une des valeurs renvoie failure, l’intégralité de l’expression renvoie failure. En clair pour mon cas, si les lvh ne sont pas supportés, kaboom, la comparaison avec max foire totalement !

J’avoue avoir été surpris ! Ceci dit, le fix a été simplement d’entourer la version avec un @supports avec ce qu’il faut dedans :

block-size: 3rem;
@supports ( block-size: ( max(1rem, 100lvh) ) ) {
  block-size: max(3rem, calc((100lvh - 3.75rem - 4.75rem) / 24))
}

Comme quoi, on a toujours des surprises…

Bref, j’ai fait une miam-list

contact@nicolas-hoffmann.net (Nico) — Wed, 22 Jan 2025 15:54:16 +0100

Fin 2022, lors d’une discussion après le repas du 31, tombe le sujet des bonnes résolutions.

Marronnier par excellence, mais j’avoue que je n’ai pas vraiment d’idées. Et puis bon, les bonnes résolutions… je sais très bien que je ne vais pas forcément les tenir sur la durée.

Me vient une idée pas sortie de la cuisine à Jupiter (Coluche) : je balance à mes proches que je ne prendrai aucune bonne résolution, mais que je vais me faire une miam-list. En clair : une liste de trucs que je dois cuisiner maison durant l’année suivante.

Cela peut être des choses simples, ou des choses nécessitant plus de travail. Bref, je teste, et le concept m’a bien fait marrer :

C’est rigolo (et ça me détend, pas besoin de npm install pour cuisiner…)
Cela ajoute diverses cordes(ons bleus ?) à mon arc de père isolé
Et vu les gourmands qui m’entourent… je sais que l’initiative sera suivie et appréciée. J’ai eu des demandes même.

Celle de 2023 a été plutôt un succès : une vingtaine de plats/pâtisseries préparées sur la liste, quelques uns non-faits, un ratage en tout et pour tout, et avec des rajouts en impro.

En langage chef de projet : complétion des OKRs supérieure à 80%, avec des items non planifiés (t’as vu, ça claque).

Bref, je renouvelle cela en 2024, toujours amusant, et j’en arrive à celle pour cette année.

Liste plus ambitieuse que l’année précédente, cependant avec des éléments vraiment faciles…

Et comme toute liste, le premier a avoir été fait a été… un non-prévu — on frise vraiment la métaphore chef de projet là !

De l’humilité pour les applications addictives

contact@nicolas-hoffmann.net (Nico) — Wed, 20 Nov 2024 10:14:16 +0100

Je retrouve de vieilles notes et autres pensées, alors je vais les publier petit à petit. Précision pour celle-ci, elle a été écrite avant le rachat de Twitter par le zinzin qui le possède actuellement — et avant que bon nombre de gens l’aient fui. Et oui je dis Twitter, car le nouveau « nom » pourrait changer quelque peu le sens de la phrase suivante, et… ce nom nouveau est débile.

Retour dans un passé pas trop lointain.

J’avoue, j’étais assez accro à Twitter. Notamment pour la veille, le côté instantané et efficace de chopper de l’info ou de pouvoir pinger des gens, le côté micro-blogging, etc., et toujours un onglet épinglé avec.

Toutefois, plusieurs événements — une shitstorm délirante, une agressivité de plus en plus palpable, etc. — m’ont vraiment fait réfléchir sur le côté détestable/meute enragée des réseaux sociaux.

La problématique était : j’adore Twitter et je dois m’en éloigner, comment faire ?

J’ai pensé à bloquer les personnes les plus virulentes, etc. même si ça calme bien ça ne résout pas le problème. Et une bête idée m’est venue : je repensais à l’expression de Tûtie dite de « la barrière de flemme », notamment évoquée dans une de mes conférences préférées : la tempête de boulettes géantes.

Et je me suis dit : tiens, et si j’essayais. Virer l’onglet épinglé, virer le raccourci sur le téléphone, ou planquer ce dernier dans un dossier sur la tablette. Mettre le truc à une distance de l’immédiateté, aussi courte soit-elle.

Vous ne le croirez peut-être pas… mais ça marche ! Certes, il m’arrive d’y faire un petit tour de temps en temps, mais cette simple distance évite de gaspiller le temps de cerveau en mode zombie. En gros, il faut faire l’effort d’y aller.

Ensuite, je me suis lancé quelques règles débiles, notamment « au troisième tweet qui en grosse colère contre quelque chose » (justifié ou non, ce n’est même pas la question), je clos l’app. Autant vous dire que celle-ci est vraiment marrante. Si vous avez le FOMO (la peur de louper quelque chose), elle a tendance à vous en guérir : que vais-je louper ? Bah, de la probable agressivité.

Là où cela m’interpelle, c’est en tant que concepteur d’interfaces — ouais je suis un UXE — j’entends souvent des discours sur les app addictives, etc. et aussi addictives soient-elles, j’invite les personnes qui conçoivent/possèdent ces apps à avoir beaucoup d’humilité. Aussi incroyable leur design, communauté, expérience, etc. puissent être… elles peuvent être mise au ban pour une simple icône disparue, sur laquelle vous n’avez aucune main mise.

Retour dans le présent.

Bref, au vu de ce que Twitter est devenu récemment, je me dis que finalement, c’était plutôt une bonne idée. :-D

Vous souvenez-vous du futur, deuxième ?

contact@nicolas-hoffmann.net (Nico) — Wed, 24 Apr 2024 22:09:16 +0200

Petit préambule.

Il y a 10 ans, pour fêter l’anniversaire de ce site, je me payais un délire de faire causer mon moi de 2014 avec celui de 2004 (autant le relire, car vous risquez de ne pas tout comprendre). Et à la fin, je termine sans réfléchir sur un gag qui fait intervenir mon moi de 2024.

Vous savez ce qui est drôle avec les gags ? C’est qu’ils se réalisent… nous sommes en 2024, et ce blog a 20 ans. Un peu rouillé et attendant une refonte depuis longtemps, mais toujours vaillant.

En emphase, il y aura parfois mon avis, mais quelque chose que je ne peux pas dire sans risquer de faille du continuum-espace temps. Hypothèse la plus pessimiste, le phénomène pourrait être localisé à notre seule galaxie.

Pour simplifier cette histoire de fous, Nico de 2024 sera abrégé N24, etc.

La discussion

— N24, tape sur l’épaule : hé, 20 ans, je te raconte pas ! (putain, j’avais qq kilos de plus)
— N14 : Nom d’un cul de canard dans ma baignoire !!!!!!!! Je ne veux rien savoir. Rendez-vous dans dix ans.

N24 : dix ans plus tard, c’est là ! (voila, tu voulais faire le gag de la Delorean qui vole dans Retour vers le futur 1, tu l’as bien mérité)
N04 : QUOI ?

N24 : bah alors vieux, enfin, jeune, on flippe ? (putain, j’avais qq kilos de plus)
N14 : pas possible… continuum… (tombe dans les vapes)
N24 : hé oui, à défaut de briser le continuum espace-temps, une blague revient toujours à l’envoyeur, cochon qui s’en dédit !

N04 : c’est une blague ? Tu es en train de me dire que ce site existera encore dans 20 ans ???
N24 : et pourquoi pas ? (et merci pour moi jeune con, je passe après le site, sympa le merdeux !)

N04, en panique : mais mais mais, ça doit être fait avec des technos ultra-modernes et j’ai dû bien le refondre au moins 100 fois !
N24 : mais pourquoi tu cherches compliqué ? Je t’entendais discuter avec l’autre évanoui là, vous… enfin je… bref nous parlions des standards. Tu sais ce que ça veut dire la compatibilité future ?
N04 : biiiin, j’ai bien lu un article sur Openweb maiiiiiis…

N24 : mais quoi ? Allez, crache mon petit ! (putain, j’avais des cheveux y a 20 ans)
N04 : bin, celui de 2014 avait l’air d’avoir des réserves sur le coup de XHTML et XML.
N24 : sans trop t’en dire, je peux te dire que cet article ne raconte vraiment pas que des conneries. Évidemment, ça n’évolue jamais exactement de la manière dont on le pense, mais ça c’est normal. Et bien sûr, je ne t’en dirai pas plus. (bin 20 ans après, ça tourne encore, même si plus personne ne connait ce délire, hormis quelques vieux briscards)

N04 : bin merde alors. Dire que j’implémentais un nouveau truc XML dont je n’étais pas sûr…
N24 : à quoi tu penses ?
N04 : bin y a bien ce truc là, j’avoue que je me suis amusé, c’est un peu à la mode, ça s’appelle un flux RSS. Ça m’a l’air simple mais je suis pas certain d’en comprendre la portée.
N24 : c’est très bien d’essayer des nouveaux trucs. (woupinaise, et dire que c’est peut-être un des trucs les plus beaux qui aient jamais été faits, et dire que je m’en sers encore et que TOUT le monde adore ça même si ça a un peu perdu en visibilité)
N04 : ça m’a l’air un peu gadget, j’avoue que j’ai un peu fait comme les autres.
N24 : oui, je m’en souviens, t’inquiète. Non, c’est très bien d’essayer des trucs, tu peux me croire. Tu verras bien si ça mord. (au moins les modes étaient moins débiles à cette époque, putain, le gamin il vient de me coller une claque… roooh, je parle comme un vieux con)

N04 : qui vivra verra… putain, 20 ans !
N24 : arrête, on dirait Chirac aux Guignols de l’info (et dire qu’il est mort, les Guignols aussi)
N04 : au moins, je me suis amusé à essayer la dernière Mandrake.
N24 : héhé, je ne m’en souvenais plus. C’était amusant ces duals boots ? (c’est vrai que je racontais tout et n’importe quoi sur le blog)
N04 : oui, avec Mozilla, Firefox 1, et tout le nécessaire.

N14 : (sort des vapes) punaise, ou suis-je ?
N24 : j’ai plus l’habitude, faut dire que maintenant que Linux est inclus dans Windows, et Firefox, j’utilise toujours, mais bon, j’ai arrêté de compter les versions après la version 100…
N04 : QUOI ? LINUX INCLUS DANS WINDOWS ? Firefox 100 ?
N24 : oui, 120 et quelques. Un souci gamin ? Tu es pâle.
N04 : (tombe dans les pommes)

N14 : mais sérieux ! Ça va pas de raconter des âneries pareilles !
N24 : héhé… oups ! (bah quoi, j’ai pas menti, le WSL ?)
N14 : et le continuum espace-temps, abruti ?
N24 : bin, je me suis dit « on s’en balance », t’aurais vu sa tronche… et la tienne !
N14 : bougre de crétin irresponsable ! Et s’il y reste, on devient quoi nous, t’y as pensé ?
N24 : ok, tu marques un point. (putain, se prendre un « irresponsable » de moi plus jeune, ça c’est de l’achèvement)

N14 : déjà que j’essayais de ne pas trop lui en révéler. Tu imagines le choc si je lui parlais media-queries, Röcssti, Van11y ou qu’il va monter sur scène dans les conférences ?
N24 : indubitablement. (mon pauvre, je pourrais te faire flipper encore plus !)
N14 : et tout s’est un peu précipité y a deux ans.
N24 : c’est pas faux.

N14 : au moins, rassure-moi, ça va continuer de progresser ?
N24 : par certains côtés oui, par d’autres, je serais plus circonspect.
N14 : tu parles de Chrome qui monte inexorablement ?
N24 : effectivement, c’est pas la chose la plus glorieuse. À se demander si les gens ont une mémoire. (et c’est encore pire maintenant)
N14 : des monopoles comme IE6 ? Non.
N24 : et pourtant, le gamin avait compris bien malgré lui les dégâts d’IE6.
N14 : il y a été confronté oui.
N24 : encore maintenant, je m’étonne que rajouter une classe flex puisse résoudre des problèmes par magie.
N14 : parle pour toi, je peux pas encore utiliser flex comme un cochon moi !
N24 : (et m…) bah tu peux mais avec des réserves pour les vieux navigateurs. (vite, se rattraper aux branches)

N14 : effectivement. Ceci dit, la communauté se bouge, c’est sympa.
N24 : sans aucun doute. (pinaise, c’est vrai c’était une certaine époque entre les confs et le reste)
N14 : c’est qu’on rêvait de faire venir Tim Berners-Lee à Paris Web en sortant des conférences.
N24 : c’est pas facile hein ? Enfin… (ne pas lui dire qu’il va le rencontrer en 2023 et même présenter devant lui, ne pas lui dire…)
N14 : et au moins les réseaux sociaux donnent une saine émulation. Pourquoi tu t’étouffes ?
N24 : disons que les réseaux sociaux… évolueront étrangement à l’avenir. (comment lui expliquer qu’il va en fuir certains pour des raisons de santé mentale ?)

N14 : en bien ou en mal ? C’est que j’aime bien Twitter moi.
N24 : joker. (en mal !)
N14 : rassure-moi, les gens sont toujours là au moins ?
N24 : majoritairement oui. Ça évoluera. (j’ai la sensation qu’on n’a jamais été aussi seuls mais bon…)

N04 : (sort des vapes)
N14 : tiens, respire un bon coup gamin. Tu as tourné de l’œil, c’est pas grave.
N24 : ça va vieux ? Enfin jeune.
N04 : ça va. Là, j’avoue que je suis dépassé.
N14 et N24 : oui, ça autant t’y habituer…
N04 et N14 : ça fait peur des fois ce sentiment.

Les trois se regardent avec un sourire.
N24 : oui, ne vous inquiétez pas pour ça. Apprenez, vivez, faites ce qui vous semble juste, fussé-ce être de la poésie ou bloguer sur des choses insignifiantes mais si importantes. Le temps est sans importance, seule la vie est importante.

Note du Nico de 2024 : même si le blog est très calme depuis plusieurs années, la-vie-toussa, 20 ans de blog, ce n’est pas rien. Un espace de liberté, intemporel, délicieusement imparfait, rouillé mais aussi durable… chapeau les gars. Je pensais revenir dans le passé en conquérant blagueur, et c’est vous qui me redonnez cette flamme : le gamin m’a rappelé cette passion, et l’autre me rappelle tout le chemin parcouru. Même si j’ai appris une certaine sagesse, finalement… vous z’êtes pas mal les gamins.

Nico de 2034, passe une tête par la fenêtre : dites les gars, j’ose vous parler de la suite ?
Les Nico de 2004 à 2024 : OH LE CON !!!

On remet ça dans 10 ans, peut-être.

Putain 20 ans !

contact@nicolas-hoffmann.net (Nico) — Mon, 22 Apr 2024 10:50:05 +0200

Hé oui, ce site a 20 ans… et deux jours.

En attendant, si vous avez envie d’envoyer un pied de nez aux gens qui vous disent que PHP ou autres CSS sont morts et qu’il faut forcément passer par une plateforme ou je-ne-sais-quelle-techno qui lave plus blanc que blanc… hé bien, ça tient encore la route pour de l’ancien.

Une petite surprise est en préparation, je suis en train de la finaliser.

Note de lecture : La Légion Zodiaque, Légendes d’Illuminaria

contact@nicolas-hoffmann.net (Nico) — Mon, 24 Jul 2023 14:59:22 +0200

J’ai eu le plaisir de recevoir le livre de David « Deltakosh » Catuhe, intitulé « La Légion Zodiaque, Légendes d’Illuminaria ».

Que dire ?

J’avoue que le travail de David sur les chevaliers a attiré ma curiosité, revisiter les mythiques chevaliers d’or n’est pas un pari facile : il touche à des icônes, n’importe quel fan a forcément son chevalier préféré, ou plusieurs (Kanon et Shaka pour ma part, même si j’aime bien Aldébaran et Manigoldo/El Cid).

En fait, cela va plus loin. En lisant ce livre, on se rend compte que l’auteur a imaginé un monde plus grand, différent. On n’en voit actuellement que quelques bribes, mais il y a un petit quelque chose qui fait… qu’on a envie d’en savoir plus, probablement la narration indirecte. (et une certaine passion personnelle pour la mythologie grecque)

En tout cas, le livre est de très belle facture : les illustrations sont magnifiques, les textes sont courts mais soignés, l’objet ne dépareillera pas dans une belle bibliothèque.

En conclusion, je reviens sur ma précédente phrase : on a envie d’en savoir plus, mais genre vraiment plus.

Petit message personnel : David, si tu as besoin d’un relecteur de type grammar-nazi ou d’un autre acolyte pour explorer Illuminaria… je suis ton homme. ;)

Pour en savoir plus, La Légion Zodiaque, Légendes d’Illuminaria, sur Amazon ou sur le site de David.

Addendum : si par hasard, vous aimez le podcast de la Confrérie, peut-être avez-vous entendu les (més)aventures de la création de ce livre, où l’auteur — non sans un certain humour — relate les obstacles de la genèse de cet ouvrage : la confrérie, la création de livre.

D’autres épisode relatent des histoires toutes plus amusantes les unes que les autres avec le livre en toile de fond, comme Plongée dans un forum 18-25 et le top 3 de nos jeux les plus marquants.

Je n’écoute que très peu de podcasts, mais j’avoue que celui-ci m’accompagne souvent, je suis en train de les rattraper à reculons. Bon boulot les gars !

Focus-visible, la pseudo-classe qui met presque tout le monde d’accord

contact@nicolas-hoffmann.net (Nico) — Mon, 05 Dec 2022 14:52:19 +0100

Toute belle histoire commence par…

Il était une fois

Il y a bien longtemps (pas tant que ça mais bon), à chaque fois que vous cliquiez sur un bouton, vous pouviez entendre un ou une PO/utilisateur/designer/dev/autre dire :

« Oh, cette vilaine bordure bleue ou noire est-ce qu’on pourrait l’enlever ? »
Mais c’est nécessaire pour les utilisateurs de clavier !
Oui mais c’est moche, on peut l’enlever ? À propos, je n’utilise pas mon clavier.
(ton qui monte) C’est nécessaire pour les utilisateurs de clavier !!!
Oui mais c’est laid, on peut l’enlever ? À propos, je n’utilise pas mon clavier.
Etc.

La cause principale de ces discussions interminables était la suivante : cliquer sur un élément active les styles de focus, comme avec le clavier.

Il était impossible de différencier un bouton activé via une souris ou un clavier (les deux avaient des styles de focus déclenchés), sauf avec des tonnes de JavaScript à coup sûr. En général, cela se finissait par un drame, un bon gros outline: 0 des familles, soit la suppression complète et entière de l’indicateur visuel pour le clavier. Nigro notanda lapillo.

C’est là que :focus-visible, anciennement appelé :focus-ring (l’idée n’est vraiment pas récente), entre en jeu pour sauver nos âmes.

Le besoin

L’un des besoins les plus élémentaires lors de l’utilisation d’un clavier est de pouvoir savoir où vous vous trouvez dans l’interface.

S’il n’y a pas de surbrillance visible de l’élément actuel, l’utilisateur peut se perdre, la navigation devient vraiment pénible et une opération simple comme atteindre un lien nécessite soudainement une attention folle… ou n’est tout simplement pas possible.

Dans le langage expert de l’accessibilité, si je ne me trompe pas, dans les WCAG, c’est le Success Criterion 2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible (traduction approximative : toute interface utilisable au clavier a un mode d’utilisation où le focus clavier est visible).

En pratique

Avant, on doublait les styles entre :focus et :hover, et on priait pour que ça passe côté produit sans prendre de remarque comme au début de cet article.

Là, on peut se permettre de totalement virer l’outline au :hover, et de bien renforcer ce dernier avec :focus-visible.

Quelque chose comme :

.mon-button:focus {
  outline: none;
}
.mon-button:focus-visible {
  outline: 3px solid chartreuse;
  // je ne peux être tenu responsable du choix de cette couleur.
}

Comment `:focus-visible` marche

Même si l’on pourrait croire que c’est de la magie… il n’y a aucune magie là dedans. Grosso modo, le navigateur utilise certaines heuristiques pour déterminer si – selon lui – l’utilisation doit déclencher :focus-visible ou non.

TLDR : si l’utilisateur utilise le clavier.

En réalité, c’est un peu plus complexe : je vous conseille de lire la spécification de :focus-visible.

Je ne vais pas tout détailler, d’autres l’ont bien fait comme How do browsers determine when something is :focus-visible?, mais je m’arrête sur un exemple, les formulaires.

On pourrait se dire assez légitimement « si je clique sur un champ de formulaire, :focus-visible ne sera pas activé ». Sauf que non ! Si un élément – comme un champ de formulaire – a besoin du clavier pour fonctionner, il activera :focus-visible, qu’on clique dessus ou qu’on l’atteigne au clavier.

En pratique, cela se gère très facilement.

C’est pour cela que je vous invite à lire la spécification et à tester. D’expérience, j’ai vu quelques cas qui ont du sens une fois la spécification lue, mais qui peuvent surprendre (si une modale apparait subitement au lancement du site avant que l’utilisateur n’ait pu interagir, etc.).

La compatibilité

Le support est excellent sur les navigateurs récents : :focus-visible sur Can I Use. Le souci est comme d’habitude IE11 (mais on s’en fout) et quelques vieux Safari, à vous de voir si vous vous en foutez ou non.

Là où c’est gênant avec ces Safari, c’est que comme ils ne reconnaissent pas du tout :focus-visible, ils décident de purement ignorer la ligne… et parfois d’autres lignes factorisées avec. Ce qui amène à des commentaires amusants.

Au pire, vous avez un outil magique pour déployer en douceur : @supports selector(:focus-visible) {. En clair, si :focus-visible est supporté, alors… faire quelque chose.

Il a pu m’arriver de le déployer en douce, et – constatant que personne n’avait rien trouvé à redire en 6 mois – d'annoncer fièrement que c’était en production depuis une demi-année sans que personne ne s’en soit jamais plaint.

Pour conclure

Cette pseudo-classe est un régal à utiliser, et elle permet enfin de concilier demandes de designs et accessibilité, voir de même séparer totalement l’expérience clavier du reste. Albo notanda lapillo.

Ces modifications simples (custom scroll via CSS)

contact@nicolas-hoffmann.net (Nico) — Thu, 02 Jul 2020 15:32:11 +0200

Dans la suite directe du billet expliquant qu’estimer est difficile/impossible, voici un récent exemple de modification que j’estimais simple, mais qui ne l’a pas été.

Pour certains conteneurs sur ProtonMail V4, on a la possibilité d’activer un scroll légèrement customisé via CSS. Le tout est fait à coups de scrollbar-width, scrollbar-color pour les navigateurs le supportant, et à coups de ::-webkit-scrollbar et ses amis pour les autres. Cela remplace avantageusement des solutions via JavaScript utilisées sur la précédente version qui posaient autant de problèmes qu’elles en résolvaient (incompatibles avec le zoom ou de faibles hauteurs notamment).

La demande est simple : il faut l’activer par défaut partout. De totale bonne foi, je fais un rapide calcul :

créer une variable pour l’activer ou non ;
la mettre dans le fragment Sass.

Ok, pas de souci, c’est vraiment facile à faire, je prévois de faire ça en une petite heure.

Effectivement, je fais ces modifications très rapidement… et je teste vite fait. Pas de souci, ça s’active bien par exemple sur la page d’accueil du Design System de ProtonMail.
Je fais un tour rapide sur les pages. Cela va être vite réglé. Que pourrait-il mal se passer ?

Hé bien, notamment sur cette page : mockup des conversations de ProtonMail v4 (et donc sur la v4 en question).

Activé tel quel, le rendu est vraiment pas heureux. C’est encore plus frappant sur les conversations qui alternent en lues (bleu clair)/non lues (blanc).

En fait, un espace de couleur uniforme est réservé pour le scroll. Et bien entendu, je n’ai pas des contenus de couleurs uniformes (c’est la fin des couleurs uniformes comme dirait la pub qui le vaut bien). Solution ?

Essayer de trifouiller la transparence du scroll ? Pas possible.
Essayer de mettre le scroll par-dessus ? Soyons sérieux, pas possible.
Mettre une bordure sur chaque élément ! Non. Sinon le conteneur n’aura pas la bordure jusqu’en bas si pas assez de messages.

Bref, j’en arrive à mettre un conteneur avec la bordure à l’intérieur dudit conteneur qui aura donc le scroll, ainsi, le design des conversations ne sera pas pété. On peut argumenter sur le fait que le scroll semble en dehors de son conteneur, mais c’est quand même mieux. Au pire, on peut envisager une seconde bordure à droite du scroll pour l’entourer mais ce ne sera pas nécessaire.

Alors, refaisons notre calcul. Activer cela, modifier les composants, tester… sur trois projets ayant leurs spécificités. Tiens, c’est plus long que prévu. Gag, autre effet de bord découvert de nombreux jours après. Pour peu qu’on ait un contenu en dark mode contenant un contenu clair, le tout peut totalement dérailler avec quelques effets de bords rigolos.

Mais bon, c’était l’affaire d’une petite heure hein ?

Des métriques pour suivre l’activité d’un dev ?

contact@nicolas-hoffmann.net (Nico) — Mon, 11 May 2020 19:06:06 +0200

Il y a quelques mois, j’ai suggéré sur Twitter l’idée de faire un billet pour dénoncer les fausses-bonnes idées en matière de métriques pour suivre l’activité d’un développeur.

Hasard du calendrier, le confinement a pu tenter certains emm… – pardon, je reformule – certaines personnes stressées par le contrôle peuvent vouloir suivre l’activité d’un développeur.

Qu’on soit clair, je comprends le besoin… non pas de contrôle bête, mais de suivi. Le suivi est utile. Pour pouvoir planifier, intercaler, gérer d’autres personnes. C’est légitime. Le contrôle bête et méchant l’est sûrement beaucoup moins.

Et dans notre Startuffe Nation, on peut se poser la question d’une métrique magique pouvant quantifier l’activité d’un développeur. En clair, il y a les bonnes et les mauvaises façons de le faire. Commençons par… les mauvaises.

Idée débile numéro 1 : au poids !

Afin de rester poli, j’évacue de suite l’angle « Le dev est là pour pisser des lignes de code ». C’est idiot. Si vous considérez vos dévs ainsi, ne vous fatiguez pas avec de l’humain. Et si d’aventure, vous aviez quelqu’un correspondant à ce profil, gare ! Certes, certaines tâches sont répétitives et/ou reviennent entre divers projets. Mais cela veut peut-être dire que votre organisation paie des gens pour faire du travail de robot. Autrement dit, si c’est le cas, cela peut tuer leur créativité, et donc leur capacité à résoudre vos problèmes. Ou alors, vous avez embauché quelqu’un de pas bon.

Hein, je te regarde, toi, chef de projet/directeur/dev qui clame un « on a toujours fait comme ça, on n’a aucune raison de changer ». C’est bien connu, le Web est réputé pour être quelque chose d’immuable, et tous les projets/contextes sont exactement les mêmes ! (sarcasmes inside)

Revenons au poids, et prenons un petit exemple. Si je regarde la PR qui fait passer ProtonMail de sa v3 à la v4 en cours de conception, nous avons réussi quelque chose d’extraordinaire.

Si on paie au poids, nous avons réussi l’exploit de produire une nouvelle version, et les devs paieront pour cela, vu que le code a diminué de manière drastique ! Je passe les chiffres en détail, mais le dégraissage du mammouth a été violent.

Plus sérieusement, on voit bien que cette métrique n’a pas de sens. Une refonte peut être l’occasion de dégager du vieux code moisi ou des parties devenues inutiles.

Idée débile numéro 2 : au commit !

Regardons le contribution graph de react-components, un projet de composants React faits chez ProtonMail (en gros, des trucs partagés dont on se sert sur tous les projets). Quelque chose vous surprend ? (vous pouvez cliquer pour agrandir)

Je suis 3e, moi, le spécialiste CSS de la boite !! Seuls deux devs me dépassent au nombre de commits, et je suis devant 5 autres devs JS. Qu’on me donne une augmentation de suite !!!

Sauf que… il est possible, je dis bien possible, que j’aie été très légèrement malhonnête en présentant cela. Déjà… il ne faut pas croire tout ce qu’on lit sur Internet, et aller à la source.

Déjà, on voit le rapport de grandeur est très relatif vu le nombre d’ajouts/suppressions. Et cela n’a aucun sens de comparer des choux et des carottes. En l’occurrence, il est aisé de voir que j’opère moins de modifications, et si on creuse un peu, mon job consiste à ajouter des classes, modifier quelques bricoles sur les composants. En outre :

Les 4e, 5e et 6e modifient bien plus de choses que moi et c’est normal, c’est leur job de faire du JavaScript !
Cela ne rend également pas compte de l’activité réelle d’autres, qui travaillent plus sur d’autres projets, sont amenés à opérer sur d’autres aspects, etc.

Bref, pour tuer cette idée, j’ajouterai que j’ai même déjà entendu des devs démotivés se sachant surveillés ainsi… multiplier les commits pour chaque virgule ou point-virgule changé. À bon entendeur.

Idée débile numéro 3 : au temps !

Si on regarde bêtement le changement dans la PR : « Punaise, il lui a fallu 4H pour changer deux classes dans les templates de l’app ? Il fait quoi le dev UI, il se fait bronzer les doigts de pied ? »

C’est possible que le dev UI se fasse bronzer oui. Mais ce qui est possible aussi :

c’est qu’il ait galéré à trouver le maillon qui foire dans un projet complexe avec des abstractions de malade ;
qu’il ait été dérangé entre temps ou demandé sur d’autres trucs ;
que le souci ait été particulièrement dur à reproduire ;
ou que la sacro-sainte solution soit éclatée sur 4 projets avec 20 contextes, la rendant particulièrement délicate ;
ou qu’il soit parti sur une autre piste, et qu’après 20 tentatives, 2 crises de nerfs, 4 arbitrages, un npm i et une crucifixion, le problème ait été réglé différemment (genre le lendemain, un éclair de génie, paf, problème réglé).

Le temps est quelque chose d’impossible à estimer. J’ai plus de 15 ans de métier, et je me gourre encore lourdement sur mes estimations, parce que quantifier l’imprévu ou l’inconnu est tout sauf une science exacte.

Encore ces derniers jours, j’ai estimé deux demandes en mode « oui ça c’est simple, une demi-journée max tout compris », et sans pêcher par orgueil, ça me semblait vraiment simple. Sauf que non : effets de bord, soucis divers imprévisibles. 2 jours de taf.

Et par pitié, ne confondez pas durée et délai. Un jour de taf, si on est sur plusieurs projets, ça peut s’étaler sur plusieurs jours. Allez, je passe sur toutes les autres idées complètement débiles.

De meilleures métriques

Désolé de ce truisme (j’adore placer ce mot), mais faire confiance à vos devs, ça fera partir tout le monde sur de bonnes bases.

Si vos devs disent que c’est compliqué de développer, c’est que ça l’est. Et s’ils disent qu’estimer est difficile/impossible, c’est que ça l’est vraiment. Si on le dit tous, c’est pas un complot des francs-développeurs dans le monde, c’est que c’est vrai.

Voici quelques pistes :

De la valeur business est-elle produite dans le temps sur un même produit (je cite une réponse très juste) ?
Les clients sont-ils contents ?
Est-ce que votre dev est apprécié des autres humainement ?
Est-ce que son travail facilite celui des autres ?
Maîtrise-t-il sa partie ?
Est-ce que les tâches sont expédiées et résolues ?
Est-ce qu’au long cours, son travail permet de continuer à garder la vélocité de l’équipe, ou est-ce que cela devient de plus en plus dur ?
Est-ce que sa partie facilite des évolutions non prévues initialement ?
Etc.

Certes, tout cela est plus difficile à quantifier via une formule magique. Surtout sur des mastodontes que personne ne maitrise.
Ceci dit, avec de la confiance et surtout des ambiances saines, cela se construit.

Après, cela ne veut pas dire que les estimations sont à jeter, mais il faut les considérer comme ce qu’elles sont : des approximations. Cela peut donner une idée – imprécise – de la charge de travail.

Pas plus tard qu’il y a 3 jours, j’ai entendu un Product Owner dire « je me fous de l’exactitude des estimations, tout ce que je veux, c’est avoir une idée de la quantité de boulot, et voir qu’on avance. Et si un jour, la boîte commençait à avoir des lemmings qui n’ont d’autres boulots que de surveiller ça, vous vous barrerez vite car la boite sera devenue merdique ». Tout est dit.

Mais pour conclure : comptez le coût induit par la mise en place d’outils pour gérer la non-confiance, que ce soit en humain, temps, argent, processus, bien-être… et comptez le coût de la confiance. C’est peut-être délirant, mais croyez que la balance est nettement en faveur de cette dernière, sans compter les effets bénéfiques induits.

Note de lecture : Grid Layout, de Raphaël Goetter

contact@nicolas-hoffmann.net (Nico) — Tue, 30 Apr 2019 14:59:00 +0200

J’ai eu le plaisir de recevoir le dernier livre de Raphaël Goetter, intitulé « Grid Layout, vous allez enfin aimer CSS ». Ce livre est sorti depuis le 18 Février de cette année.

Un livre entier pour un seul module de CSS ! Est-ce bien raisonnable ?

Hé bien, autant dire de suite : oui, et cela ne sera pas de trop ! Si le positionnement en CSS a toujours été une partie de plaisir (tousse très fort) et absolument pas limitatif (s’étouffe en toussant), là, nous tenons un des modules majeurs, car parmi les plus puissants qui soit.

Des choses soit difficilement faisables jusqu’à présent (fusion de cellules) ou souvent bricolées (grilles robustes et responsive, avec des marges négatives par exemple) sont désormais possibles sans bidouillage, et le tout très simplement. Il m’arrive parfois de me servir de Grid Layout, et je me surprends à constater la puissance et la concision de ce nouveau module.

Ce module ne va pas vous dispenser des bonnes pratiques sur CSS (séparation layout/positionnement d’un élément), mais va permettre dans l’absolu de gérer le positionnement global beaucoup plus aisément : on peut commencer à envisager de se passer de conteneurs exclusivement pour le positionnement, Grid Layout permet aussi bien de créer des systèmes complexes que des choses très simples.

En pratique, m’est d’avis que les règles de scalabilité/réutilisabilité risquent de nous faire revenir sur terre dans les intégrations complexes, mais qu’on ne se méprenne pas, le pas franchi avec Grid Layout est gigantesque, les possibilités sont énormes.

Sinon, que dire de plus sur l’auteur, est-il encore besoin de le présenter ? Passionné des CSS et des Knacss, coutumier des bons livres et… coutumier des interventions sur Grid Layout depuis un certain temps. Autant j’avais eu le plaisir il y a quelques années de co-présenter un atelier sur CSS en duo avec lui, mais la dernière fois, j’étais simple élève lors d’un de ses ateliers sur le sujet à Paris Web en 2018.

Je retrouve tout le style de Raphaël - style, CSS, vous suivez - dans ce livre, très proche de son atelier, en bien plus complet bien sûr : expliquer les choses simplement, pas à pas, sans pour autant trainer. C’est efficace, on apprend vite et bien. Le livre se lit rapidement, il se dévore même.

Bref, vous l’aurez compris : je ne peux que vous recommander la lecture de cet ouvrage. Chapeau Raphaël, ton nom truste ma bibliothèque en matière de CSS. ;)

Si vous voulez en savoir plus sur cet ouvrage, voici le site dédié : Grid Layout, vous allez enfin aimer CSS.

Créer un RevealJS light avec CSS Scroll Snap Points

contact@nicolas-hoffmann.net (Nico) — Thu, 07 Jun 2018 17:49:44 +0200

Cela faisait un certain moment que je voulais tester ce module CSS ainsi d’autres choses, l’occasion m’en a été donnée avec mes slides de Sud Web 2018. Voici un petit retour d’expérience.

Attention, je le dis de suite : certaines parties de ce délire ne sont clairement PAS utilisables en production à grande échelle. Je me le suis permis car j’étais dans un contexte totalement maitrisé… et vous allez voir que je ne m’en suis vraiment pas privé. Grosso modo, c’est un RevealJS en version très light, codé à la rache en moins de deux heures.

CSS Scroll Snap Points

L’idée de CSS Scroll Snap Points est de permettre de définir une force d’adhérence aux points d’accroche en cas de défilement d’un conteneur. Le viewport du conteneur doit s’arrêter à un point d’accroche s’il n’est pas en train de défiler. Ce n’est pas clair ? Rassurez-vous, c’est normal !

Un exemple vaut mille mots, allez voir (idéalement avec Firefox) un exemple.

Comme vous pouvez le voir, l’idée des slides en HTML est assez simple. En clair, chaque élément aura une taille de 100% et une hauteur de 100vh. Et dès qu’on se déplacera, CSS Scroll Snap Points permettra d’aller de slide en slide, nativement si j’ose dire.

La petite surprise, c’est que le touch est très très bien géré ainsi (essayez sur une Surface sur Firefox ou sur Edge). Et une fois que le focus est sur la page… les flèches gauche et droite permettent aussi de gérer le déplacement. Vous voyez l’intérêt pour un carrousel par exemple ? :)

En clair, ce module CSS a beaucoup d’avantages. Actuellement, le touch est très bien géré par Edge et Firefox (les points d’adhérence sont effectifs). Chrome et autres ne semblent pas (encore) les gérer.

Dans mon cas, cela s’est limité à définir un conteneur scroll-snap-type: mandatory et scroll-snap-points-x: repeat(100%). Et à donner à chaque slide la largeur/hauteur complète du viewport. Oui, c’est aussi simple que cela.

La doc : CSS Scroll Snap Points

Intersection Observer

Grosso modo, l’idée de cette API est de gérer quand un élément « observé » rentre ou sort du viewport, d’appeler une fonction quand c’est le cas, cela évite de devoir le faire soi-même avec des fonctions plus ou hasardeuses et/ou coûteuses en performance.

Pour être très franc, au début, j’ai voulu utiliser cela juste pour avoir l’occasion de m’en servir (je n’en ai eu l’utilité que plus tard), voir la documentation d’Intersection Observer.

L’idée était de pouvoir ajouter une classe pour savoir quelle était la slide active. En clair, je surveille toutes les slides.

if ('IntersectionObserver' in window) {
   // IntersectionObserver Supported
   let config = {
      root: null,
      rootMargin: '0px',
      threshold: 0.5
   };
   let observer = new IntersectionObserver(onChange, config);
   slides.forEach(slide => observer.observe(slide));
} else {
   // IntersectionObserver NOT Supported
   console.log('Whomp Whomp Whomp');
   }

Et quand une passe dans le viewport, je lui ajoute la classe is-active et au passage j’ajoute le fragment correspondant dans l’URL.

function onChange(changes) {
   changes.forEach(change => {
      if (change.intersectionRatio > 0.5) {
         change.target.classList.add('is-active');
         history.pushState(null, null, location.pathname + location.search + '#' + change.target.getAttribute('id'));
         } else {
             change.target.classList.remove('is-active');
            }
   });
}

C’était un caprice au début, mais cela va se révéler utile ensuite.

Ajouter des contenus qui apparaissent/bougent

Dans la présentation, à plusieurs moments je me suis dit que ce serait bien d’avoir des contenus qui apparaissent au fur et à mesure dans la même slide. Du coup, j’ai mis quelques boutons ainsi.

En clair, quand ce bouton est activé, il va chopper l’élément qui a l’id next_2 et il le fait apparaître.

Oui c’est pas génial point de vue accessibilité, on peut faire mieux, je sais ! :)

Gérer la télécommande

Durant les répétitions, je me suis rendu compte que devoir me rapprocher de ma Surface pour activer les boutons/passer les slides était gênant pour le rythme et ma liberté sur scène (et bien m’en a pris vu la configuration du lieu le jour même). C’est là que je me suis amusé à coder un peu de raffinement… qui va s’avérer vital durant la présentation.

Grosso modo, la télécommande envoie un événement clavier (voir keycode.info), comme si on appuyait sur Page Down (34) ou Page Up (33). J’avais déjà codé que si cet événement arrivait, j’appelais une fonction qui passait à la slide suivante/précédente. Pour l’animation, je ne me suis pas cassé la tête, j’ai utilisé scrollIntoView, et comme je n’avais pas de souci de compatibilité, j’ai utilisé l’option behavior: "smooth" (attention, le support est très variable selon les navigateurs, la version de base ne marche pas trop mal, mais scrollIntoViewOptions est plus rare).

Comme je voulais pouvoir activer les boutons, l’idée est assez simple : si j’ai un bouton non encore activé dans la slide active, alors j’envoie un clic dessus.

if (eventName === 'keydown' && 34 === e.keyCode) {
  let activeSlide = document.querySelector('.slide.is-active');
  let buttonNext = activeSlide.querySelector('.js-next:not(.has-been-pressed)');
  if (buttonNext) {
  buttonNext.click();
  } else {
    let buttonAnim = activeSlide.querySelector('.js-anim:not(.has-been-played)');
    if (buttonAnim) {
      buttonAnim.click();
    } else {
      let slides = [].slice.call(document.querySelectorAll('.slide'));
      selectSlideInList(slides, 'next');
    }
  }
}

Dans la fonction qui permet de revenir en arrière (sait-on jamais, des fois que j’en aie besoin durant la présentation), j’ai réinitialisé les boutons d’animation et suivants. Ce n’est pas optimal, mais ça me permettra de les rejouer si besoin est.

Et hop, le job était fait, je contrôlais l’intégralité de la présentation à la télécommande. Bien m’en a pris, car ce sera obligatoire sur place.

En conclusion

Certes c’est un exercice de style fait à la rache, mais grosso modo, avec quelques APIs, de la CSS, très peu de JavaScript et un peu d’huile de coude, j’ai pu tester quelques trucs et recréer un mini-système façon RevealJS en très peu de temps.

Il serait assez facile d’ajouter une version imprimable, de perfectionner le système, j’avais même fait quelques essais pour avoir des slides horizontales et verticales, à creuser pour plus tard, car là je n’ai clairement pas eu le temps.

Là où je me dis que cela est intéressant, c’est pour un hypothétique carrousel : on n'aurait plus à gérer le touch à coups de JavaScript, mais tout serait fait automatiquement grâce à CSS Scroll Snap Points… quand il fonctionnera correctement chez Webkit.

Voilà, si vous avez des remarques ou des commentaires, à votre disposition !