Prévisualiser les modifications HTML en temps réel

Tu changes le padding d'un bouton. Tu enregistres. Tu bascules vers le navigateur, tu rafraîchis, tu te penches pour voir si c'est bon. Ça ne l'est pas — alors tu pousses le chiffre d'un cran, enregistre, bascule, rafraîchis. Encore. Tu peux y laisser la moitié d'une matinée, sur ce petit pas de danse à quatre temps, et repartir avec un bouton toujours décalé de deux pixels.

Le remède n'a rien de neuf — l'aperçu en direct — et je ne vais pas faire comme si je l'avais inventé ; plein d'éditeurs le font, et j'ai comparé les éditeurs HTML gratuits ailleurs. Donc ce n'est pas la pub d'un outil. C'est sur ce que ce petit pas de danse te coûte vraiment — bien plus que les secondes qu'il a l'air de prendre.

la boucle n'est pas lente, elle est collante

La danse du rafraîchissement ne te coûte pas que des secondes. Elle te coûte le fil que tu tenais.

À chaque alt-tab et chaque rechargement, tu perds ta place — la position dans la page, l'idée à moitié formée de ce que tu allais tester, la chose précise que ton œil fixait. Un retour qui arrive quatre étapes plus tard finit par sembler détaché du changement qui l'a provoqué. Alors tu arrêtes d'essayer. Tester cinq variantes rapides d'une couleur devrait être quasi gratuit. Quand chacune coûte un enregistre-bascule-rafraîchis, tu t'en dissuades quatre fois et tu te contentes de la première.

L'aperçu en direct réduit cet écart à zéro. Tu tapes, la page rendue bouge. Le changement et le résultat sont côte à côte, aucun délai entre les deux. Et pour un simple fichier .html, aucune mécanique en dessous — pas de serveur de dev à lancer, pas de build à faire tourner, pas de tâche de surveillance qui ronronne dans un terminal. L'éditeur rend la vraie page dans le navigateur et la repeint à chaque frappe.

Les projets à framework, c'est une autre bête. Une appli React ou Next a vraiment besoin d'un serveur de dev avec rechargement à chaud, et c'est le bon outil pour ce travail-là. Mais tu ne devrais pas avoir à en démarrer un juste pour voir bouger un titre sur une seule page.

l'aperçu en direct qui oublie tout au rechargement

Un avertissement ici, parce que ça piège presque tout le monde au moins une fois.

Ouvre une page dans Chrome, clic droit, Inspecter, et tu peux éditer le HTML là, dans les DevTools, et le voir changer en direct. On dirait la solution. Ça n'en est pas une. Ces modifications ne vivent que dans cet onglet-là — rafraîchis, et elles ont disparu, et elles n'ont jamais touché le fichier sur ton disque. Les DevTools sont un aperçu en direct que tu ne peux pas garder. Génial pour tâter une page et voir de quoi un changement aurait l'air ; inutile pour rendre ce changement définitif. Si tu veux garder la modif, il te faut un éditeur qui réécrit dans le fichier, pas un panneau de navigateur qui jette ton travail au rechargement.

clique l'élément, tombe sur son code

La moitié de la boucle, c'est voir le changement. L'autre moitié, c'est trouver où le faire.

Tu connais la sensation. L'aperçu cloche — ce titre a la mauvaise taille — et te voilà à faire défiler le balisage, à chasser la bonne balise parmi quarante qui se ressemblent toutes. Cette chasse est un impôt à part, et un impôt silencieux.

Un éditeur à double sens la supprime. Clique l'élément dans l'aperçu, et le code derrière s'allume. HTML Tweak appelle ça « cliquer pour situer » — clique le titre sur la page, et l'éditeur saute à sa ligne exacte et la surligne. Ça marche dans les deux sens. Tape dans le code, l'aperçu se met à jour ; clique dans l'aperçu, le code suit. La page visuelle et la source sont côte à côte, à décrire toujours la même chose. Et si le côte-à-côte n'est pas ton truc, tu peux les empiler, ou en cacher un et travailler dans le seul code ou la seule page — selon ce que le changement devant toi réclame.

