Online HTML Editor
Links tippen, rechts sehen

Was ein Online HTML Editor macht

Mit einem Online HTML Editor schreiben Sie eine Webseite und sehen sie sofort. Sie tippen HTML in einen Bereich und CSS in den anderen. Einen Moment später zeichnet der Editor die Seite neu. So speichern Sie nie eine Datei, wechseln das Fenster und laden neu, nur um eine Änderung zu prüfen.

Die Bereiche stehen links, die Vorschau steht rechts. Auf schmalen Bildschirmen stapeln sie sich. Darüber legt eine Reihe von Buttons die Breite der Ansicht fest, damit Sie dieselbe Seite so sehen, wie ein Handy, ein Tablet oder ein Desktop sie zeigen würde.

Sie müssen nichts installieren. Sie öffnen einen Tab statt eines Code-Editors und schließen ihn, sobald das Layout stimmt. Außerdem bleibt der ganze Entwurf in diesem Browser. Eine unveröffentlichte Seite oder ein Kundenentwurf erreicht nie unseren Server, weil es gar keinen Serverschritt gibt.

Unter dem Ergebnis zeigt der Editor einen Bericht, der Ihre Arbeit liest. Er zählt die Elemente und die CSS-Regeln. Er nennt die Regeln ohne Treffer und listet die Lücken bei der Barrierefreiheit, die er erkennen kann. Zuletzt listet er alles, was er gesperrt hat. So fällt eine Seite, die gut aussieht, aber schlecht lesbar ist, hier auf und nicht erst in einer späteren Prüfung.

Wie die Vorschau von dieser Seite getrennt bleibt

Die Vorschau wird nicht in diese Seite eingefügt. Stattdessen zeichnet der Editor sie in einem Shadow Root, der wie ein ummauerter Garten im Browser wirkt.

Ein Shadow Root trennt Styles in beide Richtungen, wie die HTML-Spezifikation beschreibt. Also erreicht Ihre h1-Regel die Überschrift darüber nicht, und unser Stylesheet kann die Karte, die Sie bauen, nicht plattdrücken.

Wegen dieser Mauer bleibt der Editor ehrlich. Sie sehen Ihr Markup unter Ihren Regeln, ohne dass etwas von uns hineinmischt.

Der Editor macht aus Ihrem Text außerdem echte Elemente. Deshalb setzt der Browser Ihre Seite genauso, wie er eine gespeicherte Datei setzen würde. Das zählt bei einem Raster oder einer Flex-Reihe, denn eine falsche Ansicht versteckt oft die Stelle, an der eine Reihe umbricht.

Warum Skripte hier nicht laufen

Der Editor schaltet Skripte ab. Das ist eine Entscheidung, keine Lücke. Er entfernt Script-Tags, streicht onclick und jedes andere Event-Attribut und lehnt javascript:-Links ab.

Dahinter stehen zwei Gründe. Erstens kann eine Seite, die Ihr Skript ausführt, für den handeln, der Ihnen den Schnipsel geschickt hat. Zweitens kann ein Editor, der Code ausführt, nicht versprechen, dass nichts Ihren Browser verlässt.

Deshalb listet der Bericht jeden Handler und jedes Script-Tag, das er entfernt hat. So fragen Sie sich nie, warum ein Button nichts getan hat.

Wenn Sie einen JavaScript-Spielplatz brauchen, sind Sie hier falsch. Bauen Sie stattdessen Struktur und Styles hier, und verdrahten Sie das Verhalten danach in Ihrem eigenen Code-Editor.

Links und Formulare sind aus demselben Grund inaktiv. Ein Klick in der Vorschau könnte den Tab von Ihrer Arbeit wegführen, also zeigt der Editor stattdessen einen kurzen Hinweis.

Ein Layout in drei Breiten testen

Der Editor nutzt eine Breite, keinen Gerätenamen. Die Vorgaben decken 375 Pixel für ein Handy, 768 für ein Tablet und 1280 für einen Desktop ab. Außerdem nimmt das eigene Feld jede Breite von 200 bis 2560.

Ihre Media Queries reagieren auf diese Breite. Der Editor macht aus jeder @media-Regel, die nur die Breite prüft, eine Container Query auf der Vorschaubox. So greift ein Breakpoint bei 600 Pixeln, wenn die Ansicht 600 Pixel breit ist, obwohl diese Seite breiter ist.

Die eigene Breite ist oft die nützlichste. Zwischen etwa 320 und 900 Pixeln bricht fast jedes Raster irgendwo, und diese Stelle liegt auf einer krummen Zahl, die keine Vorgabe abdeckt.

Eine breite Seite passt trotzdem auf Ihren Bildschirm. Der Editor verkleinert sie auf den vorhandenen Platz, behält aber die echte Layoutbreite. Daher wirkt der Text bei 1280 klein, bricht aber genau so um wie auf einem Desktop.

Was der Bericht auflistet

Der Bericht macht den Editor zu einem schnellen Prüfwerkzeug. Er liest Markup und Stylesheet nach jedem Neuzeichnen und schreibt auf, was er gefunden hat.

Zuerst kommen die Zahlen: wie viele Elemente die Seite hat und wie viele CSS-Regeln. Danach folgt die Liste der Regeln ohne Treffer. Ein Tippfehler in einem Klassennamen scheitert stillschweigend, weil der Browser die Regel einfach überspringt. Deshalb nennt Ihnen der Bericht den Selektor.

Danach kommen die Hinweise zur Barrierefreiheit. Ein Bild ohne Alternativtext, ein Formularfeld ohne Label, ein Link, der nur ein Bild enthält, und eine Überschrift, die von Ebene zwei auf Ebene vier springt, bekommen je eine Zeile.

Dann folgen die Tags, die ein Browser selbst reparieren würde, etwa ein div, das nie schließt, oder ein schließendes Tag ohne öffnendes. Zuletzt nennt die Sperrliste jedes Skript, jeden Event-Handler, jedes externe Bild, jede Webschrift und jeden @import, den er gestoppt hat. So kommt ein fehlendes Logo mit einem Grund statt mit einem Rätsel.