#20072

A Love Letter to HTML & CSS | CSS-Tricks

+1

Tout le monde est là « nianiania, petit joueur ! CSS c’est pas un vrai langage ! » pourtant les trois-quart du temps, tout le monde se pète les dents dessus :D

Et pour le HTML, c’est pas parce que c’est « juste » de la mise en page que c’est pas important ni difficile.
Essayez donc de réciter tous les éléments HTML : https://codepen.io/plfstr/full/zYqQeRw ! Je paris que la plupart en omettront au moins une quarantaine.

https://css-tricks.com/a-love-letter-to-html-css/

#19903

Better Line Breaks for Long URLs | CSS-Tricks

L’ajout de l’élément WBR agit comme un tiret de césure conditionnel, qui permet de couper en deux un mot lorsqu’il arrive en fin de ligne.

Dans le cas des URL qu’on afficherait tels quels sur une page (dans une feuille de style pour l’impression par exemple), il peut être utile.

M’enfin pour ma part je préfère utiliser le CSS « word-break: break-all; ». Comme ça, ça coupe où ça doit couper, peu importe où c’est. C’est juste plus rapide :D

https://css-tricks.com/better-line-breaks-for-long-urls/

#19736

HTML Elements Memory Test

Pour ceux qui font du HTML : vous connaissez DIV, P ou TABLE… Mais combien d’autre en connaissez-vous ?

Perso j’en suis à 65. Il en reste 50…

Et encore, ça c’est en se creusant un peu la tête. C’est d’ailleurs fou de se dire que 99,99 % des pages web pourraient être fait avec environ une trentaine de ces éléments. Certains sont réellement très spécifique (mais c’est beau de les avoir) !

Pour ceux qui veulent la liste et tricher : https://developer.mozilla.org/fr/docs/Web/HTML/Element

https://codepen.io/plfstr/full/zYqQeRw

#19597

What is the Value of Browser Diversity? - daverupert.com

C’est vrai tout ça : la mise au point de CSS3 et HTML5 s’est faite alors qu’il y avait de multiples moteurs CSS et plein de moteurs de rendu : KHTML, WebKit, Gecko, Presto, Trident…

On se souvient des heures passées à essayer de faire un truc précis sur une page et qui marche partout.

Mais on oublie les années passées par le W3 à faire une doc qui plaise à tous, et par les éditeurs de ces nav pour les implémenter.

L’avantage de cette difficulté énorme, c’est qu’on doit prendre son temps : mesurer chaque changement, chaque mise à jour déployée, bref, faire les choses bien et faire ce qu’il faut, pas forcément ce que les gens veulent ni le faire vite.

Aujourd’hui, on a 90% de Webkit/Blink et 10% de Gecko. Le reste, c’est tout mort.

Et Webkit/Blink, c’est Google : ils contrôlent le web, ils contrôlent des millions de sites, ses ressources (lib JS, fonts…), des framework, AMP, imposent ses règles en matière d’optimisation, de SEO… Bref, on ne peut pas faire un site sans se plier aux règle faites par Google (en tout cas pas si l’on souhaite toucher du monde).

Résultat ?

Si Google veut une fonctionnalité, elle le livre dans Blink et hop, en trois semaines t’as 90 % des navigateurs qui ont la fonctionnalité active et opérationnelle (rappel : avant ça prenait bien 5 ans). Et pareil pour retirer une fonction.

Alors les webdev sont content, les usagers sont content et le Google est content.

Qui n’est pas content ?

Ceux qui n’ont pas le réseau pour adéquat pour naviguer dans des pages de 20 Mo, ceux qui veulent un web décentralisé, indépendant, libre. Ceux qui veulent essayer de vivre du web sans se plier aux règles de Google en matière de SEO, de fonctionnalités.

Donc ouais, faire des sites compatibles avec toutes les techno des navigateurs, c’est dur. Mais ça oblige parfois à mettre de côté son égo et les trucs trop fancy/inutiles et se focaliser sur le contenu, les choses essentielles et surtout l’utilisateur.

