HTML-Editor mit Live-Vorschau

Aus drei Quelltext-Tabs wird ein Browserdokument

Syntaxfarben, Zeilennummern, Klammerprüfung, Codefaltung und Vervollständigung erleichtern die Orientierung, beweisen aber keine Funktion. Aktive Datei kopieren übernimmt nur den gewählten Tab; vollständiges HTML kopieren kombiniert das Dokument. Lokaler Import nimmt Dateien innerhalb von 2 MiB an. Benachbarte Bilder brauchen weiterhin erreichbare Adressen: Eine HTML-Datei zu importieren bedeutet nicht, ihren gesamten Ordner zu importieren.

HTML beschreibt die Struktur, CSS die Darstellung und JavaScript das gewöhnliche Browserverhalten. Ein Fragment wie <main><h1>Notizen</h1></main> erhält einen Dokumentrahmen. Eine vollständige HTML-Datei behält ihren Kopf- und Inhaltsbereich; das Tab-CSS wird im Kopf, das Tab-JavaScript am Ende des Inhaltsbereichs ergänzt. Bereits enthaltene Styles und Skripte bleiben in der importierten Datei. Wird derselbe Code nochmals in einen anderen Tab eingefügt, kann sich das Verhalten verdoppeln.

Bearbeiten, Betrachten und Testen sind aufeinanderfolgende Aufgaben. Schreiben oder formatieren Sie Quelltext, prüfen Sie die Darstellung und erproben Sie anschließend die Interaktion. Ausführen verwendet den aktuellen Entwurf. Bei ausgeschalteter automatischer Ausführung zeigt die Vorschau während der Bearbeitung möglicherweise noch einen älteren Stand. Für vertrauenswürdige Layoutversuche ist Auto-run praktisch; bei einem unvollständigen Handler oder einer Nebenwirkung ist bewusstes Ausführen hilfreicher. Formatieren betrifft nur den aktiven Tab und verbessert Lesbarkeit, nicht Korrektheit.

Wählen Sie die Vorlage nach dem benötigten Muster. Blank HTML5 und Semantic Article unterstützen die Dokumentstruktur; Responsive Landing, CSS Grid Dashboard und Flexbox Pricing zeigen Layoutansätze. Interactive Card und JavaScript Counter machen Ereignisse sichtbar. CSS Animation enthält eine Regel für reduzierte Bewegung. Accessible Form verbindet Labels und Statusrückmeldung. Die Namen beschreiben Ausgangsbeispiele, keine Qualitätsgarantie nach späteren Änderungen.

Vorschaugröße und Zoom richtig unterscheiden

Die eingepasste Vorschau folgt dem verfügbaren Bereich; die festen Modi verwenden 390, 768 und 1280 CSS-Pixel. Das sind Layoutbreiten, keine nachgebildeten Smartphone-Modelle. Der Vorschauzoom verändert die sichtbare Größe im Arbeitsbereich. Er erleichtert das Betrachten einer breiten Seite, beweist aber nicht, dass diese in einen schmalen Viewport passt. Beginnen Sie bei 100%, vergleichen Sie die drei Breiten und prüfen Sie eigene Umbruchgrenzen zusätzlich mit Browserwerkzeugen.

Eine Regel bei 720 Pixeln kann bei 768 drei Spalten und bei 390 eine Spalte zeigen. Diese zwei Zustände erklären noch keinen Fehler bei 721 Pixeln. Prüfen Sie lange Überschriften, leere Zustände und Fehlermeldungen statt ausschließlich die aufgeräumte Vorlage. Ein Kind mit fester Breite, eine untrennbare URL oder große Innenabstände können trotz responsivem Raster überlaufen. Entfernen Sie jeweils eine Einschränkung und führen Sie erneut aus.

Ein Breitenvergleich beantwortet eine konkrete Layoutfrage. Er prüft weder Berührung, Bildschirmtastatur, Pixeldichte und Geräteleistung noch eine andere Browserengine. Testen Sie den Export auch mit Tastatur, vergrößertem Text und den tatsächlichen Zielgeräten. Vollbild schafft Platz; ein eigener Vorschautab erleichtert die Betrachtung. Keine dieser Aktionen veröffentlicht die Seite.

Fehler mit Konsole und Dokumentprüfungen verfolgen

Bei vollständigem HTML prüfen Sie <!doctype html>, Dokumentsprache, UTF-8, Viewportangabe und aussagekräftigen Titel. Passen Sie die Sprache an den Text an, statt den englischen Vorlagenwert zu übernehmen. Prüfungen weisen auch auf Überschriftensprünge, fehlende Buttontypen und Inline-Ereignisse hin. Konsole leeren entfernt alte Meldungen ohne Quelltextänderung; danach lässt sich eine gezielte Aktion besser beobachten.

