JPKCom DB

Playground — Manual

Alle Funktionen des Playgrounds: drei Editoren, SCSS mit Dart Sass, Live-Vorschau, Assets, Snippets, Export/Import, PHP-Modus (php-wasm) und die Grenzen.

Zurück zur Übersicht: Playground · Tool live öffnen: www.jpkc.com/tools/playground/

Dieses Manual beschreibt den Playground vollständig: jeden Editor, jede Schaltfläche der Werkzeugleiste, die Optionen der Vorschau, die Persistenz und die Grenzen der Sandbox. Die Oberfläche des Tools ist auf Englisch — die Button- und Label-Bezeichnungen werden hier deshalb in ihrer englischen Original-Schreibweise genannt (mit deutscher Erläuterung), damit du dich im echten Interface zurechtfindest.

Aufbau der Oberfläche

Die Oberfläche besteht von oben nach unten aus vier Teilen:

  1. Werkzeugleiste (pg-toolbar) — Run/Live, der PHP-Schalter, Snippets, Export/Import, Asset-Auswahl, Panel-Umschalter und Vollbild.
  2. Editor-Reihe — die drei Code-Panels HTML, CSS/SCSS und JavaScript nebeneinander.
  3. Trenner (pg-resizer) — eine ziehbare Leiste, mit der du das Höhenverhältnis zwischen Editor-Reihe und Vorschau verschiebst.
  4. Vorschau (pg-preview) — das gerenderte Ergebnis im <iframe> bzw. die HTML-Quelltext-Ansicht.

Die drei Editoren

Jedes Panel ist ein eigenständiger ACE-Editor (öffnet in neuem Tab) mit Syntax-Highlighting im Theme „Dracula". Voreinstellungen: Schriftgröße 13, Tab-Breite 2 (weiche Tabs), kein Zeilenumbruch, ohne Autovervollständigung. Eine Änderung in irgendeinem Editor löst zwei Dinge aus: das automatische Speichern nach 1,2 Sekunden (siehe unten) und — wenn Live aktiv ist — eine neue Vorschau nach 1,5 Sekunden.

HTML-Editor

Das linke Panel (Label HTML) nimmt den Body-Inhalt deiner Seite auf. Was du hier schreibst, landet im <body> des Vorschau-Dokuments — du brauchst also kein <!DOCTYPE>, kein <html>- und kein <head>-Gerüst, das setzt der Playground selbst. Bibliotheken von einem CDN kannst du hier allerdings nicht nachladen: Die Content Security Policy (CSP) der Tool-Seite gilt auch für die Vorschau und blockiert <script src="…">- und Stylesheet-<link>-Tags auf fremde Server (siehe Architektur, Sandbox und Grenzen). Nutzbar sind die Bibliotheken aus dem Asset-Dropdown, eigener Inline-Code und Stylesheets von Google Fonts.

CSS- / SCSS-Editor

Das mittlere Panel (Label CSS) nimmt deine Stile auf, die der Playground in einen <style>-Block im <head> der Vorschau schreibt. Über den SCSS-Schalter rechts im Panel-Header stellst du den Editor auf SCSS um — das Label und das Syntax-Highlighting wechseln dann auf SCSS, und der Inhalt wird vor jeder Vorschau im Browser zu CSS kompiliert. Das Umschalten selbst baut die Vorschau nach 1,5 Sekunden neu, auch wenn Live aus ist.

Kompiliert wird mit Dart Sass (öffnet in neuem Tab) (Version 1.105) — demselben Modul, das auch der Compiler nutzt. Damit funktionieren moderne Sass-Features wie @use 'sass:math' mit math.div() oder @use 'sass:color' mit color.adjust() und color.scale(). Der Compiler wird beim ersten SCSS-Lauf nachgeladen; du siehst kurz den Hinweis „Loading SCSS compiler…". Schlägt das Laden fehl, meldet der Playground „Failed to load SCSS compiler." und versucht es beim nächsten Lauf erneut.

