Après, en y regardant de plus près, dans le commit lié ci-dessus il s'agit d'enlever protocole et domaine, donc c'est toujours valide. Si le browser ne supporte pas de tels liens il faut corriger le bug dans le browser.
Des commits plus pertinents sont:
16adf9a5aee76e7a6f0c3c0a3e79ae6502149b21 Accept protocol-relative links to linuxfr.org in news links
193f3b348302cc8b48a83fcce40ac606f63c2049 Use protocol relative in 400.html
c2648f6cef078b583da58077275e28fe27c6681d Use protocol-relative URL for the image in wiki help
551918514f3b7fd365cc54db1a57e5a8db9ac875 Default avatar URL should be protocol-relative
Mais l'analyse reste juste. Ces URLs sont utilisées pour e.g. intégrer des images et intégrer une image en HTTP posait problème quand on voyait le site en HTTPS. Dans la mesure où DLFP utilise maintenant HTTPS partout, ça ne sert à rien de les conserver. C'est aussi la décision qu'a prise Wikipedia apparemment: mettre à jour les liens sans URL pour inclure https://.
Comme les commits ci-dessus impliquent surtout que DLFP a accepté les URLs sans scheme dans les contenus, il faudra soit modifier les contenus existants soit silencieusement ajouter le préfixe https://.
Ceci dit, AMHA le bug est avec le browser s'il casse la compatibilité ascendante de la sorte...
[^] # Re: https:// partout
Posté par nud . En réponse à l’entrée du suivi Liens (image) "protocol-relative / implicit" dans les flux. Évalué à 3 (+0/-0). Dernière modification le 03 janvier 2023 à 09:15.
Après, en y regardant de plus près, dans le commit lié ci-dessus il s'agit d'enlever protocole et domaine, donc c'est toujours valide. Si le browser ne supporte pas de tels liens il faut corriger le bug dans le browser.
Des commits plus pertinents sont:
Mais l'analyse reste juste. Ces URLs sont utilisées pour e.g. intégrer des images et intégrer une image en HTTP posait problème quand on voyait le site en HTTPS. Dans la mesure où DLFP utilise maintenant HTTPS partout, ça ne sert à rien de les conserver. C'est aussi la décision qu'a prise Wikipedia apparemment: mettre à jour les liens sans URL pour inclure
https://.Comme les commits ci-dessus impliquent surtout que DLFP a accepté les URLs sans scheme dans les contenus, il faudra soit modifier les contenus existants soit silencieusement ajouter le préfixe
https://.Ceci dit, AMHA le bug est avec le browser s'il casse la compatibilité ascendante de la sorte...