#18328

Why I Write CSS in JavaScript

J’ai pas de mots.

Le commentaire qui résume bien la situation, c’est ça :

AKA : too lazy to learn CSS specificity
https://mxstbr.com/thoughts/css-in-js/

#18246

Pure CSS scroll-shadow effect

Ajouter une ombre lors du scroll. Sans JS.

Certaines pages mettent une ombre sous l’entête (qui est fixe) seulement lors du scroll du contenu principal. C’est généralement fait en JS en détectant la position du scroll.

Ici, pas de JS, juste du CSS.

C’est réalisé par une astuce et des pseudo-éléments.

L’ombre est attachée au ::after de l’en-tête.

Quand on scroll le contenu principal, ce qui se passe, c’est que c’est comme une fenêtre coulissante : le contenu qui scrolle en haut est toujours là, juste caché sous l’en-tête et invisible.

À ça, j’ajoute un masque : ce masque est un ::before sous la partie qui scrolle. Le ::before scrolle avec la page.
Quand la page est en haut, le ::before est visible (pas masqué). Quand la page scrolle, le ::before est caché.

Ensuite, il suffit d’utiliser les bons z-index : le masque est au dessus de l’ombre, mais en dessous de l’en-tête. Comme ça, quand il est visible, il masque l’ombre.
Quand on scroll, le masque disparaît sous l’en-tête et l’ombre devient visible.

https://codepen.io/lehollandaisvolant/pen/QYdzzm?editors=1100

#18189

How browser rendering works — behind the scenes – LogRocket

Un article qui explique succintement comment fonctionne un moteur de rendu d’un navigateur, en particulier comment il traite le JS, l’arbre DOM (le HTML) et le CSSOM (le CSS).

La connaissance de ceci permet de savoir où placer les différents éléments.

Par exemple : le HTML commence à charger, mais le JS est bloquant : dès qu’il y a du JS dans la page (inline, ou non), alors le parsage du HTML se pause : ceci, car le JS peut modifier le HTML. Il est donc inutile de parser un truc qui peut être changé par la suite.

Or, le JS peut également toucher au CSS. Pour ça, le CSSOM doit être prêt. Donc le CSS doit être parsé pour que le JS puisse être éxécuté, et le JS doit être exécuté si on peut que le HTML soit parsé.

Dit autrement, le navigateur doit avoir fini de charger dans cet ordre :
– le CSS
– le JS (se finit après le JS)
– le HTML (terminé à la fin, quand la dernière balise se ferme)

Aussi, si on veut que la page s’affiche vite pour que le lecteur le lise rapidement, il faut donc que le CSS soit fini le plus tôt possible pour que l’information (portée par le HTML) soit affichée correctement.
Enfin, vu que le JS est bloquant, l’information utile de la page doit être affichée avant l’exécution des scripts.

Du coup, on voit bien que le CSS doit être placé au début du document et le JS à la fin : https://lehollandaisvolant.net/?d=2015/08/27/18/46/54-pourquoi-mettre-le-javascript-a-la-fin-et-le-css-au-debut

https://blog.logrocket.com/how-browser-rendering-works-behind-the-scenes-6782b0e8fb10

#18159

Pure CSS floating label

Un "floating label" en CSS qui marche tout le temps (sans JS).

Ça utilise le :placeholder-shown, mais peu importe, c’est relativement bien supporté : https://caniuse.com/#feat=css-placeholder-shown

Ah et surtout, ça utilise un vrai "label" et pas le placeholder, justement (qui est là et nécessaire, mais vide). Ça reste donc accessible pour les lecteur d’écran. Le fait de placer un span dans le label ne doit pas changer quoi que ce soit de ce côté là.

https://codepen.io/lehollandaisvolant/pen/vvavWJ?editors=1100

#18157

CSS3 Grid Layout - Alsacreations

Purée, les Grid en CSS c’est trop bien !

J’avais déjà été ébloui par les flex-box et leur possibilités (voir là), mais les grid ne sont pas en reste non plus !

Par exemple, je veux faire un formulaire pour remplir sont adresse postale, sous la forme suivante :


|--------------------------|
| n° | nom de rue          |
|--------------------------|
| complément               |
|--------------------------|
| cp     | ville           |
|--------------------------|
| état        | pays       |
|--------------------------|

C’est à dire en respectant la disposition des champs. (un peu comme là)