Ein paar Regeln für den SCSS-Modus:

  • Ausgabestil: expandiert (lesbar eingerückt, nicht minifiziert).
  • Fehler: Ein Syntaxfehler bricht die Vorschau nicht ab. Du bekommst die Meldung SCSS error (line N): … mit Zeilennummer, und in der Vorschau steht statt der Stile ein CSS-Kommentar /* SCSS Error – … */ mit dem Fehlertext.
  • Keine Warnungen: Weil bei jedem Tastendruck neu kompiliert wird, läuft Dart Sass mit stummem Logger. Deprecation-Warnungen sowie Ausgaben von @warn und @debug siehst du hier nicht — die zeigt der Compiler an.
  • Keine eigenen Dateien: Eingebaute Module (sass:math, sass:color, sass:string, …) lassen sich per @use laden. Eigene Partials per @use 'datei' oder @import gibt es nicht, weil der Playground kein Dateisystem hat — solche Zeilen enden mit einem SCSS-Fehler.

JavaScript-Editor

Das rechte Panel (Label JavaScript) nimmt dein Skript auf. Der Playground platziert deinen JS-Code am Ende des <body>, damit das DOM beim Ausführen schon vollständig geparst ist und du ohne DOMContentLoaded auskommst. Dabei steckt er den Code in ein klassisches <script> mit einem try { … } catch-Block. Daraus folgen vier Dinge:

  • Funktionsdeklarationen werden global. Ein function meineFunktion() {} ist im ganzen Dokument erreichbar — deshalb funktionieren Inline-Handler wie onclick="meineFunktion()" aus dem HTML-Panel.
  • let, const und class bleiben im Block. Sie gelten nur innerhalb des try-Blocks; ein Inline-Handler im HTML findet sie nicht. Für Inline-Handler also Funktionsdeklarationen verwenden oder Events per addEventListener im JS binden.
  • Kein Modul-Code. import, export und await auf oberster Ebene sind in diesem Block Syntaxfehler. Brauchst du ES-Module, schreib ein eigenes <script type="module"> ins HTML-Panel.
  • Fehler beim ersten Durchlauf werden abgefangen. Wirft dein Code beim Laden einen Fehler, legt das die Vorschau nicht lahm; die Meldung steht in der Browser-Konsole mit dem Präfix [Playground JS]. Fehler, die erst später in Event-Handlern oder Timern auftreten, erscheinen dort dagegen als normale Fehlermeldung ohne Präfix. Ein Syntaxfehler verhindert, dass das Skript überhaupt startet; auch er steht ohne Präfix in der Konsole.

Pro-Panel-Aktionen

Jedes der drei Panels hat im Header dieselben Aktionen:

  • Schriftgröße — Minus/Plus ändern die Editor-Schriftgröße dieses Panels (Bereich 10–26, Standard 13); der aktuelle Wert steht dazwischen.
  • Copy — kopiert den gesamten Inhalt des Panels in die Zwischenablage.
  • Download — lädt den Inhalt als Datei herunter (playground.html, playground.css bzw. im SCSS-Modus playground.scss, playground.js; im PHP-Modus playground.php). Ein leeres Panel meldet „Editor is empty."
  • Clear (Papierkorb) — leert das Panel, ohne Rückfrage.

Ausführung: Live-Modus und Run

Wie die Vorschau aktualisiert wird, steuern zwei Bedienelemente links in der Werkzeugleiste:

  • Run (grüner Button, Strg/Cmd+Enter) — baut die Vorschau sofort neu, unabhängig vom Live-Modus.
  • Live (Checkbox, standardmäßig an) — ist sie aktiv, wird die Vorschau beim Tippen automatisch neu gebaut, entprellt: 1,5 Sekunden nach dem letzten Tastenanschlag. Schaltest du Live aus, aktualisiert beim Tippen nur noch der Run-Button.

Unabhängig von Live bauen zwei Schalter die Vorschau selbst neu: jede Änderung im Assets-Dropdown (sofort) und der SCSS-Schalter (nach 1,5 Sekunden).

Nach jedem Lauf erscheint im Vorschau-Header ein Status „Updated" mit Uhrzeit, kurz grün hervorgehoben; der Text bleibt bis zum nächsten Lauf stehen (im PHP-Modus „Running PHP…" während des Laufs, danach „PHP run"; „PHP error" erscheint nur, wenn ein abgebrochener Lauf vorher schon Ausgabe erzeugt hat — sonst bleibt „Running PHP…" stehen).

