#20929

Write HTML, the HTML Way (Not the XHTML Way) | CSS-Tricks - CSS-Tricks

Le XML est beaucoup plus strict que le HTML. Certaines pratiques qu’on utilise normalement en HTML aujourd’hui sont héritées de l’époque où c’était XHTML qui servait à faire des pages web, mais sont parfaitement facultatives.

Cette page donne une petite liste de ces pratiques.

Maintenant, je préfère utiliser la syntaxe plus stricte de fermer les éléments, même en HTML. Ou encore de mettre des quotes pour les valeurs données attributs, ou encore de mettre tout en minuscule.

Je m’autorise par contre à mettre les attributs courts, tels que « required » ou « contenteditable » au lieu de « required="required" » et « contenteditable="true" ».
Tout comme je préfère aussi mettre des point virgules en fin de ligne en JS ou en fin de déclaration en CSS, qui ne sont pas toujours obligatoires. D’ailleurs en JS, j’utilise toujours le « 'use strict' », qui se met dans un mode strict où la moindre erreur (affectation à une variable non déclarée, par exemple) renvoie une erreur.

Je trouve que ça encourage aux bonnes pratiques, mais c’est également une question de préférence et de lisibilité.

https://css-tricks.com/write-html-the-html-way-not-the-xhtml-way/

#20729

autocapitalize - HTML: HyperText Markup Language | MDN

Ajouter un attribut HTML à un input :

autocapitalize="none"

Permet d’éviter que les claviers virtuels mettent une majuscules à par défaut au premier mot.

On peut aussi mettre « sentences », « word » ou « characters » pour capitaliser chaque phrase (par défaut), chaque mot, chaque lettre.
Notez que ça n’empêche pas de modifier la casse du clavier virtuel, ça permet simplement de spécifier la casse par défaut d’un clavier virtuel. Pratique quand-même !

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/autocapitalize

#20567

<input type="search"> - HTML: HyperText Markup Language | MDN

Ah tiens, il y a un attribut « incremential » qui permet de faire une recherche incrémentielle dans un <input typee="search" />.

En gros, le formulaire est envoyé à chaque fois qu’on tape une lettre dans le champ. Ça demande bien-sûr du JS pour être traité correctement.
C’est pas standard par contre, et non supporté par Firefox.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/search#incremental

#20424

Twitter's div Soup and Uglyfied CSS, Explained — Giuseppe

Pourquoi les sites web à très large audience, et donc qui ont besoin d’un support d’une très large variété de plateformes préfèrent utiliser une soupe de DIV améliorés en CSS plutôt que les éléments natifs ?

Réponse courte : parce que les nav et les plateformes dérivent d’une utilisation à la souris sur un ordinateur et un grand écran. Ce n’est ni adapté au tactile, ni aux lecteurs d’écran, ni aux dispositifs destinés à l’accessibilité.
L’usage de DIV permet sa souplesse en CSS (pas besoin de "CSS-reset" dans tous les sens), et les différents attributs comme "role" sont là pour sémantiser tout ça artificiellement.

Bref, ça revient à utiliser des briques simples pour construire des compliqués, plutôt que des pièces compliquées pour construire des trucs simples. Ça se tient, même si je ne pense pas que c’est comme ça que le HTML va progresser sémantiquement parlant.

https://giuseppegurgone.com/twitter-html/

#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/