/*
 * HPL Events Manager frontend styles.
 */

/*
 * Sucheformular-Button ("SUCHE") in Rot statt Events Managers Standard-
 * Blau. Selektor bewusst identisch zu Events Managers eigener Regel in
 * events-manager.css (".em.pixelbones.input button.button-primary" &
 * Varianten) kopiert: beide Regeln nutzen "!important", daher entscheidet
 * die Spezifität - ein einfacherer Selektor würde hier verlieren. Durch
 * die 'events-manager'-Abhängigkeit in AssetEnqueueService.php lädt diese
 * Datei garantiert danach, bei gleicher Spezifität gewinnt dann diese
 * Regel hier.
 */
.em.pixelbones.input .button.button-primary,
.em.pixelbones.input button.button-primary,
.em.pixelbones.input input[type=submit].button-primary,
.em.pixelbones.input input[type=reset].button-primary,
.em.pixelbones.input input[type=button].button-primary,
.em.pixelbones .input .button.button-primary,
.em.pixelbones .input button.button-primary,
.em.pixelbones .input input[type=submit].button-primary,
.em.pixelbones .input input[type=reset].button-primary,
.em.pixelbones .input input[type=button].button-primary,
.em.pixelbones .button.button-primary.input,
.em.pixelbones button.button-primary.input,
.em.pixelbones input[type=submit].button-primary.input,
.em.pixelbones input[type=reset].button-primary.input,
.em.pixelbones input[type=button].button-primary.input {
	color: var(--hpl-button-text-color) !important;
	background-color: var(--hpl-button-background-color) !important;
	border-color: var(--hpl-button-background-color) !important;
}

/*
 * Zentrale CSS-Variablen.
 *
 * --hpl-event-list-image-width: Einzige Stellschraube für die Bildbreite
 * in der Veranstaltungsliste. Wird von Grid-Spaltenbreite und Bildgrösse
 * gemeinsam referenziert.
 *
 * --hpl-field-label-width: Breite der Label-Spalte in allen Meta-Zeilen
 * (Organizer, Location, Online, Level-Category, Categories, Titel,
 * Teaser, Start/End, Timezone, All day...). Alle Zeilen sind
 * zweispaltig aufgebaut (Label | Wert), damit die Werte wie in einer
 * Tabelle mit unsichtbaren Rahmen untereinander ausgerichtet sind.
 * Diese eine Variable bestimmt sowohl die Breite der Grid-Spalte
 * (grid-template-columns) als auch die Breite des Label-Elements
 * selbst (.hpl-field-label) - beides muss immer denselben Wert haben,
 * sonst überlappt das Label die Wert-Spalte oder lässt Platz frei.
 */
:root {
	--hpl-event-list-image-width: 200px;

	/*
	 * Optik von Label und Wert in allen Meta-Zeilen (Organizer,
	 * Location, Online, Level-Category, Categories). Hier ändern statt
	 * an den einzelnen Selektoren - wirkt sofort überall einheitlich.
	 */
	--hpl-field-label-color: #767676;
	--hpl-field-label-font-weight: normal;
	--hpl-field-label-width: 120px;

	--hpl-field-value-color: var(--hpl-font-color);
	--hpl-field-value-font-weight: normal;

	/* Optik des Datum-Feldes */
	--hpl-field-datetime-font-weight: bold;
	--hpl-field-datetime-font-color: inherit;

	/*
	 * Konfiguration des Accordion-Indikators.
	 */
	--hpl-accordion-indicator-open: '-';
	--hpl-accordion-indicator-closed: '+';
}

/*
 * Gemeinsame Kopfzeile für den "Neue Veranstaltung"-Link
 * (.hpl-back-to-list) und den "Ausgewählte löschen"-Button
 * (.hpl-bulk-delete-events-wrapper) - beide auf derselben Höhe,
 * Link links, Button rechtsbündig. Das umschliessende <div> selbst
 * entsteht erst zur Laufzeit per JavaScript
 * (hpl-events-manager.js, setupEventListToolbarLayout(), "wrapAll"),
 * da beide Elemente von zwei unabhängigen PHP-Services mit je eigener
 * Sichtbarkeitsprüfung gerendert werden (siehe dortiger Docblock).
 *
 * Wird als direktes Kind von <article> eingefügt - also ausserhalb
 * von ".hero-section.is-width-constrained", welche sich selbst über
 * "margin-inline: auto" und "max-width" auf die Inhaltsspalte
 * zentriert. Ohne diese Regel kläbe die Zeile deshalb am linken
 * Browserrand statt an der Titel-Spalte. Die Werte
 * "--theme-container-width" / "--theme-block-max-width" sind
 * dieselben Blocksy-eigenen CSS-Variablen, die auch
 * ".is-width-constrained" verwendet (siehe main.min.css) - so bleibt
 * die Zeile exakt bündig mit dem Titel, auch wenn die Container-Breite
 * im Customizer geändert wird.
 *
 * "position: sticky" sitzt bewusst auf der ganzen Zeile (dem
 * Flex-Container), nicht auf den einzelnen Kindern: Ein sticky-Element
 * kann sich nur innerhalb der Höhe seines eigenen Elternelements
 * "festkleben" - bei den Kindern selbst wäre das Elternelement diese
 * schmale, nur zeilenhohe Kopfzeile, wodurch beide Elemente sofort
 * wieder aus dem sichtbaren Bereich verschwinden würden, sobald die
 * Zeile selbst nach oben aus dem Viewport scrollt. Die Kopfzeile ist
 * dagegen direktes Kind von <article>, welches die gesamte restliche
 * Seite (inklusive der ganzen Eventliste darunter) umfasst - dadurch
 * hat die Zeile als Ganzes genug Raum, um während des Scrollens durch
 * die Liste dauerhaft sichtbar zu bleiben.
 */
.hpl-event-list-toolbar {
	display: flex;
	align-items: flex-start;
	justify-content: space-between;
	gap: 12px;
	width: var(--theme-container-width);
	max-width: var(--theme-block-max-width);
	margin-inline: auto;
	margin-bottom: 12px;
	position: sticky;
	top: 50px;
	z-index: 10;
}

/*
 * Weisses Rechteck als Hintergrund, nur so breit/hoch wie der
 * Linktext selbst (kein voller Zeilenhintergrund): Sobald die Zeile
 * beim Scrollen über der Eventliste schwebt, würde der sonst
 * transparente, rot eingefärbte Linktext sich sichtbar mit den
 * darunterliegenden Bildern/Texten der Liste überlagern und schwer
 * lesbar werden. Der Button daneben (.hpl-bulk-delete-events-button)
 * braucht dieselbe Behandlung nicht - der hat als WordPress-Button
 * bereits eine eigene, deckende Hintergrundfarbe.
 */
.hpl-back-to-list {
	display: inline-block;
	background-color: #fff;
	padding: 4px 8px;
}

.hpl-bulk-delete-events-wrapper {
	display: inline-block;
}

.hpl-bulk-delete-events-button {
	display: inline-block;
}

/*
 * Auswahl-Checkbox pro Event in der Liste
 * (EventBulkDeleteCheckboxPlaceholderService, Platzhalter
 * #_HPL_EVENT_BULK_DELETE_CHECKBOX) - etwas Abstand zum Titeltext
 * daneben, sonst Browser-Standardoptik.
 */
.hpl-event-bulk-delete-checkbox {
	margin-right: 8px;
}

/*
 * Erzwingt eine feste, schmale erste Spalte für das Veranstaltungsbild.
 *
 * Das Original-Plugin definiert die erste Spalte als flexibel
 * (minmax(0, 1fr)), wodurch sie unabhängig von der tatsächlichen
 * Bildgrösse immer einen festen Anteil der verfügbaren Breite einnimmt.
 * Diese Regel übernimmt bewusst denselben Selektor wie das Original,
 * damit die gleiche CSS-Spezifität greift und unsere, später geladene
 * Regel zuverlässig gewinnt.
 *
 * "align-items: start" verhindert, dass die Bildspalte (.em-item-image)
 * per CSS-Grid-Standardverhalten ("stretch") auf die Höhe der viel
 * längeren Infospalte (.em-item-info: Titel, Teaser, alle Metazeilen)
 * gestreckt wird. Ohne diese Regel wäre .em-item-image immer so hoch
 * wie .em-item-info, mit leerem Platz unterhalb des eigentlichen
 * Bildes - dadurch würde ein border-right an .em-item-image (siehe
 * dort) ebenfalls zu weit nach unten reichen, statt exakt an der
 * tatsächlichen Bildhöhe zu enden.
 */
.em.em-list .em-item {
	grid-template-columns: var(--hpl-event-list-image-width) 1fr;
	align-items: start;
}

/*
 * Erzwingt die Bildbreite in der Veranstaltungsliste.
 *
 * Die Höhe wird bewusst nicht fest vorgegeben (height: auto), damit
 * unterschiedlich hohe Originalbilder proportional zur Breite skaliert
 * werden, statt verzerrt oder hart zugeschnitten zu erscheinen.
 */
.em.em-item .em-item-image,
.em.em-list .em-item .em-item-image,
.em.em-list-widget .em-item .em-item-image {
	min-width: var(--hpl-event-list-image-width);
	max-width: var(--hpl-event-list-image-width);
	width: var(--hpl-event-list-image-width);
}

.em.em-item .em-item-image img,
.em.em-list .em-item .em-item-image img,
.em.em-list-widget .em-item .em-item-image img {
	width: var(--hpl-event-list-image-width);
	height: auto;
	display: block; /* verhindert einen paar Pixel hohen Leerraum unter dem Bild, den Inline-Bilder sonst durch die Zeilenhöhe ihrer Schrift erhalten */
}

