Visionneuse HTML

Comment visualiser un fichier HTML dans le navigateur

Trois étapes, aucune n’envoie quoi que ce soit. Le moteur de rendu et les remarques tiennent dans un seul script de cette page : cela fonctionne donc aussi réseau coupé.

1. Ouvrez le code. Faites glisser le fichier .html sur la zone, passez par le sélecteur de fichiers, ou collez directement le balisage. Les fichiers sont lus avec l’API FileReader du navigateur : rien n’est transféré nulle part.
2. Regardez-le, puis regardez-le étroit. Le rendu apparaît dans un cadre isolé. Passez-le à 360 px pour un téléphone et à 768 px pour une tablette : le même code, aux largeurs où les mises en page s’effondrent d’habitude.
3. Lisez les remarques en dessous. Chaque remarque porte la ligne d’où elle vient : références que le cadre ne peut pas atteindre, image chargée en http qu’une page sécurisée laisse tomber, viewport manquant qui fait mentir l’aperçu étroit.

Comment cette visionneuse rend votre fichier

Le balisage part directement dans une iframe via srcdoc, avec sandbox="allow-scripts" et délibérément sans allow-same-origin. En pratique, cela veut dire trois choses. Vos scripts s’exécutent : une page qui se construit toute seule au chargement se construit vraiment. Le cadre vit dans son propre origine opaque, donc rien de ce qu’il contient ne peut lire cette page, son stockage ou ses cookies. Et le CSS, les polices et les images servis par des hôtes publics se chargent normalement : une page bâtie sur un CDN ressemble à ce qu’un visiteur verra.

Deux catégories ne se résolvent volontairement pas, et les remarques le disent plutôt que de vous laisser deviner. Les références aux fichiers voisins de l’original — style.css, img/entete.png — n’ont aucun dossier contre lequel se résoudre à l’intérieur du cadre. Les références à votre propre système de fichiers ne se chargent dans aucun onglet de navigateur : cette restriction vient du navigateur, pas de nous. Si la mise en page paraît sans style, lisez les remarques avant d’aller fouiller le CSS.

Voir la page en largeur téléphone

La plupart des visionneuses vous donnent une colonne à la largeur qu’a la fenêtre. Celle-ci en donne trois au cadre : 360 px, à peu près un téléphone en portrait ; 768 px, une petite tablette ; et pleine largeur, ce que permet la colonne. Le cadre est un vrai contexte de navigation : les media queries, les container queries et le retour à la ligne de flexbox répondent donc à la largeur que vous choisissez, pas à celle de votre écran.

Une réserve que les remarques soulèvent pour vous : sans <meta name="viewport" content="width=device-width, initial-scale=1">, un téléphone ne rend pas du tout en 360 pixels CSS. Il met la page en page vers 980 puis réduit le résultat : le texte devient minuscule et vos styles mobiles soigneusement écrits ne se déclenchent jamais. L’aperçu étroit n’est honnête que si cette balise est présente — c’est exactement pour cela qu’elle est signalée sous le cadre.

Pourquoi une page traduite en français casse à 360 px

C’est le défaut le plus courant des pages françaises issues d’un gabarit anglais, et c’est aussi le seul qu’un aperçu étroit rend visible en une seconde. Le français est en moyenne 20 à 30 % plus long que l’anglais, et l’écart se concentre pile là où la place manque : les boutons, les onglets, les intitulés de formulaire.

En pleine largeur, rien ne se voit : la maquette a été dessinée avec les libellés anglais et il reste de la marge. À 360 px, le bouton passe sur deux lignes et déborde de sa boîte, l’en-tête de tableau tombe en escalier, la barre de navigation crée une barre de défilement horizontale sur toute la page. Basculez le cadre entre Pleine et 360 px avec votre propre page : si quelque chose doit casser, c’est là que ça se verra.

Deux détails aggravent le phénomène en français. D’abord l’espace insécable avant ! ? ; : et à l’intérieur des guillemets « » : elle interdit au navigateur de couper à cet endroit, donc « Mot de passe oublié ?» reste d’un seul tenant même quand la place manque. Ensuite les mots simplement longs — Renseignements, Abonnement, Confidentialité — qui n’ont aucun point de coupure naturel. Les correctifs sont connus et tiennent en trois lignes de CSS : min-width: 0 sur les enfants de flex qui refusent de rétrécir, overflow-wrap: anywhere sur les libellés vraiment longs, et une taille de bouton exprimée en padding plutôt qu’en width fixe.

Une remarque honnête sur ce que fait l’outil : il ne mesure pas la longueur de vos libellés et ne détecte pas les débordements. Il vous donne le cadre à la bonne largeur, et vos yeux font le reste — c’est déjà ce que la plupart des visionneuses en ligne ne proposent pas.

Les remarques sous le cadre, et pourquoi une visionneuse n’en a d’habitude aucune

Le rendu répond à « est-ce que ça a l’air correct ». Il ne peut pas répondre à « est-ce que ce sera encore correct ailleurs », et c’est là que vivent la plupart des surprises. Chaque remarque est donc rattachée à un numéro de ligne et à une conséquence concrète :

• Une image en http:// est abandonnée par toute page sécurisée. Si l’exemple est chargé, vous en regardez une en ce moment : le logo manque au-dessus et la remarque pointe la ligne.
• Un chemin vers votre propre disque s’affiche sur votre machine et nulle part ailleurs. Dans ce cadre isolé il ne s’affiche pas non plus, ce qui est un aperçu honnête de l’expérience des autres.
• Un <!DOCTYPE html> manquant place le navigateur en mode quirks, où le modèle de boîte et les hauteurs de ligne héritées suivent des règles d’avant 2001. L’aperçu ci-dessus n’est alors l’aperçu de rien de souhaitable.
• Un module plutôt qu’un document — du code qui commence par import ou export default — n’est pas rendable du tout. Mieux vaut se l’entendre dire que fixer un cadre vide.

Si votre fichier vise une vraie adresse plutôt qu’un simple coup d’œil, la page héberger un fichier HTML fait les mêmes vérifications et enchaîne sur les deux commandes qui publient le dossier.

$ npm i -g @clize/clize && clize login
$ clize claim votrenom
$ clize deploy ./dossier --domain votrenom.clize.app