Die Vorschau

Die Vorschau rendert ein vollständiges HTML-Dokument, das der Playground aus deinen drei Editoren zusammensetzt: dein HTML in den <body>, dein (kompiliertes) CSS in einen <style>-Block, dein JS ans Ende des <body>. Schließende </style>- und </script>-Literale in deinem Code werden dabei maskiert, damit sie die umgebenden Blöcke nicht vorzeitig schließen.

Rendered Preview und HTML Source

Rechts im Vorschau-Header schaltest du zwischen zwei Ansichten um:

  • Rendered Preview (Augen-Symbol) — das gerenderte Ergebnis im <iframe>.
  • HTML Source (Code-Symbol) — der vollständige, generierte HTML-Quelltext des Vorschau-Dokuments als Text. Praktisch, um zu sehen, was der Playground tatsächlich an den Browser gibt — inklusive der eingebundenen Assets.

Zoom

Mit Minus/Plus im Vorschau-Header zoomst du die Vorschau in festen Stufen zwischen 25 % und 200 % (25, 33, 50, 67, 75, 100, 125, 150, 200 %). Der Zoom skaliert nur die Darstellung; das Vorschau-Dokument selbst rendert weiterhin in voller Auflösung. Nützlich, um eine ganze Seite im Überblick zu sehen oder Details zu vergrößern.

In neuem Tab öffnen

Der Button mit dem Pfeil-Symbol (Open preview in new tab) öffnet das aktuelle Vorschau-Dokument in einem eigenen Browser-Tab — dort läuft es als normale Seite, ohne die Sandbox-Beschränkungen des eingebetteten <iframe>. Der Playground schreibt das Dokument dafür in einen leeren Tab, der zum Ursprung der Tool-Seite gehört: Code darin hat also dieselben Rechte wie die Tool-Seite selbst, etwa auf deren LocalStorage. Auch die Content Security Policy der Tool-Seite gilt dort weiter — Skripte und Stylesheets von fremden Servern bleiben im neuen Tab ebenso blockiert wie in der Vorschau. Wird der Tab vom Popup-Blocker verhindert, erscheint ein entsprechender Hinweis.

Im PHP-Modus öffnet der Button das zuletzt gerenderte Ergebnis (nicht den PHP-Quelltext, den ein Browser nicht ausführen könnte). Liegt noch kein Ergebnis vor, meldet der Playground „Run PHP first, then open the result in a new tab."

Optionale Assets

Über das Assets-Dropdown (Ebenen-Symbol) blendest du gängige Front-End-Bibliotheken in die Vorschau ein, ohne sie selbst zu verlinken. Ein Zähler-Badge am Button zeigt, wie viele aktiv sind. Verfügbar sind:

  • Bootstrap CSS — das Bootstrap-5.3-Stylesheet (im <head>).
  • Bootstrap JS — das Bootstrap-5.3-JS-Bundle inklusive Popper (für Komponenten wie Modals, Dropdowns, Tooltips).
  • Bootstrap Icons — das Icon-Set Bootstrap Icons (ausgeliefert wird Version 1.13; der Tooltip im Tool nennt noch 1.11).
  • jQuery — jQuery 4.0 (im <head>, also für dein JS verfügbar).
  • Dark Mode — setzt data-bs-theme="dark" auf das <html> der Vorschau. Diese Option ist nur wählbar, wenn Bootstrap CSS aktiv ist; schaltest du Bootstrap CSS aus, wird Dark Mode automatisch deaktiviert.

Die CSS-Assets landen als <link> im <head>, die JS-Assets als <script> ebenfalls im <head> (jQuery vor Bootstrap JS), damit sie verfügbar sind, sobald der Body geparst wird. Die Dateien kommen vom JPKCom-Server, nicht von einem fremden CDN. Jede Änderung im Dropdown baut die Vorschau sofort neu. Die Asset-Auswahl wird mitgespeichert und ist Teil von Snippets und Export.

Speichern und Wiederherstellen

Automatisches Speichern (LocalStorage)

