On peut gérer la façon dont le nav envoie le referer aux sites liés.
Y a plein d’options (certaines ont arrêté d’être supportés d’ailleurs), mais celle que je trouve utile c’est elle :

strict-origin-when-cross-origin

Elle envoie le référer complet au pages du même site, mais aux sites extérieurs limite l’envoie à la seule "origine" (le NDD, essentiellement, avec le protocole).
Retirer complètement le referer peut être utile dans quelques cas, mais dans beaucoup d’autres, les sites bloquent les requêtes sans referer. Ne laisser que l’origine peut être un compromis acceptable.

À défaut d’utiliser les en-têtes HTTP, on peut utiliser un élément HTML meta :

<meta name="referrer" content="strict-origin-when-cross-origin" />

Liste de tous les éléments HTML.

C’est une page très simple : ça dit juste si c’est un inline/block/autofermante/header et si c’est expérimental. Y a ensuite un lien avec quelques détails.

C’est fou ce qu’on peut faire avec un tweet long de code : https://twitter.com/KilledByAPixel/status/1517294627996545024

Et ça marche : essayez dans un Codepen (n’oubliez pas de cliquer sur la zone blanche après avoir collé le HTML).

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

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 !

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.

Tout un tas de petites astuces HTML méconnues et qu'on a tendance à refaire en JS pour rien.

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.

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

Voilà.

Oui c’est un outil de feignasse.

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

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

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.

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/