/*
 * Farbige Kategorie-Linie direkt am rechten Rand des Bildes.
 *
 * Bewusst DIREKT auf dem img (nicht auf der umschliessenden
 * .em-item-image-Box, wie zunächst versucht): Die Box wurde trotz
 * "align-items: start" auf dem Grid-Container weiterhin auf die Höhe
 * von .em-item-info gestreckt dargestellt - vermutlich weil die
 * CSS-Grid-Spaltenhöhe (Row-Track) unabhängig vom align-self-Wert
 * eines einzelnen Items berechnet wird und die Box dadurch trotzdem
 * sichtbar hoch blieb. Das img selbst hat dagegen unabhängig vom
 * umschliessenden Grid-Item immer exakt seine eigene, durch
 * "height: auto" bestimmte Höhe (bestimmt durch die Bildbreite und das
 * tatsächliche Seitenverhältnis des Fotos) - ein Rahmen direkt am img
 * kann deshalb gar nicht länger werden als das Bild selbst.
 *
 * "--hpl-category-background-color" kommt über die vom Format-String
 * ausgegebene CSS-Klasse "hpl-category-..." (Platzhalter
 * #_HPL_CATEGORY_CLASS, siehe Farbtabelle weiter unten in dieser
 * Datei) - vererbt vom äusseren ".em-event.em-item"-Element.
 */