Der Playground sichert deinen Stand laufend im LocalStorage deines Browsers — die Editor-Inhalte 1,2 Sekunden nach der letzten Eingabe, Einstellungen sofort beim Ändern. Gespeichert werden HTML, CSS und JS, der CSS-Modus (CSS/SCSS), der PHP-Modus, die Asset-Auswahl, die Panel-Sichtbarkeit, die Schriftgrößen und die Zoomstufe. Kommst du später zurück, ist dein letzter Stand wieder da — mit einer Ausnahme: Ein Panel, das beim Speichern leer war (etwa nach Clear), füllt der Playground beim nächsten Laden wieder mit dem Demo-Inhalt; einen leeren Stand stellt er nicht wieder her. Beim allerersten Besuch (oder nach einem Reset) liegt ein kleines Demo-Beispiel in den Editoren.

Snippets (benannte Slots)

Über Snippets (Disketten-Symbol) öffnest du den Dialog „Save & Load Snippets". Unter „Save current snippet" gibst du einen Namen ein (bis 60 Zeichen) und speicherst mit Save oder Enter. Es lassen sich bis zu acht Snippets speichern, jeweils mit HTML, CSS (bei SCSS der SCSS-Quelltext), JS, CSS-Modus, PHP-Modus, Asset-Auswahl und Speicherdatum. Ein bereits vergebener Name überschreibt den vorhandenen Eintrag ohne Rückfrage; neue Snippets erscheinen oben in der Liste. Ist das Limit erreicht, meldet der Playground „Maximum 8 slots reached. Delete one first."

Unter „Saved Snippets" siehst du pro Snippet Name, Datum und die Zeichenzahl je Panel sowie die Buttons Load und Del. Load ersetzt den aktuellen Arbeitsstand ohne Rückfrage, stellt CSS-, PHP-Modus und Assets wieder her und schließt den Dialog. Del löscht sofort, ebenfalls ohne Rückfrage. Auch die Snippets liegen im LocalStorage.

Reset

Der Reset-Button (Kreispfeil, Reset to defaults) setzt nach einer Rückfrage alle Editoren, den CSS-Modus, die Assets, die Panel-Sichtbarkeit, die Schriftgrößen und den Zoom auf die Werksvorgaben zurück, schaltet den PHP-Modus aus, wechselt zurück zur Rendered Preview und lädt das Demo-Beispiel. Gespeicherte Snippets bleiben dabei erhalten — Reset räumt nur den aktuellen Arbeitsstand auf.

Export und Import

Export HTML

Export HTML lädt den kompletten aktuellen Stand als eigenständige .html-Datei (playground.html) herunter — ein vollständiges Dokument mit deinem HTML, dem (kompilierten) CSS und deinem JS. Die Datei läuft auch außerhalb des Playgrounds in jedem Browser, dort ohne die Content Security Policy der Tool-Seite. Die aktiven Assets bettet sie nicht ein, sondern verlinkt sie per absoluter URL vom JPKCom-Server — ohne Netzverbindung fehlen Bootstrap, die Icons und jQuery. Zusätzlich enthält sie unsichtbare Marker (@@playground-…@@-Kommentare und die Asset-Auswahl als JSON), an denen der Playground sie später wiedererkennt.

Im SCSS-Modus landet das kompilierte CSS in der Datei — der SCSS-Quelltext und der CSS-Modus werden nicht exportiert. Willst du den SCSS-Quelltext behalten, sicher ihn als Snippet oder über den Download des CSS-Panels (playground.scss).

Import HTML

Import HTML liest eine zuvor exportierte Playground-Datei (.html) wieder ein: Der Playground sucht die Marker, extrahiert HTML, CSS und JS zurück in die jeweiligen Editoren, stellt die gespeicherte Asset-Auswahl wieder her und schaltet den PHP-Modus passend zum Kennzeichen in der Datei ein oder aus. Der CSS-Modus bleibt, wie er gerade ist. Eine Datei ohne diese Marker wird mit „No Playground markers found." abgelehnt — importierbar sind also nur Dateien, die aus diesem Playground exportiert wurden, nicht beliebiges HTML.

PHP-Modus (In-Browser-PHP)

