Les hacks HTML qui ont façonné Internet
(tedium.co)- Les premiers développeurs web devaient composer avec des implémentations des standards et des défauts différents selon les navigateurs, ce qui rendait difficile de garantir de façon fiable la mise en page et le comportement souhaités avec du HTML/CSS valide uniquement
- Des environnements comme Netscape 4, Internet Explorer 5/6/7, Safari/WebKit ou Outlook ont fait naître du code de contournement propre à chaque navigateur pour le CSS, la transparence PNG, les commentaires, les sélecteurs et les aperçus d’e-mails
- Les mises en page HTML par tableaux, sIFR, Chrome Frame et le responsive design sont des exemples de combinaisons détournées de leur intention initiale pour dépasser des contraintes de design et les problèmes des anciens navigateurs
- Ces hacks avaient des limites — baisse de l’accessibilité, code non standard, dépendance à Flash et aux plugins — mais ils étaient à l’époque des moyens pragmatiques d’assurer la compatibilité et l’expression visuelle
- L’idéal des standards du web et les usages réels n’ont cessé de se heurter, et les contournements répétés des développeurs et designers ont durablement marqué le web design, le HTML des e-mails et l’adaptation au mobile
Les hacks CSS pour contourner les défauts des navigateurs
- Le hack
@importde Netscape Navigator 4.0 consistait à charger volontairement via@importdu CSS que Netscape ne prenait pas en charge, afin d’empêcher ce navigateur d’appliquer les styles avancés- Le CSS de base était chargé avec
<link>, tandis que le CSS plus avancé était séparé et chargé via@import - CSS Cookbook explique que cette méthode revenait à charger en parallèle un fichier CSS qui ne fonctionnait pas dans Netscape
- Netscape poussait JSSS au lieu de CSS, puis, après le choix de CSS par le W3C, implémenta CSS à la hâte dans Netscape 4 à l’été 1997
- Dans Netscape 4, désactiver JavaScript avait pour effet secondaire de désactiver aussi CSS
- Le CSS de base était chargé avec
- Les hacks CSS ciblant Internet Explorer 6 consistaient à ajouter un underscore devant une propriété, comme
_width, afin que seul IE6 interprète cette déclaration- Le modèle de boîte du W3C considérait que
widthexcluait la bordure et le padding, mais Internet Explorer gérait padding et bordure différemment, créant des différences de mise en page entre navigateurs - Un exemple typique était
width: 300px; _width: 320px; padding: 10px;, où une déclaration invalide en CSS standard servait de valeur de correction pour IE6 - Il existait aussi des hacks propres à IE, comme ajouter un point d’exclamation supplémentaire après
!importantpour obtenir un comportement différent uniquement dans IE7 et les versions antérieures
- Le modèle de boîte du W3C considérait que
Tordre la structure sémantique pour la mise en page
- La mise en page HTML par tableaux était un hack emblématique consistant à utiliser
<table>, initialement prévu pour représenter des données tabulaires, comme outil de placement visuel des pages- David Siegel abordait le web avec le regard d’un designer traditionnel et cherchait à créer des sites plus beaux, à rebours de l’usage voulant que le rendu visuel du HTML soit décidé par le navigateur
- Dans Creating Killer Web Sites, il explique comment contourner le balisage structurel, créer des compositions bidimensionnelles avec des images et, une fois les tableaux apparus, placer du texte dans des colonnes
- Jay Hoffman, de The History of the Web, résume que les puristes HTML/XML voyaient le mélange du design et de la structure du code comme un grand tabou
- Les mises en page par tableaux ont nui à l’accessibilité, et il a fallu du temps pour réparer ces effets, mais elles ont montré l’intérêt de permettre aux développeurs de composer visuellement des portails web
- Le responsive design, comme les mises en page par tableaux, combinait des technologies existantes d’une nouvelle manière, mais dans le cadre des standards du web, afin de modifier la mise en page selon la taille de l’écran
- Dans le web design des années 2000, l’implémentation en CSS du « Holy Grail layout », avec trois colonnes descendant jusqu’au bas de la page, était un grand sujet de débat
- Plusieurs contournements existaient, comme la création de fausses colonnes avec des images de fond, puis CSS a fini par prendre en charge les mises en page fondées sur des grilles
- Avec la diffusion des smartphones, la pertinence de l’ancienne mise en page à trois colonnes s’est affaiblie, et il est devenu nécessaire de financer des sites mobiles séparés
- Dans son article sur le responsive web design dans A List Apart, Ethan Marcotte a proposé d’utiliser les media queries pour adapter la composition d’un site au format de l’écran
- Le responsive design pouvait alors ressembler à un hack exploitant les media queries, encore peu familières, mais il a transformé durablement le web design
Images et commentaires de contournement à l’époque d’Internet Explorer
AlphaImageLoadercontournait, via un filtre propriétaire Microsoft, le fait qu’Internet Explorer 5 et 6 ne prenaient pas correctement en charge la transparence PNG- Internet Explorer prenait en charge PNG depuis la version 4, mais ne le rendait pas correctement dans de nombreux cas, et l’absence de prise en charge des PNG transparents dans IE5/IE6 était particulièrement problématique
- Dans PNG fix for Internet Explorer, Jeff Starr de Perishable Press explique que les solutions de l’époque exigeaient le filtre de transparence propriétaire AlphaImageLoader de Microsoft
- Un exemple consistait à appliquer
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(...)à IE, et une image de fond normale aux navigateurs non IE au moyen du sélecteur[class] - Ce type de petit manque fonctionnel a poussé les développeurs de la fin des années 2000 et du début des années 2010 à continuer de tenir compte des hacks propres à chaque navigateur
- Les commentaires conditionnels étaient une extension des commentaires HTML créée par Microsoft pour décider, selon la version d’IE, si un fragment HTML donné devait être rendu
- Comme Internet Explorer exigeait trop de hacks pour implémenter les sites web, Microsoft introduisit un hack supplémentaire pour gérer ces hacks
- Des commentaires HTML, normalement non exécutables, se sont ainsi transformés en une structure agissant selon des conditions de version d’IE
- Introduits pour la première fois dans Internet Explorer 5, ils restent parfois nécessaires pour les designs d’e-mails complexes dans Microsoft Outlook pour Windows
- Dans un article de 2007, Jens Oliver Meiert critiquait les commentaires conditionnels, estimant qu’ils obligeaient à réajuster le HTML de chaque document ou modèle pour gérer les versions d’IE et nuisaient à la séparation entre structure et présentation
- Les commentaires conditionnels ont été supprimés après IE9, et la compilation conditionnelle de JavaScript pouvait servir de solution de remplacement
Combinaisons non standard pour les polices, les e-mails et les anciens navigateurs
- sIFR (Scalable Inman Flash Replacement) était un hack fondé sur JavaScript qui remplaçait du texte par une intégration Flash afin d’afficher la police souhaitée sans être limité aux polices web-safe
- Les Core Fonts for the Web de Microsoft recommandaient de fait l’usage d’un nombre limité de polices web-safe, avant d’être abandonnées par la suite
- Les premières techniques de remplacement de polices partaient de l’utilisation d’images, mais elles avaient des limites d’accessibilité et de présentation
- Shaun Inman eut l’idée de remplacer la police souhaitée par un petit fichier Adobe Flash, et Mike Davidson, avec sIFR, fit en sorte que la police puisse s’adapter selon les besoins
- Dans son article de présentation de sIFR en 2004, Davidson estimait que le problème de la diffusion de polices personnalisées non installées chez l’utilisateur n’était pas encore résolu
- sIFR fut une étape intermédiaire vers de véritables solutions de polices web, et n’a pas duré longtemps lorsque Flash n’a pas réussi à passer au mobile
- Le hack du texte de pré-en-tête consistait à insérer des caractères masqués et des espaces pour empêcher les clients e-mail d’ajouter à la ligne d’aperçu du texte de corps indésirable suivant
- Le pré-en-tête est le court texte affiché après l’objet dans la boîte de réception, jouant le rôle de sous-titre de l’e-mail
- Certains clients e-mail pouvant récupérer des balises HTML ou du contenu de corps sans rapport pour l’aperçu, on forçait l’insertion d’un espace entre le pré-en-tête voulu et le texte suivant
- L’exemple recommandé par Litmus consistait à répéter des caractères comme
͏,,,etdans une zone à laquelle étaient appliquésdisplay: none,max-height: 0pxetoverflow: hidden
- Google Chrome Frame était un plugin de navigateur qui permettait d’utiliser le moteur de rendu de Chrome dans Internet Explorer, afin d’accéder à des fonctionnalités web modernes même dans des environnements dépendants d’IE6
- Certaines entreprises avaient du mal à passer à des navigateurs récents à cause de services IT très stricts et de dépendances à des technologies fondées sur IE6
- En 2009, Google créa Chrome Frame pour fournir un moteur moderne aux anciens Internet Explorer et éviter aux développeurs de maintenir plusieurs versions ou de renoncer aux nouvelles fonctionnalités
- Selon l’article annonçant le retrait de Chrome Frame, beaucoup d’utilisateurs utilisaient alors des navigateurs en retard sur les fonctionnalités récentes
- Des outils comme Google Wave et YouTube avaient besoin de fonctionnalités HTML5, et la prise en charge d’IE6 était une contrainte pour Google
- Chrome Frame est resté sur le marché pendant cinq ans, période après laquelle Chrome est devenu un navigateur extrêmement dominant
Réponses spécifiques à Safari/WebKit et évolution réelle du web
- Le hack des sélecteurs propres à WebKit consistait à exploiter la prise en charge de CSS spécifique à certains navigateurs, comme
@supports (-webkit-appearance:none) {}, pour appliquer du CSS uniquement aux navigateurs de la famille WebKit- À son lancement, Safari reposait sur un moteur enraciné dans la communauté open source et prenait fortement en charge les standards HTML/CSS à ses débuts
- Apple Mail utilisant WebKit, il était généralement considéré comme un environnement fonctionnant bien pour le codage d’e-mails
- Avec le temps, le calendrier de publication de Safari s’est retrouvé lié à ceux de Mac et d’iOS, ce qui l’a parfois mis en retard par rapport au reste du secteur
- Des développeurs ont reproché à Apple d’ignorer des bugs ou de retarder des fonctionnalités qui la désavantageaient face à la concurrence
- Dans un billet de frustration sur le développement pour Safari, un utilisateur de Reddit écrivait que même lorsque des API étaient implémentées, elles comportaient beaucoup de bugs ou se cassaient plus tard
- Ce hack fonctionnait aussi dans les premières versions de Chrome, qui avaient commencé sur une base WebKit
- L’intention initiale de HTML et les usages réels du web ont fortement divergé, et les designers comme les spécialistes UI ont construit une expression visuelle sur Internet malgré un code étrange
- Comme l’expliquait David Siegel, les organismes de standardisation voulaient que HTML fonctionne davantage comme RSS, en privilégiant l’utilisateur et la structure plutôt que le design final
- Des protocoles apparus à la même époque, comme Gopher, fonctionnaient eux aussi avec peu d’influence du design
- Mais cette philosophie n’est pas devenue dominante, en raison de la créativité des internautes et de la dépendance de l’Internet commercial au langage visuel
- Dans le HTML des e-mails, même un dégradé transparent facile à gérer en HTML/CSS standard reste difficile, et des contournements comme le glitch de tableaux HTML d’un ancien commentaire StackOverflow peuvent encore servir de solution
1 commentaires
Avis sur Hacker News
Utiliser des tableaux pour la mise en page, c’était assez compréhensible
Mais pendant quelques années après que les tableaux sont passés de mode, tout reposait sur les float pour faire la mise en page. C’était vraiment une époque rude, et je suis surpris que ce ne soit pas dans la liste
https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
« La propriété float, à l’origine destinée à faire flotter des images à l’intérieur de blocs de texte, est devenue l’un des outils les plus couramment utilisés pour créer des mises en page à plusieurs colonnes sur le Web. Avec l’arrivée de flexbox et de grid, elle est désormais revenue à son usage initial »
Vers la fin, je l’ai ouvert dans IE et tout le design s’est effondré ; comme le public visé utilisait presque certainement IE, j’ai finalement dû tout réécrire avec une mise en page à base de tableaux. Triste journée
Après que les tableaux ont été écartés, j’ai vu d’innombrables équipes front-end perdre des mois cumulés à bricoler avec float pour préserver les convictions de « puristes », en produisant des pages Web bien moins faciles à comprendre ; j’en ai tiré une leçon importante
Joel Spolsky, dans un excellent article, appelait ce genre de développeurs des Architecture Astronauts : des gens qui oublient que leur travail consiste à produire réellement du logiciel qui fonctionne bien avec un minimum d’effort. Les absurdités de la première spécification EJB, ou les fameux AbstractFactoryBuilderConstructor de Java dont on se moquait, me semblent relever du même phénomène
Avec le temps, j’ai appris à repérer assez bien cette tendance et à m’en tenir à distance
https://en.wikipedia.org/wiki/Holy_grail_(web_design)#Faux_c...
.clearfix::after { content: ""; clear: both; display: table; }[1] https://www.w3schools.com/howto/howto_css_clearfix.asp
float était délicat et difficile à faire tomber juste, et beaucoup de gens sont simplement revenus aux tableaux ; franchement, on ne pouvait pas les blâmer
spacer.gif n’a droit à aucun respect ?
Bien sûr, il est encore sur HN et inclus dans chaque requête de page
https://news.ycombinator.com/s.gif
Il y avait quelques techniques que j’aimais bien
Les Faux columns donnaient visuellement l’impression d’être étirées, ce qui faisait paraître la barre latérale aussi longue que le contenu principal : https://alistapart.com/article/fauxcolumns/
Plus loin encore, avec du 9-patch et 9 div ou un tableau 3x3, on pouvait simuler ses propres bordures en répétant l’arrière-plan sur chaque axe. L’arrivée de border-image dans CSS3 a un peu aidé, mais ce style de bordures n’est plus vraiment à la mode aujourd’hui
On pouvait aussi faire des bordures arrondies avec du 9-patch, et beaucoup de gens utilisaient des générateurs pour créer plusieurs éléments et produire du HTML simulant des bordures arrondies. Cet article l’explique : http://benogle.com/2009/04/29/css-round-corners.html En général, le balisage supplémentaire pesait plus lourd en octets qu’une image, mais on réduisait les allers-retours réseau et c’était considéré comme assez facile à faire
C’était plus proche d’ActionScript, mais l’idée de stylage était la même, et on a même écrit un billet à ce sujet : https://brajeshwar.com/2005/splice9-bitmap-window-resizer-co...
Une autre chose que j’aimais bien était l’usage du cicada principle pour les motifs d’arrière-plan non répétitifs
Cela dit, même après tout ce temps, le site reste propre
J’aime bien le fait que HN utilise encore l’un de ces procédés : la mise en page avec des tableaux HTML
Plus sérieusement, cette liste montre bien que, quand on développe sans standards, les informations de contrôle finissent encodées dans plusieurs canaux secondaires « à peu près supportables »
Ce chaos et les risques de collisions qu’il implique font reconsidérer le mépris que le processus du W3C reçoit parfois. Ce processus combine une évolution des technologies du Web pilotée par les standards avec une innovation pilotée par les navigateurs, les deux avançant tour à tour ou côte à côte
On s’en moque souvent, mais on peut aussi y voir une approche plus durable et plus stable que l’ancienne
Je me demande combien de ceux qui critiquent les nouvelles normes W3C-vendeurs voudraient revenir à cette époque exaltante qu’évoquent ces « 10 hacks étranges »
Quand ce que l’on veut faire n’est pas couvert par une fonctionnalité, on finit par le faire de manière créative d’une façon ou d’une autre. Si les standards ne sont pas assez mûrs pour capter tous les besoins potentiels, ils créent au contraire de la rigidité et produisent ce genre de situation. C’est particulièrement vrai quand on est lié à des standards, comme sur le Web, qui peuvent ou non correspondre aux besoins
Dans d’autres domaines, il y a généralement assez d’options pour que l’une d’elles soit suffisamment flexible pour faire ce dont on a besoin, et il suffit de la choisir
Quand on travaille longtemps dans la recherche, on constate qu’un nombre étonnamment élevé de choses que l’on veut faire exigent une approche technique bricolée. Beaucoup de standards et d’ensembles de fonctionnalités naissent autour des interactions business/consommateurs où va l’argent, et des systèmes qui les entourent
Beaucoup d’acteurs qui dépendent des fonctionnalités des navigateurs, par exemple les fabricants de téléviseurs qui font tourner leurs apps dans une version de WebKit ou de Chromium, restent complètement silencieux dans les comités de standardisation. Du coup, ce n’est même pas vraiment un bras de fer à trois entre Google, Apple et Mozilla
Au final, on obtient un tableau dans des div. Simplement avec 12 colonnes
J’ai appris avec HTML 3.2, donc je sais très bien quelles absurdités byzantines IE et Netscape imposaient. Mais c’étaient les choix de MS et Netscape, et même si le W3C avait eu plus de poids, rien ne garantissait ni ne laissait entendre que MS et Netscape suivraient les nouveaux standards
Malgré tout, cette époque valait mieux que la situation pourrie actuelle où, dès qu’une grande entreprise veut quelque chose, le reste du Web doit l’encaisser
Vraiment tellement mieux, super /s
Il manque mon hack « préféré » : placer les titres d’accessibilité à la position
-10000pour qu’ils ne soient pas rendus à l’écran, mais que les lecteurs d’écran puissent les lireDes choses comme
aria-labelont remplacé certains usages de ce pattern, mais pas tousRien sur html5 shiv, qu’on installait avant tout le CSS pour supprimer les quirks des navigateurs
https://paulirish.com/2011/the-history-of-the-html5-shiv/
Je me souviens du bon vieux temps des GIF transparents de 1×1 pixel utilisés pour garder les cellules de tableau bien sages
https://news.ycombinator.com/item?id=38485665
Je ne me souviens même plus pourquoi. Pour les charger plus vite, peut-être ?
Pour ajouter un autre exemple des débuts, il y avait aussi l’usage massif de l’entité de caractère d’espace insécable
On s’en servait pour pousser du texte vers la droite ou la gauche dans un conteneur et, si je me souviens bien, aussi un peu comme les GIF spacer 1x1 pour rendre les cellules de tableau dociles. Certaines pages contenaient des centaines de
, c’était presque un moyen générique d’ajouter des marges ou du paddingParfois, je ne sais pas si les développeurs Web modernes sont devenus gâtés parce qu’ils ont CSS Grid et qu’IE est mort, ou si c’est nous qui étions gâtés à l’époque parce que nous n’avions pas à subir la complexité des frameworks modernes et des chaînes de build
Cela dit, aujourd’hui est sans doute plus facile. Techniquement, on n’a pas forcément besoin d’utiliser les frameworks modernes ni les chaînes de build, et le CSS et le JavaScript modernes suffisent à créer facilement des sites et apps qui auraient été complexes autrefois
Le secteur a pris l’habitude de réinventer constamment la roue de manière plus compliquée
L’hypothèse la plus plausible est que c’est un effet secondaire du fait que le Web est plus souvent choisi par des développeurs débutants ou peu expérimentés
Le responsive design est-il vraiment un hack ? Les media queries sont excellentes
Mettre la logique conditionnelle dans le CSS plutôt que dans JavaScript est une grande victoire. Surtout quand on veut faire du rendu côté serveur
On peut interroger diverses caractéristiques de l’agent utilisateur et fournir un CSS différent selon le résultat. Appeler ça un hack relève de l’ignorance, et c’est une partie nécessaire de la création d’un design responsive