.em.em-list .em-item .em-item-image img {
	border-right: 4px solid var(--hpl-category-background-color, #d0d0d0);
}

/*
 * Farbtabelle der Event-Categories, EINZIGE Stelle, an der
 * Kategoriefarben gepflegt werden. Hier eine neue Zeile ergänzen, wenn
 * in l2w_em_hpl_category eine neue Kategorie dazukommt (Klassenname
 * "hpl-category-" + Titel aus l2w_em_hpl_category, siehe
 * CategoryPlaceholderService::renderPrimaryCategoryClass(),
 * Platzhalter #_HPL_CATEGORY_CLASS).
 *
 * Zwei Variablen pro Kategorie statt einer: "--hpl-category-background-
 * color" (die eigentliche Kategoriefarbe) und "--hpl-category-text-
 * color" (Textfarbe, damit das Badge bei hellen Hintergrundfarben
 * lesbar bleibt statt immer festem Weiss) - analog zur früheren
 * TYPO3-Lösung, die ebenfalls beide Werte pro Kategorie pflegte.
 *
 * Werte wörtlich aus der alten TYPO3-Stylesheet-Vorlage übernommen, nur
 * auf unsere Klassennamen (deutsche Titel aus l2w_em_hpl_category,
 * siehe "wp db query 'SELECT id, title FROM l2w_em_hpl_category ORDER
 * BY id'") ummuenzt statt der früheren, englischen TYPO3-internen
 * Bezeichner (z. B. "discussion" -> "diskussion", "holiday" ->
 * "feiertag", "course" -> "kurs", "congress" -> "tagung", "talk" ->
 * "vortrag", "ritual" -> "zeremonie", "membersmeeting" ->
 * "mitgliederversammlung", "empowerment" -> "einweihung"). Die
 * TYPO3-Vorlage enthielt zusätzlich "beginner"/"practitioner" - das
 * sind keine Event-Categories, sondern Level-Categories (siehe
 * LevelCategoryPlaceholderService, Feld "Level" mit Werten wie
 * "Praktizierende") und deshalb hier bewusst nicht übernommen; bei
 * Bedarf wäre das eine eigene, separate Farbtabelle nach demselben
 * Muster.
 *
 * Bewusst NICHT über Events Managers eigenes Kategorie-Farbfeld (Events
 * → Categories, Platzhalter #_CATEGORYCOLOR) gelöst - diese native
 * Taxonomie wird bei uns für Events nicht gepflegt, Farben sind reine
 * Darstellungssache und gehören deshalb hierher statt in eine separat
 * zu pflegende Datenbank-Tabelle oder Admin-Oberfläche.
 */
.hpl-category-diskussion { --hpl-category-background-color: #ee8a76; --hpl-category-text-color: #333333; }
.hpl-category-einweihung { --hpl-category-background-color: #ff6831; --hpl-category-text-color: #333333; }
.hpl-category-feiertag { --hpl-category-background-color: #e7c10e; --hpl-category-text-color: #333333; }
.hpl-category-ferien { --hpl-category-background-color: #ffcc00; --hpl-category-text-color: #333333; }
.hpl-category-film { --hpl-category-background-color: #5959b8; --hpl-category-text-color: #ffffff; }
.hpl-category-kurs { --hpl-category-background-color: #d98d95; --hpl-category-text-color: #ffffff; }
.hpl-category-meditation { --hpl-category-background-color: #c2d69a; --hpl-category-text-color: #333333; }
.hpl-category-mitgliederversammlung { --hpl-category-background-color: #7fcc7f; --hpl-category-text-color: #333333; }
.hpl-category-praxis { --hpl-category-background-color: #d790d1; --hpl-category-text-color: #ffffff; }
.hpl-category-puja { --hpl-category-background-color: #a387c7; --hpl-category-text-color: #ffffff; }
.hpl-category-retreat { --hpl-category-background-color: #8db4e3; --hpl-category-text-color: #ffffff; }
.hpl-category-tagung { --hpl-category-background-color: #83e0da; --hpl-category-text-color: #333333; }
.hpl-category-teaching { --hpl-category-background-color: #faa764; --hpl-category-text-color: #ffffff; }
.hpl-category-vortrag { --hpl-category-background-color: #b8edc2; --hpl-category-text-color: #333333; }
.hpl-category-zeremonie { --hpl-category-background-color: #9999ff; --hpl-category-text-color: #ffffff; }
.hpl-category-workshop { --hpl-category-background-color: #ff99ff; --hpl-category-text-color: #ffffff; }

/*
 * Die farbige Kategorie-Linie sitzt jetzt als border-right direkt an
 * .em-item-image (siehe weiter oben, exakt bildhoch statt einer
 * Annäherung) - .em-item-info braucht deshalb keinen eigenen Rahmen
 * mehr, nur noch die bestehende mobile Sonderbehandlung.
 *
 * "border-left: none;" ist trotzdem nötig, nicht nur weglassbar: Events
 * Managers eigene, mitgelieferte events-manager.css definiert für
 * denselben Selektor bereits "border-left: 4px solid
 * var(--default-border);" (_items.scss, Zeile ~289). Ohne explizites
 * "none" hier gewinnt zwar unsere später geladene Regel bei
 * gleicher Spezifität grundsätzlich - aber nur für Eigenschaften, die
 * wir auch tatsächlich selbst setzen. Lassen wir border-left ganz weg,
 * bleibt EM's eigene Deklaration unangetastet bestehen und wird
 * sichtbar (zweite, zu lange Linie) - genau das ist gerade passiert.
 */
.em.em-list .em-item .em-item-info {
	border-left: none;
	border-top: #d0d0d0 !important; /* Übersteuert horizontalen Strich bei Handy-Display */
}

.em-event-categories {
	display: inline !important;
}

.em-event-categories li {
	display: inline !important;
}

.em.em-list .em-item .em-item-meta .em-item-meta-line.em-event-categories a {
	text-decoration: none !important;
	font-style: normal !important;
	color: #fff !important;
}

/*
 * Kategorie-Wert (z. B. "Feiertag", Platzhalter #_HPL_CATEGORIES,
 * gerendert von CategoryPlaceholderService) als farbiges Badge/Pill,
 * analog zu Events Managers eigenen Category-Tags oben
 * (.em-event-categories a, ebenfalls weisser Text auf Farbfläche).
 *
 * Nutzt dieselben Farben wie die vertikale Trennlinie (.em-item-info
 * weiter oben) über dieselben geerbten CSS-Variablen
 * "--hpl-category-background-color" / "--hpl-category-text-color" -
 * siehe Farbtabelle ganz oben in diesem Abschnitt. Anders als bei der
 * Trennlinie braucht das Badge zusätzlich eine passende Textfarbe
 * (nicht immer Weiss), da der Kategorietext direkt auf der Farbfläche
 * steht und bei hellen Hintergründen sonst kaum lesbar wäre.
 */
/*
 * "justify-self: start" ist hier das eigentlich Wirksame, nicht
 * "display: inline-block": .hpl-field-value liegt in der
 * Wert-Spalte eines CSS-Grids (siehe ".em-item-meta-line { grid-
 * template-columns: ... 1fr !important; }" weiter unten in dieser
 * Datei) - Grid-Kinder werden per Voreinstellung ("justify-items:
 * stretch") auf die volle Spaltenbreite gestreckt, unabhängig vom
 * eigenen "display"-Wert. Ohne "justify-self: start" füllt das Badge
 * deshalb die ganze 1fr-Spalte statt nur so breit wie der Text zu sein.
 */
.hpl-event-categories .hpl-field-value {
	display: inline-block;
	justify-self: start;
	background-color: var(--hpl-category-background-color, #999);
	color: var(--hpl-category-text-color, #fff);
	padding: 2px 10px;
	border-radius: 3px;
}

/*
 * Erzwingt einspaltiges Layout für alle Meta-Zeilen.
 *
 * EM definiert .em-item-meta > div mit flex: 1 1 50%, was zu einem
 * zweispaltigen Layout führt und Categories/Tags unvorhersehbar rechts
 * platziert. Diese Regel setzt alle Meta-Zeilen auf volle Breite,
 * damit die Reihenfolge immer dem Format-String entspricht.
 */
.em.em-list .em-item .em-item-info .em-item-meta > div {
	flex: 1 1 100%;
	min-width: unset;
}

/*
 * Bild links, Meta-Tabelle rechts auf der Single-Event-Seite.
 *
 * Das Original-Plugin positioniert das Bild per CSS "order: 2" rechts
 * neben der Meta-Spalte (order: 1) - unabhängig von der Reihenfolge im
 * Format-String. Damit die Details-Seite optisch der Listen-Seite
 * entspricht (Bild links), werden beide Order-Werte getauscht.
 */
.em.em-item.em-item-single .em-item-header .em-item-image {
	order: 1;
}

.em.em-item.em-item-single .em-item-header .em-item-meta {
	order: 2;

	/*
	 * Das Original-Plugin setzt hier "gap: 20px" - gedacht als Abstand
	 * zwischen den früheren <section>-Spalten (Wann/Wo/...). Da unsere
	 * Meta-Zeilen jetzt direkte Kinder desselben Flex-Containers sind,
	 * gilt dieser Gap zwischen jeder einzelnen Zeile zusätzlich zum
	 * normalen "margin-bottom: 10px" - das erzeugt unnötig grosse
	 * Lücken. Der Zeilenabstand kommt bereits vollständig aus dem
	 * margin-bottom der einzelnen .em-item-meta-line.
	 */
	gap: 0;
}

/*
 * Verhindert unnötige Streckung der Bild/Meta-Spalten.
 *
 * .em-item-header ist "display: flex" mit dem Standardwert
 * "align-items: stretch" - dadurch wird .em-item-meta auf dieselbe
 * Höhe wie das (meist deutlich höhere) Bild gestreckt. Der so
 * entstehende Leerraum wird von .em-item-meta (selbst "flex-wrap:
 * wrap") auf die einzelnen Zeilen verteilt und erzeugt grosse Lücken
 * zwischen den Tabellenzeilen. "align-items: flex-start" lässt beide
 * Spalten stattdessen nur so hoch werden wie ihr eigener Inhalt.
 */
.em.em-item.em-item-single .em-item-header {
	align-items: flex-start;
}

/*
 * Erzwingt einspaltiges Layout auf der Single-Event-Seite.
 *
 * .em-item-header .em-item-meta ist bei EM "display: flex;
 * flex-wrap: wrap;" - alle direkten Kinder (Add-to-Calendar-Button,
 * jede .em-item-meta-line) landen dadurch standardmässig nur so breit
 * wie ihr Inhalt und stehen nebeneinander/wild verteilt, statt
 * untereinander. Diese Regel erzwingt für jedes direkte Kind die volle
 * Breite, damit alles wie in der Tabelle der Listen-Seite
 * untereinander erscheint.
 */
.em.em-item.em-item-single .em-item-header .em-item-meta > * {
	flex: 1 1 100%;
}

/*
 * Ausnahme für den Add-to-Calendar-Button: Er soll auf einer eigenen
 * Zeile stehen (dafür sorgen die 100%-Nachbarn automatisch durch den
 * Zeilenumbruch), aber nicht selbst auf volle Breite gestreckt werden.
 */
.em.em-item.em-item-single .em-item-header .em-item-meta > .em-event-add-to-calendar {
	flex: 0 0 auto;
}

/*
 * Entfernt den farbigen Rahmen am Bild auf der Single-Event-Seite.
 *
 * Das Original-Plugin zeichnet dort per "border-left: 4px solid
 * var(--default-border)" einen Balken in der Kategoriefarbe am Bild -
 * hier bewusst nicht gewünscht.
 */
.em.em-item.em-item-single .em-item-header .em-item-image img {
	border-left: none !important;
	padding-left: 0 !important;
}

/*
 * Verhindert Umbrüche mitten im Wort in den Meta-Zeilen.
 *
 * Das Theme (Blocksy) setzt global "overflow-wrap: break-word" auf
 * <body>. In schmalen Spalten (z. B. "Wann" neben dem Beitragsbild)
 * bricht der Browser dadurch auch mitten in einzelnen Wörtern/Zahlen
 * um, sobald der Text nicht mehr am Stück in die Spalte passt - das
 * war bei den früheren, kürzeren Platzhaltertexten nie sichtbar.
 *
 * "word-break: keep-all" allein reicht nicht: "overflow-wrap" ist ein
 * unabhängiger, nachrangiger Mechanismus, der auch dann noch mitten im
 * Wort umbricht, wenn sonst kein Platz reicht - unabhängig vom
 * word-break-Wert. Deshalb wird overflow-wrap hier zusätzlich explizit
 * zurückgesetzt.
 */
.em-item-meta-line {
	word-break: keep-all;
	overflow-wrap: normal;
}

/*
 * Blendet leere Meta-Zeilen aus.
 *
 * Gilt für alle .em-item-meta-line ohne Inhalt, z. B. wenn kein
 * Online-Status gesetzt ist. Greift nur bei absolut leerem Element —
 * Meta-Zeilen mit Whitespace werden separat via PHP-Placeholder
 * behandelt (kein div-Wrapper wenn leer).
 */
.em-item-meta-line:empty {
	display: none;
}

/*
 * Erzwingt eine feste Label-Spalte für alle Meta-Zeilen.
 *
 * Das Original-Plugin definiert .em-item-meta-line als
 * "display: grid; grid-template-columns: 35px 1fr;" (35px war für ein
 * Icon gedacht). HPL-Metazeilen arbeiten ausschliesslich mit Labels
 * statt Icons, deshalb wird die erste Spalte hier auf eine feste
 * Label-Breite umdefiniert (--hpl-field-label-width). Jede
 * Zeile hat dadurch immer exakt zwei Kind-Elemente: .hpl-field-label
 * (Spalte 1, bei Zeilen ohne Label leer) und .hpl-field-value
 * (Spalte 2) - das ergibt eine tabellenartige, vertikal ausgerichtete
 * Darstellung ohne sichtbare Rahmen.
 *
 * !important ist nötig: Das Original-Plugin verwendet denselben
 * Selektor mit derselben Spezifität, gewinnt also sonst unabhängig
 * von der Ladereihenfolge der Stylesheets.
 *
 * align-items: center sorgt dafür, dass Label und Wert vertikal
 * zueinander zentriert sind, auch wenn das Wert-Element höher ist als
 * die Label-Textzeile (z. B. bei Eingabefeldern mit Padding/Border) -
 * ohne das würden beide Grid-Zellen per Default "stretch" die volle
 * Zeilenhöhe einnehmen und der Label-Text oben kleben bleiben.
 */
.em.em-item .em-item-meta .em-item-meta-line,
.em.em-list .em-item .em-item-meta .em-item-meta-line,
.em.em-list-widget .em-item .em-item-meta .em-item-meta-line {
	grid-template-columns: var(--hpl-field-label-width) 1fr !important;
	align-items: center !important;
}

.hpl-field-label {
	grid-column: 1;
	color: var(--hpl-field-label-color);
	font-weight: var(--hpl-field-label-font-weight);
}

.hpl-field-value {
	grid-column: 2;
	color: var(--hpl-field-value-color);
	font-weight: var(--hpl-field-value-font-weight);
}

/*
 * Ausnahme für die Datum/Zeit-Zeile: Sie hat kein Label und soll nicht
 * unter der (leeren) Label-Spalte eingerückt wirken, sondern bündig
 * mit dem Titel links beginnen - beide Grid-Spalten zusammengefasst.
 */
.hpl-field-value--full-width {
	grid-column: 1 / -1;
}

/*
 * Hebt die Datum/Zeit-Zeile optisch hervor.
 *
 * .em-event-meta-datetime ist die feste Klasse der Datum/Zeit-Zeile in
 * beiden Format-String-Templates (List und Details), unabhängig vom
 * Label/Wert-Aufbau der übrigen Zeilen.
 *
 * Zielt bewusst auf ".em-event-meta-datetime .hpl-field-value" statt
 * nur auf ".em-event-meta-datetime": font-weight wird zwar an sich
 * vererbt, aber die generische ".hpl-field-value"-Regel weiter unten
 * setzt font-weight explizit (--hpl-field-value-font-weight) - ein
 * explizit gesetzter Wert schlägt immer eine geerbte Eigenschaft,
 * unabhängig von der Spezifität der vererbenden Regel. Diese Regel
 * hier ist spezifischer als die generische ".hpl-field-value"-Regel
 * und gewinnt daher zuverlässig.
 */
.em-event-meta-datetime .hpl-field-value {
	font-weight: var(--hpl-field-datetime-font-weight);
	color: var(--hpl-field-datetime-font-color);
}

/*
 * Accordion-Struktur für die monatliche Gruppierung der Eventliste.
 *
 * .hpl-accordion-header: Klickbare Monatsüberschrift mit Indikator,
 * optionalem Toggle-Button. Flexbox damit alle Elemente auf einer Linie
 * bleiben, Toggle-Button automatisch rechtsbündig via margin-left: auto.
 *
 * .hpl-accordion-indicator: +/- Zeichen links vom Monatsnamen.
 * Konfigurierbar über --hpl-accordion-indicator-open/closed in :root.
 *
 * .hpl-accordion-title: Der Monatsname als visuelle Zwischenüberschrift.
 *
 * .hpl-accordion-toggle: Diskrete Schaltfläche zum Aufklappen aller
 * Monate. Rechtsbündig via margin-left: auto.
 *
 * .hpl-accordion-panel: Der ausklappbare Bereich mit den Events eines
 * Monats.
 */

.hpl-accordion-header {
	display: flex;
	align-items: baseline;
	justify-content: flex-start;
	gap: 8px;
	padding: 12px 0;
	border-bottom: 1px solid #d0d0d0;
	cursor: pointer;
	margin-bottom: 16px;
}

.hpl-accordion-indicator {
	font-size: 1.2em;
	font-weight: normal;
	padding-right: 0.5em;
/*	color: #888; */
}

.hpl-accordion-indicator::before {
	content: var(--hpl-accordion-indicator-closed);
}

.hpl-accordion-header.is-open .hpl-accordion-indicator::before {
	content: var(--hpl-accordion-indicator-open);
}

.hpl-accordion-title {
	font-size: 1.2em;
	font-weight: 600;
	color: #333;
}

/*
 * top: 96px statt 50px: .hpl-bulk-delete-events-wrapper (weiter oben in
 * dieser Datei) schwebt ebenfalls rechtsbündig bei top: 50px. Ohne
 * diesen Versatz würden sich beide Elemente beim Scrollen exakt
 * überlappen, sobald beide gleichzeitig "sticky" aktiv sind - der
 * Versatz schafft stattdessen genug Platz, damit der Löschen-Button
 * darüber und dieser Umschalter darunter stehen.
 */
/*
 * "color" und "text-decoration" mit "!important": hpl-site.css setzt für
 * alle <a>-Elemente global "color"/"text-decoration" ebenfalls mit
 * "!important" - ohne eigenes "!important" würde diese globale Regel
 * gewinnen, seit .hpl-accordion-toggle ein <a> statt <button> ist.
 *
 * Zusätzlicher Selektor ".em.pixelbones a.hpl-accordion-toggle" (30.8.
 * ergänzt, sowohl hier als auch bei :hover): Dieser Umschalter liegt
 * innerhalb von Events Managers "PixelBones"-Skin (Klasse ".em
 * .pixelbones", siehe includes/css/events-manager.css, Zeile ~479),
 * dessen eigene, ebenfalls !important gesetzte Regel ".em.pixelbones a"
 * (Spezifität zwei Klassen + ein Element) eine höhere Spezifität hat
 * als der einfache Klassen-Selektor ".hpl-accordion-toggle" allein
 * (eine Klasse) - bei zwei "!important"-Regeln entscheidet zuerst die
 * Spezifität, nicht die Ladereihenfolge. Ohne diesen zusätzlichen
 * Selektor gewann deshalb bislang zuverlässig Events Managers eigenes
 * Standard-Blau (--accent-color) statt unserer --hpl-link-color/
 * --hpl-link-hover-color - der Umschalter blieb sichtbar blau statt in
 * der Website-Linkfarbe, unabhängig vom Wert der beiden Variablen.
 * Gleiches Muster wie bereits bei ".em.pixelbones a.hpl-description-link"
 * weiter unten in dieser Datei.
 */
.hpl-accordion-toggle,
.em.pixelbones a.hpl-accordion-toggle {
	position: sticky;
	top: 96px;
	display: block;
	margin-left: auto;
	text-align: right;
	background: none;
	border: none;
/*	font-size: 0.85em; */
	color: var(--hpl-link-color) !important;
	cursor: pointer;
	padding: 0;
	z-index: 10;
}

.hpl-accordion-toggle:hover,
.em.pixelbones a.hpl-accordion-toggle:hover {
	color: var(--hpl-link-hover-color) !important;
}

.hpl-accordion-panel {
	margin-bottom: 8px;
}

/*
 * Automatisch verlinkte URLs innerhalb der Event-Beschreibung.
 *
 * DescriptionAutoLinkingService markiert alle über make_clickable()
 * erzeugten Links mit dieser Klasse. Wie jeder Link auf der Seite nutzen
 * sie die allgemeine Linkfarbe --hpl-link-color, damit sich die Farbe
 * aller Links weiterhin an einer einzigen Stelle (hpl-variables.css)
 * ändern lässt. Zusätzlich gepunktet unterstrichen, damit sie sich vom
 * übrigen Fliesstext abheben. Beide Werte kommen aus denselben globalen
 * Variablen wie der Rest der Seite (--hpl-link-color,
 * --hpl-link-decoration aus hpl-variables.css).
 *
 * "underline" wird hier bewusst explizit mit angegeben statt nur
 * "var(--hpl-link-decoration)": Die text-decoration-Kurzform setzt bei
 * fehlender Linienangabe text-decoration-line implizit auf "none"
 * zurück - ohne "underline" bliebe der gepunktete Stil unsichtbar.
 *
 * !important: hpl-site.css setzt bereits "a:not(.ct-menu-link)" mit
 * !important auf --hpl-link-color (siehe dortiger Kommentar zur
 * Spezifitäts-Ladereihenfolge mit Blocksy). Ohne !important würde diese
 * spezifischere Klassen-Regel zwar die generische Linkfarbe schlagen,
 * aber ggf. weiterhin von einer eigenen, gleich spezifischen
 * !important-Regel des Themes überstimmt werden.
 *
 * Selektor ".em.pixelbones a.hpl-description-link": Events Managers
 * eigenes Skin "PixelBones" definiert in
 * includes/css/assets/_pixelbones.scss (Zeile 116, kompiliert zu
 * ".em.pixelbones a") eine eigene, ebenfalls !important-Linkfarbe mit
 * Spezifität zwei Klassen + ein Element. Eine einzelne Klasse
 * (".hpl-description-link", Spezifität eine Klasse) reicht dagegen
 * trotz !important nicht aus - Spezifität entscheidet vor
 * Ladereihenfolge. Der zusätzliche Selektor übernimmt deshalb bewusst
 * ".em.pixelbones a" mit und gewinnt dadurch zuverlässig. Der einfache
 * ".hpl-description-link"-Selektor bleibt als Fallback für Kontexte
 * ausserhalb des PixelBones-Wrappers bestehen.
 */
.hpl-description-link,
.em.pixelbones a.hpl-description-link {
	color: var(--hpl-link-color) !important;
	text-decoration: underline var(--hpl-link-decoration) !important;
}

/*
 * Events Managers eigene Meta-Zeilen-Links (Datum, Ort etc. in der
 * Event-Liste, includes/css/events-manager.css, Selektor
 * ".em-item-meta .em-item-meta-line a") holen ihre Farbe aus Events
 * Managers eigener Variable --meta-color statt aus unserer
 * --hpl-link-color. Anstatt jede einzelne Farb-/Unterstreichungs-Regel
 * dieses Drittanbieter-Plugins zu duplizieren, wird hier nur die
 * Variable selbst innerhalb von ".em" umdefiniert - Events Managers
 * eigene Regeln, die var(--meta-color) referenzieren, übernehmen den
 * neuen Wert automatisch. hpl-events-manager.css wird laut
 * AssetEnqueueService nach events-manager.css geladen und gewinnt daher
 * bei gleicher Spezifität.
 */
.em {
	--meta-color: var(--hpl-link-color);
}

/*
 * Bearbeiten-Link (Stift-Icon) aus EventEditLinkPlaceholderService,
 * Platzhalter #_HPL_EVENT_EDIT_LINK.
 *
 * Grundoptik unabhängig vom Einsatzort: kein Link-Unterstrich, Farbe
 * dezent statt in der Linkfarbe, damit der Stift nicht wie ein
 * inhaltlicher Link wirkt, sondern wie ein Werkzeug-Icon.
 *
 * "!important" bei text-decoration (30.8. ergaenzt, Nutzerfeedback
 * "Bleistift und Muelleimer sind unterstrichen"): hpl-site.css setzt
 * seit demselben Tag "text-decoration: underline ... !important"
 * global auf jedes <a>-Element (siehe dortiger Kommentar). Eine
 * hoehere Spezifitaet allein reicht gegen eine !important-Regel
 * nicht aus, unabhaengig von der Ladereihenfolge - nur eine
 * ebenfalls mit !important versehene Regel gewinnt zuverlaessig.
 * Ohne dieses !important war dieser Icon-Link seit der globalen
 * Aenderung faelschlich unterstrichen, obwohl er als Werkzeug-Icon
 * gedacht ist, nicht als inhaltlicher Link (Nutzerentscheidung: nur
 * gewoehliche Links sollen zentral unterstrichen definiert sein,
 * spezielle Links wie Icons/Menuepunkte nicht).
 */
.hpl-event-edit-link {
	display: inline-flex;
	color: var(--hpl-field-label-color);
	text-decoration: none !important;
}

.hpl-event-edit-link:hover {
	color: var(--hpl-font-color);
}

/*
 * Bearbeiten-Link auf der Einzelseite, direkt neben dem Titel
 * (EventEditLinkPlaceholderService::renderEditLinkAfterTitle(), Hook
 * "blocksy:hero:title:after" - feuert unmittelbar nach dem von Blocksy
 * gerenderten <h1 class="page-title">, siehe dortiger Klassen-Docblock).
 *
 * Blocksys Titel ist block-level und würde den danach eingefügten Link
 * ohne diese Regel auf eine neue Zeile darunter verdrängen -
 * "inline-block" lässt den Titel nur so breit werden wie sein Inhalt,
 * wodurch der direkt danach folgende, inline-flex gesetzte Link
 * (.hpl-event-edit-link oben) auf derselben Zeile Platz findet.
 * "body.single-event" ist WordPress' eigene, automatisch gesetzte
 * Body-Klasse für Einzelseiten des Post-Typs "event"
 * (EM_POST_TYPE_EVENT).
 */
body.single-event h1.page-title {
	display: inline-block;
}

/*
 * Seitentitel der "Neues Event hinzufügen"/"Event bearbeiten"-Seite
 * (WordPress rendert dafür eine ganz normale Page mit h1.page-title,
 * dessen Schriftgrösse Blocksy über seine eigenen, pro Inhaltstyp
 * konfigurierbaren Customizer-Einstellungen steuert - unabhängig von
 * unseren eigenen --hpl-h1/h3-Variablen). Auf dieser Seite wirkte der
 * Titel dadurch kleiner als die h3-Section-Überschriften im Formular
 * darunter (When/Who/Where/...), obwohl ein h1 optisch nie kleiner sein
 * sollte als die h3 einer untergeordneten Ebene.
 *
 * Selektor ohne feste Page-ID/Slug: ":has(.hpl-event-editor)" erkennt
 * die Seite stattdessen daran, dass sie unser eigenes Bearbeitungs-
 * formular (event-editor.php, Wurzel-Element ".hpl-event-editor")
 * enthält - funktioniert deshalb unabhängig davon, welche WordPress-
 * Seite in den Events-Manager-Einstellungen (dbem_edit_events_page) als
 * "Event bearbeiten"-Seite hinterlegt ist, und bleibt auch bei einer
 * künftigen Umbenennung/Verschiebung dieser Seite gültig.
 */
body:has(.hpl-event-editor) h1.page-title {
	font-size: var(--hpl-h1-font-size);
}

/*
 * Farbe: dieselbe CSS-Variable, mit der Blocksy den h1-Titel selbst
 * einfärbt (--theme-heading-1-color mit Fallback --theme-headings-color
 * - massgeblich für heading_tag "h1", siehe
 * wp-content/themes/blocksy/inc/options/general/page-title.php, Zeile
 * 920). Mit !important, da hpl-site.css bereits "a:not(.ct-menu-link)"
 * mit !important auf die eigene Linkfarbe setzt (gleiche Begründung wie
 * bei .hpl-description-link weiter oben) - ohne !important würde diese
 * Regel den Stift sonst in der allgemeinen Linkfarbe zeigen statt in
 * der Titelfarbe.
 *
 * Grösse und vertikale Position: Dashicons haben von Haus aus eine feste
 * Icon-Grösse (20px), unabhängig von der viel grösseren, fetten
 * Titelschrift daneben - "vertical-align: middle" (berechnet relativ zur
 * x-Höhe der Schrift, nicht zur optischen Mitte grosser/fetter
 * Überschriften) sass dadurch sichtbar zu tief. "vertical-align" mit
 * einem festen Pixelwert verschiebt die Grundlinie des Icons stattdessen
 * direkt und vorhersehbar nach oben, unabhängig von Schriftgrössen-
 * Metriken. Der Wert (6px) ist ein erster, augenmass-basierter Versuch -
 * müsste nach Sichtprüfung im Browser eventuell noch nachjustiert
 * werden.
 */
body.single-event h1.page-title + .hpl-event-edit-link {
	margin-left: 12px;
	vertical-align: -5px;
	color: var(--theme-heading-1-color, var(--theme-headings-color)) !important;
}

body.single-event h1.page-title + .hpl-event-edit-link .dashicons {
	width: 24px;
	height: 24px;
	font-size: 24px;
}

/*
 * Löschen-Icon auf der Einzelseite (EventDeleteLinkPlaceholderService::
 * renderDeleteLinkAfterTitle(), an denselben Hook gehängt wie der
 * Bearbeiten-Link, aber danach - erscheint deshalb im DOM direkt nach
 * .hpl-event-edit-link, nicht nach dem h1 selbst). Gleiche Grössen-/
 * Positionslogik wie beim Bearbeiten-Icon oben, nur mit kleinerem
 * Abstand (8px statt 12px), da es dem Bearbeiten-Icon folgt statt dem
 * Titeltext.
 */
body.single-event .hpl-event-edit-link + .hpl-event-delete-link {
	margin-left: 8px;
	vertical-align: -5px;
	color: var(--theme-heading-1-color, var(--theme-headings-color)) !important;
}

body.single-event .hpl-event-edit-link + .hpl-event-delete-link .dashicons {
	width: 24px;
	height: 24px;
	font-size: 24px;
}

/*
 * Frontend-Bearbeitungsformular (EventFormTemplateOverrideService,
 * Resources/Private/Templates/EventsManager/Forms/event-editor.php).
 *
 * Nur der Kopfbereich (Bild + Event Name) verwendet dieselben Klassen
 * wie die Detailansicht (.em-item-header, .em-item-meta,
 * .em-item-meta-line, .hpl-field-label/.hpl-field-value) und erbt
 * darüber automatisch deren Layout. "When", "Where", "Categories",
 * "Details" und "Bookings" sind dagegen eigene Abschnitte
 * (.hpl-event-editor-section) mit eigener Überschrift - ein erster
 * Versuch, auch diese ins Meta-Raster zu zwingen, hat die komplexen
 * Unterformulare (Datumsauswahl, Wiederkehr, Ortsadresse mit Karte)
 * nur unübersichtlich gemacht. Die Reihenfolge der Abschnitte folgt
 * trotzdem bewusst der Reihenfolge der entsprechenden Zeilen auf der
 * Detailseite: Wann, Wo, Kategorien, danach Beschreibung, danach
 * Buchungen.
 */
.hpl-event-editor .hpl-field-value input[type="text"],
.hpl-event-editor .hpl-field-value input[type="date"],
.hpl-event-editor .hpl-field-value input[type="time"],
.hpl-event-editor .hpl-field-value select,
.hpl-event-editor .hpl-field-value textarea {
	width: 100%;
	max-width: 500px;
	font-family: var(--hpl-font-family);
	color: var(--hpl-font-color);
}

/*
 * Begrenzt die Breite von em-selectize-Feldern. Das "Location"-Dropdown
 * im "Where"-Abschnitt (forms/Location/location.php) nutzt seit der
 * Zusammenlegung mit "Location Type" (23.7.2026, Klasse
 * "hpl-location-select" statt "em-selectize"/"#location-select-id")
 * kein Selectize.js mehr - diese Regel bleibt trotzdem bestehen, falls
 * andernorts wieder ein em-selectize-Feld auftaucht (z. B. Länderauswahl
 * im inaktiven manuellen Adressformular-Zweig).
 *
 * Selectize.js ersetzt das <select> beim Initialisieren durch ein
 * eigenes .selectize-control-Element und blendet das Original aus -
 * die obige Regel greift dadurch nicht mehr, da sie auf das <select>
 * selbst zielt, nicht auf das neu erzeugte Element. PixelBones setzt
 * für .selectize-control selbst keine Breite (nur für die
 * Kind-Elemente .selectize-input/.selectize-dropdown, jeweils
 * width:100% relativ zum Control), wodurch das Control ohne diese
 * Regel die volle Breite seines Elternelements (.hpl-field-value, die
 * "1fr"-Spalte des Grids) einnimmt.
 */
.hpl-event-editor .hpl-field-value .selectize-control {
	width: 100%;
	max-width: 500px;
}

/*
 * Entfernt den weissen Hintergrund, den Selectize.js seinem
 * ".selectize-input"-Ersatzelement standardmässig mitgibt (siehe
 * Docblock oben zu ".selectize-control"). Alle nativen <select>-Felder
 * im Formular sind selbst transparent (kein eigenes background-color)
 * und zeigen deshalb einfach den grauen Seitenhintergrund durch - beim
 * "Zeitzone"-Feld (aktuell das einzig verbliebene em-selectize-Feld,
 * siehe timezone.php) fiel dieses weisse Element dadurch als einziges
 * "helles Kästchen" auf. Auf Nutzerwunsch (29.8.) angeglichen, analog
 * zur bereits bestehenden Regel für ".em-recurrence-set" oben.
 */
.hpl-event-editor .hpl-field-value .selectize-input {
	background: transparent !important;
}

/*
 * Entfernt den Standard-Browser-Rahmen von <fieldset>-Elementen
 * innerhalb der Wert-Spalte (aktuell "Recurrences Between"
 * (Recurrences/dates.php, <fieldset class="inline">) und "Times"
 * (Recurrences/times.php, <fieldset class="em-recurrence-timeranges">)).
 *
 * Browser rendern <fieldset> standardmässig mit einem eigenen
 * eingekerbten Rahmen samt Innenabstand (User-Agent-Stylesheet), auch
 * wenn kein <legend> sichtbar ist. Ohne diese Regel liegt dadurch ein
 * zweiter, unpassender Rahmen um die bereits über
 * ".hpl-field-value input/select" gestylten Eingabefelder - optisch ein
 * Rückfall in die unformatierte Optik, obwohl das Label/Wert-Raster und
 * die Feld-Styles technisch längst greifen. "min-width: 0" verhindert
 * zusätzlich, dass das Fieldset (ebenfalls User-Agent-Default:
 * min-width: min-content) die Wert-Spalte über deren Breite hinaus
 * aufspreizt.
 */
.hpl-event-editor .hpl-field-value fieldset {
	border: none;
	margin: 0;
	padding: 0;
	min-width: 0;
}

/*
 * Entfernt die native "Karten"-Optik der einzelnen Recurrence-Sets
 * (weisser Hintergrund, grauer Rahmen, abgerundete Ecken - Events
 * Managers eigene events-manager-event-editor.css, Regel
 * ".em .em-recurrence-set"). Diese Karten-Optik ist für Events Managers
 * eigene "PixelBones"-Formularoptik gedacht und wirkt neben dem übrigen,
 * randlosen Formular (gleicher Hintergrund wie die Seite, keine
 * Rahmen) als Fremdkörper. Gleiche Selektor-Spezifität wie das
 * Original, deshalb !important.
 */
.hpl-event-editor .em-recurrence-set {
	background: transparent !important;
	border: none !important;
	border-radius: 0 !important;
	box-shadow: none !important;
}

/*
 * Im bei diesem Projekt weitaus häufigsten Fall genau eines
 * Recurrence-Sets blendet Events Manager die Drag/Lösch/Erweitert-
 * Buttons bereits selbst aus (siehe events-manager-event-editor.css,
 * ".em-recurrence-type-include[data-count=\"1\"] .em-recurrence-set
 * .em-recurrence-set-actions"), reserviert dafür in der Grid-Zeile aber
 * weiterhin eine 38px-Spalte und lässt auf der Datenspalte 15px
 * Innenabstand stehen - beides zusammen verschiebt die Labels sichtbar
 * gegenüber den übrigen, randlosen Formularzeilen (Start/End/Timezone).
 * Für genau diesen Einzelfall (data-count="1") wird die reservierte
 * Spalte entfernt und der Innenabstand auf 0 gesetzt, damit die Labels
 * bündig mit dem Rest des Formulars beginnen. Bei mehreren Sets (Drag-
 * Handle sichtbar, mehrere "+ Event Dates"-Einträge) bleiben Spalte und
 * Innenabstand bewusst unangetastet - dort trennen sie die einzelnen
 * Einträge optisch sinnvoll voneinander.
 */
.hpl-event-editor .em-recurrence-type[data-count="1"] .em-recurrence-set {
	grid-template-columns: 1fr !important;
}

.hpl-event-editor .em-recurrence-type[data-count="1"] .em-recurrence-set .em-recurrence-set-data {
	padding: 0 !important;
}

.hpl-event-editor-section {
	margin: 30px 0;
	padding-top: 20px;
	border-top: 1px solid #d0d0d0;
}

.hpl-event-editor-section h3,
.hpl-event-editor-content h3 {
	font-size: var(--hpl-h3-font-size);
	font-family: var(--hpl-h3-font-family);
	color: var(--hpl-h3-font-color);
	margin-bottom: 10px;
}

/*
 * Auf Nutzerwunsch (29.8.) sind die Section-Überschriften "Wann", "Wer",
 * "Wo", "Kategorien" und "Details" ausgeblendet - der Formularaufbau
 * selbst bleibt unverändert (Rahmenlinie/Abstand von
 * .hpl-event-editor-section bzw. .hpl-event-editor-content bleiben
 * bestehen, nur der <h3>-Text verschwindet). Bewusst NICHT über den
 * gemeinsamen Selektor ".hpl-event-editor-section h3" oben, da dieser
 * auch auf "Buchungen/Anmeldung" (.hpl-event-editor-bookings) passen
 * würde, dessen Überschrift stehen bleiben soll - deshalb hier einzeln
 * über die jeweilige Section-Klasse.
 */
.hpl-event-editor-when h3,
.hpl-event-editor-who h3,
.hpl-event-editor-where h3,
.hpl-event-editor-attributes h3,
.hpl-event-editor-content h3 {
	display: none;
}

.hpl-event-editor-content {
	margin: 30px 0;
}

.hpl-event-editor-textarea {
	width: 100%;
	font-family: var(--hpl-font-family);
	color: var(--hpl-font-color);
}

/*
 * Setzt die Optik des klassischen WordPress-Editors ("Details"-
 * Abschnitt, wp_editor(), sichtbar wenn dbem_events_form_editor aktiv
 * ist) auf das native WordPress-Aussehen zurück - ohne diese Regel
 * fielen Quicktags-Buttons (b/i/link/...), "Medien hinzufügen" sowie die
 * "Visuell"/"Code"-Reiter ebenfalls in Rot auf. Ursache ist eine
 * bewusste, sitenweite Regel in hpl-site.css ("Alle Buttons der
 * Website: weisse Schrift auf rotem Grund", Selektor u. a. auf dem
 * blossen <button>-Element), die dadurch auch WordPress' eigene
 * Editor-Werkzeugleiste erfasst, obwohl diese kein gestalteter
 * Website-Button ist, sondern Teil der WordPress-Bedienoberfläche
 * selbst.
 *
 * Die Werte entsprechen WordPress' eigener, unveränderter
 * .button-Optik (wp-admin/css/common.css) - keine eigene HPL-Erfindung.
 * !important und dieselbe Selektor-Struktur wie in hpl-site.css nötig,
 * um deren ebenfalls mit !important versehene Regel bei höherer
 * Spezifität (Element- zusätzlich zur Klassen-Selektor-Ebene) sicher zu
 * schlagen.
 */
.hpl-event-editor-content .button,
.hpl-event-editor-content button {
	background-color: #f6f7f7 !important;
	color: #2c3338 !important;
	border-color: #dcdcde !important;
}

.hpl-event-editor-content .wp-editor-tabs .active {
	background-color: #f0f0f1 !important;
}

/*
 * Dieselbe Rücksetzung wie oben bei .hpl-event-editor-content, diesmal
 * für den klassischen WordPress-Editor (wp_editor()) auf der frontend-
 * seitigen Einstellungen-Seite ("Zoom-Link & Spendenhinweis",
 * EventTextSettingsPageController, Shortcode "hpl_event_settings",
 * Root-Element ".hpl-event-text-settings" in
 * Templates/EventTextSettings/Index.html). Ohne diese Regel erscheinen
 * dort dieselben Quicktags-/Medien-/Visuell-Code-Buttons in Rot wie
 * ursprünglich im Bearbeitungsformular (siehe Begründung oben bei
 * .hpl-event-editor-content .button).
 */
.hpl-event-text-settings .button,
.hpl-event-text-settings button {
	background-color: #f6f7f7 !important;
	color: #2c3338 !important;
	border-color: #dcdcde !important;
}

.hpl-event-text-settings .wp-editor-tabs .active {
	background-color: #f0f0f1 !important;
}

/*
 * Feldueberschriften "Zoom-Link-Text"/"Spendenhinweis-Text" (30.8.,
 * Nutzerwunsch): als h3-Untertitel statt als blosses <label> gesetzt
 * (Templates/EventTextSettings/Index.html), optisch identisch zu den
 * h3-Abschnittstiteln im Event-Bearbeitungsformular (siehe
 * .hpl-event-editor-section h3, .hpl-event-editor-content h3 weiter
 * oben) - dieselben zentralen h3-Variablen, damit sich die
 * Überschriftenoptik weiterhin an einer einzigen Stelle
 * (hpl-variables.css) ändern lässt.
 */
.hpl-event-text-settings h3 {
	font-size: var(--hpl-h3-font-size);
	font-family: var(--hpl-h3-font-family);
	color: var(--hpl-h3-font-color);
	margin-bottom: 10px;
}

/*
 * "Speichern"-Button auf derselben Einstellungen-Seite: standardmässig
 * neutrales WordPress-Grau statt der site-weiten Markenfarbe (Rot,
 * hpl-site.css) - erst wenn tatsächlich etwas geändert wurde
 * (Klasse "hpl-event-text-settings-form-is-dirty", gesetzt von
 * hpl-event-text-settings.js bei Eingaben in eines der beiden Textfelder),
 * wechselt er in die Markenfarbe. Nach dem Speichern lädt die Seite
 * serverseitig neu (siehe EventTextSettingsPageController::saveSubmittedTexts()),
 * wodurch die Klasse automatisch wieder verschwindet - kein eigener
 * "zurücksetzen"-Code nötig.
 *
 * Für den "geändert"-Zustand wird bewusst dieselbe Variable
 * (--hpl-button-background-color/--hpl-button-text-color aus
 * hpl-variables.css) verwendet wie für alle anderen Buttons der
 * Website, statt eines eigenen Rottons - die Markenfarbe bleibt so an
 * genau einer Stelle definiert.
 *
 * Höhere Spezifität als die site-weite "Alle Buttons rot"-Regel (zwei
 * Klassen + Element-Selektor statt nur eines Attribut-Selektors)
 * gewinnt zuverlässig gegen deren !important, unabhängig von der
 * Ladereihenfolge.
 */
.hpl-event-text-settings-form input[type="submit"] {
	background-color: #f6f7f7 !important;
	color: #2c3338 !important;
}

.hpl-event-text-settings-form input[type="submit"].hpl-event-text-settings-form-is-dirty {
	background-color: var(--hpl-button-background-color) !important;
	color: var(--hpl-button-text-color) !important;
}

/*
 * Dieselbe sitenweite "Alle Buttons rot"-Regel aus hpl-site.css (siehe
 * Begründung oben bei .hpl-event-editor-content .button) erfasst auch die
 * kleinen Symbol-Schaltflächen der Wiederholungs-Sets (Verschieben,
 * Entfernen, Erweiterte Optionen, Änderungen rückgängig - siehe
 * Recurrences/set.php, Klasse "em-recurrence-set-actions"). Diese Buttons
 * zeigen ihr Symbol als background-image (siehe events-manager.css,
 * ".em-icon-trash"/".em-icon-drag"/... - jeweils ".em .em-icon { ...
 * background-color: transparent }"), das eigentlich auf transparentem
 * Grund erscheinen soll; die rote background-color legt sich als
 * durchgehendes rotes Quadrat darüber und lässt die Symbole kaum noch
 * erkennen.
 *
 * Setzt hier nur die background-color zurück auf transparent - das Symbol
 * selbst (background-image) sowie Events Managers eigene Deckkraft-Regel
 * (opacity: 0.6) bleiben unverändert vom Original.
 */
.hpl-event-editor .em-recurrence-set-actions button {
	background-color: transparent !important;
	border-color: transparent !important;
}

/*
 * Blendet den "+ Event Dates"-Button (Recurrences/recurrences.php,
 * ".em-add-recurrence-set[data-type=include]") aus: Er legt ein
 * zusätzliches, komplett unabhängiges Wiederholungsmuster ("include"-Set)
 * neben dem bereits vorhandenen an - ein Feature für gleichzeitig
 * geltende, unterschiedliche Wiederholungsmuster auf demselben Event, das
 * dieses Projekt nicht nutzt (siehe Docblock zu Recurrences/set.php) und
 * das Redakteure nur versehentlich anklicken und dann nicht mehr
 * rückgängig machen können, ohne das neue Set einzeln über den
 * Papierkorb-Button zu entfernen.
 *
 * Der zweite Button mit gleicher CSS-Klasse, aber data-type="exclude"
 * ("+ Unavailable Dates"/"+ Ausnahmetermine", legt ein weiteres
 * Ausnahme-Set an), bleibt bewusst sichtbar - das wird gebraucht.
 */
.hpl-event-editor .em-add-recurrence-set[data-type="include"] {
	display: none !important;
}

.hpl-event-editor-submit {
	margin-top: 30px;
}

/*
 * "Löschen"-Button in der Submit-Sektion des Bearbeitungsformulars
 * (event-editor.php, EventDeleteLinkPlaceholderService::buildDeleteUrl()).
 * Abstand zum primären "Update Event"-Button davor, sonst kein
 * abweichendes Styling - button-secondary liefert bereits die passende
 * WordPress-Button-Optik.
 */
.hpl-event-editor-delete-button {
	margin-left: 10px;
}

/*
 * "Event Status"-Feld ganz oben im Bearbeitungsformular, vor dem Bild
 * (event-editor.php, forms/event/when/active-status.php - unverändertes
 * Events-Manager-Original, nur die Einbindungsstelle wurde verschoben).
 * Bewusst ohne die Rahmenlinie von .hpl-event-editor-section: Als
 * allererstes Element direkt unter dem Formularanfang wirkt ein
 * Trennstrich darüber deplatziert, ein einfacher Abstand nach unten
 * reicht.
 */
.hpl-event-editor-status {
	margin-bottom: 20px;
}

/*
 * Kopfbereich des Bearbeitungsformulars: Bild oben, Titel darunter -
 * anders als auf der Detailseite, deren Klassen (.em-item-header,
 * .em-item-image, .em-item-meta) dieser Bereich mitbenutzt und die dort
 * Bild und Meta-Spalte nebeneinander anordnen (events-manager.css,
 * Zeile 3068ff., ergänzt um den Order-Tausch in dieser Datei weiter
 * oben). Die order-Werte (Bild vor Meta) bleiben unverändert gültig -
 * nur die Hauptachse wird von "row" auf "column" gedreht, wodurch aus
 * "nebeneinander" automatisch "übereinander" wird.
 */
/*
 * Formularbreiter Trennstrich über dem Bild-Bereich, im selben Stil wie
 * .hpl-event-editor-section (Farbe/Stärke #d0d0d0 1px, 20px Abstand zum
 * Inhalt darunter) - ersetzt den nur feldbreiten, nativen EM-Strich, der
 * in FeaturedImage/featured-image-public.php gezielt entfernt wird
 * (siehe dortiges <style>). .em-item-header trägt bewusst nicht selbst
 * die Klasse .hpl-event-editor-section: Anders als deren übrige Sektionen
 * hat der Kopfbereich kein eigenes <h3> und keinen oberen Rand-Abstand
 * (die vorangehende .hpl-event-editor-status liefert mit ihrem
 * margin-bottom bereits genug Platz vor dem Strich).
 */
.hpl-event-editor .em-item-header {
	border-top: 1px solid #d0d0d0;
	padding-top: 20px;
	flex-direction: column;
}

.hpl-event-editor .em-item-header .em-item-image,
.hpl-event-editor .em-item-header .em-item-meta {
	flex: 0 0 auto !important;
}

.hpl-event-editor .em-item-header .em-item-meta {
	align-self: stretch;
}

/*
 * Datum/Zeit-Zeilen im "When"-Abschnitt des Bearbeitungsformulars
 * (EventFormTemplateOverrideService, Resources/Private/Templates/
 * EventsManager/Forms/When/when.php). Start-Datum+Zeit und
 * End-Datum+Zeit stehen bewusst je auf einer eigenen Zeile
 * nebeneinander, weil Events Manager sie intern als durchgehenden
 * Zeitraum speichert (event_start_date+event_start_time bis
 * event_end_date+event_end_time), nicht als täglich wiederholtes
 * Zeitfenster.
 *
 * Blocksy setzt global "input:is([type=date],[type=text],...) {
 * width: var(--has-width, var(--theme-form-field-width, 100%)) }"
 * (static/bundle/main.min.css) - ohne eigene, explizite Breite würde
 * das Datumsfeld deshalb die ganze Zeile einnehmen und das Zeitfeld in
 * die nächste Zeile umbrechen. Beide Felder bekommen deshalb bewusst
 * eine feste Breite statt "width: 100%".
 *
 * Zeile selbst ist ein Grid mit derselben Spaltenaufteilung wie
 * .em-item-meta-line (Label | Wert, --hpl-field-label-width), damit
 * das Datumsfeld exakt bündig mit allen anderen Eingabefeldern im
 * Formular beginnt - eine reine Flexbox mit "gap" hätte zusätzlich zur
 * Label-Breite noch den Gap-Wert als Abstand vor dem ersten Feld
 * eingefügt. Datum und Zeit stehen deshalb in einem eigenen,
 * verschachtelten Flex-Container (.hpl-event-datetime-fields), der als
 * Ganzes die Wert-Spalte des Grids belegt - der Gap zwischen Datum und
 * Zeit bleibt davon unberührt.
 */
.hpl-event-datetime-row {
	display: grid;
	grid-template-columns: var(--hpl-field-label-width) 1fr;
	align-items: center;
	margin-bottom: 10px;
}

.hpl-event-datetime-fields {
	display: flex;
	align-items: center;
	flex-wrap: wrap;
	gap: 10px;
}

.hpl-event-datetime-row input[type="date"],
.hpl-event-datetime-row input[type="text"] {
	font-family: var(--hpl-font-family);
	color: var(--hpl-font-color);
}

.hpl-event-datetime-row input[type="date"] {
	width: auto !important;
	flex-shrink: 0;
}

/*
 * Bewusst über die Klasse ".em-time-input" statt über den generischen
 * Typ-Selektor "input[type=\"text\"]" - das Datums-Trigger-Feld
 * (.em-date-input) ist inzwischen ebenfalls ein type="text"-Feld
 * (siehe When/when.php) und läge sonst fälschlich in derselben Zeile
 * innerhalb von .hpl-event-datetime-row und würde dieselbe Breite
 * erben.
 */
.hpl-event-datetime-row .em-time-input {
	width: 90px;
}

/*
 * Sobald Events Managers JS Flatpickr initialisiert hat (siehe
 * When/when.php), wird aus dem ".em-date-input" ein sichtbares
 * type="text"-Feld, auf das ebenfalls Blocksys globale
 * "width: 100%"-Regel zutreffen würde - deshalb auch hier eine
 * explizite, feste Breite statt der geerbten 100%.
 */
.hpl-event-datetime-datepicker {
	flex: 0 0 auto;
}

/*
 * Sobald Flatpickr initialisiert hat, ist ".em-date-input" ein leeres
 * type="text"-Feld. "width: auto" liefert dafür keine sinnvolle Breite
 * (kein Inhalt bestimmt sie), deshalb hier bewusst eine feste Breite
 * statt "auto" - bewusst ohne eigenes Kalender-Icon, analog zum
 * Zeitfeld daneben, das ebenfalls keins hat.
 */
.hpl-event-datetime-row .em-date-input {
	width: auto;
	flex-shrink: 0;
	font-family: var(--hpl-font-family);
	color: var(--hpl-font-color);
}

/*
 * In der Veranstaltungsliste bleibt der Stift standardmässig
 * unsichtbar (opacity statt display: none, damit weiterhin per Tab
 * dorthin fokussiert werden kann) und blendet erst beim Hover oder
 * Fokus auf die Listenzeile ein - bewusst dezent, damit die Liste
 * nicht unruhig wirkt. Auf der Einzelseite (Details Page Format)
 * bleibt er dagegen immer sichtbar, da dort kein "aufgeräumtes
 * Listenbild" gefährdet ist.
 */
.em.em-list .em-item .hpl-event-edit-link {
	opacity: 0;
	transition: opacity 0.15s ease-in-out;
}

.em.em-list .em-item:hover .hpl-event-edit-link,
.em.em-list .em-item:focus-within .hpl-event-edit-link {
	opacity: 1;
}

/*
 * Löschen-Link (Papierkorb-Icon) aus EventDeleteLinkPlaceholderService,
 * Platzhalter #_HPL_EVENT_DELETE_LINK - direkt neben dem Bearbeiten-Link
 * im Titel der Listenansicht platziert (siehe dortiger Klassen-Docblock),
 * deshalb dieselbe Grundoptik und dasselbe Hover-Verhalten wie
 * .hpl-event-edit-link oben. Kein Pendant auf der Einzelseite - dort
 * gibt es (anders als beim Bearbeiten-Link) keinen Löschen-Link, siehe
 * Klassen-Docblock von EventDeleteLinkPlaceholderService.
 *
 * "!important" bei text-decoration: gleicher Grund wie bei
 * .hpl-event-edit-link oben (30.8., Nutzerfeedback).
 */
.hpl-event-delete-link {
	display: inline-flex;
	color: var(--hpl-field-label-color);
	text-decoration: none !important;
}

.hpl-event-delete-link:hover {
	color: var(--hpl-font-color);
}

.em.em-list .em-item .hpl-event-delete-link {
	opacity: 0;
	transition: opacity 0.15s ease-in-out;
}

.em.em-list .em-item:hover .hpl-event-delete-link,
.em.em-list .em-item:focus-within .hpl-event-delete-link {
	opacity: 1;
}

/*
 * "Wer"-Abschnitt des Bearbeitungsformulars (Resources/Private/Templates/
 * EventsManager/Forms/Who/who.php). Die Feldgruppen
 * (.hpl-organizer-fields-list/.hpl-organizer-fields-url) werden je nach
 * gewähltem Typ per JS ein-/ausgeblendet (hpl-events-manager.js,
 * setupOrganizerTypeToggle) - kein initiales "display: none" nötig:
 * das würde ohne JS beide Feldgruppen dauerhaft verstecken, JS setzt
 * den korrekten Anfangszustand bereits beim Laden. "Name" und "URL"
 * innerhalb von .hpl-organizer-fields-url sind eigene
 * .em-item-meta-line-Zeilen und stapeln sich dadurch bereits von
 * selbst - keine weitere Layout-Regel nötig.
 */

/*
 * Erzwingt das Label-links/Wert-Raster für Meta-Zeilen ausserhalb von
 * .em-item-meta (Who, Categories, Event Status). Das Original-Plugin
 * definiert display:grid für .em-item-meta-line nur innerhalb von
 * .em-item-meta (events-manager.css, Zeile ~3038) - das gilt für diese
 * Formularabschnitte nicht, deshalb hier eine eigene, allgemeinere
 * Regel. Für Zeilen, die zusätzlich innerhalb von .em-item-meta liegen
 * (Titel, Teaser im Kopfbereich), ist diese Regel wirkungslos
 * redundant: Die spezifischere, mit !important versehene Regel weiter
 * oben gewinnt dort ohnehin.
 */
.hpl-event-editor .em-item-meta-line {
	display: grid;
	grid-template-columns: var(--hpl-field-label-width) 1fr;
	align-items: center;
	margin-bottom: 10px;
}

/** Eingenschaften des Event-Titels in der Event-Liste **/
.em.em-list .em-item .em-item-info h3.em-item-title {
	font-size: var(--hpl-h3-font-size) !important;
}

/*
 * Box um den Teaser (#_HPL_TEASER), umbenannt von Events Managers
 * eigenem Klassennamen "em-item-desc" (aus den dortigen, bei uns
 * inaktiven Default-Formatstrings sowie deren mitgeliefertem
 * events-manager.css - siehe dortige _items.scss, Zeile ~319) zu
 * "em-item-teaser" - eigene, projekteigene Klasse statt einer fremden,
 * an der wir nur mitstylen. Die zwei Werte hier entsprechen bewusst
 * exakt Events Managers bisherigem Default (font-size: 16px;
 * margin: 20px 0), damit sich am Erscheinungsbild durch die Umbenennung
 * nichts ändert - von hier aus lässt sich der Teaser-Stil jetzt aber
 * direkt in dieser eigenen Datei anpassen, ohne die fremde EM-Klasse
 * mitzutreffen.
 *
 * Muss im entsprechenden Format-String (Settings → Formatting, z. B.
 * dbem_event_list_item_format) selbst von "em-item-desc" auf
 * "em-item-teaser" umbenannt werden - Format-Strings sind bei uns
 * DB-gespeichert (dbem_advanced_formatting=1), diese CSS-Datei kennt
 * ihren Inhalt nicht.
 */
.em-item-teaser {
	font-size: 20px;
	margin: 20px 0;
}

/*
 * Blendet "Zeiten" und "Zeitzone" bei Ausnahmeterminen (exclude-Sets,
 * "em-recurrence-type-exclude") aus: Der Anwendungsfall ist laut
 * Rückfrage beim Redakteur ausschliesslich "einzelne konkrete Tage oder
 * ein Datumsbereich" (z.B. Sommerferien) - Uhrzeiten und eine eigene
 * Zeitzone pro Ausnahme sind hier überflüssige Komplexität.
 *
 * Rein optisch (display: none) - die dahinterliegenden Felder behalten
 * ihre serverseitigen Standardwerte und werden weiterhin mit
 * abgeschickt, nur eben nicht mehr angezeigt oder bearbeitbar.
 */
.hpl-event-editor .em-recurrence-type-exclude .em-recurrence-timeranges-wrapper,
.hpl-event-editor .em-recurrence-type-exclude .em-recurrence-timezone {
	display: none !important;
}

/*
 * Blendet zusätzlich das ganze "Wiederholung"-Feld (Frequenz-Dropdown +
 * Intervall) bei Ausnahmeterminen aus - siehe Docblock in
 * Recurrences/pattern.php ("$isExcludeSet"). Übrig bleibt bei
 * Ausnahmeterminen nur noch "Wiederholungen zwischen" (der eigentliche
 * Start-/End-Datumsbereich aus dates.php).
 */
.hpl-event-editor .em-recurrence-type-exclude .em-recurrence-pattern {
	display: none !important;
}

/*
 * Der verbleibende "Zeitraum" (dates.php) steckt technisch im
 * ".em-recurrence-advanced"-Bereich, den Events Manager standardmässig
 * eingeklappt lässt (max-height: 0, siehe events-manager-event-editor.css)
 * - aufgeklappt wird er sonst nur durch Klick auf das Filter-Icon
 * ("Erweiterte Optionen") oder automatisch beim allerersten
 * "include"-Set. Ohne die jetzt entfernte "Wiederholung"-Zeile (siehe
 * Regel oben) blieb dadurch bei Ausnahmeterminen rein gar nichts mehr
 * sichtbar ausser den Icons.
 *
 * Erzwingt hier denselben "immer aufgeklappt"-Zustand, den Events
 * Manager selbst für das erste include-Set per CSS reserviert (siehe
 * ".em-recurrence-set[data-type=include]:first-child:not(.reordering)
 * .em-recurrence-advanced" im Original) - nur eben für alle
 * exclude-Sets. Blendet passend dazu auch die eingeklappte
 * Zusammenfassungszeile (".advanced-summary") und den jetzt
 * überflüssigen Auf-/Zuklapp-Button ("Erweiterte Optionen") aus, da
 * ohnehin nichts mehr zum Auf-/Zuklappen übrig ist.
 */
.hpl-event-editor .em-recurrence-type-exclude .em-recurrence-set .em-recurrence-advanced {
	max-height: 1000px !important;
	opacity: 1 !important;
	overflow: visible !important;
	padding: 18px 0 10px 10px !important;
}

.hpl-event-editor .em-recurrence-type-exclude .em-recurrence-set .advanced-summary,
.hpl-event-editor .em-recurrence-type-exclude .em-recurrence-set .em-recurrence-set-action-advanced {
	display: none !important;
	visibility: hidden !important;
}

/*
 * Ausgewählte Termine im "On"-Datumspicker der Recurrences
 * (Resources/Private/Templates/EventsManager/Forms/Recurrences/pattern.php,
 * ".em-datepicker-dates"). Die einzelnen Datums-Einträge selbst kommen
 * nicht aus PHP, sondern werden von Events Managers eigenem JS
 * (Flatpickr-Mehrfachauswahl) zur Laufzeit eingefügt - server-seitig
 * sichtbar ist nur der statische "Clear All"-Eintrag (siehe
 * pattern.php), der laut Markup dieselbe ".item"-Struktur verwendet
 * (Text + ".remove"-Link). Diese Regel geht davon aus, dass die
 * JS-generierten Einträge derselben Struktur folgen - bitte im Browser
 * gegenprüfen, ob die Chips damit wirklich wie vorgesehen aussehen,
 * sobald mehrere Termine ausgewählt sind.
 */
.em-datepicker-dates {
	display: flex;
	flex-wrap: wrap;
	gap: 6px;
	margin-top: 8px;
}

.em-datepicker-dates .item {
	display: inline-flex;
	align-items: center;
	gap: 6px;
	padding: 4px 10px;
	border-radius: 3px;
	background: var(--hpl-field-label-color);
	color: var(--hpl-button-text-color, #fff);
	font-size: 12px;
}

/*
 * "!important" (30.8., analog zu .hpl-event-edit-link oben): das
 * "x" zum Entfernen eines gewaehlten Datums ist ein Werkzeug-Icon,
 * kein inhaltlicher Link, und muss deshalb die globale
 * "text-decoration: underline ... !important"-Regel aus hpl-site.css
 * ebenfalls mit !important schlagen.
 */
.em-datepicker-dates .item .remove {
	color: inherit;
	text-decoration: none !important;
	line-height: 1;
}

.em-datepicker-dates .item.clear-all {
	background: transparent;
	border: 1px solid var(--hpl-field-label-color);
	color: var(--hpl-field-label-color);
}

/*
 * "+ Event Dates"/"+ Unavailable Dates" tragen seit dem
 * Recurrences.php-Override zusätzlich "button button-secondary" (siehe
 * dessen Docblock) - hier nur ein kleiner Abstand zwischen den beiden
 * Buttons, analog zu .hpl-event-editor-delete-button weiter oben.
 */
.em-add-recurrence-set + .em-add-recurrence-set {
	margin-left: 10px;
}

/* Upload Images Feld */
.em .em-input-upload {
	margin: 30px 0 !important;
	padding-top: 20px !important;
	border-top: 1px solid #d0d0d0 !important;
}

/* Der Rahmen der Recurring Events Eingaben */
.em .em-recurrence-sets .em-recurrence-type-include[data-count="1"] .em-recurrence-set .em-recurrence-set-data .em-recurrence-advanced {
	padding-left: 0 !important;
}

.em-recurrence-checkbox {
	margin-left: 10px;
}