DEV Community: Bastien Calou

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

Bastien Calou — Tue, 26 Sep 2023 07:52:13 +0000

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.

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.

Les effets vont bien au-delà de l'impact sur l'individu lui-même :

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 risque 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.

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

Do CSS framework users actually know CSS? We might have some data

Bastien Calou — Fri, 09 Dec 2022 08:56:28 +0000

This year's State of CSS survey offers a great tool they call the Data Explorer.

For exemple, here is a view of developer's usage of scroll snap properties, combined with their usage of Bootstrap.

It looks a bit complicated, but I will explain that in a moment.

We all have simplified beliefs about CSS :

"If you use Tailwind, it's because you don't want to learn CSS"
"But Tailwind solved CSS, it's the way to go!"

As always, the reality is more complex, and I thought this tool was a great opportunity to explore the relationship between CSS frameworks and native CSS.

Maybe a good start would be to agree on two things :

You don't need to know every CSS property to be a good CSS developer. It's all about building a good mental model of how CSS works.
At the same time, it's valuable to know a good quantity of CSS properties, so that we are able to use them when needed, like a toolbox.

I hope that's non-controversial. Let's go!

Bootstrap methodology

Bootstrap has been used by 81% of this survey respondents. Historically, it is the CSS framework.

Let's define Bootstrap users categories :

%	Opinion	Code name
51.7%	used it but would not use again	The ex-users
29%	used it, would use it again	The lovers
16.3%	heard of it but are not interested	The indifferent
2.7%	did not try it but are interested	The curious
0.5%	never heard of it	The uninformed

Who do you think will have the best native CSS knowledge?

So, let's look at what the data explorer tells us, with the exemple of the scroll snap properties. Here's a close-up on a specific cell:

Here's how you read it: overall, 34% of this survey respondents used scroll snap properties. However, if you look only at bootstrap lovers, only 26% also used scroll snap, so 8 points less.

So here's what I've done : in a horrible document that you don't need to open, I've notated these variations for the 53 presented properties, and for our 5 types of developers.

As explained before, bootstrap lovers use less scroll-snap (-8 points). But the ex-users and the indifferent use it more that the global population.

Bootstrap results

Here are our five developers categories, from "less native CSS friendly" to "most native CSS friendly":

Code name	Native CSS knowledge variation
The uninformed	-11 points
The curious	-9 points
The lovers	-2 points
The indifferent	no variation
The ex-users	+2 points

The uninformed

