/** * idf-tooltip v1.3.0 - Tooltip-Standard * * v1.3.0 (Issue 871): `.is-tt-fixed` - die Blase verlaesst ihren klemmenden * Kasten, wenn dort kein Platz ist, im Fenster aber schon. Ebenfalls von * `idf-tooltip.js` gesetzt, samt Koordinaten. * * v1.2.0 (Issue 869): `.is-tt-unten` - dieselbe Wirkung wie * `.idf-tooltip-unten`, aber von `idf-tooltip.js` gesetzt, wenn ueber dem * Element kein Platz mehr ist. Die feste Klasse bleibt fuer Konsumenten, * die es besser wissen als die Messung; wer sie setzt, wird nicht * umgeklappt. * * v1.1.1 (Issue 861): Der Pfeil sitzt wieder am Kasten. Die Kombination * setzte die Blase auf calc(100% + 6px) UND haengte die 6px-Bruecke an, * also 12 px Abstand, waehrend der Pfeil bei 100% blieb. * * v1.1.0 (Issue 861): `.idf-tooltip-multiline` und `.idf-tooltip-unten` * lassen sich kombinieren. Bis dahin schloss die Variante „unten" das * aus, weil die Hoverbruecke der Multiline-Variante in die falsche * Richtung zeigte; jetzt gibt es dafuer eine Regel. * * Schnell sichtbarer Tooltip fuer Icon-Pillen, Action-Buttons und * Spaltenkoepfe. Bis shared v1.92.2 lagen diese Regeln in * `functions/list-view/grid-css/idf-list-grid.css` - deshalb gab es sie nur * auf Seiten, die eine Liste laden. Das Dashboard hat sich `$useListGrid` * genau dafuer gesetzt. Jetzt eigener Block, laedt immer. * * Verwendung: IDF.tooltip.set($btn, 'Wichtig'); * * * KEIN `title` (Joerg, 30.08.2026: „Generell sollte es Architektur sein, * dass aria-description statt title gesetzt wird"). Der Browser zeichnet * seine eigene title-Blase an den Zeiger, also unter und rechts davon - sie * ueberlagert damit genau das Element, dessen Erklaerung sie sein soll, und * sie kommt eine Sekunde spaeter als die gestylte. Zwei Blasen fuer denselben * Satz sind eine zu viel. * * Fuer Screenreader gilt: ein KURZES Label, das das Element benennt, gehoert * als `aria-label` daran; ein laengerer Erklaersatz als `aria-description`. * Niemals der Erklaersatz als `aria-label` - das waere der NAME des * Elements. `IDF.tooltip.set()` nimmt einem beides ab. * * Und: JEDE Pille bekommt einen Tooltip. Ein Icon ohne Wort ist ohne ihn * eine Rateaufgabe (Joerg, 30.08.2026: „Pillen sollen immer einen Tooltip * haben, der sie erklaert"). * * NIE halbdurchsichtig. Eine Daempfung (`opacity`) am Host wirkt als * Gruppendeckkraft auch auf die Blase; sie gehoert an den INHALT der Pille, * nicht an die Pille selbst (shared v1.228.0). * * ACHTUNG: `data-tooltip` NIE direkt auf das FontAwesome- setzen - der * Tooltip-Text (::after) erbt dessen font-family und rendert dann in der * Icon-Schrift (#313-Nachfix). Immer den Wrapper (Button/Span) zum * Tooltip-Host machen, das nackt hinein. * * Position: ueber dem Element zentriert, `pointer-events: none`, damit der * Tooltip selbst keine Hover-Events faengt. Am Rand des Inhaltsbereichs * passt `idf-tooltip.js` die Blase ein und legt den Schub als * `--idf-tt-shift` an den Host; hier wird er nur eingerechnet. Ohne das * Script bleibt es beim zentrierten Verhalten. */ [data-tooltip] { position: relative; } /* Wenn der Tooltip-Host gehovered wird, liften wir ihn (und seinen Tooltip-::after) per z-index ÜBER alle Sticky/Position-Geschwister in der Seite. Sonst verdeckt z.B. der `.idf-list-thead` (sticky, z-index 10), der ein eigenes Stacking-Context-Pärchen bildet, den Tooltip — der ist zwar mit `z-index: 100000` ausgezeichnet, aber das wirkt nur INNERHALB des Host-Stacking-Context. Erst mit z-index am Host selbst gewinnt der ganze Subtree. Das gilt nur innerhalb desselben Stacking-Context: bildet ein Vorfahr einen eigenen (`.al-grid { position: relative; z-index: 1 }`), gewinnt der Tooltip DARIN, aber nicht gegen die fixierte Sidebar im Wurzel-Kontext. Deshalb weicht die Blase den Rand-Flächen aus, statt sich mit ihnen um den Stapel zu streiten (siehe idf-tooltip.js). */ [data-tooltip]:hover, [data-tooltip]:focus-visible { /* Bewusst sehr hoch — Modal-Overlay liegt bei 10 000, App-Sidebar bei 10. Wir wollen unter ALLEN denkbaren Modul-Stacking-Contexts (auch legacy z-index:80/200/300/400/500/600 aus idf-core.css und z-index:10001 vom combobox-popup + 10000 vom confirm-modal) gewinnen, ohne dafür den Header, die Sidebar oder Modul-Sticky-Elements anpassen zu müssen. */ z-index: 2147483640; } [data-tooltip]:hover::after, [data-tooltip]:focus-visible::after { content: attr(data-tooltip); position: absolute; left: 50%; bottom: calc(100% + 6px); transform: translateX(calc(-50% + var(--idf-tt-shift, 0px))); background: var(--ink, #111); color: var(--white, #fff); padding: 4px 8px; border-radius: var(--radius-xs); font-size: 12px; font-weight: 500; line-height: 1.2; white-space: nowrap; pointer-events: none; z-index: 2147483641; /* KEINE Transition. Hier stand `transition-delay: 200ms`, gedacht als Verzoegerung vor dem Erscheinen. Das hat sie nie geleistet: der ::after entsteht erst beim Hover, und was neu entsteht, hat keinen Ausgangswert, von dem aus es ueberblenden koennte - gemessen ist die Blase nach 15 ms da. Was die Zeile stattdessen tat: `transition-property` steht per Default auf `all`, also wurde JEDE spaetere Aenderung um 200 ms verzoegert. Genau das sah man, seit die Blase eingepasst wird: Blase erscheint mittig, 216 ms spaeter springt sie zur Seite (Joerg, 12.08.2026: „Sie wird geladen und rutscht dann zur Seite"). Gemessen mit echter Maus: transform -53,5 px bei 15 ms, -85,5 px bei 231 ms. Explizit `none` statt der Zeile zu loeschen, damit nicht irgendwann eine geerbte Transition denselben Sprung zurueckholt. */ transition: none; /* Tooltip vermeidet, dass die FontAwesome-Icon-Schrift im Tooltip- Text durchschlägt. */ font-family: inherit; /* Tooltips IMMER normal geschrieben — unabhängig vom Eltern-Element. Sonst erbt der Tooltip in Tabellen-Headern das `text-transform: uppercase` des Header-Cells (.idf-list-thead) und wird GROSS, während er anderswo normal ist. Zentrale Konsistenz: ein Tooltip-Look für alle Apps, kein modul-eigenes Styling. */ text-transform: none; letter-spacing: normal; } /* Kleiner Pfeil unter dem Tooltip (zeigt aufs Element). Er bekommt den Schub der Blase bewusst NICHT: er zeigt weiter auf das Element, die Blase verschiebt sich darüber. */ [data-tooltip]:hover::before, [data-tooltip]:focus-visible::before { content: ''; position: absolute; left: 50%; bottom: 100%; transform: translateX(-50%); border: 4px solid transparent; border-top-color: var(--ink, #111); pointer-events: none; z-index: 2147483641; } /* Multiline-Variante (`.idf-tooltip-multiline` am Host, #313): fuer Inhalts-Tooltips (Notiz-/Herkunftstexte, z.B. preisvergleich.notizen), die laenger sind als ein Kurz-Label. `pre-line` erhaelt Zeilenumbrueche aus dem Feld und bricht sonst normal um; Breite gedeckelt, linksbuendig. Kurz-Label-Tooltips (ohne die Klasse) bleiben unveraendert nowrap. Inhalts-Tooltips sind ausserdem BETRETBAR (laengere Texte lesen/ markieren): pointer-events auf dem ::after + KEINE Hover-Luecke - der 6px-Abstand ist eine transparente border-bottom des ::after selbst (background-clip: padding-box haelt sie unsichtbar). So bleibt der Host-:hover beim Uebergang Icon -> Tooltip durchgehend aktiv; mit dem frueheren freien 6px-Spalt riss er dort ab und der Tooltip flackerte zu, sobald man ihn "greifen" wollte (#313-Nachfix). */ [data-tooltip].idf-tooltip-multiline:hover::after, [data-tooltip].idf-tooltip-multiline:focus-visible::after { white-space: pre-line; width: max-content; max-width: min(360px, 60vw); text-align: left; pointer-events: auto; bottom: 100%; border-bottom: 6px solid transparent; background-clip: padding-box; } /* Variante „unten" (`.idf-tooltip-unten` am Host): die Blase klappt unter das Element statt darueber. Wofuer: die erste Zeile in einem scrollenden Kasten. Ein Spaltenkopf ganz oben im Body eines Detail-Modals hat ueber sich keinen Platz mehr - die Blase landet unter dem Modal-Kopf und wird abgeschnitten (Joerg, 26.08.2026, Reiter „Staerken"). Seit Issue 869 ist das der SONDERFALL: `idf-tooltip.js` misst beim Hover selbst, ob die Blase ueber das Element passt, und setzt sonst `.is-tt-unten` (Regeln unten, dieselbe Wirkung). Diese feste Klasse bleibt fuer Konsumenten, die es besser wissen als die Messung - wer sie setzt, wird nicht umgeklappt. Der frueher hier notierte Einwand („eine Automatik muesste bei jedem Hover den naechsten scrollenden Vorfahren suchen") ist gegenstandslos: das tut `kasten()` in idf-tooltip.js ohnehin schon fuer die Waagerechte, es fehlte nur die Hoehe der Blase. Mit `.idf-tooltip-multiline` kombinierbar, seit es dafuer eine eigene Regel gibt (unten, Issue 861). Ohne sie zeigte die Hoverbruecke der Multiline-Variante in die falsche Richtung. */ [data-tooltip].idf-tooltip-unten:hover::after, [data-tooltip].idf-tooltip-unten:focus-visible::after, [data-tooltip].is-tt-unten:hover::after, [data-tooltip].is-tt-unten:focus-visible::after { bottom: auto; top: calc(100% + 6px); } [data-tooltip].idf-tooltip-unten:hover::before, [data-tooltip].idf-tooltip-unten:focus-visible::before, [data-tooltip].is-tt-unten:hover::before, [data-tooltip].is-tt-unten:focus-visible::before { bottom: auto; top: 100%; border-top-color: transparent; /* Ohne Hex-Fallback: die Tokens laden immer, und ein Farb-Literal waere hier ein neuer Wert neben dem Token. */ border-bottom-color: var(--ink); } /* Beide Varianten zusammen (Issue 861). `multiline` haengt die 6px-Hoverbruecke als transparente `border-bottom` an die Blase: sie sitzt oben, also zeigt die Bruecke nach unten zum Host. Klappt die Blase nach `unten`, muss sie nach OBEN zeigen, sonst reisst der Host-:hover beim Uebergang ab und der Tooltip flackert zu, sobald man ihn greifen will - genau der Fehler, den Issue 313 fuer die andere Richtung behoben hat. Erster Fall: die gesperrte Pille „Wiederkehrend" im Aufgaben-Fenster (Issue 857). Ihr Text ist drei Saetze lang, und ueber ihr liegen im Fenster nur 20 px bis zur clippenden Kante von `.idf-sa-wrap`. */ [data-tooltip].idf-tooltip-multiline.idf-tooltip-unten:hover::after, [data-tooltip].idf-tooltip-multiline.idf-tooltip-unten:focus-visible::after, [data-tooltip].idf-tooltip-multiline.is-tt-unten:hover::after, [data-tooltip].idf-tooltip-multiline.is-tt-unten:focus-visible::after { bottom: auto; /* 100%, nicht calc(100% + 6px) wie die Variante ohne multiline: den Abstand stellt hier die Bruecke (border-top) selbst. Beides zusammen ergaebe 12 px, und der Pfeil bliebe bei 100% sichtbar zurueck - genau so stand er nicht mehr am Kasten (Joerg, 29.08.2026). Die Regel fuer die Blase OBEN macht es identisch: dort `bottom: 100%`. */ top: 100%; border-bottom: 0; border-top: 6px solid transparent; } /* ------------------------------------------------------------------ */ /* Die ausgelagerte Blase (Issue 871) */ /* ------------------------------------------------------------------ */ /* Setzt `idf-tooltip.js`, wenn die Blase in ihrem klemmenden Kasten keinen Platz hat, im FENSTER aber sehr wohl. Der Fall: eine Pille im Kopf eines Detail-Fensters. Ueber dem Kopieren-Knopf liegen 24 px bis zur Kante von `.idf-sa-wrap` (overflow: hidden), die Blase braucht 30 - ueber dem Fenster selbst sind aber 56 px frei. Nach unten zu klappen waere dort die falsche Antwort (Joerg, 30.08.2026: „Auch hier nach oben"). `position: fixed` haengt die Blase aus dem Kasten aus; kein `overflow` schneidet sie mehr. Die Koordinaten kommen aus dem Script, waagerecht inklusive des Schubs, den es sonst als `--idf-tt-shift` uebergibt. NICHT betretbar: die Hoverbruecke der Multiline-Variante ist eine transparente Border an der Blase und wuerde die Koordinate verschieben. Eine ausgelagerte Blase sitzt per Definition an einer engen Stelle, und dort ist Sichtbarkeit mehr wert als Markierbarkeit. Alle vier Kombinationen ausgeschrieben, damit die Regel gegen jede Variante gewinnt, die dieselbe Eigenschaft setzt - ein `!important` oder ein doppelt notierter Klassenname waere der schlechtere Weg. */ [data-tooltip].is-tt-fixed:hover::after, [data-tooltip].is-tt-fixed:focus-visible::after, [data-tooltip].idf-tooltip-multiline.is-tt-fixed:hover::after, [data-tooltip].idf-tooltip-multiline.is-tt-fixed:focus-visible::after, [data-tooltip].idf-tooltip-unten.is-tt-fixed:hover::after, [data-tooltip].idf-tooltip-unten.is-tt-fixed:focus-visible::after, [data-tooltip].idf-tooltip-multiline.idf-tooltip-unten.is-tt-fixed:hover::after, [data-tooltip].idf-tooltip-multiline.idf-tooltip-unten.is-tt-fixed:focus-visible::after { position: fixed; left: var(--idf-tt-x, 50%); top: var(--idf-tt-y, 0); bottom: auto; /* Der Schub steckt schon in --idf-tt-x, hier nur noch das Zentrieren. */ transform: translateX(-50%); border: 0; pointer-events: none; }