Le truc, c’est que j’ai juste un seul <div> avec sept <input> qui se suivent. Je ne veux pas utiliser de <p> ou de <br/>.

La solution ? Les grid (comme dans Tron) !

Je déclare le <div> comme étant une grille, divisée en 10 sections de 10 % chacune sur la largeur. Pour les lignes, le retour à la ligne est automatique ici (mais le grid permet également de modifier ça comme on veut !).

Ensuite, je donne à chaque <input> sa position : numéro de ligne, numéro de colonne et un sorte de « colspan ».

J’en ai fait un codepen pour voir ça directement : https://codepen.io/lehollandaisvolant/pen/aPjBXK?editors=1100

Et tout est parfaitement aligné, responsive et flexible ! C’est ça qui est tellement mieux qu’avec des floats !

https://www.alsacreations.com/article/lire/1388-css3-grid-layout.html

#18115

CSS Values and Units Module Level 3

Tiens, il existe une unité CSS équivalente au "em", mais pour les chiffres : le "ch".

Le "em" est la hateur du "M" dans une police donnée (du caractère du M, en fait, la pièce en plomb permettant d’imprimer un "M", qui pour le M était carrée). Elle peut être utile si, par exemple, votre bloc de texte doit faire exactement 10 lettres de large. De cette façon, que le bloc contienne "iiiiiiiiii" ou "mmmmmmmmmm", sa largeur sera toujours identique (par exemple pour aligner des blocs).

Pour les nombres, on peut utiliser le "ch" : les lettres sont toutes moins larges que les lettres, donc utiliser des "em" peut ne pas être pertinent.

Perso j’utilise ça pour un bloc qui contient une date : 25, ou 31, par exemple, mais aussi 1 ou 3. La case doit toujours faire la même largeur. Je ne veux pas utiliser le "px" car ce n’est pas proportionnel. Utiliser le "em" est chiant aussi car (à part pour les polices à chasse fixe), les largeurs des lettres et celles des chiffres ne sont pas toujours consistantes.
Du coup j’utilise ici une largeur de "2ch".

Notez qu’il existe aussi l’unité "ex" qui est la hauteur d’un x dans une police donnée.

Le ch est plutôt bien supporté par les navigateurs.

Voir aussi : https://css-tricks.com/the-lengths-of-css/

https://www.w3.org/TR/css3-values/#ch

#18095

CSS : fixed cell-width with text-overlflow management

Les tableaux sont chiants à styliser en CSS, mais je viens de trouver une méthode qui marche pas mal.

Pour les cellules de taille fixe, il faut leur donner un `width` et un `max-width` de la même valeur.

Par contre, il faut toujours qu’une des cellules fasse office de "bouche-trou" et prenne toute la place restante. Ça c’est obligé. Ou alors, il ne faut pas donner de width:100% au tableau lui-même. Dans ce cas, le tableau ne prend que l’espace qu’il a besoin.

ÉDIT : je l’ai amélioré un peu.
Regardez la dernière cellule : elle est aussi large que son contenu.

Dans cet exemple on a donc un tableau :
— avec ces cellules de taille fixe (1, 2). Le texte s’adapte à la cellule.
— avec des cellules de taille variable (3). La cellule est flexible en fonction du contenant et de la taille de la page (ou de la fenêtre de navigation). Le texte s’adapte à la cellule.
– avec des cellules de taille variable (4). La cellule est flexible en fonction du contenu. La cellule s’adapte au texte.

https://codepen.io/lehollandaisvolant/pen/REVNLy?editors=1100

#18052

Le Hollandais Volant

Oh et j’ai changé (légèrement) le thème de mon site.

J’utilise une jolie astuce CSS qui permet de faire deux colonnes de blocs de taille variable, avec en prime la possibilité de garder l’ordre des articles (sur Firefox en tout cas).

Normalement, quand on utilise des colonnes, les éléments HTML sont placés dans la première colonne puis dans la seconde. C’est le comportement que vous avez sous Chrome (ou Vivaldi, Opera…).

Firefox permet un petit truc en plus : si on regarde les articles par ordre chronologique, ils sigzaguent !
Vous me direz que c’est simple et qu’il suffit des inline-block… sauf que les inline-block ne permet pas de garder prendre des blocs de taille variable et d’avoir un beau rendu façon « journal ».