https://daverupert.com/2020/09/the-value-of-browser-diversity/

#19297

Why the GOV.UK Design System team changed the input type for numbers - Technology in government

Pourquoi il est parfois préférable d’utiliser

<input type=”text” inputmode=”numeric” pattern="[0-9]*">

au lieu de

<input type=”number”>

Ça se tient.
Après le fait d’avoir deux solutions pour une même problématique me semble être le vrai problème dans l’histoire, mais bon.

Via cet article sur quelques autres problèmes intrinsèque aux spec HTML ou à la façon dont les nav les implémentent : https://daverupert.com/2020/02/html-the-inaccessible-parts/

https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/

#19102

Optimiser et accélérer les pages web - lehollandaisvolant.net

J’ai mis à jour cette page.

J’ai ajouté :

L’utilisation du CSS font-display pour les polices d’écriture.
Il gère la façon dont le le navigateur affiche/attend le chargement de la police.
C’est à cause de ça que, parfois, les pages affichent un texte vide tant que la police n’est pas chargée.

On peut contrôler ça :

font-display: fallback;

réduit à 100 ms le temps d’attente avec le premier affichage de texte. Si la police est chargée, elle l’utilise ; sinon, elle utilise la police fallback (une police système de préférence). Pour le corps du texte, c’est ce qu’il y a de mieux.

font-display: block;

force l’attente du chargement de la police. C’est utile si vous utilisez les webfont pour vos icônes. Sans ces polices, les icônes ne s’affichent pas et aucune police système ne les remplacera. Il faut donc l’attendre.

D’autres valeurs sont possible, voyez là.

L’utilisation des src-set pour les images.

Cela permet de dire au navigateur quelle image charger pour quel taille d’écran. Ça oblige d’avoir plusieurs tailles de chaque image sur le serveur, mais ça évite à un mobile en 3G de charger image en 4K de 3 Mo là où une image de 640px suffit.

Bien-sûr, si la taille de l’écran change, il peut arriver que ça fait plus de données à afficher. Mais soyons sérieux : est-ce que vous changez souvent la taille de votre écran/fenêtre ? Et sur mobile, passez-vous toute la journée de paysage à portrait et inversement ?

L’ajout de l’attribut loading sur les images.
C’est le projet du lazyload natif en HTML. Ajoutez juste ça sur vos images et iframes :

<img src="" alt="" loading="lazy" />

Ce n’est pas encore supporté partout, juste sur Chrome/Opera, mais c’est en bonne voie et il ne faut pas s’en priver.

https://lehollandaisvolant.net/tuto/pagespd/

#18643

Everything You Ever Wanted to Know About inputmode | CSS-Tricks

Oh !!

L’attribut « inputmode » permet de choisir quel clavier sera affiché (surtout pour mobile et claviers virtuels) : clavier alphanumérique, clavier téléphonique, numérique, décimal…

C’est similaire à mettre « type="numeric" » ou « type="email" » (au lieu de « type="text" »), sauf que inputmode ne modifie que le clavier, pas ce qu’on tape avec.
On peut donc très entrer « bonjour » dans un champ avec « inputmode="email" » : ça sera valide, car ça reste un type text.

Aussi, il est possible (à tester) que le navigateur ne modifie pas le design du champ (par exemple Safari ou Chrome utilisent un champ/bouton spécifique pour les champs de type="search", ce qui est très chiant parfois).

https://css-tricks.com/everything-you-ever-wanted-to-know-about-inputmode/

#18640

Note : astuce d’accessibilité en HTML

Quand on mettez un texte alternatif sur les images (attribut « alt ») ou les vidéos (directement dans l’élément <video></video>), mettez une phrase : avec une majuscule et un point.

Comme ça, les lecteurs d’écrans vont lire ça correctement, et pas juste comme 2 ou 3 mots sortis de nulle part.

(Bien-sûr, pour ça faut déjà mettre un texte alternatif à la base, n’est-ce pas ¬_¬.)

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