HTML `<blink>` et `<marquee>` (2020)

• Dans les pages perso des années 1990, on utilisait souvent du texte clignotant et défilant pour mettre en évidence les « dernières mises à jour », et ces deux balises sont devenues des traces d’une culture web aujourd’hui difficile à croiser
• <blink> est une balise apparue dans Netscape Navigator 2.0 en 1995 ; Lou Montulli est souvent cité comme source de l’idée, mais il a expliqué ne pas avoir écrit lui-même le code de l’implémentation
• La même année, Microsoft Internet Explorer 2.0 a introduit <marquee>, qui proposait des effets basés sur des attributs pour contrôler le sens du défilement, la vitesse, la répétition et le va-et-vient
• En imbriquant les deux balises, on obtenait du clignotement dans Netscape et du défilement dans IE, et même dans les navigateurs qui ne les prenaient pas en charge, le texte lui-même restait lisible
• <blink> a pratiquement disparu et <marquee> subsiste dans certains navigateurs modernes, mais sur de vrais sites web, cela relève davantage d’une nostalgie numérique nuisible à l’accessibilité et à l’utilisabilité

---

La course aux effets visuels lancée par les navigateurs des années 1990

• <blink> et <marquee> faisaient partie des éléments emblématiques du web design des années 1990 pour attirer l’attention sur les pages perso
• Même Macromedia Dreamweaver semble avoir traité l’enveloppement de <blink> dans <marquee> comme une sorte d’anti-pattern

• <blink> : d’une plaisanterie à une balise largement utilisée

  • L’invention de <blink> est généralement attribuée à Lou Montulli, mais il a précisé ne pas avoir écrit lui-même le code final de l’implémentation
  • Montulli est la personne qui a créé le navigateur en mode texte Lynx avant de rejoindre Netscape en 1994
  • Une anecdote raconte qu’alors que les ingénieurs de Netscape proposaient des effets visuels, il leur a répondu que cela ne fonctionnerait pas dans Lynx, et a plaisanté en disant que l’effet le plus tape-à-l’œil possible sur les deux navigateurs consistait à allumer et éteindre le texte
  • Par la suite, un autre ingénieur dont le nom n’a pas été rendu public a ajouté <blink> lors d’une session de travail tard dans la nuit
  • Netscape Navigator 2.0 a ajouté la prise en charge de <blink> en 1995, à la même époque que les GIF animés et une forme précoce de JavaScript
  • Son utilisation reposait sur une structure simple, sans attributs, comme <BLINK>This is my blinking text!</BLINK>
  • Au moment où la recommandation HTML4 est arrivée deux ans plus tard, <blink> avait été documenté sur le ton de la plaisanterie, mais il a été beaucoup utilisé sur le web de la fin des années 1990
  • On l’employait pour des titres comme « latest updates » sur des pages perso, ou pour entourer des blocs entiers, et l’ambiance de cette époque peut se découvrir sur Cameron’s World

• <marquee> : le texte défilant d’Internet Explorer

  • Microsoft a lancé Internet Explorer 2.0 la même année que Netscape Navigator 2.0
  • À l’époque, Internet Explorer cherchait encore à rattraper les fonctionnalités implémentées par Netscape, mais a introduit <marquee> au lieu de <blink>
  • <marquee> permettait, grâce à plusieurs attributs, de contrôler la direction du défilement, la vitesse, la répétition et le mouvement de rebond d’avant en arrière
  • Un exemple est <MARQUEE>Oh my god this still works in most modern browsers!</MARQUEE>, qui peut encore fonctionner dans certains navigateurs modernes

Ce qui se passait quand on superposait les deux balises

• À la fin des années 1990, il était aussi assez courant d’entourer un contenu que l’on voulait mettre en avant avec à la fois <blink> et <marquee>
  • Exemple : <MARQUEE><BLINK>This is my really important message!</BLINK></MARQUEE>
  • Les utilisateurs de Netscape voyaient un texte clignotant, tandis que ceux d’IE voyaient un texte défilant ou faisant un va-et-vient
• Cette approche s’accordait avec la façon dont le web ignore les éléments inconnus tout en continuant à faire le rendu
  • Selon la loi de Postel, un navigateur doit fournir le meilleur rendu possible à l’utilisateur même lorsqu’il rencontre une entrée qu’il ne comprend pas
  • Si l’élément <video> moderne n’est pas une balise auto-fermante mais un bloc, c’est aussi pour que les anciens navigateurs ne connaissant pas <video> puissent lire le code de remplacement à l’intérieur
