Le Hollandais Volant

Des blagues CSS. Certaines sont bien marrantes.

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.

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

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

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 !

En CSS, en plus des linear-gradient et des radial-gradients, il y a maintenant le conic-gradients.

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/

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.

C’est sympa : ici, le footer reste en bas, même sur une page avec peu de texte. Ça utilise les CSS Grid.

Perso je lui préfère ma version basée sur min-height/position : https://codepen.io/lehollandaisvolant/pen/jXWQPr

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.

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.

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

Purée… le CSS c’est génial (j’adore ça) mais parfois c’est casse-tête.

Cette astuce par exemple, est très pratique quand on utiliser des menus fixes dans les pages web. Si on utilise des ancres, ça évite que l’ancre sur laquelle on clique soit cachée par le menu fixe (nav-bar).

Ça marche… sauf quand l’élément que l’on ancre est en flexbox. Là ça ne marche pas !

:/

Je n’ai pas de solution pour le moment. Du coup j’ai posté mon premier poste sur StackOverflow : https://stackoverflow.com/q/53674390/5099624 .

Un framwork CSS qui transforme tout en 8Bit façon NES ^^

Je suis en train de nettoyer mon CSS.

Et j’ai l’impression qu’on se fait bien trop chier (ou alors ce sont les spec qui ont bine changées).

Au bas mot 20 % des règles CSS que j’avais mise sont inutiles. Au mieux elles ne font rien, au pire, ont un comportement au final mauvais.

Il faut cesser de vouloir tout contrôler avec des reset CSS, soit au début, soit sur chaque élément.

Prenez les éléments pour ce qu’ils sont.
Si on utilise trop de reset sur un élément, êtes-vous bien sûr que vous utilisez le bon élément ? Ne prenez pas un H1 si c’est pour virer tous les styles. Ne prenez pas un P si c’est pour en faire un titre.

Pareil, quand on regarde le code source des pages de Google ou autre, il n’y a que des DIV. J’imagine qu’ils savent ce qu’ils font, mais c’est moche. Même les menus comme SELECT sont refait avec des DIV et du JS/CSS. Quelle horreur. Il n’y pas besoin d’aller jusqu’à ça pour avoir un beau design…

Prenez les éléments pour ce qu’ils font.
On critique souvent l’usage des listes : pour les menus, par exemple. Certains disent que les menus doivent être des DIV avec A.
Ok. Maintenant désactivez le CSS et regardez : votre menu ne ressemble plus à rien, si ce n’est qu’une suite de A qui se touchent. Dans ce cas là, une liste aurait été pertinente.

L’absence de CSS n’est pas un cas rare : quand votre page charge sur une connexion de merde, le HTML peut s’afficher avant le CSS. Avoir une liste qui devient ensuite un menu permet de s’y retrouver.

Ces lecteurs d’écran, navigateurs en mode texte, appareils de navigation destinés aux personnes ayant des difficultés pour naviguer dans une page web (handicap, etc.) se réfèrent aux éléments HTML ayant des styles spécifiques. Ça va des formulaires, bien-sûr, aux listes et aux titres.

Ne surchargez pas le HTML
Avez-vous bien besoin de faire un SPAN dans SPAN dans un BUTTON juste pour faire une icône avec une bordure ? Non : juste le BUTTON suffit si on sait manier les pseudo-éléments.

Si les pseudo-éléments ne servent qu’au design, alors ils n’apparaîtront pas dans une navigation sans CSS de toute manière.

Utilisez exclusivement le CSS pour le design.
On est en 2018 et je ne devrais pas avoir à le dire, mais bon… Le CSS est fait pour le design. Le JS c’est pour l’interaction avec la page, ou avec le serveur (Ajax). Pas pour styliser (ou alors il s’agit d’un style qui varie, mais là il n’est pas forcément mal non plus de passer par le DOM et de modifier des classes ou des attributs).

Les tableaux ne sont pas mal
On a longtemps dit que les tableaux HTML était le mal. Ce n’est pas vrai. Ils servent juste à faire des tableaux et pas autre chose. Ne faites pas une collection de SPAN disposés avec un « display: grid » si c’est pour une collections de données…

(…)