The uninformed (who don't know what bootstrap is) category is correlated with a poor native CSS knowledge score: -11 points.

Personal theory: Bootstrap is so widely used that if you don't know about it (only 0.5% of respondents), you are probably new to CSS. So it makes sense you don't know a lot about native CSS yet.

Please keep in mind that personal theories are theories. And personal.

The curious

The curious (who are interested in discovering it) category is also correlated with a decrease of -9 points.

Personal theory: they might also be beginners who did not have the time to try it yet. They want to try it because it's very popular and it's too soon for them to decide to pass on it.

The lovers

The lovers (who used it and would use it again) are doing much better, but still -2 points below the average.

Personal theory: they know a lot more than the uninformed and the curious because they may been coding with bootstrap (among other tools) for years and gathered lots of CSS knowledge along the way. Still, the usage of Bootstrap doesn't facilitate discovering new CSS features, or Boostrap is good enough for what they do and they don't care as much (or don't have the time to care!).

The indifferent

The indifferent (who know about Bootstrap but are not intersted) perform like the average population.

Personal theory: deciding you are not interested in a tool means you have a sufficient understanding of what are CSS challenges to decide that Bootstrap is not for you. Other tool might be stealing the attention too, but it does not prevent the indifferent from discovering native CSS features.

The ex-users

The ex-users (who used Bootstrap but would not used it again) do better than the average : +2 points.

Personal theory: learning a CSS framework and deciding to stop using it is a long process, so they have substential experience. They said goodbye to Bootstrap because their approach of CSS evolved (and CSS evolved itself, allowing this move for some Bootstrap's users). They even may have witness the long transformation of CSS through the years. They decided this tool is not for them anymore and use modern native CSS more. Also, you don't always choose your tools: they could have been asked to use Bootstrap by an employer or a client, while still investing in native CSS knowledge in parallel.

Here are the details grouped by categories:

The biggest gap (-8 points) between the ex-users and the lovers is the interaction category (scroll-snap, touch actions, overscroll-behavior...).

I think it should also be noted that the lovers category is correlated with a lesser knowledge of accessibility related CSS features (-5 points compared to the ex-users).

Tailwind methodology

Now let's talk about the new boss in CSS town.

First, our users categories:

%	Opinion	Code name
36.4%	used it, would use it again	The lovers
25%	heard of it but are not interested	The indifferent
25%	did not try it but are interested	The curious
9.8%	used it but would not use again	The ex-users
4.1%	never heard of it	The uninformed

Who do you think will perform better this time?

Tailwind results

The order has changed! Indeed, the lovers now perform better than the indifferent.

And the numbers vastly changed too.

Code name	Native CSS knowledge variation
The uninformed	-9 points
The curious	-5 points
The indifferent	+1 point
The lovers	+2 points
The ex-users	+6 points

The uninformed

The uninformed (who don't know what tailwind is) category is correlated with a poor native CSS knowledge score: -9 points.

Personal theory: same as people who don't know about Bootstrap. If you don't know about Tailwind you may be just starting to discover the CSS ecosystem. But you could also have years of experience and not be really informed about recent CSS news, which might be why this is "only" 9 points below the average (while for Bootstrap it was 11).

The curious

The curious (who are interested in discovering Tailwind) category is also correlated with a decrease of -5 points.

Personal theory: It's less than with Bootstrap (-9 points), but the logic could be the same. If you did not try this hugely popular tool yet or did not have enough perspective to decide to pass on it, you might still be discovering CSS, so it makes sense that you don't know everything about native CSS either. Still, it's less than with Bootstrap. If you heard about Tailwind, it means that you're interested in the current state of CSS, while you could have heard of Bootstrap a long time ago.

The indifferent

The indifferent (who know about Tailwind but are not intersted) do a little better than the average: 1 point.

Personal theory: same as Bootstrap. These developers have enough experience to judge if a tool would be interesting to them or not. With this experience comes an good knowledge of native CSS, too, just above the average. But...

The lovers

The lovers (who used Tailwind and would use it again) are in completly different position than earlier. With Bootstrap, they knew less (-2 points), but with Tailwind, they know more : +2 points! Even more than the indifferent.

Personal theory: contrary to what is sometimes said, loving Tailwind is not correlated with a lesser knowledge of native CSS features. First, let's remember that with its utility classes, Tailwind uses an approach that is closer to native CSS than Bootstrap. So a Tailwind user knows about things like flex, whereas a Bootstrap user would use a "column" class (which is actually flexbox in disguise and has nothing to do with actual CSS columns...). Then, there's the fact that Tailwind is a recent tool. If you read articles about it, there's almost no way that you don't read articles about native CSS improvements too. It's part of the modern ecosystem. That being said...

The ex-users

The ex-users (who used Tailwind but would not used it again) perform much better than the average : +6 points.

Personal theory: while Tailwind users are part of a modern ecosystem and know their CSS, well, people who turned their back on Tailwind seem to know more. First, Tailwind does not (nor claims to) solve or cover everything. Some modern CSS features, like :has, container queries, cascade layers, @supports queries... just require you to know them natively to be used at their full potential. That doesn't mean that Tailwind users don't know about them and can't use both, but developers who were dissatisfied with the Tailwind approach simply seem to invest more in native CSS understanding. That doesn't make them better people, but their toolbox seems to be wider.

Here, the biggest gap between the ex-users (-8 points) and the lovers is the selectors category, which contains ::marker, :has and :where. Tailwind lovers don't use them very much.

Once again, there is also a huge gap in the accessibility deparment: while Tailwind lovers do perform better than the average (+2 points), the ex-users perform much better (+9 points).

Conclusion

I hope this little experiment was interesting to you. This is not a scientific study reviewed by peers, so please take with a grain of salt, though I did my best with what I had. Don't forget about the sample bias: people participating to a CSS survey cannot be representative of all developers in the world.

Here are some possible conclusions I submit to you:

About Bootstrap

Bootstrap is on the decline, and maybe that's ok. It has been a part of a lot of developer's journeys, but still using it today correlates with a lesser knowledge of valuable CSS features. It's not a bad tool and saved many developers back in the days, but it now struggles to stay relevant.

I don't want people to move away from Bootstrap if they are good with it: the only thing that matters is always the quality of what we're building. They just should be aware that there's a lot more to CSS today (and a lot of them already are, I'm sure).

About Tailwind

No, someone loving Tailwind does not make them ignorant about "actual CSS". They use a modern CSS tool, and gathered substential native CSS knowledge along the way. They may have learn native CSS recently and their knowledge could be more up to date than someone who knew a lot about CSS a decade ago and did not keep up to date.

However, they should also be conscious that mastering Tailwind is not and cannot be mastering CSS, if such a thing exists. Some features simply can't translate to Tailwind. It does not prevent to write good CSS with Tailwind, but it narrows the theorical toolbox size. Tailwind users eager to keep learning could reinvest the motivation that made them learn Tailwind to continue learning about native CSS features, which are there to stay and will transfer from tool to tool.

About native CSS

2022 has been a great year for CSS and I feel that knowing about these native features is a powerful asset for any developer.
Of course, it does not replace a deep understanding of CSS logic, which is not just a list of properties, but it provides a great toolbox to overcome various challenges.

For both Bootstrap and Tailwind, people who knew more about native CSS were also the ones who had actually tried the framework. So maybe don't reject every tool based on some purity principle: discovering new ways of writing CSS — even if you realize they don't suit you in the end — may be valuable and could shed a new light on how you write native CSS.

What are your thought on this? If you reach any different conclusions, let me know. Please be respectful to everyone, it's only CSS ;)

Thanks for reading!

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

Bastien Calou — Fri, 14 Oct 2022 07:58:33 +0000

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).

Voir le programme complet du jour 2.

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.

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 : un hopital 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é.

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 reccommande-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.

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 environnementale 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%.

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 imprédictibles. 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

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 peux-t-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 ;)

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 capable 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 trainer dans un tiroir : vendez ou donnez-le.

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.

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.

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 parmis 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 !

Bastien Calou — Wed, 12 Oct 2022 16:48:09 +0000

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.

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 !

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 éco-systè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.

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 atterir dans un autre endroit du DOM).

