HTML-Änderungen in Echtzeit vorschauen

Du änderst das Padding an einem Button. Speichern. Rüber zum Browser, neu laden, hinschauen, ob's geklappt hat. Hat es nicht — also Zahl anpassen, speichern, wechseln, neu laden. Nochmal. Auf diesem Vierertakt-Tänzchen kannst du einen halben Vormittag verbrennen und am Ende mit einem Button dastehen, der immer noch zwei Pixel danebensitzt.

Die Lösung ist ein alter Hut — die Live-Vorschau — und ich tu nicht so, als hätte ich sie erfunden; viele Editoren können das, und ich habe die kostenlosen HTML-Editoren anderswo verglichen. Das hier ist also keine Werbung für ein Tool. Es geht darum, warum dieses kleine Tänzchen weit mehr kostet als die paar Sekunden, nach denen es aussieht.

die Schleife ist nicht langsam, sie ist klebrig

Der Neulade-Tanz kostet dich nicht nur Sekunden. Er kostet dich den Faden, den du in der Hand hattest.

Jedes Mal, wenn du per Alt-Tab wechselst und neu lädst, verlierst du deinen Platz — die Scrollposition, die halb geformte Idee, was du als Nächstes probieren wolltest, genau das, worauf dein Auge lag. Rückmeldung, die vier Schritte später auftaucht, fühlt sich irgendwann nicht mehr mit der Änderung verbunden an, die sie ausgelöst hat. Also hörst du auf zu experimentieren. Fünf schnelle Varianten einer Farbe durchzuspielen sollte quasi umsonst sein. Wenn jede ein Speichern-Wechseln-Neuladen kostet, redest du dir vier davon aus und gibst dich mit der ersten zufrieden.

Die Live-Vorschau schließt diese Lücke auf null. Du tippst, die gerenderte Seite bewegt sich. Änderung und Ergebnis sitzen direkt nebeneinander, keine Verzögerung dazwischen. Und bei einer schlichten .html-Datei steckt keine Maschinerie darunter — kein Dev-Server zum Starten, kein Build zum Laufenlassen, kein Watch-Task, der in einem Terminal vor sich hin brummt. Der Editor rendert die echte Seite im Browser und malt sie bei jedem Tastendruck neu.

Framework-Projekte sind ein anderes Tier. Eine React- oder Next-App braucht wirklich einen Dev-Server mit Hot Reload, und das ist das richtige Werkzeug für diese Aufgabe. Aber du solltest keinen hochfahren müssen, nur um auf einer einzelnen Seite eine Überschrift wechseln zu sehen.

die Live-Vorschau, die beim Neuladen alles vergisst

Eine Warnung hier, weil es fast jeden mindestens einmal erwischt.

Öffne eine Seite in Chrome, Rechtsklick, Untersuchen, und du kannst das HTML direkt dort in den DevTools bearbeiten und live zusehen, wie es sich ändert. Es fühlt sich wie die Antwort an. Ist es nicht. Diese Änderungen leben nur in diesem einen Browser-Tab — lad neu, und sie sind weg, und sie berühren nie die Datei auf deiner Platte. Die DevTools sind eine Live-Vorschau, die du nicht behalten kannst. Großartig, um an einer Seite herumzustochern und zu sehen, wie eine Änderung aussähe; nutzlos, um diese Änderung festzuhalten. Wenn du die Bearbeitung gespeichert haben willst, brauchst du einen Editor, der in die Datei zurückschreibt, kein Browser-Panel, das deine Arbeit beim Neuladen wegwirft.

klick das Ding an, lande auf seinem Code

Die halbe Schleife ist, die Änderung zu sehen. Die andere Hälfte ist, zu finden, wo man sie macht.

Du kennst das Gefühl. Die Vorschau sieht falsch aus — diese Überschrift hat die falsche Größe — und schon scrollst du durchs Markup und jagst das richtige Tag unter vierzig, die alle gleich aussehen. Diese Jagd ist eine Steuer für sich, und eine leise.

Ein Editor, der in beide Richtungen läuft, macht damit Schluss. Klick das Element in der Vorschau an, und der Code dahinter leuchtet auf. HTML Tweak nennt das „Klick zum Finden" — klick die Überschrift auf der Seite an, und der Editor springt zu ihrer genauen Zeile und hebt sie hervor. Es läuft in beide Richtungen. Tipp im Code, und die Vorschau aktualisiert sich; klick in der Vorschau, und der Code folgt. Die visuelle Seite und der Quelltext liegen nebeneinander und beschreiben immer dasselbe. Und wenn Nebeneinander nicht dein Ding ist, kannst du sie stapeln oder eine ausblenden und nur im Code oder nur in der Seite arbeiten — je nachdem, was die Änderung vor dir gerade braucht.

