/* ============================================================ * Pagetal CMS – Page-Builder: Baustein-Optik * ------------------------------------------------------------ * Diese Datei enthält AUSSCHLIESSLICH: * 1) die tatsächliche, auch auf der veröffentlichten Website * sichtbare Optik der Page-Builder-Bausteine (.pb-container * und deren Modifikator-Klassen) – wird daher im der * öffentlichen Website UND innerhalb der Shadow-DOM-Leinwand * im Builder geladen (siehe partials/kopf.php bzw. * admin/page-builder.php); * 2) die rein editor-eigenen Zustände, die visuell direkt an * einen Baustein gebunden sind (Auswahl-Rahmen, Drop-Zonen, * Einfüge-Indikator, Leer-Hinweis, Floating-Toolbar) – deren * Klassen werden ausschliesslich von assets/js/page-builder.js * innerhalb der Leinwand gesetzt und kommen daher auf der * öffentlichen, vom Server gerenderten Seite nie vor. * * Reine Admin-Chrome (3-Spalten-Layout, Bibliothek, Inspektor, * Topbar) steht bewusst NICHT hier, sondern in page-builder.css – * jene Datei wird nur im Backend geladen, nie auf der Leinwand * selbst oder der öffentlichen Website. * * Farben/Masse kommen konsequent aus den Theme-Variablen von * frontend.css (--gruen, --navy, --weiss, --hellgrau-1 usw.), nie * aus fixen Hex-Werten – so folgen die Bausteine automatisch den * unter "Design" gewählten Einstellungen. * ============================================================ */ /* ---------- Baustein: Container ---------- */ /* padding:0 hier bewusst EXPLIZIT nötig (nicht nur "0 als Ausgangswert"): frontend.css definiert eine generische Basis-Regel "section{padding:90px 0;}" für die eigenen, semantischen Layout-Sections der Website (z.B. Hero). Der Container-Baustein rendert selbst ebenfalls als
(siehe pagetal_pb_container_rendern()) und würde diese fremde Regel sonst erben. Bis v1.12.2 überschrieb die (höher-spezifische) Abstand-Preset- Klasse ".pb-abstand-*{padding:...}" diese Regel implizit mit; seit v1.13.0 sitzt das Innenabstand-Padding bewusst auf der inneren ".container"-Dropzone statt auf diesem äusseren Element (siehe "Zwei-Ebenen-Prinzip" in pagetal_pb_container_rendern()) - ohne dieses explizite Override würde die generische section-Regel deshalb unbeabsichtigt wieder durchschlagen und JEDEN Container (nicht nur migrierte) mit einem ungewollten zusätzlichen 90px-Innenabstand oben/ unten versehen. Bei der Wegwerf-Klon-Verifikation von v1.13.0 genau so gefunden (Höhe des äusseren Blocks war 180px zu gross) und hier behoben. */ /* Ab v1.19.99 (echtes "Fixed", siehe ausführlicher Docblock bei pagetal_pb_container_parallax_ebene_css() in includes/page-builder.php): JEDER Container bekommt zusätzlich (siehe "view-timeline-*" unten) eine eigene, nach seiner Sichtbarkeit im Scroll-Fenster benannte "Scroll-Driven-Animation"-Zeitachse ("view-timeline"). Bewusst UNCONDITIONAL/immer vorhanden (wie die Wrapper-Ebenen weiter unten) - eine ungenutzte Zeitachse kostet nichts, macht aber den Umschalt-Effekt "Fixed" ein-/ausschalten in der Live-Vorschau wieder rein über generiertes CSS möglich, ohne Leinwand-Neurendering. "--pb-fenster" als Name wird bewusst auf JEDEM Container identisch vergeben - das ist KEIN Konflikt, da ein Nachfahre (die Bildebene weiter unten) bei "animation-timeline:--pb-fenster" automatisch den NÄCHSTGELEGENEN Vorfahren mit diesem Namen verwendet (exakt wie bei CSS-Zählern/scope- bewussten Variablen) - jeder Container bekommt dadurch garantiert seine EIGENE Zeitachse, auch wenn mehrere Container mit "Fixed" auf derselben Seite vorkommen (per Playwright-Test verifiziert). */ .pb-container{position:relative;padding:0;view-timeline-name:--pb-fenster;view-timeline-axis:block;} /* Ab v1.19.99: die eigentliche Gegenbewegung für "Fixed" (siehe Docblock bei pagetal_pb_container_parallax_ebene_css()) - läuft über die obige "--pb-fenster"-Zeitachse komplett im Browser/auf der Grafikkarte, ohne jedes Zutun von JavaScript. "--pb-fixiert-margin" liefert assets/js/hintergrund-parallax.js einmalig beim Laden sowie bei "resize" (siehe dortiger Docblock) - ohne JavaScript (oder ohne Browser-Unterstützung von "animation-timeline") bleibt die Variable undefiniert, der "calc()"-Fallback "0px" sorgt dann für ein ruhiges, unbewegtes Bild statt eines Fehlers. */ @keyframes pb-fixiert-gegenbewegung{ from{transform:translateY(calc(-1 * var(--pb-fixiert-margin,0px)));} to{transform:translateY(var(--pb-fixiert-margin,0px));} } /* Video-Hintergrund (Tab "Stil" -> Hintergrund -> Video, ab v1.13.0): absolut positioniert HINTER dem Inhalt (z-index:-1), .pb-container hat bereits position:relative als Bezugsrahmen. Nur eingefügt, wenn tatsächlich ein Video-Hintergrund konfiguriert ist (siehe pagetal_pb_container_rendern()). */ .pb-container-hintergrund-video{position:absolute;inset:0;width:100%;height:100%;object-fit:cover;z-index:-1;pointer-events:none;} /* Parallax-Wrapper-Ebenen ("hg"/"ue", ab v1.19.94, siehe Docblock bei pagetal_pb_container_parallax_ebene_aktiv() in includes/page-builder.php): bewusst IMMER gerendert (siehe pagetal_pb_container_parallax_ebene_html()), auch ohne aktiven Effekt - ohne zugewiesenes CSS (siehe pagetal_pb_container_parallax_ebene_css()) bleibt ein Fenster dann ein leeres 0×0-Element ohne jede Auswirkung. Bugfix v1.19.95 (Stephans Bug-Report: schwebender Ziehen-Griff im Editor verschwand bei "Anhang: Fixed"): "overflow:hidden" sass bis v1.19.94 auf dem GANZEN Container (".pb-container") und schnitt damit auch dessen schwebende Floating-Toolbar ab (".pb-floating-toolbar", "top:-38px" - ragt bewusst über den Container hinaus, siehe weiter unten). Jetzt trägt NUR noch dieses Fenster "overflow:hidden" - exakt auf die Containergrösse begrenzt (position:absolute;inset:0), die eigentliche, überdimensionierte Bildebene (.pb-container-parallax-ebene) liegt als dessen Kind darin. z-index kommt bewusst von HIER (nicht mehr aus generiertem Block-CSS): "hg" wie der bisherige Video-Hintergrund hinter allem, "ue" knapp darüber, aber weiterhin unter dem eigentlichen Inhalt. */ .pb-container-parallax-fenster{position:absolute;inset:0;overflow:hidden;pointer-events:none;} .pb-container-parallax-fenster[data-pb-parallax-fenster="hg"]{z-index:-1;} .pb-container-parallax-fenster[data-pb-parallax-fenster="ue"]{z-index:0;} /* Container-weiter Link (Tab "Erweitert" -> "Link", ab v1.19.58, Stephans Wunsch: "sobald ein link eingetragen [...] wirkt dieser link auf den ganzen container"): ein unsichtbares deckt bei gesetztem Link die GESAMTE Containerfläche ab (siehe pagetal_pb_container_rendern()/ pbBausteinHtml() für das Markup). "pointer-events:none" ist hier bewusst der SICHERE STANDARDWERT, der überall gilt - sowohl im Editor als auch (ohne die gezielte Aktivierung unten) auf der öffentlichen Seite: der Editor-Leinwand-Canvas braucht weiterhin uneingeschränkten Klickzugriff auf JEDEN verschachtelten Baustein (Textbearbeitung, Ziehen-Greifer, Symbolleiste einzelner Kind-Bausteine) - ein durchgehend anklickbares Overlay würde genau das verhindern. NUR pagetal_pb_container_block_css() (PHP, ausschliesslich die öffentliche Seite) schaltet "pointer-events" für einen KONKRETEN, tatsächlich verlinkten Container gezielt per [data-pb-block-id]-Selektor (höhere Spezifität) wieder auf "auto" - der JS-Zwilling pbContainerBlockCssBauen() (Editor-Live-Vorschau) tut das BEWUSST NICHT (einzige, bewusste Ausnahme von der sonst überall geltenden 1:1-PHP/JS-Zwillingsregel dieses Projekts, siehe ausführliche Begründung dort sowie in PROJEKT-STATUS.md v1.19.58). Zum Bearbeiten verschachtelter Bausteine INNERHALB eines verlinkten Containers dient im Editor weiterhin die Struktur-Baum-Seitenleiste. "z-index:-1" (NICHT positiv!) ist entscheidend für die Klick- Weiterleitungstechnik in pagetal_pb_container_block_css(): ein ECHTER, per pointer-events wieder aktivierter Link/Button INNERHALB des Containers muss im normalen Zeichen-Fluss oberhalb des Overlays liegen (Malreihenfolge), damit ein Klick auf IHN gewinnt statt auf das Overlay dahinter - mit einem positiven Z-Index läge das Overlay fälschlich ÜBER jedem normalen Inhalt (auch über echten Links), da positioniertes CSS mit z-index:0/positiv laut Zeichen-Reihenfolge immer NACH normalem, nicht positioniertem Fluss-Inhalt gezeichnet wird - beim ersten Test dieser Technik per Playwright genau so nachgewiesen (ein eigener Link im Container wurde faelschlich vom Overlay "verdeckt") und dadurch vor der Auslieferung korrigiert. Mit "z-index:-1" zeichnet der Browser das Overlay VOR (=unter) jedem normalen Fluss-Inhalt - Text/Bilder OHNE eigenen Link "fallen" dadurch zum Overlay durch (siehe pointer-events:none in pagetal_pb_container_block_css()), ein ECHTER Link bleibt aber klickbar, weil er im normalen Fluss über dem Overlay liegt. ".pb-container" trägt bereits position:relative als Bezugsrahmen (analog ".pb-container-hintergrund-video" oben, das aus demselben Grund ebenfalls z-index:-1 nutzt) - zusätzlich erzwingt pagetal_pb_container_block_css() für einen tatsächlich verlinkten Container "isolation:isolate" auf dem Container selbst, damit dieses negative Z-Index NICHT versehentlich hinter vorangehende Geschwister- Bausteine auf derselben Seite "durchrutscht" (eigener, lokal abgeschotteter Stapelkontext NUR für diesen einen Container). */ .pb-container-link-overlay{position:absolute;inset:0;z-index:-1;display:block;pointer-events:none;} /* Baustein "Meldung" (ab v1.19.65) - der optionale Baustein-weite Link (Tab "Inhalt" -> "Link-URL") nutzt dieselbe "z-index:-1 + inset:0"- Overlay-Technik wie ".pb-container-link-overlay" oben (siehe dort für die volle Begründung). "isolation:isolate" erzwingt pagetal_pb_meldung_block_css() zusätzlich NUR für einen tatsächlich verlinkten Meldung-Baustein direkt auf [data-pb-block-id="..."]. */ .pb-meldung-link-overlay{position:absolute;inset:0;z-index:-1;display:block;pointer-events:none;} /* Hintergrundfarbe/-verlauf/-bild, Rand, Box-Schatten, Effekte, Abstand und Z-Index sind ab v1.13.0 KEINE festen CSS-Klassen mehr (frei wählbare Werte statt fixer Presets) – sie werden als generiertes, block-spezifisches CSS über [data-pb-block-id="..."] ausgeliefert (siehe pagetal_pb_container_block_css() in includes/page-builder.php und pbBausteinCssBauen() in assets/js/page-builder.js). Die Klassen ".pb-spalten-N"/".pb-zeilen-M" bleiben trotzdem bestehen, weil die Spaltenzahl unmittelbar mit der Drag&Drop-Erkennung verzahnt ist (siehe pbEinfuegeIndexBestimmen() in page-builder.js, liest die Zahl per Regex aus dem Klassennamen) – ihr HIER definiertes CSS (display:grid/grid-template-*) ist seit v1.14.0 allerdings reine Rückfalloption: das tatsächlich wirksame CSS (inkl. Umbruchverhalten, siehe Begründung dort) setzt IMMER das generierte, block-spezifische CSS mit höherer Selektor-Spezifität. ".pb-zeilen-M" wirkt sich seit v1.14.0 gar nicht mehr aus (Raster läuft jetzt über Flexbox, das keine feste Zeilenzahl kennt) – bewusst nicht entfernt, da die Klasse selbst harmlos ist und an anderer Stelle (falls je wieder gebraucht) sonst neu erfunden werden müsste. */ .pb-spalten-1{display:grid;grid-template-columns:1fr;} .pb-spalten-2{display:grid;grid-template-columns:repeat(2,1fr);} .pb-spalten-3{display:grid;grid-template-columns:repeat(3,1fr);} .pb-spalten-4{display:grid;grid-template-columns:repeat(4,1fr);} .pb-spalten-5{display:grid;grid-template-columns:repeat(5,1fr);} .pb-spalten-6{display:grid;grid-template-columns:repeat(6,1fr);} .pb-spalten-7{display:grid;grid-template-columns:repeat(7,1fr);} .pb-spalten-8{display:grid;grid-template-columns:repeat(8,1fr);} .pb-spalten-9{display:grid;grid-template-columns:repeat(9,1fr);} .pb-spalten-10{display:grid;grid-template-columns:repeat(10,1fr);} .pb-spalten-11{display:grid;grid-template-columns:repeat(11,1fr);} .pb-spalten-12{display:grid;grid-template-columns:repeat(12,1fr);} .pb-zeilen-1{grid-template-rows:1fr;} .pb-zeilen-2{grid-template-rows:repeat(2,1fr);} .pb-zeilen-3{grid-template-rows:repeat(3,1fr);} .pb-zeilen-4{grid-template-rows:repeat(4,1fr);} .pb-zeilen-5{grid-template-rows:repeat(5,1fr);} .pb-zeilen-6{grid-template-rows:repeat(6,1fr);} .pb-zeilen-7{grid-template-rows:repeat(7,1fr);} .pb-zeilen-8{grid-template-rows:repeat(8,1fr);} .pb-zeilen-9{grid-template-rows:repeat(9,1fr);} .pb-zeilen-10{grid-template-rows:repeat(10,1fr);} .pb-zeilen-11{grid-template-rows:repeat(11,1fr);} .pb-zeilen-12{grid-template-rows:repeat(12,1fr);} /* Bugfix v1.14.0: einen festen @media-Kollaps der Spalten-Layouts gibt es bewusst NICHT mehr (weder hier noch in includes/design.php, pagetal_design_responsive_css()) – Raster (Grid)-Container laufen seit v1.14.0 über Flexbox (flex-wrap) und brechen dadurch stufenlos an der tatsächlich verfügbaren Breite um, statt stur bei zwei festen Breakpoints einzuspaltig zu stapeln (Bug-Report Stephan). Siehe pagetal_pb_container_block_css()/pbContainerBlockCssBauen(). */ /* Inhaltsbreite "Volle Breite" (Tab "Design", ab v1.13.0): der breitenbegrenzte .container-Innenbereich (frontend.css) verliert seine max-width, behält aber seinen horizontalen Innenabstand (--container-innenabstand) als Gutter. */ .pb-container-voll > .container{max-width:none;} /* Bugfix v1.13.2: Kind-Bausteine INNERHALB eines Containers dürfen kein eigenes vertikales Margin mehr mitbringen - sonst bleibt trotz "Lücke (Gap)" = 0px (oder global auf 0px gestellt) sichtbarer Abstand übrig, weil z.B. .pb-ueberschrift/.pb-texteditor (siehe weiter unten) ein festes margin-bottom:20px für die Verwendung AUSSERHALB von Containern (direkt auf der Seiten-Wurzel, wo es KEINE Gap-Einstellung gibt und dieses Margin die einzige Abstandsquelle zwischen Bausteinen ist) tragen. Innerhalb eines Containers soll ausschliesslich "Lücke" (column-gap/row-gap, siehe pagetal_pb_container_block_css()) über den Abstand zwischen Geschwister-Bausteinen entscheiden - deshalb hier gezielt auf 0 zurückgesetzt. Bewusst nur für ".container" MIT "data-pb-dropzone" (echte Container-Dropzone, sowohl im Editor als auch auf der öffentlichen Seite) - die Seiten-Wurzel trägt im Editor zwar ebenfalls "data-pb-dropzone", aber NICHT die Klasse "container" (siehe #pb-wurzel-container/.pb-seiteninhalt-innen in assets/js/page-builder.js) und bleibt von dieser Regel unberührt. WICHTIG: ":not(.pb-container)" schliesst verschachtelte Container (Container-in-Container) bewusst aus. Ohne diesen Ausschluss würde diese Regel (Spezifität: Klasse + Attribut = höher als die einzelne Attribut-Selektor-Regel "[data-pb-block-id=X]{margin:...}", über die der eigene Aussenabstand eines Containers gesetzt wird, siehe pagetal_pb_container_block_css()) den vom Nutzer explizit gesetzten Aussenabstand eines verschachtelten Containers unbeabsichtigt überschreiben, sobald dieser innerhalb eines anderen Containers liegt. */ .container[data-pb-dropzone] > *:not(.pb-container){margin-top:0;margin-bottom:0;} /* ---------- Baustein: Überschrift ---------- */ /* Bugfix v1.13.3: "padding:4px 2px" stand hier unbegründet und undokumentiert seit dem allerersten Commit (v1.9.0-Basis) – keine andere Stelle in CSS/JS setzt das funktional voraus (Auswahl-/ Container-Rahmen im Editor nutzen bewusst "outline" mit negativem "outline-offset" statt Padding, siehe .pb-auswahl/.pb-container-rahmen weiter unten – genau damit kein zusätzlicher Platz im Boxmodell nötig ist). Es widersprach ausserdem dem mit v1.13.2 etablierten Prinzip "Null ist null": selbst bei Lücke=0 UND Aussenabstand=0 blieb über dieses Padding ein sichtbarer Rest-Abstand (4px oben/unten, 2px links/rechts) bestehen. Auf Wunsch von Stephan entfernt – Abstand zwischen Bausteinen wird jetzt AUSSCHLIESSLICH über Lücke (Gap) und/oder Innen-/Aussenabstand gesteuert, wie vorgesehen. */ .pb-ueberschrift{position:relative;margin:0 0 20px;padding:0;} /* ---------- Baustein: Texteditor ---------- */ /* Ab v1.19.5 (Stephans Bug-Report Punkt 5): die frühere feste Klasse ".pb-texteditor-schmal" (altes Feld "Breite": Normal/Schmal) wurde entfernt - durch die neue, für ALLE Bausteine geltende "Erweitert" -> "Breite/Höhe"-Funktion ersetzt (siehe pagetal_pb_baustein_groesse_css() in includes/page-builder.php). */ .pb-texteditor{position:relative;margin:0 0 20px;padding:0;line-height:1.7;color:var(--grau-text);} .pb-texteditor p{margin:0 0 16px;} .pb-texteditor p:last-child{margin-bottom:0;} .pb-texteditor ul,.pb-texteditor ol{margin:0 0 16px 22px;} .pb-texteditor ul{list-style:disc;} .pb-texteditor ol{list-style:decimal;} .pb-texteditor li{margin-bottom:6px;} /* Ab v1.19.37 (Stephans Bug-Report Punkt 2 UND Punkt 3 - derselbe Grund-Ursache, siehe Docblock bei ".pb-navigationsmenue-links a" weiter unten): das feste "color:var(--gruen)" wurde ENTFERNT. Stephan verlangt für das neue Link-Icon ausdrücklich "die farbgestaltung ist so wie in den einstellungen definierten linkfarbe für normal und hover" - das setzt voraus, dass der Link-TEXT selbst bereits dieser Einstellung folgt. Vorher tat er das nicht: die Klassen-selektierte Regel hier hatte dieselbe/höhere CSS-Spezifität wie die globale Typografie-Regel ("a{color:...}"/"a:hover{color:...}", siehe pagetal_design_typografie_css() in includes/design.php) und überschrieb dadurch die unter "Design -> Typografie je Element -> Link" konfigurierte Farbe dauerhaft - ganz besonders beim Hover, wo beide Regeln exakt dieselbe Spezifität hatten und daher rein von der Lade-Reihenfolge abhing, welche gewinnt (faktisch nie zuverlässig die konfigurierte Hover-Farbe). "text-decoration:underline" bleibt bestehen, das ist reine Texteditor-Optik, keine Farbe. */ .pb-texteditor a{text-decoration:underline;} /* Ab v1.19.37 (Stephans Bug-Report Punkt 2: "wenn in texteditor ein teil markiert wird und ein link hinzugefügt wird soll ein icon nach dem text erscheinen (dynamisch), das icon hat die genau gleiche grösse des textes... farbgestaltung ist so wie in den einstellungen definierten linkfarbe für normal und hover"): dynamisches Icon nach JEDEM Link im Texteditor, rein per CSS (keine JS-Inhalts-Manipulation nötig) - so bleibt der gespeicherte HTML-Inhalt selbst unverändert und das Icon passt sich automatisch an, sobald sich Text/Link-Grösse oder -Farbe ändert. Technik: "mask-image" mit einer eingebetteten SVG-Daten-URI (wiederverwendetes 'extern'-Icon, siehe includes/icons.php) plus "background-color:currentColor" - dadurch übernimmt das Icon IMMER automatisch exakt dieselbe Farbe wie der umgebende Link-Text, inklusive Hover (da ":hover" bereits die Farbe des selbst ändert und "currentColor" das live mitverfolgt - keine eigene ":hover"-Regel fürs Icon nötig). Grösse in "em" gesetzt, damit das Icon IMMER exakt der aktuellen Schriftgrösse des Textes entspricht (auch bei Ebene wie H2 usw.). Kleiner Abstand links UND rechts (margin), damit es sich harmonisch in den Textfluss einfügt, statt zu kleben. Das eingebettete SVG selbst nutzt bewusst einen deckenden WEISSEN Strich (nicht "currentColor", Daten-URIs können keine CSS-Variablen auflösen) - sowohl helligkeits- als auch alphabasierte Masken-Implementierungen der Browser stellen Weiss auf transparentem Grund dadurch zuverlässig als "sichtbar" dar. */ .pb-texteditor a::after{ content:''; display:inline-block; width:1em; height:1em; margin:0 .15em 0 .25em; vertical-align:-.15em; background-color:currentColor; -webkit-mask-image:url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCAyNCAyNCIgZmlsbD0ibm9uZSIgc3Ryb2tlPSIjZmZmIiBzdHJva2Utd2lkdGg9IjIiIHN0cm9rZS1saW5lY2FwPSJyb3VuZCIgc3Ryb2tlLWxpbmVqb2luPSJyb3VuZCI+PHBhdGggZD0iTTE4IDEzdjZhMiAyIDAgMCAxLTIgMkg1YTIgMiAwIDAgMS0yLTJWOGEyIDIgMCAwIDEgMi0yaDYiPjwvcGF0aD48cG9seWxpbmUgcG9pbnRzPSIxNSAzIDIxIDMgMjEgOSI+PC9wb2x5bGluZT48bGluZSB4MT0iMTAiIHkxPSIxNCIgeDI9IjIxIiB5Mj0iMyI+PC9saW5lPjwvc3ZnPg=="); mask-image:url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCAyNCAyNCIgZmlsbD0ibm9uZSIgc3Ryb2tlPSIjZmZmIiBzdHJva2Utd2lkdGg9IjIiIHN0cm9rZS1saW5lY2FwPSJyb3VuZCIgc3Ryb2tlLWxpbmVqb2luPSJyb3VuZCI+PHBhdGggZD0iTTE4IDEzdjZhMiAyIDAgMCAxLTIgMkg1YTIgMiAwIDAgMS0yLTJWOGEyIDIgMCAwIDEgMi0yaDYiPjwvcGF0aD48cG9seWxpbmUgcG9pbnRzPSIxNSAzIDIxIDMgMjEgOSI+PC9wb2x5bGluZT48bGluZSB4MT0iMTAiIHkxPSIxNCIgeDI9IjIxIiB5Mj0iMyI+PC9saW5lPjwvc3ZnPg=="); -webkit-mask-size:contain; mask-size:contain; -webkit-mask-repeat:no-repeat; mask-repeat:no-repeat; -webkit-mask-position:center; mask-position:center; } /* Ab v1.17.52 (Stephans Wunsch: "Basis-Upgrade" analog WordPress) - h2/h3/h4 erben Schriftschnitt/-farbe bereits von der globalen Regel "h1,h2,h3,h4{font-weight:700;line-height:1.2;color:var(--navy);}" (assets/css/frontend.css) - hier nur die im Texteditor-Kontext sinnvolle Grössen-Abstufung/den Abstand ergänzt, siehe pagetal_pb_html_bereinigen() für die zugehörige Server-Whitelist. Ab v1.19.37 (Stephans Bug-Report Punkt 2/3): die früheren festen "font-size"-Werte je Überschrift-Ebene wurden ENTFERNT - sie überschrieben (höhere CSS-Spezifität durch die Klasse ".pb-texteditor") IMMER die unter "Design -> Typografie je Element" konfigurierte Schriftgrösse, unabhängig davon, was dort eingestellt war. Nur der Zeilenabstand (margin) bleibt hier bestehen, die Schriftgrösse kommt jetzt ausschliesslich aus der globalen Typografie. Ausserdem neu: h1/h5/h6-Regeln, da der Texteditor-Werkzeugkasten (siehe pbInhaltTabRendern() in assets/js/page-builder.js) ab sofort auch diese Formate anbietet, nicht mehr nur h2-h4. */ .pb-texteditor h1{margin:0 0 20px;} .pb-texteditor h2{margin:0 0 16px;} .pb-texteditor h3{margin:0 0 14px;} .pb-texteditor h4{margin:0 0 12px;} .pb-texteditor h5{margin:0 0 10px;} .pb-texteditor h6{margin:0 0 8px;} .pb-texteditor h1:last-child,.pb-texteditor h2:last-child,.pb-texteditor h3:last-child,.pb-texteditor h4:last-child,.pb-texteditor h5:last-child,.pb-texteditor h6:last-child{margin-bottom:0;} .pb-texteditor blockquote{margin:0 0 16px;padding:4px 0 4px 18px;border-left:3px solid var(--gruen);font-style:italic;color:var(--navy);} .pb-texteditor blockquote:last-child{margin-bottom:0;} .pb-texteditor blockquote p{margin:0 0 8px;} .pb-texteditor blockquote p:last-child{margin-bottom:0;} .pb-texteditor hr{margin:24px 0;border:none;border-top:1px solid var(--hellgrau-2);} .pb-texteditor s,.pb-texteditor strike{text-decoration:line-through;} /* ---------- Baustein: Sammlungstypen-Feld (Platzhalter im Editor) ---------- */ /* Ab v1.17.35 (Stephans Bug-Report: "kann nicht per Drag and Drop verschoben werden... wird im Container noch freiliegend"): dieser Platzhalter (siehe pbBlockHtml() in assets/js/page-builder.js) bekam im Gegensatz zu .pb-ueberschrift/.pb-texteditor nie ein eigenes "position:relative" - sein ".pb-floating-toolbar" (mit dem Ziehen- Greifer, siehe dort, "position:absolute;top:-38px") positionierte sich dadurch relativ zum nächsten POSITIONIERTEN VORFAHREN (z.B. der Leinwand-Wurzel) statt relativ zum Platzhalter selbst - der Greifer landete dadurch weit entfernt von seinem eigentlichen Baustein, wo er praktisch nicht mehr treffbar war (Ziehen im Struktur-Baum war davon nicht betroffen, der nutzt einen eigenen, unabhängigen Mechanismus). margin-bottom analog .pb-ueberschrift/.pb-texteditor (Basis-Abstand nach unten, kann durch die neue Archiv-Einstellung "Abstand zwischen den Widgets" überschrieben werden, siehe includes/page-builder.php). */ .pb-sammlungstypen-feld-platzhalter{position:relative;margin:0 0 20px;} /* ---------- Baustein: Seitentitel/Breadcrumb (Drag&Drop im Editor) ---------- */ /* Ab v1.17.54 (Stephans Bug-Report: "kann die Bausteine Seitentitel und Breadcrumb nicht per Drag & Drop im Pagebuilder verschieben") - exakt derselbe, bereits einmal behobene Fehlertyp wie beim Sammlungstypen-Feld weiter oben (siehe dortiger Kommentar, v1.17.35): ".pb-hero-titel-bereich"/ ".pb-hero-permalink-bereich" (siehe pbBlockHtml() in page-builder.js sowie pagetal_pb_seitentitel_rendern()/pagetal_pb_breadcrumb_rendern() in includes/page-builder.php) bekamen nie ein eigenes "position:relative" - ihr im Editor eingefügter ".pb-floating-toolbar" (mit dem Ziehen-Greifer, "position:absolute;top:-38px") positionierte sich dadurch relativ zum nächsten POSITIONIERTEN VORFAHREN (z.B. der Leinwand-Wurzel) statt relativ zum jeweiligen Baustein selbst - der Greifer landete dadurch weit entfernt von seinem eigentlichen Baustein, wo er praktisch nicht mehr treffbar war. Beide Klassen werden zwar auch auf der ÖFFENTLICHEN Seite gerendert, dort erzeugt der Server aber nie ein ".pb-floating-toolbar"- Element darunter (das kommt ausschliesslich aus der Editor-Logik oben) - "position:relative" allein hat für sich genommen keinerlei sichtbaren Effekt auf normale Blockelemente wie hier (h1/p.breadcrumb im normalen Textfluss, keine absolut positionierten Kind-Elemente im echten Rendering) und verändert daher auf der Live-Seite nichts. */ .pb-hero-titel-bereich,.pb-hero-permalink-bereich{position:relative;} /* Ab v1.17.57 KORRIGIERT (Stephans Bug-Report: "hier gibt es einen abstand zwischen den widgets [im Pagebuilder]. wenn ich im frontend bin ist dieser abstand nicht [...] wir müssen dies im pagebuilder so anzeigen, wie es im frontend angezeigt wird, sonst ist es irreführend"): die in v1.17.54 hier ergänzte Regel "margin-bottom:20px" (nur innerhalb von "#pb-wurzel", siehe Kommentar-Historie unten) war zwar technisch editor-only und veränderte nie die Live-Seite - sie erzeugte aber genau den von Stephan zu Recht bemängelten optischen Widerspruch: einen sichtbaren Abstand im Pagebuilder zwischen zwei direkt aufeinander folgenden Seitentitel-/Breadcrumb-Bausteinen, den es auf der echten Seite gar nicht gibt - der Editor sollte aber WYSIWYG sein. Erneute Untersuchung per Playwright ergab: das ursprüngliche Problem (Griff des ZWEITEN Bausteins landet in der Fläche des davorstehenden ERSTEN, elementFromPoint trifft den falschen Baustein statt des Griffs) trat beim erneuten, sauberen Test mit Standard-Werten (kein manuell gesetzter Z-Index) GAR NICHT mehr auf - "position:relative" allein reicht hier tatsächlich aus, weil das DOM des zweiten (späteren) Bausteins in der Stapelreihenfolge automatisch über dem ersten liegt. Der ursprüngliche Fehlschlag beim allerersten Test dieses Bugs entpuppte sich als Test-Artefakt: die dabei verwendete Testseite hatte durch FRÜHERE, unabhängige Tests des "Erweitert"-Tab-Felds "Z-Index" bereits einen von 0 abweichenden Wert auf dem ERSTEN Baustein stehen (z.B. "9"), wodurch dieser bewusst höher gestapelt wurde als der zweite, ausgewählte Baustein - mit Z-Index 0 auf beiden Seiten (Normalfall bei praktisch jeder echten Seite) ist das kein Problem. Damit ein Nutzer, der einem VORDEREN Hero-Baustein bewusst einen hohen "Erweitert"-Z-Index vergibt, trotzdem nicht denselben Effekt erneut erleben kann, bekommt der gerade AUSGEWÄHLTE Baustein (Klasse ".pb-auswahl", wird ohnehin schon für den gestrichelten Auswahlrahmen genutzt, siehe weiter unten) hier zusätzlich einen sehr hohen Z-Index - wieder bewusst NUR innerhalb von "#pb-wurzel" (siehe Erklärung oben, existiert nie auf der öffentlichen Seite) - damit sein Griff in JEDEM Fall über allen Nachbar-Bausteinen liegt, unabhängig von deren eigenem Z-Index. Die alte "margin-bottom"-Regel entfällt ersatzlos, der Pagebuilder zeigt Seitentitel/Breadcrumb jetzt exakt so an wie das veröffentlichte Frontend. */ #pb-wurzel .pb-hero-titel-bereich.pb-auswahl,#pb-wurzel .pb-hero-permalink-bereich.pb-auswahl{z-index:60;} /* ---------- Baustein: Sammlungstypen-Feld (Ausrichtung im FRONTEND) ---------- */ /* Ab v1.17.35 (Stephans Bug-Report: "die ausrichtung wird im pagebuilder angezeigt hat aber im frontend keine wirkung"): Der Editor setzt die Ausrichtung als Inline-Style direkt auf den Platzhalter (siehe pbBlockHtml() in assets/js/page-builder.js, Baustein "sammlungstypen_feld"), aber pagetal_pb_sammlungstypen_feld_rendern() (includes/page-builder.php) gibt für die ÖFFENTLICHE Ausgabe stattdessen nur die Klasse "pb-sammlungstypen-feld-ausrichtung-{links|zentriert| rechts}" aus - für die es hier nie eine passende CSS-Regel gab, weshalb die Einstellung im Frontend wirkungslos blieb. Diese drei Regeln schliessen genau diese Lücke, ohne am bestehenden Editor-Verhalten irgendetwas zu ändern. */ .pb-sammlungstypen-feld-ausrichtung-links{text-align:left;} .pb-sammlungstypen-feld-ausrichtung-zentriert{text-align:center;} .pb-sammlungstypen-feld-ausrichtung-rechts{text-align:right;} /* ---------- Baustein: Navigationsmenü (ab v1.18.0, Nutzerwunsch Stephan: Header-/Footer-Templates - zeigt automatisch dieselbe Hauptnavigation wie das bisherige, fest einprogrammierte "nav.primary" (siehe partials/kopf.php) an, damit sich ein neu gestalteter Header optisch nahtlos einfügt. "justify-content" je Ausrichtung wird dynamisch als Block-CSS ergänzt (siehe pagetal_pb_navigationsmenue_block_css()), Basis-Optik (Schriftgewicht/-farbe, Abstand zwischen den Punkten, Hover-Farbe) bewusst 1:1 von "nav.primary" übernommen (frontend.css) - dieselbe Navigation soll in einem eigenen Header-Template optisch nicht anders wirken als im bisherigen. ---------- */ /* "position:relative" ab v1.18.0 (Stephans Bug-Report: "navigationswidget kann nicht mit drag an drop im pagebuilder verschoben werden") - exakt derselbe, bereits zweimal behobene Fehlertyp wie beim Sammlungstypen- Feld (v1.17.35) und bei Seitentitel/Breadcrumb (v1.17.54, siehe ausführlicher Kommentar dort): ohne eigenes "position:relative" positioniert sich der im Editor eingefügte ".pb-floating-toolbar" (mit dem Ziehen-Greifer, "position:absolute;top:-38px") relativ zum nächsten POSITIONIERTEN VORFAHREN statt relativ zum Baustein selbst - der Greifer landet dadurch weit entfernt vom eigentlichen Baustein, wo er praktisch nicht mehr treffbar ist. Auf der öffentlichen Seite erzeugt der Server nie ein ".pb-floating-toolbar"-Element (kommt ausschliesslich aus der Editor-Logik in page-builder.js) - dort hat "position:relative" für sich genommen keine sichtbare Auswirkung. */ .pb-navigationsmenue{position:relative;display:flex;align-items:center;flex-wrap:wrap;} .pb-navigationsmenue-leer{position:relative;font-size:.8rem;color:#9aa3ad;font-style:italic;} /* Icon-Liste-Widget (ab v1.19.0): Layout/Farben/Typografie/Abstand/ responsives Text-Ausblenden kommen ausschliesslich über das je Baustein generierte CSS (siehe pagetal_pb_icon_liste_block_css() in includes/page-builder.php bzw. pbIconListeBlockCssBauen() im Editor) - hier nur der Leer-Zustand-Platzhalter (nie auf der veröffentlichten Seite sichtbar, siehe pagetal_pb_icon_liste_rendern()), analog .pb-navigationsmenue-leer oben. */ .pb-icon-liste-leer{position:relative;font-size:.8rem;color:#9aa3ad;font-style:italic;} /* Ab v1.19.1 (Stephans Bug-Report: "ich kann das neue Widget nicht per Drag and Drop im Pagebuilder bewegen") - exakt derselbe, bereits dreimal behobene Fehlertyp wie beim Sammlungstypen-Feld (v1.17.35), bei Seitentitel/Breadcrumb (v1.17.54) und beim Navigationsmenü (v1.18.0, siehe deren ausführliche Kommentare oben): ".pb-icon-liste" (das eigentliche, BEFÜLLTE Element - im Gegensatz zum bereits korrekt behandelten Leer-Zustand ".pb-icon-liste-leer" oben) bekam nie ein eigenes "position:relative" - sein im Editor eingefügter ".pb-floating-toolbar" (mit dem Ziehen-Greifer, "position:absolute; top:-38px") positionierte sich dadurch relativ zum nächsten POSITIONIERTEN VORFAHREN statt relativ zum Baustein selbst, der Greifer landete dadurch weit entfernt von seinem eigentlichen Baustein und war praktisch nicht mehr treffbar. Damit dieser Fehlertyp nicht ein fünftes Mal auftritt: JEDER neue Page-Builder- Baustein MUSS auf seinem äussersten, tatsächlich befüllten Wurzelelement "position:relative" tragen (unabhängig davon, ob der Leer-Zustand-Platzhalter das schon hat) - siehe Checkliste in PROJEKT-STATUS.md. Auf der öffentlichen Seite hat die Regel wie bei den anderen drei Bausteinen keine sichtbare Auswirkung (kein ".pb-floating-toolbar" ausserhalb des Editors). */ /* Ab v1.19.1 (Stephans Bug-Report: "Automatische Erkennung ... die Icons werden immer ohne Text angezeigt, egal wie breit die Anzeige gerade ist"): Ursache war NICHT die Erkennungslogik selbst (assets/js/ icon-liste-mobil.js), sondern eine strukturelle Lücke, die erst bei Stephans konkretem Testfall sichtbar wurde - eine Icon-Liste INNERHALB einer Topbar-Spalte (".pb-topbar-spalte" ist selbst "display:flex"). Ohne eigene Flex-Eigenschaft ist ".pb-icon-liste" dort ein ganz normaler FLEX-ITEM seines Eltern-Elements - und ein Flex-Item ohne "flex-grow" nimmt gemäss CSS-Spezifikation NIE automatisch den verfügbaren Platz ein, sondern schrumpft/wächst rein nach seinem EIGENEN Inhalt ("shrink-to-fit"). ".clientWidth" der Liste selbst entsprach dadurch nie der TATSÄCHLICH verfügbaren Spaltenbreite, sondern nur der Breite ihres GERADE gerenderten Inhalts - sobald der Text einmal (z.B. durch einen kurzen Layout-Sprung beim ersten Messen) ausgeblendet wurde, blieb "clientWidth" fortan auf die winzige Icon-only-Breite eingefroren, wodurch die Erkennung sich selbst dauerhaft in den "kein Platz"-Zustand einsperrte, unabhängig von der tatsächlichen Fensterbreite. Ausserhalb eines Flex-Kontexts (z.B. eine Icon-Liste direkt auf der Seiten-Wurzel) trat der Fehler NICHT auf: dort ist ".pb-icon-liste" ein normaler Block (kein Flex-Item), Block-Elemente füllen ihren Container standardmässig ohnehin vollständig aus. "flex:1 1 auto" behebt das strukturell für JEDEN Flex-Elternkontext (Topbar-Spalte, Header-Spalte, ein Container mit "Kinder nebeneinander"): die Liste nimmt jetzt zuverlässig den ihr zugewiesenen Platz ein, wodurch "clientWidth" wieder korrekt die tatsächlich verfügbare Breite widerspiegelt - ausserhalb eines Flex-Elternkontexts hat die Eigenschaft keinerlei Wirkung (nur Flex-ITEMS werten "flex" überhaupt aus), also 0 Verhaltensänderung für den bereits funktionierenden Fall. "min-width:0" hebt zusätzlich die Flexbox-Standardvorgabe "min-width:auto" auf (die ein Flex-Item sonst nie unter seine eigene Inhalts-Mindestbreite schrumpfen lässt) - ohne das könnte eine lange, nicht umbrechende Zeile die gesamte Spalte/den Header gegen die Absicht dieser Einstellung aufweiten. */ .pb-icon-liste{position:relative;flex:1 1 auto;min-width:0;} /* Baustein "Soziale Icons" (ab v1.19.43): "position:relative" ist hier PFLICHT (siehe ausführliche Begründung + Checkliste direkt oberhalb bei ".pb-icon-liste") - der Editor-Floating-Toolbar dieses Bausteins positioniert sich sonst relativ zum nächsten positionierten Vorfahren statt relativ zum Baustein selbst. Form/Farbe/Grösse/Abstand/Hover kommen ausschliesslich über das je Baustein generierte CSS (siehe pagetal_pb_soziale_icons_block_css() in includes/page-builder.php bzw. pbSozialeIconsBlockCssBauen() im Editor) - hier nur der Leer-Zustand- Platzhalter (nie auf der veröffentlichten Seite sichtbar) und dieses strukturelle Minimum, analog ".pb-icon-liste" oben. */ .pb-soziale-icons{position:relative;} .pb-soziale-icons-element{list-style:none;} /* Ab v1.18.0 ("Vollpaket"-Erweiterung, Stephans Wunsch nach mehr Einstellungsmöglichkeiten analog Elementor): die Menüpunkte stecken jetzt in einem eigenen Wrapper ".pb-navigationsmenue-links" statt direkt im