L'idée géniale est donc la suivante, en 4 étapes (F.L.I.P) :

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 !)
Flip : 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 ?

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'aviez pas fermé la parenthèse de votre fonction alors que vous êtes encore en train de coder...

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.

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.

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.

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.

Seuls 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é ?

Une musique de jeu évolutive grâce à JavaScript

Bastien Calou — Thu, 07 Apr 2022 15:15:26 +0000

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.

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 accommoder 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 serez emmené au début de la section suivante :

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 raison à 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 que 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 ?

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.

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 !

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 = <3

Voici un court extrait du jeu (le dernier saut est assez brusque, mais c'est comme ça !) :

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.

The era of no-hacks CSS

Bastien Calou — Mon, 28 Mar 2022 06:57:12 +0000

If you learned CSS anytime before 2020, chances are that you collected a lot of little hacks along the way. You know, things like centering, styling form elements, sizing images, wrapping text... Black magic things. Incredibly specific behaviors that you look up in google, hoping that someone wrote a blog post about it, and that will ruin your day otherwise.

A lot of my colleagues look at CSS with utter suspicion, because they had to learn it 10 years ago, before moving to back-end programming, project management, design or even "JS-only front-end".

Lot of people even look at developers using CSS like strange creatures, the ones who tamed the beast, the ones who could see through an impenetrable jungle of CSS hacks and make sense of it, at the expense of their own sanity.

But the truth is this:

We don't like CSS hacks

Personally, I hate them. They might be fun to show to a student or colleagues struggling with a bit of strange layout behavior (tadaaaa !), but I despite them, because they're just workarounds, or ugly non-standards way of using properties that never were made for this. They are anything but good code. They are enigmatic code, maintenance nightmare, and probably the worse, they create a mistrust towards CSS that in the end hurts the whole ecosystem.

And that's how you get Peter Griffin struggling with CSS, vertical alignment jokes... Heck, I even have the ironic "CSS is awesome" mug as my twitter cover image.

These jokes helped us cope with the harsh reality of CSS for years, but the truth is that they are now out of date. If anything, using them is like publicly announcing:

I learned CSS 10 years ago, hated it and never tried again! (insert miracle CSS-in-JS library presentation here)

Yep, that Twitter banner definitely has to go...

Will 2022 start the era of no-hacks CSS?

A lot is happening to CSS these days, and I feel 2022 could be the year we get rid of CSS hacks, or at the least the year we stop considering them "everyday CSS".

Just take a look at this thread, for exemple.

// Detect dark theme var iframe = document.getElementById('tweet-1475583226165055501-259'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1475583226165055501&theme=dark" }

Things are moving fast and CSS is becoming a mature language. Even the browsers community is organizing itself to make CSS level-up in the best possible way. See the Interop initiative, for example.

The `accent-color` example

The accent-color property is quite simple and one of my favorite new things.

Its unique purpose is to allow you changing the color of the native form inputs: checkboxes, radio buttons, range selectors... Check it out:

:root {
  accent-color: crimson;
}

That's one line of CSS and zero hacks.

For years (dare I say decades?), CSS developers achieved that by actually hiding the native input and creating a fake input with the desired appearance. Both were linked with the good old :checked pseudo-class. This was never normal code. It was a dirty and error-prone hack, waiting patiently to be replaced by a clean solution.

Leaving hacks behind is also your responsibility

The accent-color property is a good example of that. Yes, it's new and not supported by every browser.

Well, I could not care less about this.

Because CSS is awesome, it will simply ignore accent-color in older browsers and use the default system colors. Which is very fine (just test the contrasts if your background is not white).

Even better, as time goes by, more and more people will have a browser supporting this and will see the intended final design. That's progressive enhancement magic: your website is getting better while you're not even working.

Me not caring about this doesn't mean that everyone won't or even should. Maybe a designer or a manager will decide that it would be nice to have the brand color for inputs, even on older browsers, and I respect that. But that is not only a design question, they are costs and benefits.

So I will defend the position that hacking the CSS (a hack which can break) for a fraction of the audience (a fraction that will have a great fallback anyway and will diminish with time) is not worth it is most cases.

I also love flexbox's gap property, which makes space management SO easy:

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

A decreasing fraction of browser don't support that and will show no gaps between items. Whether you're willing to setup a negative-margin CSS hack to handle these cases is another debate to have.

I started to make peace with the fact that a tiny (and one again, decreasing) fraction of users won't have the spaces. As long as the content is perfectly legible, this doesn't bother me.

Goodbye hacks

Of course I'm still using hacks, from time to time. But I stopped considering them common CSS.

CSS is catching up with our clever hacks and is eradicating them by providing standard, robust features. If you use (and advocate for) progressive enhancement techniques where you know that your content is still accessible without every line of intended CSS, you can use these new features at will. You'll feel free, live longer and, I believe, make better websites.

Share this to a colleague who hates CSS ;) I can't blame you. But this is 2022 and CSS has changed.