• Même dans les navigateurs qui ne connaissaient aucune des deux balises, le texte du contenu restait lisible
  • En ce sens, on est proche d’une amélioration progressive : on ajoute des effets voyants uniquement dans les navigateurs compatibles et on laisse du texte simple dans les autres environnements
  • JavaScript et CSS peuvent être appliqués selon la même règle, ce qui aide la maintenabilité et l’accessibilité

Aujourd’hui, des fonctionnalités plus proches d’une trace historique

• Netscape 7 faisait partie des rares navigateurs à prendre en charge à la fois <blink> et <marquee> en 2002
  • Il existait des subtilités liées à l’ordre de prise en charge et aux éléments imbriqués, mais sur certaines pages perso, défilement et clignotement apparaissaient en même temps
• <blink> est désormais une balise pratiquement morte, même si l’on peut recréer un effet similaire en CSS si c’est absolument nécessaire
• <marquee> est encore vivant
  • Il existe non seulement des polyfills, mais aussi une prise en charge native qui subsiste dans certains navigateurs
  • Malgré cela, il vaut mieux éviter d’utiliser <marquee> sur de vrais sites web
• Le sujet est intéressant comme matériau pour apprécier la nostalgie numérique, mais il n’y a aucune raison d’imposer à d’autres utilisateurs du texte clignotant et défilant

[GN⁺]

Avis sur Hacker News

• https://web.archive.org/web/20201111125145/https://danq.me/2...

• On dirait que ça existait déjà il y a 3 000 ans
  Je me souviens de l’époque où l’on se disputait pour savoir si utiliser la navigation dans des frames était une mauvaise pratique. Pas des iframe, des frames. Avant AJAX, on utilisait HTTP 204 pour envoyer des messages au serveur sans rafraîchir la page, et au début des années 2000, on passait des jours dans Dreamweaver à tracer les frontières des États sur une carte d’un pays pour créer des images cliquables
  Quand une mise à jour de modèle Dreamweaver écrasait les changements, il n’y avait pas de gestion de versions pour les récupérer, et on traitait parfois côté backend la position du clic dans l’image. On streamait les mises à jour de page en Motion JPEG, et pour corriger l’alpha blending des PNG dans IE, on passait par plusieurs étapes avant de finir par s’appuyer sur une approche ActiveX
  On construisait la navigation des sites en Java, Flash et Silverlight, et je me souviens aussi à quel point les GIF espaceurs, les commentaires conditionnels et Firebug semblaient providentiels. Je ne sais pas quand je suis devenu vieux ; un jour, c’était juste le cas

  1. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
  • Je faisais des logiciels web avec des frames et je pensais que ça ne posait aucun problème. Aujourd’hui encore, je ne sais pas vraiment quels sont les vrais problèmes des frames ; on mentionne parfois l’accessibilité avec les lecteurs d’écran, mais je ne sais toujours pas précisément ce qui cloche
  • J’ai travaillé pour un client qui devait prendre en charge IE6, et au milieu de tous les bugs et contraintes, je désespérais chaque fois que le designer envoyait une maquette Photoshop avec des coins arrondis
    Il fallait aussi du responsive, mais à l’époque il s’agissait surtout de s’adapter à différentes tailles de bureau, et il fallait généralement découper les coins pour les placer dans des cellules de tableau. Faire ce genre de choses à la main finit par vous donner, en tant que développeur, une étrange résistance
  • Je me souviens avoir découpé des GIF avec une extrême précision à l’aide de l’outil tranche de Photoshop pour les placer exactement dans des tableaux HTML
    C’étaient des designs optimisés pour du 800x600, et tous ces moments se sont perdus dans le temps, comme des larmes dans la pluie
  • Je visite encore plusieurs fois par semaine des sites qui utilisent des frames. On dirait que personne n’a dit aux gens de l’Open Group/POSIX qu’on n’est plus censé utiliser des frames aujourd’hui
  • J’avais créé un webchat avec des frames. En haut, une zone où le texte se chargeait indéfiniment ; en bas, un champ de saisie qui recevait une réponse 204 pour ne pas se rafraîchir quand on envoyait un message
    À l’époque d’IE4+, ça me semblait être la manière la plus élégante de faire

