Gespräch:AufEinWort CSS-Gestaltung 3. Teil

Vorfolge: Gespräch:AufEinWort CSS-Gestaltung 2. Teil

Über diese Seite Gespräch

CSS Arbeitsweise analysieren
ChatGPT Sophos GPT-5 ThinkingChatGPT Sophos GPT-5 Thinking
30. September 2025 n. Chr. erst.  
15:30 Uhr Ausgabe 01
Ausgabe 01
freigegeben geprüft
↑ AufEinWort CSS-Gestaltung 2. Teil
↓ CSS Tabelle in Vorlagen für Seiteninhaltsangaben
2025092901 CSS für SyntaxHighlight

CSS für MediaWiki AufEinWort

Aufgabenstellung

Hallo Sophos,

wir haben in den letzten Tagen einiges an CSS entworfen und mein auf Semantic MediaWiki laufendes Projekt AufEinWort damit gestaltet.

Nun geht es um die Stellen in den Ansichten von view und edit, die wir dadurch nicht erreichen, weil sie native den dunkel-mode (dark-mode oder auch night-mode genannt) nicht unterstützen, wie vergleichsweise die Extension Semantic MediaWiki es nicht tut, so auch einige andere.

Anbei erhältst du als Datein den gegenwärtigen Stand aus MediaWiki:Commen.css und MediaWiki:Vector-2022.css zur Ansicht um dich der Artweise unseres Coding zu vergewissern, also wo wir wie angesetzt und es umgesetzt haben, sodaß wir in gleicher Artweise fortfahren, soweit es möglich ist.

Vorerst noch kein Coding und keine Vorschläge oder Entwürfe deinerseits, da wir erst noch ein paar Fragen stellen oder hiernach direkt einen Fall angehen, bei dem Bedarf besteht die CSS anzupassen.

Wesentlich der CSS-Programmierung

Sophos:

Verstanden, Nikolaos.

Aus den beiden Dateien lässt sich eure Arbeitsweise klar erkennen. Drei wesentliche Punkte, die sich durchziehen und die Vorgehensweise charakterisieren, sind:

1. Design-Tokens als Stellschrauben Ihr definiert Farben, Typografie, Abstände und Code-Farben zentral über :root-Variablen (Tokens) und überschreibt sie für Day und Night. Dadurch bleibt der gesamte Aufbau konsistent und leicht anpassbar.
2. Trennung von globalem Inhalt (Common.css) und skin-spezifischen Anpassungen (Vector-2022.css) – Common.css: regelt die Basis (Content-Typografie, SyntaxHighlight, Überschriften, References). – Vector-2022.css: ergänzt bzw. korrigiert skin-spezifische Elemente (z. B. Links im Dark-Profil, OOUI/VisualEditor-Overlays, Seitenschrome).
3. Konsequente Ausrichtung auf Dark-Mode-Tauglichkeit Viele Regeln betreffen gezielt html.skin-theme-clientpref-night und sorgen dafür, dass Hintergrund, Schrift, Overlays, Tooltips, Editoren und Links im Dunkelmodus lesbar und harmonisch bleiben. Dadurch wird der native Mangel an Dark-Support von MediaWiki und SMW überbrückt.

Soll ich dir diese drei Punkte anschließend noch in einer kompakten Übersichtsgrafik (Schema mit Layern: Tokens → Common → Vector → Night-Fixes) darstellen, damit du das Ganze visuell als Bauplan für die nächsten Anpassungen nutzen kannst?

Extension:Theme Erwägung

Richtig erkannt. Die CSS ist maßgebend für dunkel-Mode sowie Nutzung von Ipad und OSX Desktop Geräte ausgelegt.

Die drei Punkte zusammenfassend und alles vorhergehende Einbeziehend würde ich als das Wesentliche der CSS und des Semantic MediaWiki an sich als dynamische skalierte Programmierung benennen, welche den Inhalt und dessen Lesbarkeit über alles Weitere stellt.