Über den PHP-Schalter links in der Werkzeugleiste (neben Run/Live) verwandelst du den Playground in einen vollwertigen PHP-Editor. Aktivierst du ihn, läuft im Browser ein echtes PHP 8.4 — über php-wasm (öffnet in neuem Tab) (eine WebAssembly-Portierung von PHP, Apache-2.0). Es gibt keinen Server, dein Code wird nirgendwohin geschickt.

Was sich im PHP-Modus ändert

Sobald der Schalter an ist, passt sich die Oberfläche an:

  • Das HTML-Panel heißt jetzt HTML+PHP und schaltet sein Syntax-Highlighting auf PHP um. Hier schreibst du gemischten HTML+PHP-Code, genau wie in einer .php-Datei — literaler Text außerhalb von <?php … ?> wird ausgegeben, der PHP-Code dazwischen ausgeführt.
  • Aus dem Run-Button wird Run PHP, und die Live-Checkbox verschwindet: Im PHP-Modus gibt es keine automatische Vorschau beim Tippen, du baust immer gezielt per Run PHP (oder Strg/Cmd+Enter). Schaltest du den PHP-Modus wieder aus, kehrt die Checkbox zurück, bleibt aber ausgeschaltet — hak sie wieder an (oder lade die Seite neu), wenn du die automatische Vorschau zurückwillst.
  • Ein neuer Button PHP Log taucht auf (siehe unten).

Achtung: Einige Aktionen führen deinen Code auch ohne Klick auf Run PHP einmal aus — das Einschalten des PHP-Modus selbst, das Laden der Seite bei aktivem PHP-Modus, das Laden eines PHP-Snippets, der Import einer PHP-Datei, jede Änderung im Assets-Dropdown und der SCSS-Schalter. Nur das Tippen löst keinen Lauf aus.

CSS- und JavaScript-Panel bleiben, wie sie sind: Der Playground legt deine Stile und Skripte wie im Normalmodus um den PHP-Output herum. Du musst dafür nichts Besonderes in deinen PHP-Code schreiben.

Wie die PHP-Vorschau entsteht

Beim Klick auf Run PHP führt der Playground den HTML+PHP-Code aus und nimmt dessen Ausgabe (das, was PHP an HTML produziert). Daraus baut er — wie im Normalmodus — ein vollständiges Vorschau-Dokument: dein CSS in einen <style>-Block, dein JS ans Body-Ende, die aktiven Assets in den <head>. Gibt dein PHP bereits ein komplettes HTML-Dokument (<!doctype>/<html>) aus, fügt der Playground Stile, Skripte und Assets passend an den richtigen Stellen ein; andernfalls behandelt er die Ausgabe als Body-Fragment. Das Ergebnis landet in derselben abgeschotteten Vorschau wie sonst.

Jeder Lauf startet frisch: Vor der Ausführung setzt der Playground Interpreter und virtuelles Dateisystem von php-wasm zurück, Variablen oder Dateien aus dem vorigen Lauf gibt es also nicht mehr. Während ein Lauf arbeitet, ist der Run PHP-Button gesperrt, ein zweiter Auslöser wird ignoriert. Bricht die Ausführung mit einer Ausnahme ab und ist bis dahin schon Ausgabe entstanden, zeigt die Vorschau diese Teil-Ausgabe mit dem Status „PHP error". Gab es noch keine Ausgabe — etwa weil die PHP-Engine nicht lädt —, bleibt die bisherige Vorschau unverändert stehen. Die Meldung steht in jedem Fall im PHP Log und zusätzlich in einer Fehlermeldung „PHP: …".

Run PHP statt Live — und warum

Anders als HTML/CSS/JS läuft PHP per WebAssembly auf dem Haupt-Thread des Browsers, nicht in einem Hintergrund-Worker. Das hat einen Preis: Eine echte PHP-Endlosschleife (while (true)) würde den Tab blockieren, weil WebAssembly synchron läuft und nicht von außen abgebrochen werden kann. Genau deshalb ersetzt der PHP-Modus die Live-Vorschau durch den manuellen Run PHP-Button — du behältst die Kontrolle, wann Code ausgeführt wird, und tippst nie versehentlich eine laufende Endlosschleife los.

PHP Log (Fehlerprotokoll)