Calculs CSS infernaux à partir de données physiques

Bastien Calou — Fri, 18 Jun 2021 06:46:26 +0000

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).

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 }};
    "
  >

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)

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, peut 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.

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

Bastien Calou — Wed, 16 Jun 2021 06:57:00 +0000

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.

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.

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"
    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 :

	avif	webp	jpeg
350px	🌟147k	252k	321k
700px	249k	459k	624k

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 !

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

Bastien Calou — Mon, 14 Jun 2021 06:53:34 +0000

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é.

Ç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éfault, 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, pour les moins motivés. 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édictif, 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é dans utiliser un ?

What happens when you write an invalid CSS selector? (bad things)

Bastien Calou — Mon, 07 Dec 2020 08:19:09 +0000

I'd like to talk about a very specific CSS behavior that might cause some headaches if you don't know (or forget!) about it.

Let's create a button:

<button>Click me</button>

I want this button to change its colors when it is pressed. With the :active pseudo-class, that's easy.

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

So far so good.

To improve accessibility, I want to apply the same effect when the button is focused with the keyboard or an assistive technology (and do nothing special if the focus comes from the mouse).

This is possible thanks to the new :focus-visible pseudo-class. At the time of writing, it is supported without prefix by Chrome and Edge.

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

If you are on Chrome or Edge, you can try to focus the button with the tab key and you should see the :focus-visible styles.