C'est ça qui met fin à l'essentiel du plissement d'yeux. Tu ne fais plus la traduction entre « ce qui cloche » et « où ça vit dans le fichier ». C'est le même clic.

la même page, en largeur téléphone

Une page peut avoir l'air finie sur ton portable et voler en éclats sur un téléphone.

C'est celui que la boucle de rafraîchissement cache le plus mal, parce que tu testes à exactement une taille — celle de l'écran devant lequel tu es assis. Puis la page part, et sur un écran étroit le menu passe à la ligne, un titre déborde du bord, deux colonnes censées tenir côte à côte s'empilent en un joli bazar.

Comme un aperçu en direct est la vraie page dans un vrai navigateur, tu peux vérifier les petites tailles sans rien installer de plus. Tire la fenêtre en étroit et regarde ce qui se recompose. Ou ouvre le mode responsive de ton navigateur — dans Chrome et Edge, c'est la barre d'appareils à l'intérieur des DevTools — et passe en revue les largeurs téléphone, tablette et bureau. Ce que tu cherches, c'est du texte qui déborde de sa boîte, des boutons qui tombent sur deux lignes, et tout ce qui dépasse le bord de l'écran. Attrape-le ici, à ton bureau, plutôt que sur une capture qu'un client t'envoie trois jours plus tard.

six étapes vers un aperçu en direct

Voici le parcours complet, d'un bout à l'autre. Si c'est l'ouverture même du fichier qui te laisse dans le flou, j'ai détaillé les façons d'éditer un fichier HTML à part.

1. Ouvre ton fichier .html dans un éditeur visuel qui montre la page et le code ensemble. Dans HTML Tweak, tu l'ouvres directement depuis ton ordinateur — rien ne part en ligne.
2. Mets les deux panneaux côte à côte pour voir les deux d'un coup.
3. Commence à éditer. Change les mots sur la page, ou modifie une balise dans le code — chaque côté met l'autre à jour en direct, à mesure que tu tapes, sans enregistrer-rafraîchir entre les deux.
4. Clique dans l'aperçu ce que tu veux changer, et laisse « cliquer pour situer » te déposer sur son code.
5. Vérifie en étroit. Resserre la fenêtre, ou utilise le mode responsive de ton navigateur, pour t'assurer que la mise en page tient sur un téléphone.
6. Enregistre. Sous Chrome ou Edge, les changements se réécrivent directement dans ton fichier d'origine ; dans les autres navigateurs, tu récupères une copie modifiée en téléchargement. Dans les deux cas, aucun build et aucune inscription.

les petits trucs qui font mentir l'aperçu

Un aperçu en direct reflète ton fichier de près — mais pas parfaitement. Une poignée de choses peuvent lui faire montrer quelque chose qui n'est pas tout à fait vrai, bon à savoir avant que l'une d'elles te coûte une heure.

• Du CSS ou des images en cache. Si ta page tire une feuille de style ou une image, le navigateur s'accroche parfois à une vieille copie. Ton HTML se met à jour en direct, mais une image de fond périmée peut traîner. Un rafraîchissement forcé — Ctrl+Maj+R — sur la page sous-jacente la déloge.
• Tester éternellement à une seule largeur. Je l'ai dit plus haut, et ça reste le loupé le plus fréquent. Parfait sur le portable, cassé sur le téléphone. Fais du test en étroit une habitude, pas une pensée après coup.
• Confondre l'aperçu et le fichier enregistré. La vue en direct reflète tes modifications à l'instant où tu les tapes. Le fichier sur le disque ne change qu'au moment où tu enregistres. Ferme sans enregistrer et la page garde son ancien contenu, aperçu en direct ou pas.
• Dégainer un outil de build dont tu n'as pas besoin. Un fichier .html ne réclame ni serveur de dev, ni bundler, ni plugin de rechargement à chaud. C'est une montagne de config pour regarder changer une couleur. Garde ça pour les vrais projets.

Tu as une page ouverte là, maintenant, et un changement que tu n'arrêtes pas de rafraîchir pour vérifier ? Édite-la avec un aperçu en direct et regarde-la bouger pendant que tu tapes — la touche rafraîchir peut prendre son après-midi.