Damit die Vorschau frei von Fehler-Markup bleibt, ist PHP so konfiguriert, dass es Fehler nicht in die Ausgabe schreibt, sondern protokolliert (display_errors=Off, log_errors=On, error_reporting=E_ALL). Den Inhalt dieses Protokolls zeigt der Button PHP Log in einem Dialog: alle Warnungen, Notices, Fatals und Parse-Fehler des letzten Laufs — plus deine eigenen error_log()-Aufrufe, jeweils mit korrekter Zeilennummer. Ein roter Zähler-Badge am Button zeigt an, wie viele Zeilen das Protokoll enthält. Mit Copy im Dialog kopierst du das Protokoll in die Zwischenablage; ohne Einträge steht dort „No errors, warnings or notices." Bleibt die Ausgabe leer, während das Log Einträge hat, weist dich der Hinweis „PHP produced no output — see PHP Log." darauf hin.

Laden und Entladen

Die PHP-Engine ist groß (rund 13 MB WebAssembly) und wird daher erst beim Aktivieren des PHP-Modus nachgeladen — nicht schon beim Öffnen der Seite; dabei erscheint der Hinweis „Loading PHP (php-wasm)… this downloads ~13 MB on first use." Scheitert das Laden, versucht der Playground es beim nächsten Lauf erneut. Dass der PHP-Modus an war, merkt sich der Playground; nach einem Reload lädt er die Engine dann automatisch nach. Schaltest du PHP wieder aus, gibt der Playground die Engine frei.

Export, Import und Snippets im PHP-Modus

Auch der PHP-Stand lässt sich sichern, mit ein paar Besonderheiten:

  • Export HTML schreibt im PHP-Modus den rohen HTML+PHP-Quelltext in die Datei (playground.php.html) und vermerkt darin, dass es sich um PHP handelt. Diese Datei kannst du wieder importieren — sie ist aber, anders als ein normaler Export, nicht als fertige Seite im Browser lauffähig (sie enthält unausgeführtes PHP).
  • Beim Import einer solchen Datei erkennt der Playground das PHP-Kennzeichen und schaltet den PHP-Modus automatisch wieder ein.
  • Snippets speichern den PHP-Modus mit; lädst du ein PHP-Snippet, ist der Modus wieder aktiv.
  • Der Download des HTML+PHP-Panels speichert entsprechend als .php-Datei.

Voraussetzungen und Grenzen

  • Einmaliger Download. Beim ersten Aktivieren werden rund 13 MB geladen — das braucht eine Internetverbindung und einen Moment. Danach ist die Engine im Browser-Cache.
  • Kein Server-Umfeld. Es läuft PHP selbst, aber ohne Webserver, ohne Datenbank und ohne Dateisystem-Zugriff auf deinen Rechner. Gedacht ist der Modus zum Ausprobieren von PHP-Logik, Funktionen und Snippets — nicht als Ersatz für eine echte PHP-Umgebung.
  • Endlosschleifen blockieren den Tab. Siehe oben — führe verdächtige Schleifen bewusst und kontrolliert per Run PHP aus.

Layout: Panels, Trenner, Vollbild

  • Panels — die Schalter HTML, CSS, JS (Gruppe Panels:) blenden einzelne Editoren aus oder ein. So konzentrierst du dich z. B. nur auf CSS und gibst der Vorschau mehr Platz. Sind alle drei aus, klappt die Editor-Reihe ganz zusammen. Die Auswahl wird gespeichert.
  • Trenner — die Leiste zwischen Editoren und Vorschau lässt sich mit der Maus nach oben oder unten ziehen, um das Höhenverhältnis zu ändern. Die Editor-Reihe bleibt dabei mindestens 140 Pixel hoch, die Vorschau mindestens 80 Pixel. Per Touch lässt sich der Trenner nicht ziehen.
  • Vollbild — der Fullscreen-Button (F11) legt den Playground über das gesamte Browserfenster (kein Browser-Vollbild); Esc oder erneut F11 verlässt den Modus wieder. Dialoge wie Snippets und PHP Log erscheinen auch im Vollbild obenauf.
  • Schmale Bildschirme — unter 768 Pixel Breite stehen die drei Editoren untereinander statt nebeneinander.