Je trouve ça tellement chouette que je vais mettre ça ailleurs aussi.

Je n’utilise pas de float non plus (qui aurait rendu compliqué un design fluide et responsive). Bien-sûr, tout est 100% CSS !

Si vous voyez des bugs sur un navigateur récent, merci de me le signaler :-)

ÉDIT : après quelques remarques :
– j’ai rajouté le nuage de tags. Je ne pensais pas que quelqu’un les utilisais encore…
– j’ai remis les blocs dans l’ordre sur un affichage mobile (un oubli de ma part).
– le layout en double colonne est joli, mais n’est pas pratique sous Chrome, à cause de l’ordre des éléments. Je ne peux pas faire comme dans Firefox à cause d’un bug dans Blink (il est marqué comme résolu mais ça ne l’est pas pour le mode "Column" de flexbox, et ça ne sera jamais corrigé malheureusement : il est en wontfix).
Du coup, soit je passe par un brin de JS pour forcer les deux colonnes (c’est juste un "height" à fixer), soit je repasse en mode colonne unique.

https://lehollandaisvolant.net/

#18048

Note : Astuce CSS

Imaginez vous avez un template avec N posts à la suite. S’il y N articles, vous voulez un style A. S’il y a 1 seul article, par contre, vous voulez un style B.

Le CSS est très simple :

#blog > article {
    width: 500px;
}
#blog > article:first-of-type:last-of-type {
    width: 1000px;
}

L’idée est que si l’article est tout seul, il est à la fois le premier et le dernier !

Par exemple, là, je bosse sur un design où les articles sont mis côté à côté de largeur 500px. Quand un seul article est affiché, je veux en revanche qu’il occupe toute la largeur.

https://lehollandaisvolant.net/?mode=links&id=20181209215006

#18046

Note

PUTAIN C’EST QUOI CES SITES DE MERDE QUI M’EMPÊCHENT DE SCROLLER COMME JE VEUX AVEC LE CLIC-MOLETTE?

Vous allez me laissez utiliser ma souris et mon clavier oui ???

https://lehollandaisvolant.net/?mode=links&id=20181209184405

#18043

You need neither PWA nor AMP to make your website load fast @ tonsky.me - Liens en vrac de sebsauvage

+1

La remarque la plus pertinente dans l’histoire c’est quand il dit que la plupart des applications ne sont que des fenêtres web et ne fonctionnent pas sans connexion. Autrement dit, n’importe qui d’offline ne les ouvrirait même pas.

Facebook, Tinder, Tumblr, Twitter… tout ça ne sert à rien sans connexion. Conclusion ? Gardez-ça dans le navigateur.

Et quand bien même ces applications (genre Facebook) enregistraient les derniers posts en local pour les servir en offline… qui donc aurait envie de relire des posts déjà lu ? Les réseaux sociaux comme ça ne sont pas fait pour être lus et relus : ce ne sont pas des ressources utiles qui s’utilisent en offline et que l’on veut archiver.

L’avantage que je vois dans les PWA (et qui m’a poussé à aller voir ça de près) c’est le fait de pouvoir utiliser ça offline. Y compris des choses qui n’ont aucune interaction avec le serveur. Mon site, mon blog, fonctionne très bien dans le navigateur : pas besoin d’un app ni d’un PWA pour ça.
Par contre, mes petits outils, pour certains, si, ça m’est déjà souvent arrivé d’être dans le train, de vouloir noter un truc et de ne pas avoir de connexion.

Les PWA (et les applications en général), ne sont utiles quand s’ils sont entièrement fonctionnels en offline. Autrement c’est pas la peine.
À la limite, les données sont synchronisé avec un serveur, mais l’essentiel doit se passer sur l’appareil. Pas l’inverse !

***

Récemment (hier) j’ai revu tout le CSS de mon site… Au total, j’ai réduit ça de pas moins de 10 %. Le HTML a été réduire aussi (~25%) et le JS est resté stable. Tout ça pour dire que y a d’autres façons d’optimiser les choses.
Pour le CSS, ne factorisez pas. Il faut mieux réutiliser du HTML (et donc le CSS) plutôt qu’appliquer des styles identiques à deux éléments HTML différents. Ça ne vaut pas le coup, c’est impossible à maintenir et c’est un nid à redondances.

https://sebsauvage.net/links/?tIbZtg