Vous n'avez probablement plus besoin des balises meta http-equiv dans vos pages HTML. D'ailleurs, bien peu étaient réellement standards et la plupart n'ont plus aucun effet dans les navigateurs modernes.

Faire de l'inspection du trafic chiffré, donc casser TLS pour écouter ce qu'il se passe et filtrer, notamment en entreprises, c'est faire du MITM, tout simplement.

Retour d'expérience sur une tentative de migration mitigée de Electron vers Tauri (2 technologies permettant de développer des applications de bureau avec les technos web).

Retour d'expérience sur une tentative de migration mitigée de Electron vers Tauri (2 technologies permettant de développer des applications de bureau avec les technos web).

La "nouvelle" Navigation API vise à remplacer l'actuelle History API qui n'a jamais été très ergonomique.

Cette nouvelle API est assez massive, elle propose – notamment pour les SPA (Single Page Application) – de centraliser la gestion de la navigation à un seul endroit.

Bien évidemment, ça ouvre la porte aux sites qui vont vouloir en faire trop, qui vont vouloir outrepasser le comportement natif du navigateur, et ça peut finir en grand n'importe quoi comme à l'époque des popups.

Heureusement il semble y avoir quelques garde-fous pour, par exemple, empêcher un site de rendre le bouton de retour natif du navigateur inopérant et ainsi vous piéger dessus.

Par contre j'imagine que rien n'empêche un site de créer des navigations programmatiques artificielles lorsque vous arrivez dessus pour qu'il faille appuyer un grand nombre de fois sur "retour" pour s'en échapper. Mais c'est techniquement déjà possible avec l'History API de toute façon.

C'est pour l'instant uniquement supporté par les navigateurs basés sur Chromium.

La documentation MDN est également disponible.

La "nouvelle" Navigation API vise à remplacer l'actuelle History API qui n'a jamais été très ergonomique.

Cette nouvelle API est assez massive, elle propose – notamment pour les SPA (Single Page Application) – de centraliser la gestion de la navigation à un seul endroit.

Bien évidemment, ça ouvre la porte aux sites qui vont vouloir en faire trop, qui vont vouloir outrepasser le comportement natif du navigateur, et ça peut finir en grand n'importe quoi comme à l'époque des popups.

Heureusement il semble y avoir quelques garde-fous pour, par exemple, empêcher un site de rendre le bouton de retour natif du navigateur inopérant et ainsi vous piéger dessus.

Par contre j'imagine que rien n'empêche un site de créer des navigations programmatiques artificielles lorsque vous arrivez dessus pour qu'il faille appuyer un grand nombre de fois sur "retour" pour s'en échapper. Mais c'est techniquement déjà possible avec l'History API de toute façon.

C'est pour l'instant uniquement supporté par les navigateurs basés sur Chromium.

La documentation MDN est également disponible.

Je ne pourrais pas être plus d'accord.

C'est encore une fonctionnalité native simple mais très puissante des navigateurs que certains frameworks ont encouragé à ignorer et à remplacer maladroitement.

Ça ne veut pas dire qu'il faut bannir le state en mémoire, mais simplement comprendre les avantages et inconvénients de chacun et les utiliser à bon escient. L'article illustre ça avec beaucoup de justesse.

Je ne pourrais pas être plus d'accord.

C'est encore une fonctionnalité native simple mais très puissante des navigateurs que certains frameworks ont encouragé à ignorer et à remplacer maladroitement.

Ça ne veut pas dire qu'il faut bannir le state en mémoire, mais simplement comprendre les avantages et inconvénients de chacun et les utiliser à bon escient. L'article illustre ça avec beaucoup de justesse.