Vivement les variables CSS ! – HTeuMeuLeu

#16458

Les variables peuvent se déclarer dans le body, ou encore le ::root, mais également dans des .classes.

Dans ce cas ils agissent comme des variables locales : si une variable est déclarée sur le .red et le .blue, alors un élément .block pourra avoir le couleur selon sa classe, quand bien même la variable utilisée pour cette couleur soit la même (voir la dernier exemple en bas).

http://www.hteumeuleu.fr/vivement-les-variables-css/

Note : détecter un navigateur mobile en JS

#16322

Généralement j’ai besoin de savoir si je suis sur mobile ou pas à cause des différences d’interaction entre mobile et desktop (pas de drag-n-drop possible sur mobile par exemple).

Ma méthode c’est de tester une propriété CSS en JS.
Vu que j’utilise les mediaQueries en CSS, quand je suis sur mobile, le CSS appliqué est changé et je détecte ça en JS.


body {
    color: blue;
}
@media (max-width: 700px) {
    body {
        color: red;
    }
}

var isMobile = (window.getComputedStyle(document.body).color != 'red') ? true : false;

Il suffit soit de détecter une propriété dont on est sûre qu’elle sera appliquée sur mobile, soit d’appliquer spécifiquement un bout de CSS bidon sur un élément bidon en CSS, spécifiquement pour cet usage.

Par exemple comme ça :


html {
    color: red;
}
body {
    color: black;
}
@media (max-width: 700px) {
    html {
        color: blue;
    }
}

Ici la page sera toujours en noir, à cause du body, prioritaire sur le html. Mais la couleur sur le html joue le rôle d’un flag.
Bien-sûr, ceci n’est valable que pour la majorité des cas et reste une détection basée sur la taille de l’écran (ou du viewport plutôt).

Si vous avez un écran tactile de 15 pouces, c’est sûr que ça restera le même CSS que sur un écran de PC de 15 pouces alors qu’au fond l’UX sera différente.

On peut toujours détecter la taille de l’écran directement en JS, mais c’est parfois difficile à cause des pixel ratio qui sont intégrées ou non (suivant le nav) dans la taille de l’écran détecté en JS.
Regardez la taille de l’écran sur un mobile sur cette page, vous verrez que ça n’est pas toujours la taille réelle en pixels de votre écran.

Mais ça peut suffire dans la plupart des cas et c’est léger.

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

How to animate "box-shadow" with silky smooth performance | Tobias Ahlin

#16281

Les animations CSS sont cool, mais parfois gourmandes en ressources. Ici une astuce pour améliorer les performances quand on veut animer une box-shadow sur un bloc au :hover.

Au lieu de faire

#box {
    box-shadow: 4px 4px 4px transparent;
    transition: box-shadow 1s ease;
}

#box:hover {
    box-shadow: 4px 4px 4px silver;
}

Préférez d’ajouter un ::after sur le block, avec une ombre fixe.
Ensuite, mettez la transition sur l’opacité du ::after.

Le truc c’est que les moteurs de rendus ne calculent que l’opacité du ::after, et non l’ombre qui est bien plus lourde à produire et donc à animer (car elle dépend de plein de choses, dont les dimensions du bloc.

#box {
    position: relative;
}
#box::after {
    content: "";
    position: absolute;
    z-index: -1;
    top: 0; bottom: 0; left: 0; right: 0;
    box-shadow: 4px 4px 4px silver;
    opacity: 0;
    transition: box-shadow 1s ease;
}

#box::after:hover {
    opacity: 1;
}

http://tobiasahlin.com/blog/how-to-animate-box-shadow/

Do responsive sites have to be so tall on mobile? | Viget

#16269

Je suis d’accord : un truc que le responsive design fait, c’est qu’il réorganise à la vertical les éléments d’une page, faisant en sorte que la page est super longue, y compris simplement un article (juste par le fait des éléments qu’il contient).

Pour modifier ça, et mettre comme il propose, certains élements spéficique en ligne et d’autres en dessous en colonne, il faut utiliser du JS (pour déplacer physiquement les éléments au sein du HTML).

Une autre solution peut être le CSS avec Flex et Grid.
Le premier est largement supporté, mais le déplacement des éléments reste (selon moi) une fonctionnalité relativement secondaire des Flexbox (qui permet avant tout de faire des boîtes flexibles). Grid commence tout juste à pointer le bout de son nez, il n’est pas encore bien implémenté partout.

https://www.viget.com/articles/do-responsive-sites-have-to-be-so-tall-on-mobile

Simple Table-Of-Contents in JavaScript (enhanced)

#16262

J’ai publié ce pen avec du JS pour faire un sommaire (TOC) dans une page. Le TOC est totalement automatique.

Ici j’ai aussi ajouté mon astuce pour ajouter des numéros (le « 2.1 » sur le sous titre 1 du titre 2 de la page), à la fois dans le TOC et dans les h1, h2…
Ces numéros sont entièrement en CSS (avec la propriété counter — ancienne mais peu utilisée), c’est pour ça qu’ils ne sont pas sélectionnables.

J’utilise tout ça sur la plupart de mes pages depuis longtemps :
https://lehollandaisvolant.net/tuto/gpg/
https://lehollandaisvolant.net/linux/checklist/
https://lehollandaisvolant.net/tuto/tor/
https://lehollandaisvolant.net/tuto/pagespd/
https://lehollandaisvolant.net/tuto/bin/
etc.

position - CSS | MDN

#16242

Le positionnement « sticky » permet un effet sympa. C’est l’effet appliqué sur le sommaire, à droite sur cette page du MDN.

Ce mode donne un positionnement "relative" en temps normal et "fixed" dans certaines conditions, ces dernières étant définies avec les propriétés "top", "bottom", etc.

Si le défilement de la page force l’élément à sortir de la vue de la page (ou de la zone délimitée entre les "top", "bottom", etc.), alors le positionnement passe en "fixed" et le bloc reste visible.

Ça évite d’avoir à utiliser du JS.

À ce jour, seul Firefox le supporte.
Safari le prend si on met Webkit.
Chrome le prend en compte à partir de la version 56.
Edge, IE et Opera ne le prennent pas encore en compte.

On peut donc l’utiliser si l’effet recherché n’est pas bloquant.
Dans ce cas il suffit d’utiliser un fallback :

position: relative;
position: sticky;
top: 0;

Material Design and the Mystery Meat Navigation Problem

#16212

Une petite critique du Material Design, et de certains de ses problèmes récurrents.

Concernant le « mystery button » y a un truc qu’il faut pas oublier, c’est qu’une même icône a une signification basée sur le contexte, de l’application. Et ça, ce n’est pas un bug, c’est bien une feature !

https://medium.freecodecamp.com/material-design-and-the-mystery-meat-navigation-problem-65425fb5b52e

Avoid Default Browser Focus Styles | Adrian Roselli

#16211

Et il ne parle pas des thèmes sombres.

À une époque, j’avais abandonné les thèmes sombres sous Ubuntu justement pour ça : car les champs de formulaire avec la couleur par défaut étaient sombres aussi… avec un texte sombre.

C’est un peu à cette époque que j’ai découvert les couleurs CSS dictées par le système lui-même.

http://adrianroselli.com/2017/02/avoid-default-browser-focus-styles.html