• C’est quelque chose que j’ai fait il y a longtemps, et chaque fois que je le montre, les gens sont surpris qu’il n’y ait absolument aucun JavaScript. Toutes les animations sont faites uniquement avec la balise marquee : https://udel.edu/~ianozi/

  • Je n’ai sans doute pas vu la balise marquee depuis une vingtaine d’années, donc j’avais peut-être oublié, mais je ne savais pas qu’on pouvait faire un défilement vertical avec le paramètre direction
  • https://no-js.abhij.it/

• Ma technique préférée avec marquee consistait à les imbriquer dans des directions différentes
  Si la marquee intérieure se déplaçait dans le sens opposé à l’extérieure, à la même vitesse, on pouvait donner l’impression que le contenu défilait puis s’arrêtait ; et avec davantage de niveaux en alternant les vitesses, on pouvait aussi obtenir un effet de déplacement aléatoire. Il me semble qu’il fallait donner une largeur maximale à la marquee intérieure pour que ça fonctionne

• Il y a une raison pour laquelle marquee est très utile : l’injection HTML
  marquee bouge, et comme presque personne ne l’utilise intentionnellement, il est facile de voir si une attaque a réussi lorsqu’on teste une vulnérabilité d’injection HTML. Même pour des non-techniciens, « ça ne devrait pas bouger, mais ça bouge » passe beaucoup mieux que « ce texte ne devrait pas être en gras, mais il l’est »

  • Quand je fais de la sanitation HTML, j’ajoute en easter egg uniquement marquee à la liste d’autorisation, et je n’autorise presque rien d’autre
  • Je consulte Hacker News via un agrégateur personnalisé, et grâce à cet article, j’ai découvert que mon agrégateur était vulnérable à l’injection HTML. À l’écran, (2020) défilait comme une marquee
  • J’ai toujours utilisé la balise <plaintext>. Comme c’est un élément qu’on ne peut pas fermer, elle transforme tout le reste du document en HTML brut, donc c’est très visible
    https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

• La balise blink était évidemment détestée depuis longtemps, et j’avais essayé, à titre expérimental, de chercher "blink" dans le binaire d’un navigateur que j’utilisais, probablement Netscape, pour le remplacer par "blonk". Et voilà, ça ne clignotait plus

  • L’édition de binaires était, et reste, assez amusante. Je me souviens avoir remplacé "__gnu_warning" par "__gnu_whining" pour faire taire les remontrances inutiles autour de gets()
    Bien sûr, il y a le risque de dépassement de tampon, mais si vous utilisez un programme jetable, il suffit de ne pas dépasser le tampon
  • J’ai aussi bricolé le client Slack comme ça. L’avantage des applis Electron, c’est que c’est vraiment simple, et on peut supprimer les fonctionnalités qu’on n’aime pas
    Par exemple, masquer les notifications ou désactiver l’envoi du signal indiquant que je suis en train d’écrire un message

• « La bête apparaîtra entourée d’un nuage tourbillonnant de vengeance. La maison des incroyants sera rasée et ils seront brûlés jusqu’au sol. Leurs balises clignoteront jusqu’au jour du Jugement. »
  C’est un passage de The Book of Mozilla, 12:10 dans about:mozilla, et maintenant Mozilla brûle jusqu’au sol. Fin

  • Malgré tout, j’utilise encore Firefox comme navigateur principal

• Un ami avait l’habitude d’entourer son deuxième prénom avec des balises pour repérer rapidement les échappements manquants et les XSS potentielles. À l’époque, ça trouvait étonnamment bien les problèmes

• Ce commentaire est en construction. Revenez souvent pour voir les mises à jour

  • Où sont le compteur de visiteurs et le livre d’or ?
  • Pour quel navigateur cette page est-elle optimisée ?
  • N’oubliez pas non plus [NEW]

• Une des raisons pour lesquelles les gens détestent ce genre d’éléments, c’est qu’ils ont été surutilisés
  Mais c’est justement cet abus qui a poussé beaucoup de gens à essayer HTML par eux-mêmes. Pour quelqu’un qui débutait en HTML, essayer blink ou marquee était assez gratifiant, une sorte de drogue d’initiation au monde du HTML
  Ceux qui utilisaient ces éléments ont sans doute fini par apprendre qu’il ne fallait pas le faire, ou alors c’était une page mySpace et ils ont continué. Il est facile de se moquer de blink et marquee, un peu comme un graphiste méprise quelqu’un qui utilise Comic Sans, mais ces tabous ont été très utiles pour donner aux gens la confiance de se dire : « allez, j’essaie »