Reagiert ein Button nicht, prüfen Sie zuerst Skriptfreigabe und letzten ausgeführten Stand. Suchen Sie nach einem neuen Durchlauf den ersten Konsolenfehler. Liefert querySelector den Wert null, stimmen häufig Selektor und Element-ID nicht überein oder das Element fehlt. Protokollieren Sie nahe am Fehler einen kleinen Wert statt eines vertraulichen Gesamtobjekts. Die begrenzte Konsole erfasst übliche Meldungen, Fehler und abgelehnte Promises; sie ersetzt weder einen Breakpoint-Debugger noch eine vollständige Ablaufaufzeichnung.

Die Prüfungen untersuchen das zusammengesetzte Dokument auf typische Probleme: fehlende Dokumentangaben, doppelte IDs, Bilder ohne alt-Attribut, unbeschriftete Formularfelder, namenlose Aktionen und auffällige Links. Ein Fehler verlangt eine Prüfung im Kontext; ein Hinweis kann eine Gestaltungsfrage sein. Für Dekoration kann alt="" richtig sein, während ein informatives Bild eine sinnvolle Beschreibung benötigt. Mehrere H1-Elemente sind nicht allein deshalb ungültig, weil eine klare Hauptüberschrift empfohlen wird.

Die W3C-Anleitung zu Formularbeschriftungen erläutert den Nutzen sichtbarer, mit dem Feld verbundener Labels. Ein beim Tippen verschwindender Platzhalter ist kein gleichwertiger Ersatz. Prüfen Sie nach einer Korrektur die Tab-Reihenfolge, den Fokus und die Rückmeldung. Ein bestandenes Preflight belegt weder Kontrast und Lesereihenfolge noch Screenreader-Nutzbarkeit oder vollständige HTML-Konformität. Dafür braucht es Validator und aufgabenbezogene Barrierefreiheitsprüfung.

Prüfen Sie die Netzwerklast, bevor Sie das Layout verfeinern. Öffnen Sie für vertrauenswürdige externe Ressourcen vor dem erneuten Laden die vollständigen Netzwerkwerkzeuge des Browsers. Vergleichen Sie einen Ladevorgang ohne zwischengespeicherte Dateien mit einem erneuten Aufruf. Untersuchen Sie fehlgeschlagene Anfragen, übertragene Bytes, große Bilder und Bibliotheken sowie die Auslöser weiterer Anfragen. Die Netzwerkreferenz von Chrome unterscheidet die Übertragungsgröße von der größeren unkomprimierten Ressourcengröße. Auch eine kleine HTML-Datei kann mehrere Megabyte an Abhängigkeiten laden. Entfernen Sie eine unnötige Ressource oder verkleinern Sie ein übergroßes Bild und wiederholen Sie denselben Vergleich. Eine schnelle Vorschau aus dem Cache belegt keine gute Leistung bei langsamer Verbindung.

Prüfen Sie den Aufbau der Seite und nachträgliche Verschiebungen. Die Hinweise zu renderblockierendem CSS erklären, weshalb eine benötigte Formatvorlage die erste gestaltete Darstellung verzögern kann; die Dateigröße ist nicht der einzige Aufwand. Untersuchen Sie Laden und lange JavaScript-Ausführung mit den Performance-Werkzeugen des Browsers, nicht nur mit Console oder Checks. Springt eine Überschrift beim Laden eines Bildes, einer Schrift oder einer Einbettung, helfen die Hinweise zu Layoutverschiebungen: Reservieren Sie den vorgesehenen Platz mit passenden Angaben für width/height oder aspect-ratio und prüfen Sie den Ladevorgang erneut. Dokumentieren Sie Abhängigkeiten und Testbedingungen. Der reduzierte Versuch bildet weder den Cache und die Serverantworten des späteren Hosts noch die Leistung aller Endgeräte ab.

Externe Dateien bewusst auflösen

Der Ressourcendialog akzeptiert HTTP- oder HTTPS-Adressen für Stylesheets und browserfertige Skripte sowie eine Basisadresse für relative Pfade. Tragen Sie pro Zeile eine Adresse ein. Mit https://example.org/demo/ wird images/logo.png unterhalb dieses Verzeichnisses gesucht; /images/logo.png beginnt dagegen im Ursprungsverzeichnis. Der HTML-Standard erläutert diese Auflösung. Eine Basisadresse legt keine Dateien ab und macht lokale Dateien nicht online verfügbar.

Fehlt nach dem Import ein Bild oder Font, prüfen Sie zuerst die Adresse. Sie kann zum falschen Verzeichnis gehören, eine Anmeldung verlangen, durch die Netzwerkfreigabe blockiert sein oder einer Einschränkung des Anbieters unterliegen. Netzwerkfreigabe erlaubt einen Versuch, garantiert aber keine erfolgreiche Antwort. Skriptausführung ist eine eigene Freigabe: Externes JavaScript benötigt eine passende Ressource und die Erlaubnis zur Ausführung.