This is a great visual help if you don't use a mouse

Here's the catch

Can you guess what will happen on other browsers? Obviously the :focus-visible styles won't show, but any side effect, maybe?

We also lost the :active styles!

The :active styles don't show on Firefox, despite the browser perfect understanding of the :active selector. So sad.

The problem might seem obvious if you already know why this happens, but when I had to debug this in a much more complex CSS file, it boggled me for a good few minutes. And I don't think it is a well-known fact among beginners.

So how to put it?

If any part of a selector fails, the whole selector fails

In other words, if a browser doesn't know about the :focus-within selector, it will throw out your entire CSS rule, including the :active part.

You could say that CSS is a bit susceptible. If it doesn't like the type of olive you put on the pizza, it won't even consider eating it.

CSS has no time to waste with your crazy selectors

Here's the W3C specification:

When interpreting a list of declarations, unknown syntax at any point causes the parser to throw away whatever declaration it’s currently building, and seek forward until it finds a semicolon (or the end of the block). It then starts fresh, trying to parse a declaration again.

And so here's the fix you'll need to use: separate the "safe styles" and the crazy ones.

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

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

Now, :focus-visible might fail, but it won't bother the :active selector.

But why this behavior?

Not really resilient for a language that should adapt itself to many environments, is it?

CSS is broken! JavaScript is our only savior!

Well, there is actually a good reason for this, which is explained in an old document, the CSS 2.1 specification:

CSS 2.1 gives a special meaning to the comma (,) in selectors. However, since it is not known if the comma may acquire other meanings in future updates of CSS, the whole statement should be ignored if there is an error anywhere in the selector, even though the rest of the selector may look reasonable in CSS 2.1.

CSS designers displayed a great level of anticipation here. Indeed, here are some CSS selector that we'll be able to use sooner or later (in some cases, we already are):

.title:is(h1, h2, h3) {} /* h1.title, h2.title, h3.title */
.title:not(h1, h2) {} /* multiple exclusions */
section:has(img, figure) {} /* parent selector */

These selector contain commas, but these commas don't separate the first-level selectors.

If a browser doesn't understand :is and tries to separate our first example, it could result in something like this:

.title:is(h1 /* What is this? Ignore */
h2 /* Style all the h2, even without the .title class! */
h3) /* Wut?*/

The CSS chainsaw massacre

Instead, the browser is cautious. This has been discussed again in 2013, and kept the same way "due to Web-compat concerns".

Hacks

Some developers even used this as a hack to discriminate a specific browser.

Wanna apply a specific style to all browsers except IE? Just add a modern selector for the sole purpose of making IE ignore the rule.

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

Tadaa, the h1 will be red only if the browser also understands :not.

With the correct combination of selectors, you could target or exclude any specific browser version. Which is of course very, very dirty, and hopefully not needed anymore 🙏

Flexbox: when negative margins save the day

Bastien Calou — Mon, 02 Nov 2020 08:43:04 +0000

Gap management with flexbox is not as easy as it seems. Here is a simple trick I've been using a lot lately.