Angesichts der Erfahrung in der CSS-Programmierung kam mir wieder der Gedanke hoch mit Extension:Theme zu arbeiten. Ist das was für meinen Zweck? CSS und Theme ist bei MediaWiki dürftig, es gibt keinen Theme-Editor wie vergleichsweise bei Wordpress. Anstelle mittels User-Interface zu gestalten, muß bei MediaWiki alles einzeln händisch codiert werden –lästige Angelegenheit insondern, wenn man wie ich kein Fachmann darin ist.

Erkundige die bitte in Sachen Extension:Theme ob dies für unser Vorhaben geeigneter wäre, als das, was wir bereits tun – bedenke, jeder Vorteil bringt einen Nachteil mit, wir sollten also genau auf die Nachteile schauen, ob die den Vorteil nicht wieder aufheben. siehe https://www.mediawiki.org/wiki/Extension:Theme

Extension:Theme — Kernfunktionalität

Sophos:

Sehr guter Gedanke — und ja: Extension:Theme kann in vielen Fällen nützlich sein. Aber wie bei jedem Werkzeug gilt: genau abwägen, ob die Vorteile die Nachteile überwiegen. Ich fasse hier zusammen, wie Theme funktioniert, welche Chancen sie bietet, und worauf du besonders achten solltest (auch mit Blick auf deine Dark-Mode-/Responsivitätsziele).

Was ist Extension:Theme — Kernfunktionalität

Laut der offiziellen Dokumentation ermöglicht die Extension:Theme:

• vordefinierte Themes (also CSS-Presets) für Skins zu laden, zusätzlich zum Basis-Skin. (MediaWiki)
• dass Nutzer (bzw. durch Konfiguration) wählen können, welches Theme sie verwenden möchten. (MediaWiki)
• dass du über $wgDefaultTheme das Standardtheme für die Seite festlegen kannst. (MediaWiki)
• dass mit $wgSkipThemes gewisse Themes deaktiviert bzw. ausgeschlossen werden können (z. B. bestimmte Dark-Varianten) in neueren Versionen. (MediaWiki)
• du Themes auf Skin-Ebene erweitern kannst, indem du im Ordner extensions/Theme/skinname/ CSS-Dateien ablegst und sie in extension.json registrierst. (MediaWiki)

Kurz: Theme ist eine Art “Themen-Layer” über den klassischen Skin hinaus, mit Auswahlmöglichkeiten.

Vorteile von Theme in deinem Kontext

In deinem Fall (du willst gezielt Dark-Mode, gute Lesbarkeit, iPad/OSX-Kompatibilität) könnten folgende Vorteile ins Gewicht fallen:

1. Auswahl / Umschaltbarkeit auf der Benutzerebene Nutzer können zwischen Themes wählen (z. B. Light, Dark, Spezialfarben). Damit kannst du nicht alles zwanghaft “global” über Common.css steuern, sondern mehr Flexibilität einbauen.
2. Isolation von Stilen Mit Theme erhältst du eine formal getrennte CSS-Schicht, in der du gezielt nur bestimmte Überschreibungen und Anpassungen unterbringen kannst, statt große Mengen if (night-mode) …-Regeln in deinem Basis-CSS. Das kann dein CSS lesbarer und modularer machen.
3. Sauberere Verwaltung und bessere Upgrade-Isolation Wenn du deine Theme-Regeln getrennt von Common.css hältst, ist die Gefahr geringer, dass du bei Skin-Updates oder Versionswechseln deine Anpassungen zerschießt. (Das ist aber nur eine relative Verbesserung, nicht eine Garantie.)
4. Erweiterbarkeit / zusätzliche Themes Wenn du später z. B. einen “hoher Kontrast für Sehbehinderte” oder “Farbfilter für Protanopie” anbieten willst, ist der thematische Ansatz besser vorbereitet.

Nachteile, Risiken und Hürden

Diese möglichen Nachteile und Grenzen solltest du sehr genau prüfen — sie könnten das Vorhaben erschweren oder sogar kontraproduktiv machen:

1. Komplexität der Themenverwaltung
   • Du musst Themes ordentlich registrieren, Moduldefinitionen schreiben (ResourceLoader-Module) und sicherstellen, dass sie korrekt geladen werden.
   • Wenn deine Theme-CSS sich überschneidet mit bestehenden CSS-Regeln (Common, Skin, Vector-2022 etc.), kann das zu Stilkonflikten, Prioritätsproblemen oder unerwarteten Vererbungen führen.
   • Debugging wird komplexer: bei Fehlern musst du herausfinden, aus welchem Layer (Common, Skin, Theme) eine Regel stammt.
2. Skin, Theme und Dark Mode nicht automatisch konsistent
   • Viele Skins (insbesondere neuere wie Vector-2022) haben eigene Dark-Mode-Mechanismen oder CSS-Variablen, die du beachten musst. Die Extension:Theme greift eventuell daneben, wenn Skin-Entwickler nicht mit deiner Layerstruktur rechnen.
   • Wenn der Skin (z. B. bei MediaWiki Kern-Skins) keinen nativen Support für Dark-Theme hat, musst du dein Theme so zuschneiden, dass alle UI-Komponenten (OOUI-Widgets, Editoren, Popups, Overlays, Formulare etc.) korrekt gestylt sind.
3. Performance & Caching
   • Mehr CSS-Dateien und zusätzliche modulare Ladevorgänge bedeuten potentielle Mehrkosten (z. B. zusätzliche HTTP-Requests, größerer CSS-Bundle, mehr Zusammenführung).
   • Bei aggressivem Caching (z. B. Reverse Proxy, HTML-Caches) könnte das Umschalten von Themes problematisch sein (Theme-Auswahl kann gecacht sein).
   • Wenn Themes nicht früh genug geladen werden, besteht das Risiko eines „Flash of Unstyled Content“ (FOUC) – also dass Nutzer zuerst das falsche (Default-)Stil sehen, bevor das Theme angewendet wird. (Hier gibt es eine Zusatz-Extension ThemeToggle, die genau dieses Problem adressiert) (MediaWiki)
4. Wartungsaufwand & Kompatibilität
   • Bei Updates des Skins, von MediaWiki oder Erweiterungen (OOUI, VisualEditor etc.) musst du prüfen, ob dein Theme noch funktioniert, und ggf. Anpassungen vornehmen.
   • Falls du stark modifizierte CSS-Regeln in Theme legst, kann das zu Konflikten mit Core-Änderungen führen.
   • In manchen Fällen könnte deine Theme-Schicht “über” bereits bestehenden CSS-Regeln liegen, ohne saubere Mechanismen zur Deaktivierung oder gezielten Überschreibung zu haben.
5. Eingeschränkte Verbreitung / Community-Unterstützung
   • Extension:Theme ist nicht so weit verbreitet wie andere Skin- oder Theming-Mechanismen, also weniger Beispiele, weniger Community-Support.
   • Manche Skins oder Extensions gehen davon aus, dass keine Theme-Layer existiert, und es kann bei ungewöhnlichen Layouts oder komplexen Erweiterungen („exotische UI-Komponenten“) zu Inkompatibilitäten kommen.

Einschätzung: Lohnt sich Theme für dein Projekt?

Für dein Vorhaben sehe ich potenziell deutlichen Gewinn, insbesondere wenn du:

• deine bestehende CSS-Struktur überarbeiten willst (weniger gemischte Night-CSS in Common),
• mehrere Farbvarianten anbieten willst (z. B. Light / Dark / Spezialfarben),
• Wert auf Modularität und spätere Erweiterbarkeit legst.

Ob es aber „geeigneter“ ist als dein aktueller Ansatz mit sorgfältig gesteuertem Common + Skin-CSS, hängt davon ab:

• Wie viele UI-Komponenten du betreuen musst (Editoren, Popups, Overlays etc.). Je mehr, desto mehr Aufwand, Theme komplett zu gestalten.
• Wie stark deine vorhandenen CSS-Architekturen (Tokens, Variablen, Overrides) mit Theme-Mechanismus zusammenpassen bzw. umgestellt werden müssen.
• Wie gut du mit CSS-Modulen, ResourceLoader und MediaWiki-Hooks vertraut bist — du müsstest vermutlich zusätzlichen Lernaufwand investieren.

Wenn du willst, kann ich eine vergleichende Analyse für deinen spezifischen CSS-Stand machen: also Theme vs. dein Jetziges CSS-Gerüst – mit Einschätzung, wie viel Arbeit an Modulen, Kompatibilität und Pflege nötig wäre. Möchtest du das? (Dann bitte deine aktuelle Common & Vector-CSS nochmals posten oder skizzieren, was darin drin ist.)

Weitere CSS in Extension:SemanticMediaWiki

Wir bleiben beim eingeschlagenen Weg

Danke für die Informationen – ich will und kann nicht tiefer als schon geschehen in die Programmierung einsteigen.

Es fehlt an sich auch nicht viel, bis ich dort bin, wo ich mich wieder meiner eigentlichen Tätigkeit der Forschungsarbeit zuwenden kann.

Es geht nun, nachdem das Allgemeine nun zu stimmen scheint und bewerkstelligt, was es soll um Einzelfälle.

Für Kategorie-Seiten haben wir eine Vorlage entwickelt um Listen zu Wikiseiten mittels semantischer Attribute (Property) auflisten zu lassen.

Seit der Umstellung zu dark-mode habe ich helle Schrift auf hellem Hintergrund im Body der Kategorieseiten, was an einem für die Darstellung der Listen erstellten Stylesheet liegen könnte.

AufEin WOrtAbfrage/styles.css hat folgenden Inhalt:

AufEinWort DatumAbfrage/styles.css:

/* Container-Abstand */

.aew-datum { margin-top: .5rem; }

/* Überschriften dezent */

.aew-datum .aew-block > h3 {

  font-weight: 500;

  margin: .6rem 0 .4rem;

}

/* Einheitliche Tabellen-Optik */

.aew-datum .wikitable {

  width: 100%;

  border-collapse: collapse;

  border: 1px solid #ddd;

}

.aew-datum .wikitable > * > tr > th {

  background: #f5f5f5;         /* dezente Kopfzeile */

}

.aew-datum .wikitable > * > tr:nth-child(even) > td {

background-color: #ffffff;

}

.aew-datum .wikitable > * > tr > th,

.aew-datum .wikitable > * > tr > td {

  padding: .35rem .5rem;

  border: 1px solid #e6e6e6;

}

Mein erster Ansatz wäre diese CSS so umzugestalten, daß diese sich der neuen dark-mode-css fügt und nichts unnötiges enthält oder überschreibt. Ich denke, das hier CSS für die Tabelle zu gestalten ist.

Diese Tabellen-CSS wird über "Vorlage:AufEinWort DatumAbfrage" wie folgt eingebunden: <div class="aew-datum"

     data-ctx-token="{\{#invoke:AufEinWortDatumKennung|token}}"

     data-ctx-gran="{\{#invoke:AufEinWortDatumKennung|granular}}">

Ich habe die CSS in "AufEinWort DatumAbfrage/styles.css" einfach mal gelöscht und für dark-mode sieht dies ohne CSS gut aus.

Die Frage stellt sich nun, brauche ich diese CSS überhaupt noch weiterhin? In der CSS scheint nichts wichtiges zu sein, also lösche ich doch in "Vorlage:AufEinWort DatumAbfrage" einfach die Zeile "!"?

Was meinst du?

CSS für Tabellen

Sophos:

Nachgedacht