Eine browserfertige CDN-Datei kann für ein kleines Beispiel genügen. Ein npm-Paketname, JSX, TypeScript, Sass oder PHP wird hier nicht automatisch ausführbar. Es gibt keine Paketinstallation, Kompilierung, Datenbank oder Vermittlung privater APIs. Für Frameworks und authentifizierte Anwendungen ist eine geeignete Entwicklungsumgebung erforderlich; prüfen Sie Ressourcen unter den tatsächlich vorgesehenen Richtlinien der späteren Website.

Was schützt die Vorschaugrenze?

Die WHATWG-Sandboxregeln beschreiben einen isolierten iframe-Ursprung ohne ausdrückliche Same-Origin-Freigabe. Diese Freigabe erteilt die Vorschau nicht. Skripte und Netzwerk beginnen ausgeschaltet und werden getrennt aktiviert; ein Import schaltet auch Auto-run aus. Für ein statisches Layout können beide aus bleiben. Für einen vertrauten Zähler genügen Skripte ohne externe Anfragen.

Die Isolation begrenzt Zugriffe, beurteilt aber nicht die Vertrauenswürdigkeit des Codes. Schleifen können Ressourcen verbrauchen, Skripte täuschende Anmeldeformulare zeichnen und freigegebene Ressourcen Anfragen an ihre Anbieter senden. Geben Sie keine Zugangsdaten in Vorschauinhalte ein. Die Konsolenbegrenzung dämpft normale Nachrichtenfluten, garantiert aber keinen Schutz vor einem blockierten Tab.

Ein separater Vorschautab behält iframe und ausgewählte Freigaben. Ein vollständiger HTML-Export ist anders: Er enthält Code und Ressourcen ohne die Ausführungsbeschränkungen des Arbeitsbereichs. Beim direkten Öffnen können Skripte laufen. Prüfen Sie die Datei vor dem Öffnen und Weitergeben, besonders bei fremdem Ursprung.

Das passende Dokument für die Weiterarbeit sichern

Projekt-JSON erhält Titel, getrennte Tabs, Basisadresse und Ressourcenlisten. Vollständiges HTML ist das zusammengesetzte Browserdokument, kein Offline-Paket aller externen Bilder und Bibliotheken. Beim erneuten HTML-Import bleibt alles im HTML-Tab; die ursprüngliche Aufteilung wird nicht rekonstruiert. Sichern Sie JSON für die Weiterbearbeitung und HTML für die Betrachtung des Ergebnisses.

Für die Fehlersuche ist unkomprimiertes HTML hilfreicher. Der minimierte Export entfernt Kommentare und komprimiert unterstützten Code. Vergleichen Sie das Ergebnis und behalten Sie den Originaltext. Browserentwürfe gehören zum lokalen Profil, nicht zu einer Cloud-Sicherung oder Versionshistorie. Speicher kann gesperrt oder gelöscht werden. Bei einem beschädigten Entwurf sichern Sie benötigte Inhalte vor dem Zurücksetzen; bewusstes Speichern oder Zurücksetzen kann den gespeicherten Stand ersetzen.

Teilen erzeugt ein komprimiertes Projekt im URL-Fragment, einschließlich Quelltext und Ressourcen. Der Link ist kein zugriffsgeschütztes Geheimnis und keine gehostete Produktionsseite. Empfänger können das Projekt ansehen und weiterleiten. Überschreitet es die Linkgrenze, laden Sie JSON herunter. Importiert werden HTML/HTM und unterstütztes Projekt-JSON innerhalb der Dateigrenze, kein ganzer Asset-Ordner.

Warum die Dokumentstruktur weiterhin zählt

CERNs Darstellung der Web-Anfänge führt zu Tim Berners-Lees Arbeit von 1989 an verknüpfter Information. Dieser Dokumentgedanke bleibt hilfreich: Überschriften zeigen Beziehungen, Links führen zu sinnvollen Zielen und Formulare sammeln Angaben für einen Zweck. Eine attraktive Ansammlung allgemeiner Kästen kann trotzdem ein schlecht verständliches Dokument sein.

Entscheiden Sie bei einem Dokumentationsbeispiel zuerst, was der Leser verstehen soll. Für eine Aktion eignet sich ein echter Button, für Navigation ein Link. Erläutern Sie Tabellenspalten statt ausschließlich Farben zu verwenden. Solche Entscheidungen machen das Beispiel verständlicher und erleichtern seine spätere Übernahme außerhalb des Editors.

Eine brauchbare Übergabe nennt Quelltext, zuletzt geprüfte Breite, Browser, Freigaben und erwartetes Ergebnis. Sie unterscheidet einen im Beispiel reagierenden Zähler von einer veröffentlichungsreifen Anwendung. So bleibt der schnelle Versuch wertvoll, ohne Serververhalten, Produktionssicherheit oder alle Gerätekombinationen beweisen zu müssen.