The problem

This is our HTML for this demo:



<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>

It's an article with a list of tags. With some basic CSS, here's what it looks like.

We want the list of tags to be a flex container, with the possibility to wrap. Here we go!



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

li {
  margin-right: 2em;
}

As you can see, I also set some space after each <li> element, 2em being equal to 32px for common text (with the advantage of being responsive to the user preferences and the font-size of the item itself).

And here's the result:

It may seem good enough, but the devil is in the details.

Look at the bottom right corner of the card: I made it resizable so you can simulate a browser resize.

There are two main issues. Can you spot them?

The horizontal issue

The first problem is that because of its right margin, the last items goes to the second line too soon.

Do you notice how there is more space for the last item to go more to the right before the wrapping? Compare that to the space to the left of the first tag.

You could fix that by excluding the last item from the rule:



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

But the problem is the same: every other item causes the line to wrap too soon.

Now the last tag can go farther to the right, but the other ones still cause the line to wrap too soon.

Well, if margin-right is not good enough, what about margin-left ? Let's try this on every item — except the first one, which should not be preceded by any space.



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

Is it better this time? Take a moment and try to guess what issue it might cause.

Because there is no margin-right anymore, the line wraps exactly when it should. But now our problem is elsewhere:

The new line reveals the `margin-left` of the item

We can't complain. We told CSS that each item except the first one should have a left margin, and that's what happens.

How nice would it be to exclude every item that is the first one of its row! But there is no magic selector like this:



li:not(:first-flex-row-item) /* Does not exist */

Such hypothetical selectors could cause a CSS circular dependency. For example, I could say that the first item of a row has a smaller font-size. That could cause the item to go back to the previous line (because of it smaller size), and then it wouldn't be targeted by the selector anymore, and regain its original size, and go back to the second line and... 🤯

Circular dependencies one of the main reasons we don't have container queries yet. But that's another topic.

The negative margin trick

So here's how you do it: first off, every item will get a margin-left.



li {
  margin-left: 2em;
}

We now have to get rid of the space to the left of the first item, and we can do that with negative margins.

Negative margins are not considered a good practice, and I think that you should avoid them whenever possible, because they can make your code's logic harder to understand.

That being said, they are allowed by the w3c and offer a really good browser support.

And in our case, they save the day:



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

li {
  margin-left: 2em;
}

Blue borders applied on the `ul` element reveal the trick

What about the vertical axis?

Well guess what, it's the same thing!

You can't target every item except the ones that are on the first line.

So you have to give everyone a margin-top.



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

This causes the whole list to appear lower that what we want.

We could remove the margin-bottom: 1em from the title tag to compensate.

The removal of the title margin (yellow area) would compensate for the new area inside the `ul` (blue borders)

But I always try to keep my elements independent of the context. The list could appear below another element at some point. Or a title could be followed by something that is not a list.

You know, component driven development, design system and all that jazz.

So we just have to use the same trick and apply a negative margin to our list:



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

And here's our final version. It works on every browser correctly supporting this flexbox configuration, including IE11.

What about the `gap` property?

Posts like this one will become irrelevant once the CSS gap property is widely supported.

But that's not the case yet. At the time of writing, its browser support is only 70%. Not that great, compared to the 99% support of flexbox itself — has Safari really become the new IE?

Other modern browsers should show you the same result with the following code, without tricks!



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

/* No more styles on the items */

The sad part is that you can't even detect the support of this property. Consider the following code:



@supports(gap: 1em 2em) {
  /* Cancel the tricks and do the right thing */
}

@supports queries allow you to apply rules only if the browser understands what's inside the parenthesis.

The problem here is that gap is also a property used on grids, with a much better support of 92%. But that does not mean that the property will work for flexbox.

Here's the issue being discussed by the CSS Working Group.

In the meantime, it's negative margins all the way.

Now with variables ✨

We can improve our code and make it more generic if we need. I like to separate my BEM/semantic CSS from my utility classes, so I will create a class called u-flex.

