Design und Events

Das Aussehen kommt aus dem Dashboard-Designer. Die Host-Seite steuert nur Platzierung und Breite des Custom Elements. Schnittstellen für den Ablauf stellt das Widget über Custom Events bereit.

Design im Dashboard

Owner und Admins öffnen Design in den Widget-Aktionen. Der Designer ist eine eigene Dashboard-Seite mit Live-Vorschau. Der Editor arbeitet mit einem versionierten Dokument (schemaVersion 1), nicht mit frei eingebettetem CSS oder HTML.

Unterstützte Gruppen:

Gruppe	Inhalt
Presets	Hell und Dunkel als vollständige Ausgangswerte; sie folgen den UI-v2-Geist-Tokens der gehosteten Buchungsseite (warmes Grau, fast schwarze Primärfarbe, 12-px-Schale)
Farben	Seitenhintergrund, Fläche, Dezente Fläche, Haupttext, Dezenter Text, Primärfarbe, Text auf Primärfarbe, Rahmen, Fokus, Fehler als `#RRGGBB`
Typografie	Systemschrift sans/serif/mono oder eine Workspace-Schrift für Überschriften, Fließtext und Schaltflächen; Basisschrift 12–22 px; Typografie-Skalierung 1–1,5; Schriftstärken 400, 500, 600 oder 700
Abstände	Außenabstand und Bereiche 8–48 px, Bedienelemente 4–32 px
Radius	Karten 0–32 px, Schaltflächen und Bedienelemente 0–24 px
Dichte	Kompakt, Komfortabel, Großzügig
Abschnitte	Reihenfolge von Kopfbereich, Kursauswahl, Buchungsformular und Bestätigung. Das Embed zeigt derzeit nur Kopfbereich und Kursauswahl; die beiden anderen Bereiche sind für spätere Buchungswege reserviert.

Ungültige Farben bleiben sichtbar, sind aber nicht speicherbar. Die Qualitätsprüfung meldet Kontrast- und Layoutwarnungen; sie blockieren das Speichern nicht, erscheinen aber noch einmal vor dem Veröffentlichen. Rückgängig nimmt die letzte Änderung zurück, Theme zurücksetzen stellt das Start-Theme wieder her.

Letzten Stand wiederherstellen macht die unmittelbar vorherige Veröffentlichung zur neuen Revision. Der gespeicherte Entwurf bleibt erhalten.

Isolation auf der Host-Seite

Jedes Element hängt ein offenes Shadow DOM. Host-CSS erreicht interne Knoten nicht. Das Widget setzt am Shadow-Rand Schrift, Farbschema und Textgröße zurück.

Die Breite folgt dem Container des Elements, nicht dem Viewport. Unter 34 rem Breite wird die Kursliste einspaltig, Aktionen werden vollbreit.
Der Ladezustand hält eine Mindesthöhe, damit das Layout nicht springt.
prefers-reduced-motion unterdrückt unnötige Bewegung.
Auf hellen und dunklen Host-Seiten bleibt das veröffentlichte Widget-Theme maßgeblich.

Die Host-Seite darf das äußere Element positionieren und über CSS Shadow Parts einzelne Bereiche ansprechen: shell, header, content, course-list und course. Farben und Typografie kommen weiterhin aus dem Dashboard-Design. Zum Beispiel:

orbinaut-booking-widget {
  display: block;
  max-width: 42rem;
  margin-inline: auto;
}

orbinaut-booking-widget::part(course) {
  break-inside: avoid;
}

Öffentliche Events

Alle Events werden im DOM nach oben weitergegeben und durchqueren das Shadow DOM (composed: true). detail enthält nur öffentliche IDs und einen begrenzten Status. Widget-Key, Workspace-ID, Name oder E-Mail sind nie enthalten. Die Buchung entsteht auf der gehosteten Seite, nicht im Widget.

Event	`detail`	Wann
`orbinaut:ready`	`{ apiVersion, widgetId, courseCount }`	Manifest geladen. `apiVersion` ist `"1"`.
`orbinaut:book-clicked`	`{ courseId, bookingUrl }`	Eine Person wählt Buchen. `bookingUrl` ist die gehostete Seite `/b/{slug}/{courseId}` mit `source=widget`.
`orbinaut:error`	`{ code, phase, retryable }`	Laden fehlgeschlagen. `phase` ist `"load"`.

document.addEventListener("orbinaut:book-clicked", (event) => {
  const { courseId, bookingUrl } = event.detail;
  // Host-Analytics. Einwilligung und Speicherdauer liegen bei dir.
});

document.addEventListener("orbinaut:error", (event) => {
  const { code, phase, retryable } = event.detail;
  if (retryable) {
    // z. B. Hinweis, es später erneut zu versuchen
  }
});

Die Codes und sichtbaren Texte stehen in der Fehlerbehebung. Host-Tracking über diese Events ist unabhängig von der datenschutzarmen Nutzungsmessung im Dashboard.