Das ist der Teil, der das meiste Blinzeln beendet. Du übersetzt nicht mehr zwischen „was sieht schief aus" und „wo in der Datei steckt es". Es ist derselbe Klick.

dieselbe Seite, in Handybreite

Eine Seite kann auf deinem Laptop fertig aussehen und auf einem Handy auseinanderfallen.

Das ist die Sache, die die Neulade-Schleife am schlechtesten versteckt, weil du bei genau einer Größe testest — der Größe des Bildschirms, vor dem du zufällig sitzt. Dann geht die Seite raus, und auf einem schmalen Bildschirm bricht die Navigation um, eine Überschrift läuft über den Rand, zwei Spalten, die nebeneinander sitzen sollten, stapeln sich zu einem Durcheinander.

Da eine Live-Vorschau die echte Seite in einem echten Browser ist, kannst du die kleinen Größen prüfen, ohne extra etwas zu installieren. Zieh das Fenster schmal und schau, was sich neu umbricht. Oder öffne den Responsive-Modus deines Browsers — in Chrome und Edge ist das die Geräteleiste in den DevTools — und geh Handy-, Tablet- und Desktop-Breiten durch. Was du suchst, ist Text, der aus seinem Kasten quillt, Buttons, die auf zwei Zeilen umbrechen, und alles, was über den Bildschirmrand hinausläuft. Fang es hier ab, an deinem Schreibtisch, statt auf einem Screenshot, den dir ein Kunde drei Tage später schickt.

sechs Schritte zu einer Live-Vorschau

Hier der ganze Durchlauf, von vorn bis hinten. Wenn schon das Öffnen der Datei der Teil ist, bei dem du unsicher bist, habe ich die Wege, eine HTML-Datei zu bearbeiten separat aufgeschrieben.

1. Öffne deine .html-Datei in einem visuellen Editor, der die Seite und den Code zusammen zeigt. In HTML Tweak öffnest du sie direkt von deinem Rechner — nichts wird hochgeladen.
2. Leg die beiden Fenster nebeneinander, damit du beide auf einmal siehst.
3. Fang an zu bearbeiten. Änder die Worte auf der Seite oder ein Tag im Code — jede Seite aktualisiert die andere live, während du tippst, ohne Speichern-und-Neuladen dazwischen.
4. Klick in der Vorschau alles an, was du ändern willst, und lass „Klick zum Finden" dich auf seinem Code absetzen.
5. Prüf sie schmal. Zieh das Fenster rein oder nimm den Responsive-Modus deines Browsers, um sicherzugehen, dass das Layout auf einem Handy hält.
6. Speichere. In Chrome oder Edge schreiben sich die Änderungen direkt in deine Originaldatei zurück; in anderen Browsern bekommst du eine bearbeitete Kopie heruntergeladen. So oder so, kein Build und keine Anmeldung.

kleine Dinge, die die Vorschau lügen lassen

Eine Live-Vorschau spiegelt deine Datei genau — aber nicht perfekt. Eine Handvoll Dinge kann sie dir etwas zeigen lassen, das nicht ganz stimmt, gut zu wissen, bevor eines davon dich eine Stunde kostet.

• Altes CSS oder alte Bilder aus dem Cache. Wenn deine Seite ein Stylesheet oder ein Bild einbindet, klammert sich der Browser manchmal an eine alte Kopie. Dein HTML aktualisiert sich live, aber ein veraltetes Hintergrundbild kann hängen bleiben. Ein harter Reload — Strg+Umschalt+R — auf der zugrunde liegenden Seite räumt es weg.
• Für immer bei einer Breite testen. Ich hab's oben gesagt, und es ist immer noch der häufigste Fehlgriff. Perfekt auf dem Laptop, kaputt auf dem Handy. Mach den Schmal-Check zur Gewohnheit, nicht zum Nachgedanken.
• Vorschau und gespeicherte Datei verwechseln. Die Live-Ansicht spiegelt deine Änderungen in dem Moment, in dem du sie tippst. Die Datei auf der Platte ändert sich erst, wenn du speicherst. Schließ ohne Speichern, und die Seite behält ihren alten Inhalt, Live-Vorschau hin oder her.
• Zu einem Build-Tool greifen, das du nicht brauchst. Eine .html-Datei will keinen Dev-Server, keinen Bundler und kein Live-Reload-Plugin. Das ist ein Haufen Setup, um eine Farbe wechseln zu sehen. Heb dir das für die echten Projekte auf.

Hast du gerade eine Seite offen und eine Änderung, für die du dauernd neu lädst, um sie zu prüfen? Bearbeite sie mit einer Live-Vorschau und schau ihr beim Tippen zu, wie sie sich bewegt — die Neulade-Taste kann sich den Nachmittag freinehmen.