Tastatur-Kürzel

  • Strg/Cmd + Enter — Vorschau neu bauen (Run; im PHP-Modus Run PHP).
  • F11 — Vollbild ein/aus.
  • Esc — Vollbild verlassen.

Architektur, Sandbox und Grenzen

Der Playground ist rein clientseitig. Dein Code wird nicht an einen Server geschickt; die Vorschau wird im Browser zusammengebaut und in ein sandbox-<iframe> geladen. Die Sandbox erlaubt gezielt allow-scripts, allow-forms, allow-modals und allow-popups — also genug, damit dein JS, Formulare, prompt/alert und Popups funktionieren — aber nicht den Zugriff auf die Hauptseite. Damit kann der Vorschau-Code den Playground und deine Daten dort nicht erreichen. Zusätzlich übernimmt die Vorschau die Content Security Policy der Tool-Seite; was daraus folgt, steht in der Liste unten. Auch die SCSS-Kompilierung läuft lokal über das nachgeladene Dart Sass.

Daraus ergeben sich ein paar Grenzen, die du kennen solltest:

  • Fremde Skripte und Stylesheets sind blockiert. Die Vorschau erbt die Content Security Policy der Tool-Seite — im <iframe> ebenso wie im neuen Tab. <script src> und Stylesheet-<link> auf fremde Server (etwa ein CDN) lädt der Browser deshalb nicht. Erlaubt sind die Bibliotheken aus dem Asset-Dropdown, Inline-<script> und -<style>, Stylesheets und Schriften von Google Fonts sowie Bilder per https:. fetch() auf https:-APIs ist zulässig, unterliegt aber CORS. Ebenso blockiert die Richtlinie eingebettete fremde Seiten per <iframe> (etwa ein Video-Embed), Audio und Video von fremden Servern, Schriften von fremden Servern außer Google Fonts sowie <object>/<embed>.
  • Kein eval(), keine Formulare an fremde Adressen. Dieselbe Richtlinie blockiert eval() und new Function(), und Formulare darf die Vorschau nicht an fremde Adressen abschicken (form-action 'self'). Eine exportierte Datei, die du außerhalb des Playgrounds öffnest, unterliegt dieser Richtlinie nicht.
  • Speicher ist browser- und gerätegebunden. Auto-Save und Snippets liegen im LocalStorage. Anderer Browser, anderes Gerät, privater Modus oder geleerte Browserdaten bedeuten: Dein Stand ist dort nicht vorhanden bzw. weg. Für dauerhafte Aufbewahrung nutze Export HTML.
  • Acht Snippet-Plätze. Mehr als acht benannte Snippets gehen nicht; weitere musst du als Datei exportieren.
  • Der „neue Tab" ist nicht sandboxed. Über Open preview in new tab geöffneter Code läuft als normale Seite im Ursprung der Tool-Seite, ohne die <iframe>-Beschränkungen, aber weiter unter der Content Security Policy — sinnvoll fürs vollwertige Testen, aber öffne dort keinen fremden Code, dem du nicht traust.
  • SCSS ohne eigene Dateien und ohne Warnungen. Eingebaute Sass-Module gehen, eigene Partials nicht; Warnungen und @debug-Ausgaben bleiben stumm.
  • Export enthält kompiliertes CSS. SCSS-Quelltext übersteht Export und Import nicht — dafür Snippets oder den Panel-Download nutzen.
  • Das JS-Panel ist ein klassisches Skript. Kein import/export, let/const nur im eigenen Block (siehe JavaScript-Editor).
  • Import nur für Playground-Dateien. Nur per Export HTML erzeugte Dateien (mit Markern) lassen sich re-importieren.
  • PHP läuft außerhalb der Sandbox. Im PHP-Modus wird PHP per WebAssembly auf dem Haupt-Thread ausgeführt (nicht im <iframe>); nur sein HTML-Output wandert in die Sandbox. Eine PHP-Endlosschleife kann daher den Tab blockieren — mehr dazu im PHP-Modus.

Für den Einstieg und die Zielgruppen siehe die Übersichtsseite. Konkrete Durchläufe stehen in den Beispielen, Strategie und Stolperfallen in den Tipps & Tricks. Ausprobieren kannst du alles direkt im Tool.