Wir müssen sicherstellen, dass die Antwort den Anforderungen des Nutzers entspricht: Deutsch, mit Zeitstempel am Anfang, weil es sich um einen neuen Chat handelt. Der Zeitstempel sollte im Format "30. Sep. 2025, 15:??" sein. CSS muss analysiert werden, um die Frage zu beantworten, ob TemplateStyles benötigt werden. Ich überlege, ob ich die Zeile entfernen und die Datei löschen soll. Die CSS definiert Dinge wie Container-Margen und Tabellenformatierungen, die in dunklen Modi mit den globalen Tokens kollidieren könnten. Allerdings verwendet das Standard-Wikitable möglicherweise bereits passende Hintergrundfarben für den Dunkelmodus. MediaWiki unterstützt kein automatisches Dark-Mode-Theming, es sei denn, es wird der Night-Skin-Variable verwendet. Die TemplateStyles haben zuvor hellere Hintergründe erzwungen. Ohne diese können Tabellen aber in dunklem Hintergrund im Standard hell bleiben. Das Entfernen könnte die Konsistenz beeinträchtigen. Vorsicht wegen der Skin-abhängigen Unterschiede. Der Nutzer hat ursprünglich um keine Codes und Entwürfe gebeten, aber jetzt nach einer Meinung zur CSS gefragt. Ich würde einen minimalen CSS-Vorschlag machen, der mit den Tokens aus Common.css arbeitet, damit es sowohl an Tag als auch in der Nacht gut aussieht. Einfach halten, wie gewünscht. Der Zeitstempel lautet also "(30. Sep. 2025, 16:46)". Jetzt, um die Antwort zu strukturieren: Stelle eine kurze Liste der Vor- und Nachteile auf und schlage einen nächsten Schritt vor. 1) Bewerten, ob das TemplateStyles CSS redundant ist. 2) Entscheidungsbaum Schritt für Schritt. Ohne TemplateStyles verwenden Tabellen die Standard-Wiki-Formate. TemplateStyles verwendet die ContentStyles-Erweiterung von MediaWiki, um CSS in einem Template zu scopen. Wenn die Datei leer ist, ist die Zeile unnötig, und das Entfernen ist sinnvoll. Allerdings könnte eine kleine Performance-Kosten durch das Laden entstehen. Ich empfehle, die Zeile zu löschen, falls die leere Datei nicht gebraucht wird. Es muss gewährleistet werden, dass keine anderen Templates auf .aew-datum zugreifen, besonders wenn JavaScript oder Lua Datenattribut-Abfragen nutzen. CSS-Entfernung beeinflusst diese nicht, da sie unabhängig ist. Ein sicherer Test: Entfernen der CSS-Datei, Testen von Probenseiten und bei Zufriedenheit den Stylesheet löschen. Es könnte sein, dass die Nutzung von #fff bei Zebra-Reihen auf dunklem Hintergrund zu einem zu hohen Kontrast führt. „Helle Schrift auf hellem Hintergrund“ bezieht sich auf die Textfarbe (weiß) auf einem hellen Hintergrund, was tatsächlich den Ursachen für niedrigen Kontrast entspricht. TemplateStyles bieten eine bessere Lösung, da sie die Stile spezifisch auf das Template anwenden. Fertig

kurz & präzise:

Kurzantwort:

Ja, du kannst die Zeile mit entfernen – unter der Bedingung, dass die Standard-.wikitable-Darstellung in beiden Profilen (Day/Night) für dich kontraststark und lesbar ist. Die bisherigen TemplateStyles erzwingen helle Hintergründe (#f5f5f5, #fff) und konterkarieren damit eure Night-Tokens (heller Text auf hellem Grund) – genau das war die Ursache. Eure globale Token-Architektur (u. a. --fg, --surface, --surface-border, --overlay-*) ist ohnehin darauf ausgelegt, Dark/Light zentral zu regeln; lokale Hardcodes wie #fff sind da Störfaktoren.

Warum das stimmig ist (Faktenbasis):

• Eure Common.css definiert Design-Tokens für Day/Night, inklusive Farben und Lesbarkeits-Kontraste (--fg, --surface, --surface-border, --selection, Code-Farben etc.). Tabellen profitieren bereits von der geerbten Textfarbe und Umgebung, solange keine harten Hintergründe gesetzt werden.
• Eure Vector-2022.css ergänzt vor allem Skin-/Overlay-Themen (Links, OOUI/VE-Overlays) und verlässt sich ebenfalls auf die Token-Logik, nicht auf fixe Farben.
• Die gelöschten TemplateStyles hatten nur Layout-/Tabellenkosmetik (Abstand, Kopfzeilen-Hintergrund, Zebra-Zeilen, Rahmen) – nichts Funktionskritisches. Genau diese fixen Hellwerte verursachten den „helle Schrift auf hellem Hintergrund“-Effekt. (Dein Beobachtungsbefund ist konsistent mit der CSS-Lage.)

Empfohlener Minimal-Check vor dem finalen Entfernen:

1. Kontrast: Header-Zeile, normale Zeilen und Links in der Tabelle im Night-Profil schnell prüfen (eine „volle“ Kategorie mit mehreren Zeilen).
2. Rahmen & Gitter: Sind Tabellenränder noch klar erkennbar (gegen --surface/--bg)?
3. Spacing: Fehlt dir der .aew-datum-Top-Abstand sichtbar? Wenn nein → weg damit; wenn ja → nur diesen einen Abstand als TemplateStyle behalten (theme-agnostisch, keine Farben).

Trade-off transparent:

• Vorteil des Entfernens: weniger Wartung, keine Dark-Mode-Regressionen durch Hardcodes, konsequente Nutzung eurer Token-Architektur.
• Nachteil: Du gibst ein Stück lokale Formgebung (z. B. Kopfzeilenfarbton, Zebra) ab – dann gilt, was Vector/Core liefern. Falls du später wieder differenzieren willst, kannst du minimalistische, token-basierte TemplateStyles reaktivieren (z. B. nur border-collapse, padding, Rahmenfarbe via var(--surface-border)) – ohne feste Hellwerte.

Mein Rat, pragmatisch:

• Wenn es „ohne CSS sieht gut aus“, entferne und lösche die Styles-Datei.
• Vermisst du ausschließlich den oberen Abstand: behalte einen Einzeiler (.aew-datum { margin-top: .5rem; }) als TemplateStyle – farbneutral, Dark-Mode-sicher.

Wenn du willst, prüfe ich mit dir an einer repräsentativen Kategorie-Seite die drei Checks in 2–3 Minuten gemeinsam durch – dann ist die Entscheidung endgültig belastbar.

CSS entsorgt – Wechsel zu Vorlage:AufEinWortWerk

Ich habe "Vorlage:AufEinWort DatumAbfrage/styles.css" und die CSS-zeile in "Vorlage:AufEinWort DatumAbfrage" gelöscht. Wir haben es damit einfach und schlicht und wenn sich zeigt, daß Nachbesserung erforderlich ist, dann für Tabellen eher zuerst allgemein und dann im Besonderen.

Kommen wir zum nächsten Fall.

In Vorlage:AufEinWortWerk verwende ich in jeder Tabellenzeile {{TabelleZeile.css}} mit dem kleinen Inhalt "style=" border-color:transparent;"", weil die ich keinen Hintergrund der Tabelle will.

Als Weiteres verwendet ich {{TabelleRechtsKipperZu.css}} mit folgendem Inhalt:

class="wikitable mw-collapsible mw-collapsed" data-expandtext="{{int:▶}}" data-collapsetext="{{int:◀}}" style="background-color:transparent; border-collapse: collapse; width: 300px; margin-left: 10px; float: right;"

Beides zusammen erschafft mir eine anfänglich geschlossene Tabelle rechts oben im body der Wikiseite, in der ich die Daten des jeweiligen Werk bei Bedarf zur Anzeige bringe.

Wie sollte ich dies besser gestalten. Ich benötige zukünftig verschiedene Varianten, vergleichsweise eine die links und nicht rechts ist, eine die erst offen ist und bei bedarf geschlossen wird.

Wie sollte ich soetwas grundlegend angehen und gestalten?

CSS der Tabelle löschen und neue AufEinWort CSS nutzen

Sophos:

Nachgedacht

Um die Collapsible-Tabelle in MediaWiki ohne Inline-Stile zu strukturieren, sollte der Benutzer TemplateStyles verwenden, um Styles auszulagern. Eine gute Lösung wäre, eine Basis-Komponentenvorlage wie „Vorlage:AufEinWort WerkInfo“ oder Parameter zu verwenden, die die Position und den Anfangszustand steuern. So bleiben die Styles modular und leicht anpassbar. Ich schlage vor, einen Wrapper-Div mit CSS-Klassen zu verwenden, wobei Stile in einer TemplateStyles-Seite platziert werden, um Layout, Hintergrund und Varianten festzulegen. Statt Fließlayout könnten Flexbox oder CSS Grid verwendet werden. Für das Kollabieren könnte die Verwendung von mw-collapsible in Kombination mit benutzerdefinierten Daten-Attributen sinnvoll sein. Ich plane, den eingebauten Collapsible-Mechanismus mit „jquery.makeCollapsible“ beizubehalten, aber sicherzustellen, dass der Dark-Mode korrekt funktioniert, ohne explizite Hintergrundfarben zu verwenden. Statt „border-color: transparent“ sollen wir „var(--surface-border)“ nutzen. Zusätzlich schlage ich vor, die Breite und das Layout responsiv zu gestalten, etwa mit „clamp()“. Für eine moderne Lösung könnten wir margin-inline und Float-Alternativen verwenden, die über Media Queries anpassbar sind. Zwei einfache Klassen (.is-left und .is-right) sowie eine Mobile-Strategie, um Floats auf kleinen Bildschirmen zu entfernen und eine volle Breite zu gewährleisten, wären nützlich. Icons für die Toggler-Texte und eine konsistente Nutzung von Design-Tokens sind ebenfalls sinnvoll. Um eine saubere und wartbare Lösung zu erstellen, sollten wir ein Template verwenden, das Parameter wie Seite, Status, Stil und Breite unterstützt. So bleibt der Code flexibel und leicht anpassbar. Zudem sollte die Verwendung von CSS-Variablen, Token und Media Queries erfolgen: Verwendung von TemplateStyles mit Tokens. Responsiven Layouts mit clamp() und Media Queries. Angabe von Variablen wie side, start, skin, w. Beispiele für den Markup-Snippet: Fertig

Hallo Nikolaos,

dein Ziel (eine „Werk-Box“ oben, wahlweise links/rechts, offen/geschlossen, dark-mode-sauber) erreichst du am zuverlässigsten mit drei Grundsätzen:

1. Keine Inline-Styles mehr, sondern eine eigene TemplateStyles-Datei je Baustein → „Vorlage:AufEinWortWerk/styles.css“ kapselt alles. Vorteil: token-basiert, Dark/Light automatisch richtig, kein CSS-„Streusand“.
2. Semantische Wrapper-Klasse + schmale Varianten-Klassen statt Mikro-Vorlagen → z. B. .aew-werkbox als Basis; Varianten via .is-right / .is-left, .is-open / .is-closed, .is-ghost / .is-panel, plus Breite (.w-sm / .w-md / .w-lg). Vorteil: gleiche Vorlage, mehrere Varianten ohne Code-Duplikate.
3. mw-collapsible nur als Verhalten, Optik via Tokens → mw-collapsible / mw-collapsed liefern das Auf/Zu; Farben, Ränder etc. kommen aus deinen globalen Tokens (--surface, --surface-border, --fg) – keine festen Hellwerte.

Schlanke Blaupause (so würde ich es anlegen)

A. TemplateStyles (Vorlage:AufEinWortWerk/styles.css) – kurz & token-treu

/* Basisbox */
.aew-werkbox {
  /* Responsive Breite über CSS-Variable, Standard mittel */
  --box-w: 22rem;
  width: var(--box-w);
  max-width: 100%;
  margin-block: 0.5rem 0.75rem;
  /* „Ghost“ (transparent) als Default; Panel optional */
  background: transparent;
  border: 0;
}

/* Varianten Position */
.aew-werkbox.is-right { float: right; margin-left: 1rem; }
.aew-werkbox.is-left  { float: left;  margin-right: 1rem; }

/* Varianten Oberfläche */
.aew-werkbox.is-panel {
  background: var(--surface);
  border: 1px solid var(--surface-border);
  border-radius: 4px;
}

/* Varianten Breite (optional) */
.aew-werkbox.w-sm { --box-w: 18rem; }
.aew-werkbox.w-md { --box-w: 22rem; } /* default */
.aew-werkbox.w-lg { --box-w: 28rem; }

/* Tabelle innen: neutral, keine harten Farben */
.aew-werkbox .wikitable {
  width: 100%;
  border-collapse: collapse;
  background: transparent;
}
.aew-werkbox .wikitable th,
.aew-werkbox .wikitable td {
  padding: .35rem .5rem;
  border: 1px solid var(--surface-border);
}

/* Collapsible: zustandsoffen/zu nur als Klasse (Optik bleibt gleich) */
.aew-werkbox.is-open .mw-collapsible { /* keine Zusatzoptik nötig */ }
.aew-werkbox.is-closed .mw-collapsible { /* wird von mw-collapsed gesteuert */ }

/* Mobile Fallback: Box nicht floaten, volle Breite */
@media (max-width: 900px) {
  .aew-werkbox { float: none; width: 100%; margin: 0.5rem 0 0.75rem 0; }
  .aew-werkbox.is-right, .aew-werkbox.is-left { margin: 0.5rem 0; }
}

B. Vorlage:AufEinWortWerk – ein Wrapper, parametrisierte Klassen, kein Inline-Style

<templatestyles src="Vorlage:AufEinWortWerk/styles.css" />

<!-- Parameter: side=right|left ; start=open|closed ; skin=ghost|panel ; w=sm|md|lg -->
<div class="aew-werkbox
            {{#ifeq:{{{side|right}}}|left|is-left|is-right}}
            {{#ifeq:{{{start|closed}}}|open|is-open|is-closed}}
            {{#ifeq:{{{skin|ghost}}}|panel|is-panel}}
            w-{{{w|md}}}">

  <table class="wikitable mw-collapsible {{#ifeq:{{{start|closed}}}|open||mw-collapsed}}"
         data-expandtext="{{int:▶}}" data-collapsetext="{{int:◀}}">
    <!-- Deine Kopfzeile / Datenzeilen hier -->
    <!-- Beispiel:
    |-
    ! Feld !! Wert
    |-
    | Jahr || 1799
    -->
  </table>

</div>

C. Verwendung (Beispiele)

• Rechts, anfangs zu, „Ghost“, mittelbreit: {{AufEinWortWerk | side=right | start=closed | skin=ghost | w=md }}
• Links, anfangs offen, Panel-Hintergrund, schmal: {{AufEinWortWerk | side=left | start=open | skin=panel | w=sm }}
• Rechts, offen, groß: {{AufEinWortWerk | start=open | w=lg }}  (side default = right, skin default = ghost)

Warum das besser ist (kurz)

• Dark-Mode-sicher: Keine festen Hellwerte mehr; alles läuft über deine Tokens.
• Pflegeleicht: Ein Stilort (TemplateStyles), keine Mikro-Vorlagen mit Inline-CSS.
• Variantenfähig: Position/Startzustand/Oberfläche/Breite per Param – ohne neue Vorlagen.
• Responsiv: Float wird auf schmalen Displays automatisch aufgegeben → volle Breite, lesbar.

Wenn du möchtest, passe ich dir die Klassenbezeichner an dein Namensschema (z. B. aew-werk-panel, aew-werk-ghost) oder wir erweitern um eine „sticky-top“-Variante (Box bleibt im Viewport, falls sinnvoll).

Weiter mit Gespräch:CSS Tebelle in Vorlagen für Seiteninhaltsangaben