/* Theme Name: My Listing Child Theme URI: http://mylisting.27collective.net/my-city/ Description: MyListing Child Theme Author: 27collective Author URI: https://27collective.net/ Template: my-listing Version: 1.1 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: one-column, two-columns, three-columns, left-sidebar, right-sidebar, grid-layout, custom-menu, custom-logo, featured-images, footer-widgets, full-width-template, sticky-post, theme-options, threaded-comments, translation-ready Text Domain: my-listing-child */ /* === BTWG-ANPASSUNG #003 β€” Silbentrennung fuer lange Woerter (Snippet S-13) === */ /* -------------------------------------------------------------------------- S-13 β€” Silbentrennung fuer lange Woerter (Titel, Begriffe, Tabellenzeilen) -------------------------------------------------------------------------- DAS PROBLEM Lange deutsche Komposita laufen auf schmalen Schirmen aus der Seite oder werden abgeschnitten: "Kuenstlicheintelligenzanwendungsentwicklungs- kompetenzzentrum", "Digitale Gesellschaft & Nachhaltigkeit", "Auftaktveranstaltung". Deutsch ist dafuer anfaellig wie kaum eine andere Sprache β€” und Browser trennen von sich aus NICHT, solange man es nicht verlangt. DIE LOESUNG: `hyphens: auto` Damit trennt der Browser mit seinem EINGEBAUTEN Woerterbuch β€” also nach den Regeln der jeweiligen Sprache, nicht irgendwo. Genau das ist gewollt: "korrekte Rechtschreibung" statt Abschneiden. πŸ›‘ VORAUSSETZUNG: Die Seite muss ihre Sprache nennen. Ohne `lang` am html-Element greift `hyphens: auto` NICHT β€” der Browser weiss dann nicht, welches Woerterbuch er nehmen soll, und tut lieber nichts. Gemessen 08.08.2026 (AIMF): `` ist gesetzt. βœ“ Auf einer neuen Plattform VOR dem Einspielen pruefen. WARUM NICHT `word-break: break-all` Das bricht mitten im Wort, ohne Ruecksicht auf Silben β€” "Auftaktveran| staltung" wird zu "Auftaktverans|taltung". Sieht nach Fehler aus und ist fuer Deutsch schlicht falsch. Nur `hyphens: auto` trennt nach Silben. `overflow-wrap: break-word` steht trotzdem dabei β€” als Notnagel fuer das, was KEIN Woerterbuch trennen kann: lange Adressen, Aktenzeichen, erfundene Testwoerter. Es greift erst, wenn die Silbentrennung nicht ausreicht, und verhindert dann wenigstens das Ueberlaufen. `hyphenate-limit-chars: 8 4 4` haelt Trennungen lesbar: nur Woerter ab 8 Zeichen, mindestens 4 Zeichen vor und nach dem Trennstrich. Ohne diese Grenze trennen Browser auch "Kur-se" β€” technisch richtig, optisch unruhig. EINZELFALL VON HAND STEUERN Wo das Woerterbuch daneben liegt, setzt man im Text ein weiches Trennzeichen `­` an die gewuenschte Stelle. Es ist unsichtbar und wirkt nur, wenn dort tatsaechlich getrennt wird. Umgekehrt schuetzt ` ` eine Stelle vor dem Umbruch. -------------------------------------------------------------------------- */ /* Titel der Detailseite */ .profile-name h1, /* Titel auf den Vorschaukacheln */ .listing-preview-title, .lf-item-info h4, /* Ueberschriften der Inhaltsbloecke */ .title-style-1__heading, /* Begriffe: Kategorien, Themengebiete, Niveau … */ .listing-details .category-name, .c27-listing-preview-category-list .category-name, #c27-single-listing .element .pf-body li > a > span, /* Tabellenzeilen "Auf einen Blick": Beschriftung und Wert */ #c27-single-listing .item-attr, #c27-single-listing .item-property { -webkit-hyphens: auto; hyphens: auto; hyphenate-limit-chars: 8 4 4; overflow-wrap: break-word; } /* === BTWG-ANPASSUNG #004 β€” Lange Begriffe umbrechen statt abschneiden (Snippet S-17) === */ /* -------------------------------------------------------------------------- S-17 β€” Lange Begriffe UMBRECHEN statt abschneiden -------------------------------------------------------------------------- DAS PROBLEM Auf der Detailseite stehen die Begriffe (Format, Niveau, Themengebiete, Landkreis …) als Liste: links ein Icon, rechts der Name. Ist der Name zu lang, schneidet das Theme ihn ab und setzt drei Punkte: "Digitale Gesellschaft & Nachhalt…" πŸ›‘ SILBENTRENNUNG HILFT HIER NICHT. Das Theme setzt `white-space: nowrap` und `text-overflow: ellipsis` β€” damit ist ein Umbruch verboten, BEVOR die Trennung ueberhaupt zum Zug kaeme. Erst muss das Abschneiden weg. πŸ›‘ ES GIBT ZWEI VERSCHIEDENE TERM-STRUKTUREN β€” wer nur eine kennt, fixt die falsche. Gemessen am 08.08.2026: | Wo | Markup | abschneidende Regel | |---|---|---| | Vorschaukarte, Kategorie-Fuss | `span.category-name` | `.listing-details .category-name{text-overflow:ellipsis}` | | **Detailseite, Term-Bloecke** | **`ul.details-list > li > a > span`** (KEINE Klasse am span!) | **`.element .pf-body>.details-list li a span{text-overflow:ellipsis}`** | Beide werden unten abgedeckt. Der zweite Fall war der eigentliche Beschwerdegrund ("Podiumsdiskussion", "Netzwerktreffen" abgeschnitten) β€” ein Selektor auf `.category-name` greift dort ins Leere, weil das span ueberhaupt keine Klasse traegt. Dazu `white-space: nowrap` auf `.listing-details>ul>li` bzw. `.listing-details-3 .details-list li`. HERKUNFT: Diese Loesung laeuft bei THB seit dem 16.07.2026 (dort als THB-ANPASSUNG #016 fuer die Vereins-Detailseiten). Sie ist hier zentral gehoben worden, weil das Problem jede Plattform mit langen Begriffen hat. SCOPE: nur die Term-Bloecke der DETAILSEITE (`#c27-single-listing .block-type-terms`). Vorschaukarten und Suche bleiben unberuehrt β€” dort ist Abschneiden richtig, weil die Kachel eine feste Groesse hat. Kein `!important` noetig: die Spezifitaet reicht, und das Child-CSS wird spaeter geladen. ⚠️ Beim Einspielen den Idempotenz-Check BLOCK-SPEZIFISCH ankern (z. B. auf `text-overflow: clip`), nicht auf einen Wert wie `font-size: 13px` β€” der steht woanders in der Datei ebenfalls, und der Einbau wird dann faelsch- licherweise als "schon vorhanden" uebersprungen. (Real passiert bei THB.) -------------------------------------------------------------------------- */ /* Fall 1 + 2: der Listenpunkt selbst darf umbrechen. */ #c27-single-listing .block-type-terms .listing-details > ul > li, #c27-single-listing .block-type-terms .details-list li, #c27-single-listing .block-type-terms .details-list li > a { white-space: normal; overflow: visible; height: auto; } /* Fall 1: Vorschau-/Kategorie-Struktur mit Klasse am span. Fall 2: Detailseiten-Term-Bloecke β€” das span hat KEINE Klasse. */ #c27-single-listing .block-type-terms .category-name, #c27-single-listing .block-type-terms .details-list li > a > span { white-space: normal; overflow: visible; text-overflow: clip; /* Jetzt, wo umgebrochen werden DARF, greift die Silbentrennung (S-13). */ -webkit-hyphens: auto; hyphens: auto; hyphenate-limit-chars: 8 4 4; overflow-wrap: break-word; } /* === BTWG-ANPASSUNG #005 β€” Buttons eckiger statt Pille (Snippet S-07) === */ /* -------------------------------------------------------------------------- S-07 β€” Buttons eckiger statt Pille -------------------------------------------------------------------------- Das Theme gibt den Quick-Action-Buttons eine volle Pillen-Rundung (border-radius 50px). EDDY 02.08.2026: "Bei den Buttons ging es mir nicht um die CI, sondern wirklich nur um die Art des Radius β€” dass es eckiger wirkt." 5px laeuft bei THB seit dem 08.07.2026 (dort THB-ANPASSUNG #005) β€” mit diesem Snippet sehen alle Plattformen gleich aus. BEWUSST OHNE !important und ohne ID-Scope: Die Theme-Regel hat dieselbe Spezifitaet, das Child-CSS wird spaeter geladen und gewinnt dadurch. -------------------------------------------------------------------------- */ .quick-listing-actions > ul > li > a { border-radius: 5px; } /* Der Haupt-Button oben (der CTA im Kopfbereich) gehoert optisch dazu. */ .lmb-calltoaction > a { border-radius: 5px; } /* === BTWG-ANPASSUNG #006 β€” Scrollbalken der Buttonleiste unter die Buttons (Snippet S-05) === */ /* -------------------------------------------------------------------------- S-05 β€” Scrollbalken der Button-Leiste liegt UNTER den Buttons -------------------------------------------------------------------------- EDDY 02.08.2026: "Man kann die Buttons auf dem Smartphone nach rechts scrollen, und dieser Scrollbalken darunter ΓΌberdeckt den unteren Teil der Buttons. Da mΓΌsste man ein bisschen Abstand reinkriegen, dass der Balken eher unten drunter ist und es optisch zusammenpasst." Ursache: Das Theme setzt .quick-listing-actions > ul auf overflow-x:auto. Der Scrollbalken wird INNERHALB dieses Kastens gezeichnet β€” und weil die Buttons bis an den unteren Rand reichen, legt er sich ueber sie. Loesung: Platz unter den Buttons schaffen, damit der Balken dort landet. Zusaetzlich ein schmaler, zurueckhaltender Balken statt des System-Standards. Auf breiten Bildschirmen umbricht die Leiste ohnehin (flex-wrap) und scrollt gar nicht β€” dort aendert sich nichts Sichtbares. -------------------------------------------------------------------------- */ #c27-single-listing .quick-listing-actions > ul { padding-bottom: 12px; scrollbar-width: thin; scrollbar-color: rgba(0, 0, 0, 0.2) transparent; } #c27-single-listing .quick-listing-actions > ul::-webkit-scrollbar { height: 4px; } #c27-single-listing .quick-listing-actions > ul::-webkit-scrollbar-track { background: transparent; } #c27-single-listing .quick-listing-actions > ul::-webkit-scrollbar-thumb { background: rgba(0, 0, 0, 0.2); border-radius: 4px; } /* === BTWG-ANPASSUNG #007 β€” Kopfbereich auf dem Smartphone hoeher (35 -. 50 Prozent unter 768px) (Snippet S-11) === */ /* -------------------------------------------------------------------------- S-11 β€” Kopfbereich der Detailseite: auf dem Smartphone hoeher -------------------------------------------------------------------------- DAS PROBLEM Die Theme-Einstellung "Cover image height" ist KEINE Hoehe, sondern ein SEITENVERHAELTNIS. Der Wert landet als `padding-bottom: X%` an der Sektion β€” die Hoehe ist also immer ein Anteil der SEITENBREITE und schrumpft auf schmalen Schirmen zwangslaeufig mit. Gemessen an AIMF (Einstellung 20, my-listing 2.16, 08.08.2026): Monitor 1920 px -> ~384 px ok Laptop 1440 px -> ~288 px ok Handy 390 px -> ~78 px ein Streifen Die Einstellung gilt geraeteuebergreifend β€” im Backend ist das also nicht loesbar. Der Theme-Standard (20:7 = 35 %) hilft nicht: auf dem Handy waeren das immer noch nur ~137 px. DIE LOESUNG Unterhalb des Theme-Umbruchpunkts (768 px, der zweithaeufigste im Theme-CSS β€” kein selbst erfundener Wert) ein groesseres Verhaeltnis setzen. Desktop bleibt voellig unberuehrt. 50 % ergibt auf einem 390-px-Geraet rund 195 px: ein breiter Bildstreifen, auf dem das Titelbild noch als Bild wirkt, ohne den halben Schirm zu fuellen. DAS IST DIE EINZIGE ZAHL, AN DER MAN DREHT β€” hoeher wirkt praesenter, niedriger laesst den Inhalt frueher beginnen. WARUM `!important` UND WARUM DIE ZWEITE REGEL Beide Werte stehen als INLINE-Style im Markup (das Theme rechnet sie in PHP aus), und Inline schlaegt jede Stylesheet-Regel ohne `!important`:
Wuerde man NUR die Sektion hoeher machen, bliebe das Bild bei seinem 5:1-Verhaeltnis stehen β€” die Sektion waere hoeher als das Bild, und darunter klaffte ein Loch in der Overlay-Farbe. Deshalb bekommt das Bild zusaetzlich `height: 100%` und sein Verhaeltnis zurueckgesetzt; `object-fit: cover` aus dem Theme sorgt weiter dafuer, dass nichts verzerrt, sondern beschnitten wird. NICHT BETROFFEN: Eintraege ohne Titelbild. Die rendern ueber ein anderes Template (`partials/single/cover/none.php`, Klasse `profile-cover-no-img`) mit fester Hoehe. Solange ein Standardbild am Inseratstyp hinterlegt ist, kommt dieser Fall ohnehin nicht vor. -------------------------------------------------------------------------- */ @media only screen and (max-width: 768px) { .profile-cover.profile-cover-image { padding-bottom: 50% !important; } .profile-cover.profile-cover-image > img { aspect-ratio: auto !important; height: 100% !important; top: 0; left: 0; } } /* === BTWG-ANPASSUNG #009: Kopf-Buttons auf dem Desktop flacher (42 auf 36,75 px) (Snippet S-31) === */ /* -------------------------------------------------------------------------- S-31: Kopf-Buttons der Detailseite auf dem Desktop flacher -------------------------------------------------------------------------- EDDY 22.08.2026, zuerst: "Diese Buttons auf Desktop in der Hoehe um 25 Prozent reduzieren. Mobil passt es, mobil sollen sie so bleiben." Nach dem Ansehen auf Staging, am selben Tag: "Jetzt sind sie zu flach von der Hoehe. Vorher waren sie zu hoch. Jetzt braeuchten wir so einen Mittelwert." Deshalb steht hier die MITTE zwischen beiden, nicht die urspruengliche Rechnung. Gemeint ist die Button-Leiste im Kopfbereich (Direktnachricht senden, zur Webseite, E-Mail senden, anrufen, teilen, merken), also S-07 und S-05. NICHT gemeint ist der farbige Haupt-Button daneben (.lmb-calltoaction), der bleibt bei seinen 48 px. WORAUS DIE HOEHE ENTSTEHT (gemessen 22.08.2026 an allen fuenf Plattformen, berechnete Browser-Werte, Desktop 1440 und Handy 390) 42 px = padding 10 + Zeilenhoehe 20 + padding 10 + Rahmen 1 + 1 Ueberall identisch, box-sizing ist border-box. Es gibt KEINE `height`-Regel. πŸ›‘ Ein `height: 31.5px` waere deshalb der falsche Griff: Der Inhalt braucht seine 20 px, die Polsterung 20 weitere, und der Kasten wuerde entweder ueberlaufen oder den Text quetschen. Reduziert wird, was die Hoehe MACHT. DIE RECHNUNG zu hoch Theme-Stand 42 px zu flach erster Versuch, minus 25 % 31,5 px Mitte (42 + 31,5) / 2 36,75 px Polster (36,75 - 20 - 2) / 2 7,375 px je Seite Das sind 12,5 Prozent weniger als der Theme-Stand. Bruchteile von Pixeln sind hier richtig, der Browser rechnet in Subpixeln. πŸ›‘ DIE ZAHL IST EIN URTEIL, KEINE MESSUNG. Sie kommt aus zwei angesehenen Zustaenden, nicht aus einer Regel. Wer sie spaeter aendern will, aendert sie HIER und rollt neu aus, statt sie auf einer Plattform zu ueberschreiben. Links und rechts bleiben die 15 px des Themes stehen. Es geht um die Hoehe, nicht um die Breite, deshalb nur `padding-top` und `padding-bottom` und nicht die Kurzform `padding`. WARUM 769 UND NICHT 768 S-11 fasst "mobil" als `max-width: 768px`. Bei genau 768 px gaelten sonst beide Regeln, und der Desktop-Wert wuerde dort greifen, wo das Theme noch mobil denkt. 768 ist der zweithaeufigste Umbruchpunkt im Theme-CSS, kein selbst erfundener Wert. BEWUSST OHNE !important: Die Theme-Regel `.quick-listing-actions > ul > li > a` wiegt (0 IDs, 1 Klasse, 3 Elemente), diese hier wiegt gleich viel und wird spaeter geladen. Innerhalb einer Media-Query bleibt das so. -------------------------------------------------------------------------- */ @media only screen and (min-width: 769px) { .quick-listing-actions > ul > li > a { padding-top: 7.375px; padding-bottom: 7.375px; } } /* === BTWG-ANPASSUNG #010: Kopfbereich lesbar halten, Verlauf unten und rechts (nur Desktop) (Snippet S-20) === */ @media (min-width: 768px) { /* Der Verlauf braucht einen Bezugsrahmen. Das Theme setzt ihn meist schon β€” hier zur Sicherheit, falls eine Plattform davon abweicht. */ body.single-listing .profile-cover-image { position: relative; } /* ---- unten: Titel und Slogan ---- */ body.single-listing .profile-cover-image::after { content: ""; position: absolute; left: 0; right: 0; bottom: 0; height: 45%; background: linear-gradient(to top, rgba(0, 0, 0, .6), rgba(0, 0, 0, 0)); z-index: 2; pointer-events: none; } /* ---- rechts: der Termin ---- Schmaler und schwaecher als unten: Dort steht eine Ueberschrift, hier nur eine Zeile. Die beiden Verlaeufe ueberlagern sich in der unteren rechten Ecke β€” deshalb bleibt dieser bei .45 statt .6, sonst wird die Ecke zu dunkel. */ body.single-listing .profile-cover-image::before { content: ""; position: absolute; top: 0; right: 0; bottom: 0; width: 38%; background: linear-gradient(to left, rgba(0, 0, 0, .45), rgba(0, 0, 0, 0)); z-index: 2; pointer-events: none; } /* ---- der Inhalt gehoert ueber die Verlaeufe ---- πŸ›‘ HIER STEHT KEIN `position` β€” und das ist der ganze Punkt. Bis zum 19.08.2026 stand hier `position: relative` auf fuenf Selektoren. Das Theme positioniert `.listing-main-info` aber ABSOLUT an den unteren Bildrand. Ein eigenes `relative` hebt das auf: Der gesamte Kopfinhalt β€” Titel, Termin, Preis, Schaltflaeche β€” faellt an den Anfang des Covers und landet oben IM MENUE. Fuenf Tage lang unbemerkt, weil nach jeder Aenderung nur die gerade angefasste Stelle geprueft wurde und nie die Seite als Ganzes. `z-index` genuegt: Ein absolut positioniertes Element ist bereits positioniert, der z-index wirkt also. Und die Kinder (Titel, Termin, Preis, Schaltflaeche) steigen mit ihrem Elternteil mit β€” sie brauchen weder eigenen z-index noch eigene Positionierung. ⚠️ Wer hier je wieder `position` ergaenzen will: erst messen, ob das Zielelement schon positioniert ist (`getComputedStyle(el).position`). Ein `relative` auf ein `absolute` ist kein Zusatz, sondern ein Rueckbau. */ body.single-listing .profile-cover-image .listing-main-info { z-index: 3; } }