HTeuMeuLeu

J’ai découvert il y a quelques mois que GitHub supporte les alertes en Markdown (« une extension Markdown basée sur la syntaxe blockquote que vous pouvez utiliser pour mettre l’accent sur des informations essentielles »). Ça permet concrètement de faire des blocs de citations colorés avec une icône spécifique. Et comme je suis incapable de me souvenir de la syntaxe, en voici un rappel.

> [!NOTE]
> Useful information that users should know, even when skimming content.

> [!TIP]
> Helpful advice for doing things better or more easily.

> [!IMPORTANT]
> Key information users need to know to achieve their goal.

> [!WARNING]
> Urgent info that needs immediate user attention to avoid problems.

> [!CAUTION]
> Advises about risks or negative outcomes of certain actions.

J’ai arrêté de suivre Gruber depuis un moment. Mais j’ai exceptionnellement écouté le dernier épisode de son podcast avec Louie Mantia. Et à environ 2:24, il raconte un truc sur Alan Dye (le Vice President of User Interface Design à qui l’on doit l’horreur qu’est Liquid Glass qui va nous tomber dessus le mois prochain) auquel je n’arrête pas de repenser.

J’ai eu un briefing avec Alan Dye et une poignée d’autres membres de la presse, la deuxième ou troisième année de l’Apple Watch. […] Et j’avais une question, parce que je pense qu’ils venaient de peaufiner dans la dernière version de watchOS la façon dont ils faisaient le rendu graphique.

Quand vous regardez une montre analogique, avec l’aiguille des heures, l’aiguille des minutes et l’aiguille des secondes, il y a un axe Z, même si watchOS a toujours été relativement plat. Et même si vous achetez une montre à quartz à 7 $ dans un magasin discount, sur chaque montre physique avec des aiguilles, les aiguilles sont superposées dans le même ordre. L’aiguille des minutes est au-dessus de l’aiguille des heures. Et s’il y a une aiguille des secondes, elle est au-dessus de l’aiguille des minutes. Ainsi on a les heures, minutes et secondes dans cet ordre. Et l’Apple Watch affiche les aiguilles dans le même ordre.

Mais ce n’est pas parfaitement plat. Et ils affichent une sorte d’ombre autour de choses pour que vous puissiez voir quand l’aiguille des minutes est légèrement au-dessus de l’aiguille des heures. Ce n’est pas tout à fait à la minute où elles se superposent. C’est genre une minute avant. Il y a une petite ombre pour les distinguer. Et j’avais une question à propos de la source lumineuse de cette ombre.

Et je me suis dit « oh, enfin, je vais pouvoir poser cette question à Alan Dye ». Et lui était comme : « Ah bon ? On affiche une ombre ? » Et je me suis dit : « Oh, il n’a jamais regardé. » J’ai immédiatement réalisé qu’il n’avait jamais regardé ça de près. Quelqu’un chez Apple l’avait fait. Mais ce n’était pas Alan Dye. Et je me souviens d’avoir pensé, à ce moment précis : « Oh, il ne fait pas ce que je pensais qu’il faisait. »

Nicolas pose une colle intéressante sur Mastodon. Pourquoi dans l’exemple suivant, sur Firefox, la première déclaration est ignorée mais pas la seconde ?

input[type="range"]::-webkit-slider-thumb {
  background-color: red;
}

input[type="range"]::-webkit-slider-thumb,
input[type="range"]::-moz-range-thumb {
  background-color: blue;
}

Les préfixes -webkit– sont normalement réservés aux navigateurs utilisant WebKit (Safari, ou tout autre navigateur sur iOS) et dérivés (Chrome et toute sa clique). On pourrait donc se dire que Firefox ignore simplement la première déclaration parce qu’il ignore les préfixes -webkit- et applique la seconde parce qu’il connaît les préfixes -moz-.

Oui, mais… (Parce qu’il y a forcément un mais sinon c’était trop facile.) En CSS, dixit MDN :

Un inconvénient des listes de sélecteurs est la non-équivalence des deux blocs suivants :

h1 {
  font-family: sans-serif;
}
h2:maybe-unsupported {
  font-family: sans-serif;
}
h3 {
  font-family: sans-serif;
}

h1,
h2:maybe-unsupported,
h3 {
  font-family: sans-serif;
}

En effet, un seul sélecteur vous manque et tout est dépeuplé. Enfin, un seul sélecteur invalide rend l’ensemble de la règle invalide.

Dans notre exemple initial, cela signifie que notre seconde déclaration (avec deux sélecteurs, dont un -webkit- inconnu pour Firefox) devrait aussi être ignorée.

Que se passe-t-il donc ?

Après quelques recherches, j’ai fini par trouver ! Dans la spécification CSS « Selectors Level 4 » :

Tout autre pseudo-élément dont le nom commence par la chaîne « -webkit- » et qui ne soit pas une notation fonctionnelle doit être traité comme valide au moment de l’analyse. (Cela signifie que ::-webkit-asdf est valide au moment de l’analyse, mais pas :-webkit-jkl().) S’ils ne sont pas reconnus et supportés, ils doivent être traités comme ne correspondant à rien, et sont des pseudo-éléments -webkit- inconnus.

CQFD.

Après avoir enchaîné plusieurs projets utilisant Tailwind CSS, je démarre en ce moment un nouveau projet n’utilisant que Sass. Et c’est assez libérateur. Mais il y a un petit truc de Tailwind CSS qui me manque : son fichier de config (tailwind.config.js).

L’idée n’a rien de nouveau et on n’a pas attendu Tailwind pour créer des variables. Mais jusque là, mes fichiers de variables en Sass ressemblaient plutôt à un fichier monolithique avec une queue leu-leu de variables, un peu comme celui de Bootstrap.

Voici comment j’ai procédé pour imiter le fichier de configuration de Tailwind CSS v3.0 en Sass.

Lire la suite de « Imiter le fichier de config de Tailwind en Sass »

S’il y a bien un truc qui m’énerve, ce sont les sites soit disant « éco-conçus » qui appliquent un effet de « dithering » (diffusion d’erreur en français, aussi parfois désigné comme un effet de tramage) sur leurs images.

Lire la suite de « Éco-conception et dithering »