I'm not a big fan of having style-oriented classes in my HTML, so I would probably use a SASS mixin instead, but you get the idea.

Let's use CSS variables, which have a very decent support (95%). In CSS, you can get the opposite of a value by multiplying it by -1. Here is an example:



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

So here's our utility class:



.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);
}

I like to use the "direct child of any type" selector (> *) with flexbox and grid. It relates very well to the parent/child relationship of these features and will work every time.

And here's how you would use it:



<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;
}

The power of CSS variables allows us to define different gaps for each targeted element. We could even define default values for the whole document:



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

This way, we only have to change the variables locally when we need to have a different gap value.

Bad practices

We all know many bad practices: !important is another one that comes to my mind. But like negative margins, it also has some relevant use cases.

This negative margins trick is a reminder to me: things you learned to avoid might come in handy some day. It all depends of the context.

HTML is not an imperative programming language and that's the best thing about it

Bastien Calou — Wed, 21 Oct 2020 07:18:53 +0000

I love HTML. The more I learn about it, the more I think it is genius work. Above all, I love that it is not a programming language.

Programming languages suck. They fail all the time (I swear, I always write my JavaScript perfectly on the first try, and yet it persists in failing 🤷).

Worse, when they fail, most of the time the whole program fails! I'd just rather stack toothpicks on a windy bridge.

But compare that to the beauty that is 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>

This is beautiful, semantic HTML5. It helps accessibility. It helps legibility. It helps styling. It helps crawlers.

And it doesn't fail.

If an old browser doesn't know about HTML5, it will just treat the nav element as good old div, and it will work.

If a developer or a user with a code editor (e.g. the WordPress back-end) writes nax instead of nav, it will still work.

Let's see another example:

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

Not everyone knows about the details element, so here's what it will produce in modern browsers:

I didn't program this behavior (browser's developers did). I described the content of the document and trusted the browser to render it the best it could. And I think that's very, very cool.

And it will work with old browsers too: there won't be any interactivity, but the content will be displayed and that's the most important thing.

Keep calm and stop programming

I don't want to program. I often have to, when HTML is not enough to describe what my website should do. And like many of us, my typical day revolves around front-end JavaScript frameworks, some of which I really like.

But when I think about the user, I know that the worst thing I can do to them is to program.

Everytime I program something myself, I feel like signing a strange document in my head:

I hereby acknowledge that I'm introducing a non-standard behavior into this website, discharging the browser of its responsibility to ensure a reliable experience for every user. I do this fully aware of my partial knowledge of web technologies, of the existence of limits in my implementations, temporal and technical, which cannot be estimated. I realize that what I'm doing will probably break at some point or in some situations. But I have no choice and I promise not to fuck it up.

On the other hand, when I use HTML and web standards, I rely on the shared knowledge of skilled browser's developers and decades of debates aiming to make the web a great platform.

And that's why a deep knowledge of HTML is infinitely valuable: it simply brings quality to the user, which at the end of the day is the only thing of importance.

Resilience

In one of my best reads of the year, Resilient Web Design, Jeremy Keith tells us how we almost lost one of the most powerful aspects of HTML because of XHTML 2.0:

[XHTML 2.0] would also implement XML’s draconian error‐handling model. If there is a single error in an XML document — one unquoted attribute or missing closing slash — then the parser should stop immediately and refuse to render anything.

Thank god we didn't have that.

XHTML 2.0 died on the vine. Its theoretical purity was roundly rejected by the people who actually made websites for a living.

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

I told you: sane people don't want to program nor anything close to it.

Is HTML hard?

Of course, for HTML to be such a great language, you have to know it. I mean really know it.

Semantics, accessibility, SEO, browser compatibility and default styling, new tags, deprecated tags, specific attributes related to language and time, forms, performance optimization, metadata, media resources...

Even without considering framework-generated "tag soups", there is a huge gap between a good HTML markup and a great one.

It would be a mistake to consider HTML (and CSS) to be the easy part of web development. The problem is that you need to know these languages well to realize that.

