2 points par GN⁺ 2023-12-03 | 1 commentaires | Partager sur WhatsApp
  • 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 @import de Netscape Navigator 4.0 consistait à charger volontairement via @import du 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
  • 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 width excluait 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 !important pour obtenir un comportement différent uniquement dans IE7 et les versions antérieures

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

  • AlphaImageLoader contournait, 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 ͏, ,  , et ­ dans une zone à laquelle étaient appliqués display: none, max-height: 0px et overflow: 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

 
GN⁺ 2023-12-03
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 »

    • À l’époque où float venait d’apparaître, j’ai entièrement développé un site de réparation informatique sous FF
      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
    • Déjà, appeler les mises en page à base de tableaux un hack m’agaçait
      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
    • « Pendant des années, on faisait les mises en page avec float » : cela s’appelait les faux columns, et même une mise en page de base en 3 colonnes était tellement difficile qu’on l’appelait le « Graal » des mises en page
      https://en.wikipedia.org/wiki/Holy_grail_(web_design)#Faux_c...
    • Comme W3Schools l’appelle encore, le nouveau hack moderne clearfix
      .clearfix::after { content: ""; clear: both; display: table; }
      [1] https://www.w3schools.com/howto/howto_css_clearfix.asp
    • L’époque entre les tableaux et flexbox/grid a été pénible
      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

    • On ne peut pas parler de mises en page à base de tableaux sans les images d’espacement
  • 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

    • Notre équipe a tellement utilisé l’approche 3x3 qu’on a fini par créer un composant dédié
      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
    • J’ai cliqué sur A List Apart et j’ai été assez surpris de voir que l’en-tête est cassé sur mobile
      Cela dit, même après tout ce temps, le site reste propre
    • La technique des sliding doors pour les coins arrondis mérite aussi d’être mentionnée : https://alistapart.com/article/slidingdoors/
    • Les Faux columns sont toujours présentes sur notre site Web principal. On n’a jamais le temps de les remplacer par quelque chose de plus moderne ;)
  • 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 »

    • Ce n’est pas tant l’absence de standards que l’absence de fonctionnalités nécessaires
      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
    • Malheureusement, aujourd’hui W3C et TC39 sont totalement dominés par Google, qui pousse de nombreux standards en ne se préoccupant presque que formellement des procédures
      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
    • C’est amusant de dire que les tableaux ont « disparu » alors qu’ils ont été largement remplacés par Bootstrap
      Au final, on obtient un tableau dans des div. Simplement avec 12 colonnes
    • WHATWG n’a jamais fait évoluer le Web pour qui que ce soit d’autre que des intérêts commerciaux
      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 -10000 pour qu’ils ne soient pas rendus à l’écran, mais que les lecteurs d’écran puissent les lire

    • Une variante proche de cette méthode reste encore assez courante. Dans tous les cas, il n’existe toujours pas de très bonne option pour gérer du texte invisible mais accessible aux lecteurs d’écran
      Des choses comme aria-label ont remplacé certains usages de ce pattern, mais pas tous
    • Est-ce que ça fonctionne encore ? Ou faut-il utiliser ARIA ?
  • Rien 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/

    • reset, normalize et consorts manquent aussi
  • Je me souviens du bon vieux temps des GIF transparents de 1×1 pixel utilisés pour garder les cellules de tableau bien sages

    • « Bon vieux temps » ? La page que tu regardes en ce moment l’utilise aussi ;)
      https://news.ycombinator.com/item?id=38485665
    • À l’époque, on découpait de grandes images en grille et on les maintenait en place avec des tableaux
      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 padding

  • Parfois, 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

    • Probablement les deux
      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 développement Web a une nuance particulière par rapport aux autres domaines où j’ai travaillé
      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

    • Utiliser les media queries pour prendre en charge différents médias semble être exactement le bon cas d’usage
    • Si l’on ne requête pas ce que l’on veut réellement savoir, mais quelque chose qui se trouve simplement corrélé à ce dont on a besoin, alors ça devient un hack
    • Ce n’est pas un hack
      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