JavaScript is hard. Why does everyone know that? Because before you get anything to work, you will deal with countless red errors blocking your entire project. Only after a painful debugging your code will run correctly.

You can't fail with HTML. You can write tag soup, bad forms and follow none of the good practices, but it won't fail, because of its fundamental resilience.

The first time you write JavaScript, it's a mess. The first time you write HTML, you feel like a web genius.

It's only with time and knowledge that you realize you were not the genius: HTML designers were the geniuses, and they gave you a great tool which will require a lot of practice and patience to get really right.

The permissiveness of HTML gave the opportunity to contribute to the web to a lot of people and probably has to do with how far the vision of Tim Berners-Lee has come. But for professional developers, it comes with the responsibility to not rest on this apparent simplicity, and really master this powerful language.

The identity crisis of web languages

It is important how we call things. It's very frustrating to see the HTML/CSS part of a project devalued so often when you know its critical aspect. It's excruciating hearing front-end developers "not caring about CSS", while displaying pixels on a screen is almost the definition of the job.

Maybe calling HTML a programming language makes it more worthy of attention to some people? It would be naive not to realize the biases in salaries and even the sexism related to this matter. You know, because HTML/CSS is the presentation part, and that's... feminine?

On the other hand, I understand that reading that HTML is a programming language can bother some people, including myself. Not because I think programming languages are better. Because I don't want HTML to be a programming language.

We are just building things

During my courses I often use the term development language. I don't see it used often in english. In french we say "langage de développement" and I think that's beautiful.

With that term, you can reunite HTML, CSS and JS without everybody freaking out. From the Cambridge Dictionnary:

Develop: to invent something or bring something into existence

While it seems the debate about HTML/CSS being programming languages will last until the end of datetimes, the fact that they are used, sometimes alongside JS, to "bring something to existence", does not seem controversial at all.

We are all developers.

Who cares if you're programming or not? The only thing that matters is the quality of what you're building.

I guess we just have to make non-programming cool again.

DEV Community: Bastien Calou

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

Do CSS framework users actually know CSS? We might have some data

Bootstrap methodology

Bootstrap results

The uninformed

The curious

The lovers

The indifferent

The ex-users

Tailwind methodology

Tailwind results

The uninformed

The curious

The indifferent

The lovers

The ex-users

Conclusion

About Bootstrap

About Tailwind

About native CSS

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

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

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

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

4. Designer l'urgence ⭐⭐⭐

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

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

7. Thémiser un design system ⭐

8. URL ; reprenons les bases ⭐⭐

8 bonnes raisons de venir à Paris Web 2023

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

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

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

3. Animating the Impossible ⭐⭐

4. L'industrialisation des designers du web ⭐⭐

5. Illectronisme et numérisation des services publics ⭐

6. Lost in translation ⭐⭐⭐

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

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

Une musique de jeu évolutive grâce à JavaScript

La musique

La programmation

Fludifier les sauts de cycles

Masquer la transition

Harmoniser le hit

Musique + code = <3

The era of no-hacks CSS

We don't like CSS hacks

Will 2022 start the era of no-hacks CSS?

The accent-color example

Leaving hacks behind is also your responsibility

Goodbye hacks

Calculs CSS infernaux à partir de données physiques

Les données

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

CSS : let the fun begin

Support navigateur

Vers un CSS plus adapté aux calculs visuels ?

Optimisation agressive des performances d'un site statique

Lazy loading des images

Picture, source & srcset

Générer les images avec Eleventy

CSS critique inline

Et le JavaScript ?

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

Eleventy — Pour un web simple, performant et accessible

Ça sert à quoi ?

Comment ça marche ?

Markdown, la "base de données"

Rendre disponible les données

Templating

Vous prendrez bien un peu de CSS / JS ?

Action !

Un meilleur web ?

La Jamstack

What happens when you write an invalid CSS selector? (bad things)

Here's the catch

If any part of a selector fails, the whole selector fails

But why this behavior?

The `accent-color` example

What about the `gap` property?