/* ═══════════════════════════════════════════════════════════════════════ datenaufnahme.css · v1639 — aus der Bordkarte wird eine Zeile Marcel am 26.09.2026: „Ich fand den ersten Entwurf am besten … im Tab Objekt und im Quick Check halt die helle Version." ── WAS HIER PASSIERT, UND WAS AUSDRÜCKLICH NICHT ──────────────────── Diese Datei ändert **nur das Aussehen**. Der Markup-Vertrag, an dem die gesamte Mechanik hängt, bleibt Zeichen für Zeichen stehen: .dp-pf-tile + input[value=…] ← `selectedSources()` liest genau das #oab-run ← der Auslöser #oab-results ← wohin die Marktpreisindikation kommt .dp-pf-tile.on / .dp-pf-led ← der Zustand je Quelle > Eine Umgestaltung, die Markup anfasst, muss jede Mechanik daran neu > beweisen. Eine, die nur Flächen setzt, muss gar nichts beweisen - > sie KANN nichts kaputtmachen. Deshalb wird hier nichts entfernt, sondern ausgeblendet: Streifen, Perforation, Trennstrich und Strichcode tragen `display:none`. Wer die Bordkarte zurückwill, löscht vier Zeilen. ── WAS AUS DEM BILD BLEIBT ────────────────────────────────────────── Der QR-Code. Er ist das einzige Element der alten Karte, das etwas TUT - er führt auf DealPilot. Strichcode und Perforation codierten nichts; sie waren Zierat, und Zierat ist das, was einem Banker auffällt. ── ZWEI FLÄCHENSÄTZE ──────────────────────────────────────────────── Die Karte steht in beiden Modi. Unten deshalb erst der dunkle Satz (Vorgabe) und darunter der helle unter `body.dp-chrome-hell` - kein eigener Schalter, sondern der, den die App ohnehin führt. ── GEMESSEN VORHER ────────────────────────────────────────────────── `.dp-pfbar` war **78 px** hoch, mit Streifen (1280x78), Vorspann (151x78), Perforation, zwei Segmenten, Trenner, QR (54x68) und einer Reisszone von 208x78, in der ein Strichcode von 174x52 stand. ── v1702d: DIESE BASIS IST NICHT MEHR AN `dp-neue-karte` GEHAENGT ─── Die 50 Regeln unten standen an `body.dp-neue-karte` - einer Marke, die JEDES Layout am body setzt. Damit bekam der Streifen in Kanzlei, Tower und Aktenmappe zwangslaeufig die Zeile: 55 px, Grund rgb(19,18,16), Streifen/Perforation/Vorspann auf 0x0. Gemessen am 29.09.2026, nachdem die Kartenstil-Vorgabe schon gefallen war - der Streifen sah trotzdem nicht aus wie in der Demo, weil das Layout ihn eine Ebene tiefer noch einmal umbaut. > Zwei Ebenen bauten dieselbe Flaeche um. Die eine abzuschalten sieht > aus wie ein Fehlschlag, solange die andere noch greift. Die Marke heisst hier jetzt `body.dp-pfzeile` und wird NIRGENDS gesetzt. `dp-neue-karte` bleibt unangetastet - sie formt weiter die Objektkarten, was ein anderer Zweck ist und nicht mitfallen darf. ═══════════════════════════════════════════════════════════════════════ */ /* ── Der Zierat ──────────────────────────────────────────────────── */ body.dp-pfzeile .dp-pfbar .dp-pf-stripe, body.dp-pfzeile .dp-pfbar .dp-pf-perf, body.dp-pfzeile .dp-pfbar .dp-pf-sep, body.dp-pfzeile .dp-pfbar .dp-pf-bc{ display:none !important; } /* ── Die Zeile ───────────────────────────────────────────────────── */ body.dp-pfzeile .dp-pfbar{ display:flex !important; flex-direction:row !important; align-items:center !important; flex-wrap:wrap !important; gap:10px 14px !important; min-height:0 !important; height:auto !important; padding:8px 14px !important; border-radius:3px !important; background:#131210 !important; border:1px solid #2A2622 !important; box-shadow:none !important; } body.dp-pfzeile .dp-pf-scroll{ overflow:visible !important; } /* Der Vorspann: aus „BOARDING PASS / PRE-FLIGHT" wird eine Beschriftung. */ body.dp-pfzeile .dp-pfbar .dp-pf-lead{ display:flex !important; align-items:baseline; gap:8px; height:auto !important; min-height:0 !important; padding:0 !important; background:transparent !important; border:0 !important; flex:0 0 auto; } /* GEMESSEN nach der Richtungskorrektur: mit Vorspann brach die Zeile bei 1280 px auf zwei Reihen um (99 px). Der Vorspann sagt "Datenaufnahme" - und genau das steht drei Zeilen darueber schon als Abschnittsueberschrift. > Zwei Beschriftungen fuer dieselbe Sache kosten hier eine ganze Reihe. > Die zweite faellt. Der Knoten bleibt stehen (die Mechanik liest ihn nicht, aber jemand koennte ihn suchen) - er wird nur unsichtbar. */ body.dp-pfzeile .dp-pfbar .dp-pf-lead{ display:none !important; } body.dp-pfzeile .dp-pfbar .dp-pf-lead .bp{ display:none !important; } body.dp-pfzeile .dp-pfbar .dp-pf-lead .k{ font-family:'JetBrains Mono', ui-monospace, monospace !important; font-size:11px !important; letter-spacing:.1em !important; text-transform:uppercase !important; color:#BFB7A9 !important; height:auto !important; padding:0 !important; } body.dp-pfzeile .dp-pfbar .dp-pf-lead .s{ display:none !important; } /* Die beiden Gruppen stehen nebeneinander, nicht übereinander. */ /* GEMESSEN am 26.09.2026: hier stand nur display/align/gap - und die urspruengliche "flex-direction: column" hat ueberlebt. Die Leiste blieb deshalb 77 statt 49 px hoch, weil Beschriftung und Kacheln uebereinander standen. > DISPLAY GESETZT, RICHTUNG VERGESSEN. Heute zum zweiten Mal (vorher > die Schiene in layout-varianten.css). "display: flex" sagt nichts > ueber die Richtung - wer eine Spalte zur Zeile machen will, muss > BEIDES schreiben. Dasselbe gilt fuer "flex-wrap": ein geerbtes > "nowrap" schlaegt ein neues "wrap" ohne !important. */ body.dp-pfzeile .dp-pfbar .dp-pf-seg{ display:flex !important; flex-direction:row !important; align-items:center !important; gap:9px !important; height:auto !important; min-height:0 !important; padding:0 !important; flex:0 1 auto; min-width:0; flex-wrap:wrap; } body.dp-pfzeile .dp-pfbar .dp-pf-grouplbl{ font-family:'JetBrains Mono', ui-monospace, monospace !important; font-size:9px !important; letter-spacing:.11em !important; text-transform:uppercase !important; color:#8C8479 !important; height:auto !important; width:auto !important; padding:0 !important; margin:0 !important; white-space:nowrap; flex:0 0 auto; } body.dp-pfzeile .dp-pfbar .dp-pf-row{ display:flex !important; flex-direction:row !important; gap:6px !important; flex-wrap:wrap !important; height:auto !important; min-height:0 !important; width:auto !important; } /* Die Kacheln: Haarlinie, Gold nur am Gewählten. */ body.dp-pfzeile .dp-pfbar .dp-pf-tile{ display:flex !important; align-items:center !important; gap:7px !important; height:auto !important; min-height:0 !important; padding:6px 11px !important; margin:0 !important; border:1px solid #2A2622 !important; border-radius:2px !important; background:#0E0D0B !important; box-shadow:none !important; transform:none !important; white-space:nowrap; } body.dp-pfzeile .dp-pfbar .dp-pf-tile:hover{ border-color:var(--wl-b8932f, #b8932f) !important; } body.dp-pfzeile .dp-pfbar .dp-pf-tile.on{ border-color:var(--wl-c9a84c, #C9A84C) !important; box-shadow:inset 3px 0 0 var(--wl-c9a84c, #C9A84C) !important; } body.dp-pfzeile .dp-pfbar .dp-pf-lbl{ font-size:12.5px !important; } body.dp-pfzeile .dp-pfbar .dp-pf-logo img{ max-height:15px !important; width:auto !important; } body.dp-pfzeile .dp-pfbar .dp-pf-logo.dp{ font-size:12.5px !important; } body.dp-pfzeile .dp-pfbar .dp-pf-ic{ display:inline-flex !important; align-items:center; } body.dp-pfzeile .dp-pfbar .dp-pf-led{ width:6px !important; height:6px !important; border-radius:50% !important; margin-left:2px !important; flex:0 0 auto; } /* QR und Auslöser ganz rechts. */ body.dp-pfzeile .dp-pfbar .dp-pf-qr{ margin-left:auto !important; flex:0 0 auto; width:auto !important; height:auto !important; padding:0 !important; background:transparent !important; border:0 !important; display:flex !important; align-items:center; gap:6px; } body.dp-pfzeile .dp-pfbar .dp-pf-qr svg{ width:28px !important; height:28px !important; border-radius:2px; } body.dp-pfzeile .dp-pfbar .dp-pf-scan{ display:none !important; } /* GEMESSEN: die Reisszone blieb **208 px** breit, obwohl der Knopf darin nur 80 misst und der Strichcode auf display:none steht. Ursache war `min-width:208px` - ich hatte `width:auto` gesetzt und die Mindestbreite vergessen. > MIN-WIDTH SCHLAEGT WIDTH, genau wie min-height height schlaegt (die > Falle steht so schon in CLAUDE.md). Ein `width:auto !important` sieht > dabei aus, als haette man es geregelt. Diese 208 px waren der Grund, warum die Zeile bei 1280 px auf zwei Reihen umbrach: 1010 px Kinder plus 42 px Abstaende gegen 1028 px Platz. Ohne sie sind es 882. */ body.dp-pfzeile .dp-pfbar .dp-pf-rz{ display:flex !important; align-items:center !important; height:auto !important; min-height:0 !important; width:auto !important; min-width:0 !important; max-width:none !important; padding:0 !important; background:transparent !important; border:0 !important; flex:0 0 auto; } body.dp-pfzeile .dp-pfbar .dp-pf-rz::before, body.dp-pfzeile .dp-pfbar .dp-pf-rz::after{ display:none !important; } body.dp-pfzeile .dp-pfbar .dp-pf-launch{ height:auto !important; min-height:0 !important; padding:8px 18px !important; font-size:13px !important; border-radius:2px !important; white-space:nowrap; } /* ── Heller Satz ─────────────────────────────────────────────────── */ body.dp-chrome-hell .dp-pfbar{ background:#FFFFFF !important; border-color:#E6E1D6 !important; } body.dp-chrome-hell .dp-pfbar .dp-pf-lead .k{ color:#6B645A !important; } body.dp-chrome-hell .dp-pfbar .dp-pf-grouplbl{ color:#9A9287 !important; } body.dp-chrome-hell .dp-pfbar .dp-pf-tile{ background:#FDFCFA !important; border-color:#E6E1D6 !important; color:#1A1A18 !important; } body.dp-chrome-hell .dp-pfbar .dp-pf-tile.on{ background:#FFFDF8 !important; } body.dp-chrome-hell .dp-pfbar .dp-pf-logo.dp{ color:#F2EDE3 !important; } /* v1875: die Pille bleibt schwarz, #1A1A18 löschte „Deal" (Kontrast 1,02) */ body.dp-chrome-hell .dp-pfbar .dp-pf-qr svg rect{ fill:#fff; } /* ── Tablet und Handy ──────────────────────────────────────────────── GEMESSEN: bei 390 px stehen vier Kacheln, zwei Beschriftungen, QR und Knopf nicht in einer Zeile - sie MÜSSEN umbrechen. Der Knopf darf dabei nicht in der Mitte landen: er ist der Abschluss und gehört unten über die volle Breite, sonst sucht man ihn. */ @media (max-width:1024px){ body.dp-pfzeile .dp-pfbar{ gap:8px 12px !important; padding:8px 12px !important; } body.dp-pfzeile .dp-pfbar .dp-pf-qr{ display:none !important; } /* auf dem Tablet kein QR - man hat das Gerät ja in der Hand */ } @media (max-width:700px){ body.dp-pfzeile .dp-pfbar{ flex-direction:column !important; align-items:stretch !important; } body.dp-pfzeile .dp-pfbar .dp-pf-seg{ flex-wrap:wrap !important; } body.dp-pfzeile .dp-pfbar .dp-pf-seg{ width:100%; } body.dp-pfzeile .dp-pfbar .dp-pf-row{ width:100%; } body.dp-pfzeile .dp-pfbar .dp-pf-tile{ flex:1 1 calc(50% - 3px) !important; justify-content:center !important; } body.dp-pfzeile .dp-pfbar .dp-pf-rz{ width:100%; } body.dp-pfzeile .dp-pfbar .dp-pf-launch{ width:100% !important; } } /* GEMESSEN: die Status-LED einer GEWAEHLTEN Kachel war rgb(241,242,244) - nahezu weiss, auf hellem Grund also unsichtbar. Der Zustand stand damit nur noch in der Goldkante. Gruen und Rot bleiben in jeder Marke gleich (CLAUDE.md: "Statusfarben nie tokenisieren") - deshalb steht hier ein Literal und KEIN --wl-Token. Der Gold-Waechter kennt diese beiden Toene nicht. */ body.dp-pfzeile .dp-pfbar .dp-pf-led{ background:#CEC6B6 !important; } body.dp-pfzeile .dp-pfbar .dp-pf-tile.on .dp-pf-led{ background:#3FA56C !important; } body:not(.dp-chrome-hell) .dp-pfbar .dp-pf-tile:not(.on) .dp-pf-led{ background:#2A2622 !important; } /* v1870a: nur AUS - die Regel galt auch fuer gewaehlte Kacheln, Marcel: "die Lampe ist schwarz" */ /* Auf dem Handy steht die erste Kachel allein in ihrer Gruppe - sie soll dann die volle Breite nehmen wie die Gruppe darunter, sonst sieht es aus, als fehle etwas daneben. */ @media (max-width:700px){ body.dp-pfzeile .dp-pfbar .dp-pf-seg:first-of-type .dp-pf-tile{ flex:1 1 100% !important; } } /* GEMESSEN: der Ausloeser blieb 50 px hoch und machte die ganze Zeile 76 statt 54 px. Ursache: `#oab-run` traegt `min-height:50px`, und ein ID-Selektor (1,0,0) schlaegt jede Klassenregel (0,2,0) - auch mit !important, denn !important entscheidet erst BEI GLEICHER Herkunft, nicht ueber die Spezifitaet hinweg. > ID-Selektoren sind der blinde Fleck aus FALLEN.md. Wer eine Klasse > schreibt und sich wundert, sucht als erstes eine ID. Deshalb hier mit ID: `.dp-pfbar button#oab-run` ist (1,1,1). */ body.dp-pfzeile .dp-pfbar button#oab-run, body.dp-pfzeile .dp-pfbar #oab-run.dp-pf-launch{ min-height:0 !important; height:auto !important; padding:8px 18px !important; font-size:13px !important; border-radius:2px !important; } @media (max-width:700px){ body.dp-pfzeile .dp-pfbar button#oab-run{ width:100% !important; } } /* ═══ QUICK-CHECK ═══════════════════════════════════════════════════ GEMESSEN am 26.09.2026: der Quick-Check ist eine EIGENE App in einem iframe (`quickcheck-app.html`). Deshalb hat ihn weder diese Datei noch das Ausblenden der Bewertungspartner aus v1637 erreicht - dort standen Sprengnetter und PriceHubble unveraendert auf der Karte. > Ein iframe ist ein eigenes Dokument. Eine Regel, die in der > Hauptanwendung wirkt, wirkt darin GAR NICHT - und das sieht man > nur, wenn man hineinsieht. Die Karte dort traegt dasselbe Markup (`.dp-pfbar`, `.dp-pf-tile`), also greift alles oben, sobald diese Datei auch im iframe geladen ist. Nur die beiden Partnerkacheln brauchen eine eigene Zeile, weil sie dort STATISCH im HTML stehen statt aus JavaScript zu kommen. Ausgeblendet, nicht geloescht: `QcApp.sprengnetter()` und `QcApp.priceHubble()` bleiben vollstaendig. Wer sie zurueckwill, loescht diese eine Regel. */ body.dp-pfzeile .dp-pfbar .dp-pf-tile[data-src="spr"], body.dp-pfzeile .dp-pfbar .dp-pf-tile[data-src="ph"]{ display:none !important; } /* ═══ DAS QUICK-BOARDING-COCKPIT ════════════════════════════════════ Marcel: „im Quick Check … dass du das so umbaust, dass sich das aehnelt" - gemeint sind die Score-Karten im Reiter Bewertung, die seit v1640 dauerhaft weiss sind. GEMESSEN: `#qb-bp` ist rgb(10,10,10), 1320x277. Sein rechter Abriss `#qb-stub` war schon weiss - die Karte war also ohnehin zweifarbig. Jetzt wird der linke Teil nachgezogen, mit derselben Grammatik wie `.dpsh-pass`: weisser Koerper, Haarlinie, und das Kopfband als EINZIGER Farbakzent. Der Verlauf traegt die Whitelabel-Token, faerbt sich beim Mandanten also mit. */ #qb-bp{ background:#FFFFFF !important; border:1px solid #E6E0D3 !important; box-shadow:0 1px 2px rgba(42,39,39,.05) !important; color:#1A1A18 !important; } #qb-bp .qb-main{ background:#FFFFFF !important; color:#1A1A18 !important; } #qb-bp .ghead{ background:linear-gradient(110deg, var(--wl-e8cc7a, #E8CC7A), var(--wl-c9a84c, #C9A84C) 55%, var(--wl-b8932f, #b8932f)) !important; color:#141210 !important; } #qb-bp .ghead *{ color:#141210 !important; } /* Die Textklassen, die gemessen hell gesetzt waren. Einzeln benannt - ein Sammelselektor auf alle Kinder wuerde auch die Balken und den Zeiger des Tachos treffen, und die tragen Statusfarben. */ #qb-bp .mbody, #qb-bp .kt, #qb-bp .k, #qb-bp .r, #qb-bp .cbars, #qb-bp .cb, #qb-bp .dialwrap, #qb-bp .qcb-hinweis, #qb-bp .qcb-hinweis-satz, #qb-bp .qcb-rechenweg, #qb-bp .qcb-rows, #qb-bp .mbody b, #qb-bp .kt b{ color:#1A1A18 !important; } #qb-bp .qcb-hinweis{ background:#F7F5F1 !important; } #qb-bp .contrail{ opacity:.25 !important; } /* ── Im Quick-Check gilt der helle Satz IMMER ──────────────────────── GEMESSEN: das QC-Dokument traegt `html.qc-app` (fest im Dokument) und body-Klassennamen - `body.dp-chrome-hell` gibt es dort nicht und kann es nicht geben, weil der Skin-Schalter in der Hauptanwendung sitzt. Die Zeile blieb deshalb rgb(19,18,16) auf einer inzwischen weissen Karte. > Zwei Dokumente, ein Aussehen: die Bedingung, die im einen Dokument > den hellen Satz einschaltet, muss im anderen eine ANDERE sein. */ html.qc-app .dp-pfbar{ background:#FFFFFF !important; border-color:#E6E1D6 !important; } html.qc-app .dp-pfbar .dp-pf-grouplbl{ color:#9A9287 !important; } html.qc-app .dp-pfbar .dp-pf-tile{ background:#FDFCFA !important; border-color:#E6E1D6 !important; color:#1A1A18 !important; } html.qc-app .dp-pfbar .dp-pf-tile.on{ background:#FFFDF8 !important; } html.qc-app .dp-pfbar .dp-pf-logo.dp{ color:#F2EDE3 !important; } /* v1875: Marcel „da ist das Deal in Grau" — dasselbe wie oben, im QuickBoarding */ html.qc-app .dp-pfbar .dp-pf-led{ background:#CEC6B6 !important; } html.qc-app .dp-pfbar .dp-pf-tile.on .dp-pf-led{ background:#3FA56C !important; } /* ── Kontrast im Cockpit ───────────────────────────────────────────── GEMESSEN auf weissem Grund: Beschriftungen standen auf rgb(154,144,128) - ein Ton, der fuer dunklen Grund gemacht ist und auf Papier bei knapp 2:1 Kontrast liegt. Werte standen auf dem Goldton rgb(201,168,76), der auf Weiss noch schlechter faellt. > Ein heller Grauton ist auf Schwarz zurueckhaltend und auf Weiss > unlesbar. Farben, die den Grund wechseln, muessen mitwechseln. */ #qb-bp .cl, #qb-bp .l, #qb-bp .h{ color:#6B645A !important; } #qb-bp .cv, #qb-bp .v{ color:#1A1A18 !important; font-weight:600; } #qb-bp summary{ color:var(--wl-b8932f, #b8932f) !important; } #qb-bp .qcb-hinweis b, #qb-bp .qcb-hinweis-satz{ color:#1A1A18 !important; } /* ═══ DIE CHECKLISTE BEIM ANLEGEN (v1643) ═══════════════════════════ */ .dpnq-ov{ position:fixed; inset:0; z-index:2147482400; display:grid; place-items:center; background:rgba(18,16,14,.5); padding:20px; } .dpnq-k{ width:min(540px,100%); background:#FDFCFA; border:1px solid #CEC6B6; border-radius:3px; box-shadow:0 26px 70px -30px rgba(0,0,0,.7); padding:18px 20px 16px; font-family:'Inter', system-ui, sans-serif; color:#1A1A18; } .dpnq-kopf{ display:flex; align-items:center; justify-content:space-between; } .dpnq-kopf b{ font-family:'Space Grotesk', system-ui, sans-serif; font-size:17px; } .dpnq-x{ border:0; background:transparent; font-size:20px; line-height:1; cursor:pointer; color:#9A9287; padding:2px 6px; } .dpnq-x:hover{ color:#1A1A18; } .dpnq-vor{ margin:4px 0 14px; font-size:13px; color:#6B645A; } .dpnq-liste{ display:grid; gap:7px; } .dpnq-z{ display:flex; align-items:flex-start; gap:11px; padding:10px 13px; border:1px solid #E6E1D6; background:#fff; border-radius:2px; cursor:pointer; } .dpnq-z:hover{ border-color:var(--wl-b8932f, #b8932f); } .dpnq-z.an{ border-color:var(--wl-c9a84c, #C9A84C); box-shadow:inset 3px 0 0 var(--wl-c9a84c, #C9A84C); background:#FFFDF8; } .dpnq-z input{ width:15px; height:15px; margin-top:2px; flex:0 0 auto; accent-color:var(--wl-b8932f, #b8932f); } .dpnq-t{ min-width:0; line-height:1.3; } .dpnq-t b{ display:block; font-size:13.5px; font-weight:600; } .dpnq-t small{ display:block; font-size:11.5px; color:#6B645A; margin-top:1px; } .dpnq-fuss{ margin:13px 0 0; font-size:12px; color:#6B645A; } .dpnq-fuss b{ color:#1A1A18; } .dpnq-knoepfe{ display:flex; align-items:center; gap:8px; margin-top:14px; flex-wrap:wrap; } .dpnq-merk{ display:flex; align-items:center; gap:6px; font-size:12px; color:#6B645A; cursor:pointer; margin-right:auto; } .dpnq-merk input{ width:14px; height:14px; accent-color:var(--wl-b8932f, #b8932f); } .dpnq-b{ font-family:inherit; font-size:13px; padding:9px 16px; border-radius:2px; border:1px solid #CEC6B6; background:#fff; color:#1A1A18; cursor:pointer; } .dpnq-b:hover{ border-color:var(--wl-b8932f, #b8932f); } .dpnq-haupt{ background:linear-gradient(110deg, var(--wl-e8cc7a, #E8CC7A), var(--wl-c9a84c, #C9A84C) 55%, var(--wl-b8932f, #b8932f)); color:#141210; border-color:transparent; font-weight:600; } @media (max-width:560px){ .dpnq-knoepfe{ flex-direction:column; align-items:stretch; } .dpnq-merk{ margin-right:0; margin-bottom:4px; } .dpnq-b{ width:100%; } } /* ═══════════════════════════════════════════════════════════════════════ v1651 · DIE ZWEITE ACHSE — Trichter und Bordkarte Alles oben ist die BASIS (`body.dp-neue-karte`, Entwurf 1: die Zeile). Was jetzt folgt, baut darauf auf und ordnet um. Ohne gewaehlten Stil greift nichts davon - der Istzustand bleibt bitgenau. Gesetzt wird der Stil von `js/karten-stil.js` als `data-dp-kartenstil` am ``. Am `` und nicht am ``, damit er schon steht, bevor der Koerper gebaut ist. ═══════════════════════════════════════════════════════════════════════ */ /* ── ENTWURF 4 · TRICHTER ────────────────────────────────────────────── Links die Quellen, rechts was daraus wird. Der Entwurf beantwortet die Frage, die Neue wirklich haben: „und was passiert dann?" Gebaut als Gitter mit ZWEI Spalten. Alle vorhandenen Kinder bleiben in Spalte 1 - `.dpk-ertrag` ist das einzige, das in Spalte 2 gesetzt wird und ueber alle Zeilen spannt (`grid-row:1 / -1`). > Ich habe zuerst `grid-template-areas` versucht. Das scheitert, > weil es in der Leiste ZWEIMAL `.dp-pf-seg` gibt - zwei Elemente in > einem Bereich stapeln uebereinander, statt untereinander zu > stehen. Mit Auto-Platzierung in Spalte 1 passiert genau das > Richtige, ohne jedes Kind einzeln zu benennen. */ /* Alles Vorhandene bleibt links. */ /* Die linke Spalte bekommt ihr eigenes Polster - das Gitter hat keins, sonst saesse der Trennstrich zur rechten Spalte im Polster. */ /* Der Trenner zwischen den beiden Quellgruppen wird wieder sichtbar - im Trichter hat er Platz und Bedeutung. */ /* Der QR bleibt links unten, klein und ruhig. */ /* Die rechte Spalte. */ /* Der Abrufknopf sitzt im Trichter UNTER dem Ergebnis - dort, wo der Blick nach dem Lesen ankommt. `margin-top:auto` schiebt ihn ans untere Ende, egal wie hoch die linke Spalte geworden ist. */ /* ── SCHMALE SCHIRME ────────────────────────────────────────────────── Der Trichter braucht Breite; unter 820 px bricht er auf zwei Bloecke um - so steht es schon im Entwurf. Die Bordkarte legt ihren Abschnitt unter die Quellen und behaelt die Perforation als WAAGERECHTE Linie: ihre Bedeutung ist „hier wird getrennt", nicht „hier ist rechts". */ /* v1985: hier stand eine @media (max-width:820px) mit zwei Trichter-Regeln. Mit dem Entwurf sind beide gefallen, und ein leerer Medienblock ist kein Platzhalter, sondern eine Frage fuer den naechsten Leser. */ /* ═══════════════════════════════════════════════════════════════════════ v1651b · drei Nachbesserungen, alle gemessen ═══════════════════════════════════════════════════════════════════════ */ /* ── (1) EIN BESTEHENDER FEHLER, DER NICHT VOM STIL KOMMT ───────────── `.dp-pf-mtrigger` ist der Aufklapper, der die Datenaufnahme auf dem Handy zu einem Knopf zusammenfaltet. `style.css:33229` versteckt ihn und blendet ihn erst unter 640 px ein. Gemessen bei 1706 px Fensterbreite: er steht da, 283 px breit. Ursache ist eine Sammelregel: `.sec button:not(.dp-tip):not(.tab):not(.sb-action-btn)… { display:inline-flex !important }` Sie trifft JEDEN Knopf in einem Abschnitt - auch einen, den ihr Autor nie gesehen hat - und schlaegt mit `!important` das `display:none`, das keins hat. > Eine Ausnahmeliste aus acht `:not()` ist keine Praezision, sondern > eine Wette darauf, dass niemand einen neunten Knopf baut. Hier wird nicht die Sammelregel angefasst - sie haengt an Dutzenden Stellen - sondern der eine Knopf gezielt zurueckgeholt. */ .dp-pf-mtrigger{ display:none !important; } @media (max-width: 640px){ .dp-pf-mtrigger{ display:flex !important; } } /* ── (2) DER TRICHTER: GRUPPEN NACH LINKS UND UNTEREINANDER ─────────── Gemessen: `.dp-pf-seg` traegt aus der Zeilen-Basis `flex-direction:row; justify-content:center`. In einer 55-px-Leiste ist das richtig - dort sollen die Kacheln mittig sitzen. Im Trichter klebt dadurch alles an der rechten Kante einer 982 px breiten Spalte. `display` war gesetzt, die RICHTUNG nicht. Derselbe Fehler wie bei `.dpl-schiene` in v1649. */ /* Der Kopf der linken Spalte - der Gegenpart zu „Was dabei herauskommt". Ohne ihn ist der Trichter nur ein Kasten mit einer Trennlinie; mit ihm beantwortet er die Frage, fuer die er gebaut wurde. Gefuehrt wird er im Pseudoelement, damit der Knoten, an dem `object-actions.js` haengt, unangetastet bleibt. */ /* Die erste Gruppe rueckt dafuer nach oben - der Kopf traegt jetzt den Abstand. */ /* ── (3) DER ABRUFKNOPF, UND WARUM MEINE REGEL VERLOR ───────────────── Gemessen: der Knopf blieb 84 px breit, obwohl `.dpk-ertrag .dp-pf-launch{width:100% !important}` dasteht. `object-actions.js:118` setzt ihn als `#oab-run.dp-pf-launch` - eine ID. **Bei ID gegen Klasse hilft `!important` nicht**, die Spezifitaet entscheidet zuerst. Die Falle steht in CLAUDE.md, und ich bin zum zweiten Mal hineingelaufen (nach `#oab-run{min-height}` in v1648). Deshalb traegt der Selektor die ID mit. */ html[data-dp-pfstil]:not([data-dp-kartenstil]) .dp-pf-rz #oab-run.dp-pf-launch, html[data-dp-kartenstil="bordkarte"] .dp-pf-rz #oab-run.dp-pf-launch{ width:100% !important; min-width:0 !important; display:flex !important; justify-content:center !important; } html[data-dp-pfstil]:not([data-dp-kartenstil]) .dp-pfbar .dp-pf-rz, html[data-dp-kartenstil="bordkarte"] .dp-pfbar .dp-pf-rz{ width:100% !important; box-sizing:border-box !important; } /* ═══════════════════════════════════════════════════════════════════════ v1651c · zwei Ursachen, beide gemessen ── (1) `grid-row: 1 / -1` SPANNT NICHT, WENN ES KEIN EXPLIZITES GITTER GIBT ─────────────────────────────────────────────────── Gemessen: `.dp-pf-lead` war 189 px hoch - auf den Pixel genau so hoch wie `.dpk-ertrag` daneben. Beide standen in Gitterzeile 1. Ursache: `-1` zaehlt die Linien des EXPLIZITEN Gitters. Ich hatte nur `grid-template-columns` gesetzt, keine `grid-template-rows` - das explizite Gitter hat also NULL Zeilen, und `1 / -1` fiel auf `1 / 1` zusammen. Statt ueber alles zu spannen, stand der Ertragsblock in Zeile 1 und blies sie auf seine eigene Hoehe auf. > Eine Angabe, die auf ein Gitter zeigt, das es nicht gibt, ist > nicht falsch - sie ist LEER. Und leer sieht aus wie gesetzt. `span 50` ist unabhaengig vom expliziten Gitter. Die Leiste hat acht Kinder; fuenfzig ist kein Rechenwert, sondern ein Deckel. ── (2) DER AUFKLAPPER: `:not()` ERBT DIE SPEZIFITAET ──────────────── Mein `.dp-pf-mtrigger{display:none !important}` aus v1651b hat NICHT gewirkt - gemessen, `inline-flex`, 283 px. `.sec button:not(.dp-tip):not(.tab):not(.sb-action-btn)…` sind acht Klassen plus ein Element, also (0,8,1). Meine eine Klasse ist (0,1,0). **Zwischen zwei `!important` entscheidet die Spezifitaet**, und sieben davon stecken in den `:not()`. Behoben an der richtigen Stelle: `style.css:30198` fuehrt seine Ausnahmen selbst, und der Aufklapper ist eine. Ein neuntes `:not()` statt eines Gegengewichts hier. ═══════════════════════════════════════════════════════════════════════ */ /* Der Kopf der linken Spalte darf nicht mitwachsen. */ /* Der Trichter: der Abrufknopf klebte am unteren Rand, weit unter den drei Ergebniszeilen. `margin-top:auto` schiebt ihn ans Ende des Blocks - aber der Block ist so hoch wie die linke Spalte, nicht so hoch wie sein Inhalt. Ein fester Abstand haelt ihn dort, wo der Blick nach der letzten Zeile ankommt. */ /* Und ein Atemzug zwischen dem Kopf und der ersten Gruppe. */ /* ═══════════════════════════════════════════════════════════════════════ v1659b · DIE KARTEI — ENTWURF 2, AN DER DEMO AUSGEMESSEN Marcel: „bei der Datenaufnahme haette ich eigentlich gerne die Kartei, nur dass der Abruf-Button mit in die Kartei-Seite reinkommt, aber ganz auf die rechte Seite." Gemessen in der Demo (`entwurf-aktionsbox.html`, „2 · Kartei"): Karte bg weiss · Rahmen 1px rgb(230,225,214) · radius 2px overflow hidden · 1090x192 Kopfzeile flex · bg rgb(244,242,237) · Polster 10/15 Trennlinie unten 1px · gap 10 · 43 px hoch Quellen flex · durchsichtig · Polster 14/15 · gap 9 · 92 px Fusszeile Trennlinie oben · Knopf RECHTS · 55 px Der Knopf steht im Entwurf bereits in einer Fusszeile ganz rechts - genau das, was Marcel beschreibt. Es war also kein Umbau noetig, sondern der Entwurf, den ich noch nicht gebaut hatte. ═══════════════════════════════════════════════════════════════════════ */ html[data-dp-kartenstil="kartei"] .dp-pfbar{ display:flex !important; flex-direction:column !important; flex-wrap:nowrap !important; align-items:stretch !important; background:#FFFFFF !important; border:1px solid #E6E1D6 !important; border-radius:2px !important; overflow:hidden !important; padding:0 !important; gap:0 !important; height:auto !important; min-height:0 !important; } /* Die Kopfzeile: Marke, Titel, rechts die Zaehlung. */ html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-lead{ display:flex !important; order:1 !important; flex-direction:row !important; align-items:center !important; gap:10px !important; padding:10px 15px !important; margin:0 !important; background:#F4F2ED !important; border-bottom:1px solid #E6E1D6 !important; height:auto !important; width:auto !important; } html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-lead .bp{ display:inline !important; font-size:0 !important; font-family:'Space Grotesk',sans-serif; font-weight:700; letter-spacing:0; text-transform:none; color:#1A1A18; background:none !important; border:0 !important; padding:0 !important; } html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-lead .bp::after{ content:'DealPilot'; font-size:14px; } html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-lead .k{ display:inline !important; font-size:13.5px !important; font-weight:600 !important; color:#1A1A18 !important; letter-spacing:0 !important; text-transform:none !important; } html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-lead .s{ display:none !important; } /* Rechts die Zaehlung - `karten-stil.js` setzt sie als Attribut. */ html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-lead::after{ content:attr(data-dpk-wahl); margin-left:auto; font-family:"JetBrains Mono",ui-monospace,monospace; font-size:10px; letter-spacing:.07em; text-transform:uppercase; color:#9A9287; } /* Die Quellen. */ html[data-dp-kartenstil="kartei"] .dp-pfbar > .dp-pf-seg{ order:2 !important; display:flex !important; flex-direction:column !important; align-items:flex-start !important; padding:14px 15px 0 !important; margin:0 !important; background:transparent !important; } html[data-dp-kartenstil="kartei"] .dp-pfbar > .dp-pf-seg:last-of-type{ padding-bottom:14px !important; } html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-grouplbl{ display:block !important; margin-bottom:7px !important; } html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-row{ display:flex !important; gap:9px !important; flex-wrap:wrap !important; justify-content:flex-start !important; width:100% !important; } html[data-dp-kartenstil="kartei"] .dp-pfbar > .dp-pf-sep{ display:none !important; } html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-stripe, html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-perf, html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-bc, html[data-dp-kartenstil="kartei"] .dp-pfbar > .dp-pf-qr{ display:none !important; } /* Die Fusszeile mit dem Abrufknopf ganz rechts. */ html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-rz{ order:3 !important; display:flex !important; flex-direction:row !important; align-items:center !important; width:auto !important; min-width:0 !important; flex:0 0 auto !important; /* v1682b: `margin:0` stand hier und hat jedes spaetere `margin-left:auto` ueberschrieben — auch das aus v1682, obwohl das eine hoehere Spezifitaet hatte: die Kurzschrift setzt ALLE vier Seiten, und sie stand mit `!important` in derselben Datei weiter oben. Der Abruf-Bereich gehoert IMMER nach rechts; das steht jetzt hier, wo auch der Rest seiner Lage steht, statt als Gegenregel woanders. */ padding:10px 15px !important; margin:0 0 0 auto !important; background:transparent !important; border-top:1px solid #E6E1D6 !important; } html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-rz::before{ content:'Adresse und Wohnfläche genügen für den Start.'; font-size:12.5px; color:#8A8272; } /* v1682b — DIE ID GALT NUR FUER EINE DER BEIDEN LEISTEN. Hier stand `#oab-run.dp-pf-launch`. Der Abruf-Knopf heisst aber nur im Objekt-Tab so; im QuickBoarding traegt er `.qc6-run`. Die Regel hat den Knopf also in der einen Leiste nach rechts geschoben und in der anderen nie — genau der Unterschied, den Marcel gesehen hat („der Abruf-Button ist ruebergerutscht"). `:is(#oab-run, .qc6-run)` erbt die Spezifitaet seines STAERKSTEN Arguments, hier also die der ID. Damit bleibt die Regel genau so stark wie vorher und trifft jetzt beide. */ html[data-dp-kartenstil="kartei"] .dp-pfbar :is(#oab-run, .qc6-run).dp-pf-launch{ margin-left:auto !important; width:auto !important; min-width:0 !important; } /* ── v1660 · DIE KARTEI-KOPFZEILE, MIT DER ID DER LEISTE ───────────── Gemessen: die Kopfzeile stand ZENTRIERT (`.bp` bei x=1105 in einer 1278 px breiten Zeile), `.bp` zeigte weiterhin „BOARDING PASS", und die Zaehlung fehlte. Alle drei Regeln aus v1659b waren richtig geschrieben und haben verloren - dieselbe Ursache wie ueberall an diesem Tag: eine `:is()`-Regel mit ID-Spezifitaet. **Die Leiste heisst `#oab-bar`**, und mit ihrer eigenen ID im Selektor ist die Frage erledigt. > Wenn ein Element eine ID hat, ist sie das kuerzeste Mittel gegen > jede fremde Regel. Man muss sie nur benutzen. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-lead{ justify-content:flex-start !important; text-align:left !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-lead .bp{ font-size:0 !important; line-height:0 !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-lead .bp::after{ content:'DealPilot' !important; font-size:14px !important; line-height:1.2 !important; font-family:'Space Grotesk',sans-serif; font-weight:700; letter-spacing:.01em; color:#1A1A18; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-lead .k{ font-size:13.5px !important; font-weight:600 !important; color:#1A1A18 !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-lead::after{ content:attr(data-dpk-wahl) !important; margin-left:auto !important; font-family:"JetBrains Mono",ui-monospace,monospace; font-size:10px; letter-spacing:.07em; text-transform:uppercase; color:#9A9287; } /* Die Quellgruppen linksbuendig - sie erbten dieselbe Zentrierung. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg{ justify-content:flex-start !important; align-items:flex-start !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-row{ justify-content:flex-start !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-rz{ justify-content:flex-start !important; } /* ── v1661 · DIE QUELLEN NEBENEINANDER, DER KNOPF DANEBEN ──────────── Marcel: „bei der Datenaufnahme passt noch gar nicht die Marktbewertung mit der Formatierung. Das ist untereinander. Das sollte ja als Streifen nebeneinander und auch der Abruf-Button daneben." Gemessen: die beiden Quellgruppen („Marktbewertung" und „Daten uebernehmen aus") standen als eigene Bloecke untereinander, der Knopf in einer dritten Zeile. Das kostete 266 px Hoehe. Jetzt ein Streifen: Kopfzeile oben ueber die volle Breite, darunter die beiden Gruppen NEBENEINANDER, und der Abrufknopf rechts in derselben Zeile. > Eine Zeile sagt „das gehoert zusammen und passiert gleichzeitig". > Drei Zeilen sagen „erst das, dann das, dann das" - und so ist es > nicht: man waehlt Quellen und drueckt ab. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar{ flex-direction:row !important; flex-wrap:wrap !important; align-items:stretch !important; } /* Die Kopfzeile behaelt die volle Breite. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-lead{ flex:1 0 100% !important; width:100% !important; } /* Die beiden Gruppen teilen sich den Rest, der Knopf bekommt sein eigenes Mass. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg{ flex:1 1 260px !important; min-width:0 !important; padding:12px 15px !important; border-right:1px solid #E6E1D6 !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg:last-of-type{ border-right:0 !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-rz{ flex:0 0 auto !important; border-top:0 !important; border-left:1px solid #E6E1D6 !important; align-items:center !important; padding:12px 15px !important; } /* Der erklaerende Satz gehoert bei dieser Anordnung nicht neben den Knopf - dort steht er quer. Er faellt weg; die Gruppennamen sagen dasselbe. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-rz::before{ content:none !important; } /* Unter 900 px untereinander - nebeneinander waere dort gequetscht. */ @media (max-width: 900px){ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg{ flex:1 0 100% !important; border-right:0 !important; border-bottom:1px solid #E6E1D6 !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-rz{ flex:1 0 100% !important; border-left:0 !important; border-top:1px solid #E6E1D6 !important; } } /* ── v1662 · VIER QUELLEN, EINE REIHE ──────────────────────────────── Marcel: „bei der Datenaufnahme, das passt noch gar nicht mit der Marktbewertung, mit der Formatierung. Das ist untereinander." v1661 hatte die beiden GRUPPEN nebeneinander gestellt und ich hatte das fuer erledigt gehalten - gemessen: `.dp-pf-seg` bei x=550 und x=1130, gleiche Hoehe. Marcel meinte aber das, was IN den Gruppen passiert. Gemessen an der Vorlage (`entwurf-aktionsbox.html`, Entwurf 2): die Demo-Kartei hat **keine Gruppentitel**. Sie hat EINE Reihe mit VIER Quellen - `display:flex; flex-direction:row; gap:9px; padding:14px 15px` - und darunter die Fusszeile mit dem Knopf. Chip: 172x64, Grund `#FFFDF8`, Rahmen 1 px Gold wenn gewaehlt, Radius 2 px, Polster 11/13. Unsere Leiste teilt dieselben vier Quellen in zwei Gruppen mit einem Titel DARUEBER. Genau dieser Titel erzeugt das „untereinander": Titel, darunter Chips - zweimal nebeneinander. > Eine Ueberschrift ueber zwei Chips ordnet nichts, sie halbiert > nur die Reihe. Vier gleichrangige Quellen brauchen keine > Einteilung, sie brauchen eine Zeile. Die Gruppen bleiben im DOM (sie werden woanders gebaut), treten aber auf Inhaltsbreite zurueck; ihre Titel verschwinden. Das Ergebnis ist die Reihe der Demo, ohne einen fremden Baum umzuhaengen. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-grouplbl{ display:none !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg{ flex:0 1 auto !important; padding:14px 0 14px 0 !important; border-right:0 !important; align-items:center !important; justify-content:center !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg:first-of-type{ padding-left:15px !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg + .dp-pf-seg{ padding-left:9px !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-row{ width:auto !important; flex-wrap:nowrap !important; align-items:stretch !important; } /* Alle vier Chips gleich hoch und gleich gefasst - in einer Reihe faellt jeder Unterschied sofort auf. Die Masse sind die der Demo, ohne Unterzeile also flacher. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-tile{ min-height:42px !important; align-items:center !important; padding:0 13px !important; border-radius:2px !important; border:1px solid #E6E1D6 !important; background:#FFFFFF !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-tile:has(input:checked), html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-tile.an{ border-color:var(--wl-c9a84c, #C9A84C) !important; background:#FFFDF8 !important; } /* Der Knopf rechts an den Rand - ohne diesen Schub steht er direkt neben dem letzten Chip, mitten in der Zeile. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-rz{ margin-left:auto !important; border-left:0 !important; } @media (max-width: 900px){ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-row{ flex-wrap:wrap !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg{ padding-left:15px !important; padding-right:15px !important; justify-content:flex-start !important; align-items:flex-start !important; } } /* ── v1663 · „DEAL" WAR NICHT GRAU, SONDERN UNSICHTBAR ─────────────── Marcel: „bei der DealPilot Datenaufnahme, da ist das Deal in einem Grau, das muesste auch in hell sein, wie oben das Logo links." Gemessen am Chip `.dp-pf-logo.dp`: Grund rgb(5,5,5) die schwarze Pille Text rgb(26,26,24) „Deal" -> Kontrast 1,02 rgb(232,204,122) „Pilot" -> liest sich Das ist kein Grauton, das ist ein Wort, das nicht da ist. Ursache ist eine Hellmodus-Regel (`body.dp-chrome-hell … {color:#1A1A18}`), die annimmt, der Chip stuende auf hellem Grund - er behaelt aber seine schwarze Pille. > Eine Hellmodus-Regel, die nur die SCHRIFT umfaerbt, setzt voraus, > dass auch die Flaeche mitgeht. Tut sie es nicht, loescht die Regel > das Wort. Die Marke oben links ist der Massstab, gemessen: `.dpl-wm` = `#F2EDE3`, sein `` = `#b8932f`. Der Chip bekommt dasselbe Creme; das Gold des `` bleibt das hellere `#E8CC7A`, weil es auf Schwarz steht und nicht auf Creme. */ html[data-dp-kartenstil] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-logo.dp{ color:#F2EDE3 !important; } html[data-dp-kartenstil] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-logo.dp b{ color:var(--wl-e8cc7a, #E8CC7A) !important; } /* ── v1668 · DIE KARTEI BEKOMMT ZURÜCK, WAS DIE KARTE HAT ──────────── Marcel: „So wie im Design heute muss auch ein Trennstrich zwischen der Marktbewertung und dem Daten-übernehmen-aus sein. Auch die Überschrift muss mit drauf sein. Zwischen den Buttons muss auf jeden Fall Abstand sein. Dann fehlt der QR-Code." Die Vorlage ist der Auslieferungszustand, gemessen an `#oab-bar` (1280x78): .dp-pf-lead 149x78 dunkler Kopfblock .dp-pf-perf 1x78 Perforation .dp-pf-seg 101x78 „Marktbewertung" ÜBER dem Chip .dp-pf-sep 1x78 rgba(5,5,5,.22) <- der Trennstrich .dp-pf-seg 438x78 „Daten übernehmen aus" + drei Chips a.dp-pf-qr 54x68 <- der QR .dp-pf-rz 208x78 Barcode + Abrufknopf **Ich hatte in v1662 drei davon ausgeblendet** — Gruppentitel, Trennstrich und QR — weil Marcel damals sagte, die Quellen stünden „untereinander". Das stimmte, aber die Ursache war die Anordnung, nicht die Beschriftung. > Wer auf „das steht untereinander" mit „dann nehmen wir die > Überschriften weg" antwortet, behebt das Symptom und nimmt dabei > die Gliederung mit. Die Reihe war das Ziel, nicht die Kahlheit. Sie kommen zurück — die Reihe bleibt. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-grouplbl{ display:block !important; margin:0 0 6px !important; font-family:"JetBrains Mono",ui-monospace,monospace !important; font-size:9px !important; letter-spacing:.9px !important; text-transform:uppercase !important; /* v1954a: #9A9287 auf Weiss ergab Kontrast 3.07 - unter dem Minimum von 4,5, und das bei 9 px Versalien mit 0.9 px Sperrung. Gefunden beim Rundlauf ueber alle Stile, NACHDEM Buetten behoben war: derselbe Mangel, andere Datei-Stelle. Ein Durchlauf ueber alle Faelle findet, was eine Einzelmeldung nicht nennt. #6E685F bringt 5,51 und bleibt warmgrau. */ color:#6E685F !important; } /* Der Trennstrich zwischen den beiden Gruppen — dieselbe Haarlinie wie auf der Karte, nur auf die Höhe der Kartei gebracht. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-sep{ display:block !important; flex:0 0 1px !important; width:1px !important; align-self:stretch !important; margin:14px 14px !important; background:#E6E1D6 !important; } /* Die Gruppen brauchen jetzt wieder Kopfhöhe — und Luft zwischen den Chips. Marcel ausdrücklich: „zwischen den Buttons muss auf jeden Fall Abstand sein." */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg{ flex-direction:column !important; align-items:flex-start !important; justify-content:center !important; padding:12px 0 14px !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-row{ gap:12px !important; } /* ── v1668b · DER QR UND DIE GOLDENE KANTE ─────────────────────────── Marcel: „Dann fehlt der QR-Code. Der QR-Code müsste auch mittig platziert werden, in Richtung Abruf-Button, aber natürlich auch mit Abstand. Hinten am Abruf-Button ist irgend so eine goldene Kante, das muss noch weg." Gemessen in der Kartei: a.dp-pf-qr 0x0 <- ausgeblendet .dp-pf-rz border-right 1px rgb(201,168,76) <- die Kante border-radius 10px 16px 16px 10px Die Kante ist ein Rest der Bordkarte: dort war `.dp-pf-rz` die **Reisszone**, und die goldene Rundung markierte den Abriss. In der Kartei gibt es keinen Abriss — die Kante markiert also nichts mehr und sieht aus, als wäre sie vergessen worden. Sie war es auch. > Eine Linie, die einmal etwas bedeutet hat, bedeutet nach dem Umbau > nicht weniger, sondern etwas Falsches: sie verspricht eine Trennung, > die es nicht gibt. Den QR hatte ich in v1661 mit der Perforation und dem Strichcode zusammen ausgeblendet — als Teil der Metapher. Er ist aber keine Metapher, sondern ein Weg aufs Handy. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-rz{ border-right:0 !important; border-radius:0 !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-qr{ display:flex !important; flex:0 0 auto !important; align-self:center !important; width:46px !important; height:46px !important; margin:0 18px 0 auto !important; padding:3px !important; background:#fff !important; border:1px solid #E6E1D6 !important; border-radius:2px !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-qr svg, html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-qr img, html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-qr canvas{ width:100% !important; height:100% !important; display:block !important; } /* Der Abrufbereich steht jetzt direkt neben dem QR und braucht seinen Schub nach rechts nicht mehr — sonst reisst er die beiden auseinander. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-rz{ margin-left:0 !important; } /* ── v1668c · ZWEI ELEMENTE, DIE NICHT IN DER REIHE STANDEN ────────── Gemessen nach v1668b — die Leiste war auf 183 px gewachsen und zwei Teile standen irgendwo: .dp-pf-seg [550,199] und [658,199] <- die Reihe .dp-pf-sep [564,129 1x18] <- daneben, oben .dp-pf-qr [1763,115 46x46] <- ausserhalb der Karte Beide tragen aus der Bordkarte `position:absolute`: dort war der Trennstrich eine gezeichnete Linie auf der Karte und der QR eine aufgedruckte Marke — beide lagen AUF dem Papier, nicht darin. > `display:block` holt ein Element nicht in die Reihe zurück. Wer > nur die Sichtbarkeit umschaltet und die Positionierung vergisst, > macht etwas sichtbar, das trotzdem nicht mitzählt. Dazu die Höhe: mit Titel braucht ein Segment 96 px, die Leiste kam damit auf 183. Die Vorlage ist 78 px hoch plus 38 px Kopfzeile — also Segmente auf 77. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-sep, html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-qr{ position:static !important; top:auto !important; right:auto !important; bottom:auto !important; left:auto !important; transform:none !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-sep{ height:auto !important; min-height:0 !important; margin:16px 16px !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg{ padding:8px 0 10px !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-grouplbl{ margin:0 0 4px !important; } /* ── v1668d · OHNE `order` STEHT MAN GANZ VORNE ────────────────────── Gemessen: `position` war nach v1668c korrekt `static` — und beide Teile standen trotzdem bei y=131 bzw. y=115 statt in der Reihe bei y=199. Der Grund ist nicht die Positionierung, sondern die REIHENFOLGE. Die Kartei vergibt seit v1659 `order`: .dp-pf-lead order:1 die Kopfzeile .dp-pf-seg order:2 die Quellen .dp-pf-rz order:3 der Abruf `.dp-pf-sep` und `.dp-pf-qr` waren damals ausgeblendet und haben deshalb nie eines bekommen. Der Standardwert ist **0** — und 0 kommt vor 1. > Wer in einer geordneten Reihe kein `order` hat, steht nicht > hinten, sondern ganz vorne. Ein vergessener Wert ist hier keine > Auslassung, sondern eine Ansage. Beide bekommen `order:2` und stehen damit dort, wo das DOM sie ohnehin führt: Segment · Trennstrich · Segment · QR. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-sep, html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-qr{ order:2 !important; } /* ── v1668e · DER QR IN DER MITTE DER KARTE ────────────────────────── Marcel: „bei der Ansicht heute, da muss der QR-Code auch mittig auf die Datenaufnahme-Karte." Gemessen im Auslieferungszustand (`#oab-bar` 614..1894, 78 px hoch): letzter Chip endet ~1130 a.dp-pf-qr 1501 .. 1555 (54x68) .dp-pf-rz beginnt 1686 Senkrecht sitzt er schon mittig (oben 5, unten 5). WAAGERECHT steht er in einer 556 px breiten Lücke bei 371 px — also deutlich rechts von deren Mitte, ohne dass etwas ihn dort hält. > Ein Element, das in einer Lücke steht, aber nicht in ihrer Mitte, > sieht nicht platziert aus, sondern liegengeblieben. `margin:auto` auf beiden Seiten teilt den freien Raum gleich auf. In der Kartei gilt weiter die eigene Regel aus v1668b — dort soll er ausdrücklich neben dem Abrufknopf stehen. */ :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-qr{ margin-left:auto !important; margin-right:auto !important; } /* ── v1670 · DER QR IM QUICKBOARDING ───────────────────────────────── Marcel: „Das Ganze musst du im Quick-Check natürlich auch noch einmal ausprobieren." Titel, Trennstrich und die goldene Kante stimmten dort nach v1668 bereits — der QR fehlte, weil es ihn **im Markup nie gab** (`quickcheck-app.html` führte die Leiste ohne ihn, der Objekt-Tab hat ihn seit jeher). Er ist jetzt da und hängt an derselben Quelle wie der QR des Boarding-Passes: `renderQR()` / `_shareUrl`. > Eine Auskunft, zwei Anzeigen — aber nur eine Quelle. Ein zweiter > Weg zum selben QR wäre am ersten Tag derselbe und am dreißigsten > nicht mehr. **Ohne Ziel bleibt er leer und nimmt keinen Platz.** Ein QR-Kästchen, das man nicht scannen kann, ist kein Platzhalter, sondern ein Versprechen, das nicht eingelöst wird. */ html[data-dp-kartenstil="kartei"] #qc7-sources.dp-pfbar > #qc7-qr:not([data-hat-ziel]){ display:none !important; } html[data-dp-kartenstil="kartei"] #qc7-sources.dp-pfbar > #qc7-qr[data-hat-ziel]{ display:flex !important; order:2 !important; position:static !important; flex:0 0 auto !important; align-self:center !important; width:46px !important; height:46px !important; margin:0 18px 0 auto !important; padding:3px !important; background:#fff !important; border:1px solid #E6E1D6 !important; border-radius:2px !important; } html[data-dp-kartenstil="kartei"] #qc7-sources.dp-pfbar > #qc7-qr img, html[data-dp-kartenstil="kartei"] #qc7-sources.dp-pfbar > #qc7-qr canvas{ width:100% !important; height:100% !important; display:block !important; } /* ── v1671 · ABSTAND, GRÖSSE, GEWICHT ──────────────────────────────── Marcel, drei Messbefunde an der Kartei: 1. „Am Anfang, vor Marktbewertung, setzt der Button direkt am Anfang des Kastens an." — gemessen: das erste Segment beginnt **2 px** hinter der Kartenkante. Die Kopfzeile darüber hat 16 px Einzug; die Reihe darunter hatte keinen. > Zwei Pixel sind kein Abstand, sondern das Fehlen eines > Abstands. Was bündig sein soll, wirkt so, als sei es > angestoßen. 2. „Der QR-Code ist relativ schmal und klein." — 46×46 px. Ein QR, den man mit dem Handy treffen muss, lebt von der Modulgröße; bei 37 Modulen sind 46 px rund 1,2 px je Modul. 3. „Den Abruf-Button ungefähr in der gleichen Größe wie die anderen Buttons, so wie Weiter: Investition." — gemessen: .dp-pf-launch 84 × 29 Polster 8/18 „Weiter: Investition" 164 × 40 Polster 10/16 Der wichtigste Knopf der Karte war der kleinste der Seite. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg:first-of-type{ padding-left:18px !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-qr, html[data-dp-kartenstil="kartei"] #qc7-sources.dp-pfbar > #qc7-qr[data-hat-ziel]{ width:64px !important; height:64px !important; padding:4px !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-launch{ min-height:40px !important; padding:10px 20px !important; font-size:13px !important; border-radius:2px !important; } /* ── v1672 · DIE CO-PILOT-KACHEL ───────────────────────────────────── Sie sieht aus wie die anderen Kacheln, ist aber keine Quelle: kein Ankreuzfeld, kein Lämpchen, keine Beteiligung an „n von 4 gewählt". Sie startet etwas, statt etwas beizusteuern. > Ein Knopf, der wie ein Schalter aussieht, wird für einen gehalten. > Der Unterschied muss sichtbar sein — hier über die goldene Kante, > die sonst nur der Abruf trägt. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dpk-copilot{ border-color:color-mix(in srgb, var(--wl-c9a84c, #C9A84C) 45%, #E6E1D6) !important; background:#FFFDF8 !important; cursor:pointer; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dpk-copilot:hover{ border-color:var(--wl-c9a84c, #C9A84C) !important; background:#FFFBF0 !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dpk-copilot .dp-pf-ic, html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dpk-copilot .dp-pf-ic *{ color:var(--wl-c9a84c, #C9A84C) !important; stroke:var(--wl-c9a84c, #C9A84C) !important; } html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dpk-copilot .dp-pf-lbl{ font-weight:600 !important; } /* ── v1672b · `:first-of-type` ZÄHLT DEN TYP, NICHT DIE KLASSE ─────── Gemessen nach v1671: der Abstand vor „Marktbewertung" war weiter **1 px**. Meine Regel lautete > .dp-pf-seg:first-of-type{ padding-left:18px } und traf nichts. `:first-of-type` fragt nach dem ersten Element seines TYPS unter den Geschwistern — und das erste `div` in der Leiste ist `.dp-pf-lead`, die Kopfzeile. Die Klasse im Selektor ändert daran nichts; sie filtert nur, ob der Treffer am Ende noch passt. > `:first-of-type` ist keine Aussage über die Klasse, die davor > steht. Wer `.klasse:first-of-type` schreibt, meint fast immer > „das erste mit dieser Klasse" — und bekommt „das erste seines > Typs, falls es zufällig diese Klasse hat". Der genaue Anker ist der Nachbar: die Perforation steht im DOM direkt vor dem ersten Segment (sie ist nur ausgeblendet, nicht entfernt). */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-perf + .dp-pf-seg{ padding-left:18px !important; } /* ── v1672c · KURZSCHRIFT SCHLÄGT EINZELWERT, WENN SIE SPÄTER STEHT ── Auch `.dp-pf-perf + .dp-pf-seg{padding-left:18px}` blieb wirkungslos — gemessen weiter 1 px. Der Grund ist nicht die Spezifität, sondern die Kurzschrift zwei Blöcke weiter oben: > .dp-pf-seg{ padding:8px 0 10px !important } `padding` setzt ALLE vier Seiten, also auch `padding-left:0`. Zwei `!important`-Regeln, die dieselbe Eigenschaft berühren — und die Kurzschrift gewinnt, weil sie in der Datei später steht als mein Versuch von v1671 und gleich spezifisch ist wie der von v1672b. > Eine Kurzschrift ist kein Wert, sondern vier. Wer danach einen > davon einzeln setzen will, muss ihn ENTWEDER später schreiben > ODER auf eine Eigenschaft ausweichen, die sie nicht berührt. `margin-left` berührt sie nicht. */ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-perf + .dp-pf-seg{ margin-left:18px !important; } /* ═══════════════════════════════════════════════════════════════════ v1680 — DER SCHATTEN, DER EIN SCROLLEN BEHAUPTET ------------------------------------------------------------------- Marcel: „unter Quick Boarding und der Ansicht Heute die Pre-Flight- Karte pruefen, die sieht nicht aus wie vorher." Und vorher schon einmal: „hinten am Abruf-Button ist irgend so eine goldene Kante." GEMESSEN am Element, nicht an der Regel: .dp-pf-scroll::after 34 x 126,6 px, rechts aussen linear-gradient(90deg, transparent, rgba(0,0,0,.22)) .dp-pf-scroll overflow-x: VISIBLE scrollWidth 1280 === clientWidth 1280 Der Schatten sagt „hier geht es rechts weiter". **Es geht nirgends weiter** — die Leiste bricht seit dem Kartei-Umbau um, statt zu scrollen. Uebrig bleibt ein dunkler Balken ueber dem Abrufen-Knopf, der die Karte abzuschneiden scheint. Er steht in `@media (min-width: 769px)` (style.css:36586) und trifft damit genau den Schreibtisch, an dem Marcel ihn sieht. Auf dem Handy scrollt die Leiste wirklich — dort bleibt er. Die Bedingung ist nicht die Bildschirmbreite, sondern ob ueberhaupt gescrollt wird. Diese Regel haengt deshalb an denselben Ankern, die `overflow:visible` setzen: wo nichts ueberlaeuft, gibt es nichts anzudeuten. `@media` erhoeht keine Spezifitaet — die Ankerkette muss die Arbeit tun, nicht die Umgebung. ═══════════════════════════════════════════════════════════════════ */ body.dp-pfzeile .dp-pf-scroll:has(.dp-pfbar)::after, body.dp-pfzeile .dp-pf-scroll::after, html[data-dp-kartenstil="kartei"] .dp-pf-scroll:has(.dp-pfbar)::after, html[data-dp-kartenstil="kartei"] .dp-pf-scroll::after{ content:none !important; display:none !important; background:none !important; width:0 !important; } /* ═══════════════════════════════════════════════════════════════════ v1682 — WARUM DIE LEISTE IM QUICKBOARDING ANDERS AUSSAH ------------------------------------------------------------------- Marcel: „die Datenaufnahme im Quickboarding sieht nicht so aus wie im Tab Objekt. Der Abruf-Button ist rübergerutscht und da ist auch noch was Goldenes mit drin." GEMESSEN, beide Leisten nebeneinander: Tab Objekt QuickBoarding QR-Inhalt 6.109 Zeichen 0 (leer) QR angezeigt ja display:none Abrufen sitzt bei x = 1585 (rechts) x = 650 (mitten drin) goldene Unterkante ja ja **Der Abruf-Knopf ist nicht verrutscht — ihm fehlt der Nachbar.** Der QR wird im iframe nie gefüllt: sein Ziel kommt per Nachricht `qc-autopass-code` aus der Haupt-App, und ohne Pass gibt es keins. Die Regel `#qc7-qr:not([data-hat-ziel])` klappt ihn dann ein — das war als Schutz gemeint („ein QR ohne Ziel ist ein Bild, kein Weg") und hat den Platz gleich mit eingezogen. > Ein Schutz, der Platz wegnimmt, verschiebt alles daneben. Der > Knopf stand nie falsch; die Lücke neben ihm war zu gross. Deshalb: der Abruf-Bereich haelt seinen Platz am rechten Rand aus eigener Kraft (`margin-left:auto`) und haengt nicht mehr davon ab, ob ein QR danebensteht. Und die goldene Unterkante faellt weg — sie steht an BEIDEN Leisten, aber erst wenn der Knopf mitten im Fluss sitzt, sieht man sie als Strich quer durch die Karte. Marcel hat sie zweimal gemeldet. ═══════════════════════════════════════════════════════════════════ */ :is(#oab-bar, #qc7-sources).dp-pfbar .dp-pf-rz{ margin-left:auto !important; border-bottom:0 !important; } /* Steht ein QR daneben, gehoert der Abstand zwischen beide - nicht zwischen Segment und Knopf. */ :is(#oab-bar, #qc7-sources).dp-pfbar .dp-pf-qr + .dp-pf-rz{ margin-left:14px !important; } /* v1686b: nur MIT Ziel den Platz beanspruchen. Ein leerer QR (0 px breit) schob sich sonst selbst an den rechten Rand und riss die Luecke wieder auf, die v1686 gerade geschlossen hatte — gemessen 113 px statt der gesetzten 18. Ein Element ohne Inhalt soll keinen Raum fordern. */ /* v1693b: die Bedingung `[data-hat-ziel]` gilt nur im QuickCheck — dort setzt `renderQR()` das Attribut, sobald ein Pass existiert. Im Objekt-Tab gibt es das Attribut NIE, dafuer ist der QR immer gefuellt (gemessen: 54 px breit). Beide Leisten brauchen dieselbe Wirkung, aber nicht dieselbe Bedingung. */ #qc7-sources.dp-pfbar .dp-pf-qr[data-hat-ziel], #oab-bar.dp-pfbar .dp-pf-qr{ margin-left:auto !important; } /* ═══════════════════════════════════════════════════════════════════ v1686 — OHNE QR KEINE LUECKE ------------------------------------------------------------------- Marcel: „das Abrufen, das ist irgendwo ganz wild neben ImmoMetrica." GEMESSEN bei „Heute", beide Leisten einzeilig: Tab Objekt QuickBoarding QR-Breite 289 px 0 px Luecke vor Abrufen — 255 px weiss Im Objekt-Tab FUELLT der QR den Raum vor dem Abruf-Knopf. Im QuickBoarding gibt es keinen Pass und damit keinen QR — der Knopf wurde von `margin-left:auto` an den rechten Rand geschoben und liess eine handbreite leere Flaeche hinter sich. Beides war fuer sich richtig und zusammen falsch: v1682 hat den Knopf nach rechts geholt, weil er sonst mitten in der Leiste klebte; das galt fuer die ZWEIZEILIGE Kartei-Fassung. Einzeilig und ohne QR gehoert er wieder an seinen Nachbarn. `:has(.dp-pf-qr[data-hat-ziel])` fragt genau das, worauf es ankommt — ob ein QR mit ZIEL danebensteht, nicht ob das Element existiert. Sobald ein Pass entsteht, setzt `renderQR()` das Attribut, der QR erscheint, und der Knopf rueckt von selbst wieder nach rechts. ═══════════════════════════════════════════════════════════════════ */ /* v1694 — ZURUECKGENOMMEN: hier stand margin-left:18px. Marcel will den Abruf-Knopf und den Barcode auch im QuickCheck am Ende. Die 18 px stammen aus v1686, als der Knopf am Rand stand und 255 px weisse Flaeche hinter der letzten Kachel liess. Die Luecke kam aber nicht von der Ausrichtung, sondern von den 95 px Rand eines LEEREN QR (v1686c). Der Grund ist behoben, die Notloesung nicht mehr noetig. > Eine Abhilfe, die den Anlass ueberlebt, wird zum naechsten Anlass. */ #qc7-sources.dp-pfbar .dp-pf-rz{ margin-left:auto !important; } /* v1693b — ZURUECKGENOMMEN fuer den Objekt-Tab. Diese Bedingung stammt aus v1686 und war fuer die QuickCheck-Leiste gedacht, in der nach dem letzten Segment wirklich nichts mehr kommt. Im Objekt-Tab steht der QR sehr wohl da (54 px breit) — er traegt nur kein `data-hat-ziel`, weil dieses Attribut allein die QuickCheck- Fassung setzt (`renderQR()`). Die Regel hat den Abruf-Bereich deshalb 246 px vor dem Ende festgenagelt. > Eine Bedingung, die an EINER Stelle richtig ist, wird an der > anderen zur Falle, wenn ihr Merkmal dort nie gesetzt wird. Sie gilt jetzt nur noch fuer `#qc7-sources`; im Objekt-Tab uebernimmt das `margin-left:auto` weiter unten. Die schwaechere Gegenregel daneben zu stellen haette nicht geholfen: `:not(:has(…))` traegt hier mehr Spezifitaet als die Ankerkette ohne sie. */ #qc7-sources.dp-pfbar .dp-pf-rz{ margin-left:auto !important; } /* v1686c — EIN ELEMENT MIT NULL BREITE TRUG 95 PX RAND. Nachgerechnet, Leiste im QuickBoarding bei „Heute": letztes Segment endet 927 QR margin-left 47,5 -> sitzt bei 975, Breite 0 QR margin-right 47,5 Abrufen margin-left 18 -> beginnt bei 1040 47,5 + 47,5 + 18 = 113 — genau die gemessene Luecke. Die 18 waren gesetzt und richtig; die 95 kamen von den Raendern eines Elements, das gar nichts anzeigt. Ein QR ohne Ziel ist kein Bild, kein Weg und auch kein Abstand. */ /* v1693c — DIE DRITTE REGEL MIT DEMSELBEN FEHLER. `[data-hat-ziel]` setzt allein `renderQR()` im QuickCheck. Im Objekt-Tab gibt es das Attribut NIE — also las diese Regel dort dauerhaft „QR ohne Ziel" und nahm ihm den Rand, obwohl er 54 px breit und gefuellt ist. Zusammen mit den beiden Geschwistern in v1693b hat sie den Abruf-Bereich 249 px vor dem Ende festgehalten. > Dreimal dieselbe Ursache an drei Stellen: ein Merkmal, das nur EINE > der beiden Leisten kennt, als Bedingung fuer BEIDE geschrieben. > Beim ersten Mal war es ein Versehen, beim dritten ein Muster. Ab hier gilt: Regeln mit `data-hat-ziel` tragen `#qc7-sources` und niemals `#oab-bar`. */ /* v1694: margin-LEFT bleibt auto, damit der leere QR den freien Platz schluckt und Barcode wie Abruf-Knopf mit ans Ende nimmt. Weg muessen nur margin-RIGHT und padding - die 47,5 px rechts rissen die Luecke VOR dem Knopf auf. Den freien Rest zu schlucken ist kein Abstand, sondern Ausrichtung. */ #qc7-sources.dp-pfbar .dp-pf-qr:not([data-hat-ziel]){ margin-left:auto !important; margin-right:0 !important; padding:0 !important; } /* ═══════════════════════════════════════════════════════════════════ v1687 — ZWEI BESCHRIFTUNGEN, EINE JE ZUSTAND ------------------------------------------------------------------- Marcel: „wenn ich auf Heute umstelle und dann auf Quick Check gehe, ist immer noch die Pre-Flight-Karte — die hast du umgewandelt in Datenaufnahme. Das muss wieder so sein wie vorher." Auf Prod nachgesehen (`157.90.117.167`, `object-actions.js:301`): dort steht bis heute **PRE-FLIGHT** und **Daten einlesen**. Ich hatte beides fuer die neuen Ansichten umbenannt und damit auch „Heute" veraendert — eine Ansicht, die ausdruecklich UNVERAENDERT bleiben soll. Die Karte gibt jetzt beide Texte aus; welcher gilt, entscheidet der Kartenstil. Eine Quelle, zwei Zustaende — nicht zwei Staende derselben Karte. ═══════════════════════════════════════════════════════════════════ */ .dp-pfbar .k-neu{ display:none; } .dp-pfbar .k-heute{ display:inline; } html[data-dp-kartenstil] .dp-pfbar .k-neu, body.dp-pfzeile .dp-pfbar .k-neu{ display:inline; } html[data-dp-kartenstil] .dp-pfbar .k-heute, body.dp-pfzeile .dp-pfbar .k-heute{ display:none; } /* Im iframe entscheidet die gespiegelte Marke: `data-dp-heute` steht genau dann, wenn die Haupt-App auf „Heute" steht (v1685). */ html[data-dp-heute] .dp-pfbar .k-neu{ display:none !important; } html[data-dp-heute] .dp-pfbar .k-heute{ display:inline !important; } /* ── v1688 · Ausgabeleiste im BMF-Modal ───────────────────────────── Erscheint erst nach der Berechnung. `downloadXlsx()` hatte bis hierher keinen einzigen Aufrufer — die Funktion war exportiert und fuer den Nutzer unerreichbar. */ .bmf-ausgaben{ margin-top:16px; padding-top:14px; border-top:1px solid color-mix(in srgb, var(--wl-c9a84c, #C9A84C) 26%, transparent); } .bmf-ausgaben-kopf{ font-family:'JetBrains Mono',monospace; font-size:10.5px; letter-spacing:.08em; text-transform:uppercase; opacity:.6; margin-bottom:9px; } .bmf-ausgaben-liste{ display:flex; flex-wrap:wrap; gap:9px; } .bmf-ausg{ display:flex; flex-direction:column; gap:2px; align-items:flex-start; flex:1 1 210px; padding:10px 13px; cursor:pointer; text-align:left; font:inherit; color:inherit; border-radius:8px; border:1px solid color-mix(in srgb, var(--wl-c9a84c, #C9A84C) 34%, transparent); background:color-mix(in srgb, var(--wl-c9a84c, #C9A84C) 7%, transparent); } .bmf-ausg:hover{ background:color-mix(in srgb, var(--wl-c9a84c, #C9A84C) 17%, transparent); } .bmf-ausg-l{ font-size:13.5px; line-height:1.25; } .bmf-ausg-s{ font-size:11px; line-height:1.3; opacity:.62; } @media (max-width:560px){ .bmf-ausg{ flex:1 1 100%; } } /* ═══════════════════════════════════════════════════════════════════ v1693 — DER ABRUF-BEREICH STAND NICHT AM ENDE ------------------------------------------------------------------- Marcel: „bitte auch im Tab Objekt den Button noch passend wieder rechts ans Ende der Pre-Flight-Karte, genauso wie den Barcode dahinter." Gemessen bei „Heute", Tab Objekt: Leiste endet rechts bei 1894 Abruf-Bereich endet bei 1656 Rand dazwischen 238 px Die Regel aus v1686 gibt dem Bereich `margin-left:18px`, wenn kein QR mit Ziel danebensteht — das war fuer die QuickCheck-Leiste gedacht, in der nach dem letzten Segment nichts mehr kam. Im Tab Objekt steht der QR sehr wohl da (54 px), er traegt nur kein `data-hat-ziel`, weil das Attribut nur die QuickCheck-Fassung setzt. > Eine Bedingung, die an EINER Stelle richtig ist, wird an der > anderen zur Falle, wenn ihr Merkmal dort nie gesetzt wird. Der Abruf-Bereich ist das letzte Element der Leiste und gehoert an ihr Ende — unabhaengig davon, was davor steht. `margin-left:auto` sagt genau das; die 18 px bleiben als ABSTAND zum Nachbarn, nicht als Ersatz fuer die Ausrichtung. ═══════════════════════════════════════════════════════════════════ */ #oab-bar.dp-pfbar .dp-pf-rz{ margin-left:auto !important; } /* Steht ein QR daneben, gehoert der Abstand zwischen die beiden. */ #oab-bar.dp-pfbar .dp-pf-qr + .dp-pf-rz{ margin-left:14px !important; } /* Der QR wandert dann mit ans Ende — er gehoert zum Abruf, nicht zu den Quellen davor. */ #oab-bar.dp-pfbar .dp-pf-qr{ margin-left:auto !important; } /* ===================================================================== v1706c - DIE KARTEI: QR GROESSER, OHNE RAHMEN, PILLEN IN SCHWARZ ===================================================================== Marcel am 29.09.2026: "die Kartei, die nimmst du noch mit rein, mit dem Unterschied, dass du da bitte um den QR-Code, dass du den ein bisschen groesser machst und keinen Rahmen da drumrum und dass du die Schriftart von Expose, Marktbericht, Sprache und ImmoMetrica vielleicht noch in Schwarz anpasst." Der QR war in der Kartei GAR NICHT da: er stand oben in derselben Ausblendliste wie Streifen, Perforation und Strichcode (`> .dp-pf-qr { display:none }`). Er wird hier wieder eingeblendet - die Ausblendung bleibt stehen und wird gezielt ueberschrieben, damit im Diff sichtbar bleibt, dass es eine Aenderung an IHR ist. ===================================================================== */ html[data-dp-kartenstil="kartei"] .dp-pfbar > .dp-pf-qr{ display:flex !important; align-items:center !important; justify-content:center !important; border:none !important; outline:none !important; box-shadow:none !important; background:transparent !important; padding:0 !important; margin:0 0 0 auto !important; width:86px !important; height:86px !important; flex:0 0 auto !important; } html[data-dp-kartenstil="kartei"] .dp-pfbar > .dp-pf-qr canvas, html[data-dp-kartenstil="kartei"] .dp-pfbar > .dp-pf-qr img, html[data-dp-kartenstil="kartei"] .dp-pfbar > .dp-pf-qr svg{ width:86px !important; height:86px !important; border:none !important; box-shadow:none !important; border-radius:0 !important; } /* Die Beschriftung unter dem Code (SCAN) darf bleiben, aber sie traegt keinen Rahmen mit - sonst waere der Rahmen nur verschoben. */ html[data-dp-kartenstil="kartei"] .dp-pfbar > .dp-pf-qr *{ border:none !important; box-shadow:none !important; } /* Die Quellen-Pillen: Expose / Marktbericht, Sprache, ImmoMetrica. Schwarz auf der hellen Kartei - der Text ist eine Beschriftung, keine Auszeichnung. Der Haken und der Rahmen bleiben, wie sie sind. */ html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-tile, html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-lbl, html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-logo.dp{ color:#111111 !important; } html[data-dp-kartenstil="kartei"] .dp-pfbar .dp-pf-tile.on .dp-pf-lbl{ color:#000000 !important; } /* ===================================================================== v1706g - DER QR: GROESSER, OHNE RAHMEN, ABER MIT RUHEZONE ===================================================================== Gemessen nach v1706c: der QR ist wieder da, aber 64x64 und mit Rahmen - meine Groessenangabe war schwaecher als die vorhandene. Hier mit doppelt genannter Klasse, ohne eine ID zu erfinden. EINE KORREKTUR AN MIR SELBST: in v1706c stand `background:transparent`. Das war falsch. Marcel hat "keinen Rahmen" gesagt, nicht "keinen Grund" - und ein QR-Code ohne helle Ruhezone ist nicht mehr scannbar. Die staerkere Regel hat das zufaellig verhindert; richtig ist es trotzdem nur, wenn es hier ausdruecklich steht. > Ein Rahmen ist Zierat. Die weisse Flaeche um einen QR ist Technik. ===================================================================== */ html[data-dp-kartenstil="kartei"] .dp-pfbar > .dp-pf-qr.dp-pf-qr{ width:92px !important; height:92px !important; min-width:92px !important; min-height:92px !important; border:none !important; outline:none !important; box-shadow:none !important; border-radius:4px !important; background:#FFFFFF !important; /* Ruhezone - nicht entfernen */ padding:5px !important; margin:0 0 0 auto !important; display:flex !important; align-items:center !important; justify-content:center !important; flex:0 0 auto !important; } html[data-dp-kartenstil="kartei"] .dp-pfbar > .dp-pf-qr.dp-pf-qr canvas, html[data-dp-kartenstil="kartei"] .dp-pfbar > .dp-pf-qr.dp-pf-qr img, html[data-dp-kartenstil="kartei"] .dp-pfbar > .dp-pf-qr.dp-pf-qr svg{ width:82px !important; height:82px !important; max-width:none !important; max-height:none !important; border:none !important; box-shadow:none !important; border-radius:0 !important; } /* ===================================================================== v1713 - ENTWURF 21 "BUETTEN" ALS KARTENSTIL ===================================================================== Marcel hat das Bild geschickt (Dateien/karte.png): Variante 21 aus design/mockups/preflight-varianten-v1425.html, Zeile 838 ff. "Schweres Buettenpapier mit sichtbarer Faser; die Kacheln sind nicht gedruckt, sondern blindgepraegt - der aktive Zustand ist eine Vertiefung mit Goldkante." Die Regeln sind aus der Demo UEBERNOMMEN, nicht nachgebaut. Nur die Klassennamen sind gemappt - in der echten App tragen sie das Praefix `dp-`, im Uebrigen heissen sie gleich: .v-buetten -> html[data-dp-kartenstil="buetten"] .dp-pfbar .pf-lead -> .dp-pf-lead .pf-tile -> .dp-pf-tile .pf-bp/.k/.s -> .dp-pf-lead .bp/.k/.s .pf-tile.an -> .dp-pf-tile.on .pf-led -> .dp-pf-led .pf-grouplbl -> .dp-pf-grouplbl .pf-sep -> .dp-pf-sep .pf-qr .code -> .dp-pf-qr .pf-perf -> .dp-pf-perf .pf-rz -> .dp-pf-rz Gegengeprueft im Browser: alle siebzehn Teile existieren unter diesen Namen. > Eine Vorlage wird uebernommen, nicht interpretiert. Wer sie > nachbaut, baut sein eigenes Bild von ihr. Der helle Grund ist hier Absicht und kein Versehen: Buetten IST Papier. Deshalb kehren auch die Textfarben um - dunkle Tinte auf hellem Grund, nur der Pre-Flight-Block links bleibt dunkel. ===================================================================== */ html[data-dp-kartenstil="buetten"] .dp-pfbar{ --loch:#0B0B09; background: repeating-linear-gradient(0deg, rgba(150,132,96,.035) 0 1px, transparent 1px 2px), repeating-linear-gradient(90deg, rgba(150,132,96,.03) 0 1px, transparent 1px 2px), radial-gradient(120% 100% at 30% 0%, #FFFDF7, #F6F0E2 62%) !important; box-shadow:0 14px 36px rgba(90,76,40,.24), inset 0 1px 0 rgba(255,255,255,.9) !important; border:0 !important; border-radius:16px !important; overflow:hidden !important; display:flex !important; align-items:stretch !important; padding:0 !important; gap:0 !important; min-height:78px !important; height:auto !important; } /* Der Pre-Flight-Block links bleibt dunkel - er ist die Bordkarte im Papier, nicht Teil des Bogens. */ html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-lead{ background:#100E0A !important; border-radius:16px 0 0 16px !important; box-shadow:inset -1px 0 0 rgba(184,147,47,.4) !important; display:flex !important; flex-direction:column !important; justify-content:center !important; padding:12px 16px !important; flex:0 0 auto !important; order:0 !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-lead .bp{ color:#8A7F62 !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-lead .k { color:#F5EEDC !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-lead .s { color:#A2977E !important; display:block !important; } /* Abschnittsbeschriftungen: MARKTBEWERTUNG, DATEN EINLESEN */ /* ══ v1954 · ZWEI TEXTE WAREN NICHT LESBAR ════════════════════════════ Marcel am 07.10.2026: "Das Problem ist, dass bei Datenuebernahme aus den Knoepfen alles in Dunkelgrau steht. Das muesste groesser sein." GEMESSEN, Text gegen den EFFEKTIVEN Grund (erster Vorfahr mit Flaeche): Gruppentitel 9px #9A8F76 auf rgb(244,242,237) Kontrast 2.86 QR-Beschriftung 7.5px #9A8F76 auf rgb(244,242,237) Kontrast 2.86 Das Minimum ist 4,5. Beide lagen bei 2,86 - und das bei 9 bzw. 7,5 px. Die Kachelbeschriftung daneben hat 15,40; deshalb liest sich die Leiste wie "alles dunkelgrau": die kraeftigen Stellen stehen neben ausgewaschenen. > Marcel hat die Farbe genannt, nicht den Kontrast. Der Ausloeser ist > eine Beobachtung, keine Diagnose - gemessen war nicht "zu dunkel", > sondern ZU HELL auf hellem Papier. #665C49 bringt 5,88 und bleibt ein warmer Grauton, also der Buetten-Charakter. Die Groessen gehen auf 10 px und 9 px - Marcels "muesste groesser sein". ════════════════════════════════════════════════════════════════════ */ html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-grouplbl{ color:#665C49 !important; font-size:10px !important; } /* Die Kacheln sind blindgepraegt, nicht gedruckt. */ html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-tile{ background:#FFFDF7 !important; color:#2A2418 !important; border:0 !important; box-shadow:inset 0 0 0 1px rgba(150,132,96,.24), inset 0 1px 0 rgba(255,255,255,.9), 0 1px 2px rgba(120,100,60,.14) !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-tile .dp-pf-lbl, html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-tile .dp-pf-logo, html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-tile .dp-pf-logo.dp{ color:#2A2418 !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-tile .dp-pf-ic, html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-tile svg{ color:#9A8B62 !important; stroke:currentColor !important; } /* Der aktive Zustand ist eine VERTIEFUNG mit Goldkante - kein Leuchten. */ html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-tile.on{ background:#FFFDF7 !important; box-shadow:inset 0 0 0 1.5px rgba(184,147,47,.7), inset 0 2px 4px rgba(150,120,50,.18) !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-led{ background:#DDD3BC !important; box-shadow:inset 0 1px 2px rgba(120,100,60,.3) !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-tile.on .dp-pf-led{ background:var(--wl-b8932f, #b8932f) !important; box-shadow:0 0 8px rgba(184,147,47,.6), inset 0 1px 1px rgba(255,255,255,.5) !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-sep{ background:rgba(150,132,96,.3) !important; display:block !important; width:1px !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-perf{ border-left-color:rgba(120,100,60,.4) !important; display:block !important; } /* QR und Reisszone */ html[data-dp-kartenstil="buetten"] .dp-pfbar > .dp-pf-qr{ display:flex !important; align-items:center !important; justify-content:center !important; background:transparent !important; border:0 !important; flex:0 0 auto !important; padding:0 10px !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-qr canvas, html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-qr img, html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-qr svg{ border-color:#2A2418 !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-scan{ color:#665C49 !important; font-size:9px !important; } /* v1954 */ html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-rz{ background:radial-gradient(120% 100% at 50% 0%, #FFFDF7, #F4EDDD) !important; display:flex !important; align-items:center !important; margin-left:auto !important; flex:0 0 auto !important; padding:0 14px !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-bc{ display:block !important; opacity:.8 !important; /* v1725: der Barcode war hier 9 px hoch statt 53. Er ist NICHT gequetscht - er ist absolut mit inset:12px 16px gesetzt (style.css:32995), und seine Box ist bei Buetten nur 34 px hoch statt 78 (align-self:center weiter unten). 34 minus zweimal 12 ergibt genau die gemessenen 10. > Ein Rand in festen Pixeln ist eine Aussage ueber die Hoehe des > Elternteils. Wird das Elternteil flacher, frisst der Rand den > Inhalt - und der Inhalt sieht aus, als waere er kaputt. Die Buetten-Gestaltung bleibt (kompakter Block, mittig auf dem Papier), nur der Rand folgt der kleineren Box: 34 minus zweimal 5 ergibt 24 px Barcode. */ inset:5px 12px !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-stripe{ display:none !important; /* der Runway-Verlauf gehoert nicht aufs Papier */ } /* Die beiden Loecher oben und unten - im Entwurf sitzen sie auf der Perforation und machen aus dem Bogen einen Abriss. */ html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-perf{ position:relative !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-perf::before, html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-perf::after{ content:'' !important; position:absolute !important; left:50% !important; transform:translateX(-50%) !important; width:11px !important; height:11px !important; border-radius:50% !important; background:var(--loch, #0B0B09) !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-perf::before{ top:-6px !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-perf::after { bottom:-6px !important; } /* Der Abruf-Knopf bleibt gold - er ist die Handlung, nicht das Papier. */ html[data-dp-kartenstil="buetten"] .dp-pfbar :is(#oab-run, .qc6-run).dp-pf-launch{ background:linear-gradient(110deg, var(--wl-e8cc7a, #E8CC7A), var(--wl-c9a84c, #C9A84C) 55%, var(--wl-b8932f, #b8932f)) !important; color:#1A1407 !important; border:0 !important; box-shadow:0 1px 3px rgba(120,100,60,.3) !important; } /* ===================================================================== v1713b - DER QR RISS DIE BUETTEN-LEISTE AUF 334 PX ===================================================================== Gemessen nach v1713: die Leiste war 1280x334 statt rund 90. Alle Kinder standen auf 323 px Hoehe - weil EINES so hoch war und `align-items:stretch` den Rest mitzieht: .dp-pf-qr 328 x 323 Ich hatte dem QR bei Buetten keine Groesse gegeben, nur Polsterung. Ohne Grenze nimmt er, was da ist. > `align-items:stretch` macht aus einem zu grossen Kind eine zu grosse > Zeile. Der Fehler sieht dann aus, als waere die ganze Leiste falsch > gebaut - dabei ist es ein einziges Element. ===================================================================== */ html[data-dp-kartenstil="buetten"] .dp-pfbar{ align-items:center !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar > .dp-pf-qr{ width:64px !important; height:64px !important; min-width:64px !important; min-height:0 !important; max-width:64px !important; max-height:64px !important; flex:0 0 64px !important; align-self:center !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-qr canvas, html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-qr img, html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-qr svg{ width:52px !important; height:52px !important; max-width:52px !important; max-height:52px !important; } /* Der Pre-Flight-Block darf die Hoehe vorgeben, aber nicht mehr als noetig - er ist die Bordkarte, nicht die Seite. */ html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-lead{ align-self:stretch !important; min-height:0 !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar > .dp-pf-seg{ align-self:center !important; padding:10px 12px !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-perf, html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-sep{ align-self:stretch !important; } html[data-dp-kartenstil="buetten"] .dp-pfbar .dp-pf-rz{ align-self:center !important; } /* ===================================================================== v1729 - AUF DEM TABLET STAND DER ABRUFEN-KNOPF AUSSERHALB DES BILDES ===================================================================== Marcel: "alles muss auf dem handy und tablet funktionieren" In der Messkabine bei 765 px gemessen: Leiste 34..727 (693 px breit) QR-Code 740..794 - 29 px draussen Abrufen 808..1016 - 251 px draussen, komplett unerreichbar Die Kinder laufen ueber ihren EIGENEN Container hinaus: die Leiste ist flex mit nowrap, die Teile schrumpfen nicht, und der Container traegt overflow-x:visible. Die Seite scrollt deshalb auch nicht - es gibt keinen Weg zu dem Knopf. Gegengemessen: aendert nichts (der Container waechst nicht mit), holt den Knopf auf 48..256 ins Bild. Die Leiste wird dabei 190 statt 78 px hoch - auf einem Tablet ist das der richtige Tausch. > Ein Knopf, den man nicht erreichen kann, ist kein Knopf. Nur der Tablet-Bereich: unter 700 px greift die eigene Handy-Fassung, dort wurde bei 387 px kein einziger Ueberlauf gemessen. */ @media (min-width:701px) and (max-width:1100px){ .dp-pfbar{ flex-wrap:wrap !important; } } /* v1870a · Die Lampe einer gewaehlten Kachel leuchtet gruen - in der Haupt-App und im QuickBoarding. Gemessen: Z. 232 faerbte JEDE Lampe dunkel (ohne Ruecksicht auf .on) und schlug per Spezifitaet die gruene Regel aus style.css. Statusfarbe, deshalb Literal und kein Token. */ body .dp-pf-tile.on .dp-pf-led, html.qc-app .dp-pf-tile.on .dp-pf-led, body.dp-pfzeile .dp-pfbar .dp-pf-tile.on .dp-pf-led { background: radial-gradient(circle at 35% 30%, #5BD98E, #3FA56C 70%) !important; border-color: rgba(5,5,5,.35) !important; box-shadow: 0 0 0 2px rgba(63,165,108,.25), 0 0 10px 1px rgba(63,165,108,.9) !important; opacity: 1 !important; } /* ============================================================================== v1941 - DIE QUELLEN-LEISTE BRICHT UM, STATT WAAGERECHT ZU SCROLLEN Marcel am 07.10.2026: "Also auf der Desktop-Ansicht hat man da zum Beispiel eine horizontale Scrollbar. Das moechte ich nicht. … wenn die in der Handy-Ansicht sind, dann sind die Buttons manchmal zu gross. … vielleicht anders rendern untereinander und auch huebscher darstellen." GEMESSEN, Schreibtisch 1177 px, Breite von `#oab-bar` gegen den Platz: Automatisch 1267 > 753 Ueberlauf Zeile 1267 > 753 Ueberlauf Buetten 1409 > 753 Ueberlauf Kartei 751 = 751 ok Bordkarte ok Trichter ok Drei von sechs Stilen schoben die Kacheln aus der Flaeche. Das Wischen war fuer das Handy gedacht; am Schreibtisch wird daraus eine Scrollleiste, die niemand sucht - und was rechts draussen steht, findet man dort auch nicht. > **Eine Flaeche, die mehr tragen soll, als sie breit ist, hat zwei > Antworten: schieben oder umbrechen.** Schieben versteckt; Umbrechen zeigt. > Bei fuenf Kacheln, die alle gleich wichtig sind, ist Verstecken die > falsche. Auf dem Handy stehen sie dadurch untereinander statt nebeneinander - jede ueber die volle Breite, mit 44 px Mindesthoehe fuer den Finger (dasselbe Mass wie bei den Objektkarten in v1935). ============================================================================== */ /* Umbrechen statt schieben - auf jeder Breite. */ .dp-pf-scroll, .dp-pf-scroll .dp-pfbar, #oab-bar.dp-pfbar { overflow-x: visible !important; flex-wrap: wrap !important; } /* Auf dem Handy untereinander, volle Breite, fingergerecht. */ @media (max-width: 900px) { #oab-bar.dp-pfbar, .dp-pf-scroll .dp-pfbar { flex-direction: column !important; align-items: stretch !important; gap: 6px !important; } #oab-bar.dp-pfbar .dp-pf-tile, .dp-pf-scroll .dp-pfbar .dp-pf-tile { width: 100% !important; max-width: 100% !important; min-height: 44px !important; flex: 0 0 auto !important; justify-content: flex-start !important; } /* ── v2117 · DIE REIHE HAT NIE ERFAHREN, DASS SIE UMBRECHEN SOLL ───── Marcel am 11.10.2026: „Hab in der Messkabine gerade iPad mini auf und es ist alles verzerrt." GEMESSEN bei 767 px, Reiter Objekt: .dp-pf-row 34-729 wrap=nowrap 4 Kinder Kind 1 34-729 Kind 2 735-1431 <- draussen Kind 3 1437-2132 <- draussen Kind 4 2138-2833 <- draussen Jede Kachel ist hier 100 % breit (die Regel direkt darueber), und die Reihe steht auf `nowrap` - also vier Vollbreit-Kacheln nebeneinander in einer 695 px breiten Reihe. `.dp-pf-scroll` traegt `overflow:hidden`, deshalb sieht man den Ueberlauf nicht einmal: DREI VON VIER KACHELN SIND UNERREICHBAR. > **Es ist eine Luecke zwischen zwei Grenzen, nicht ein falscher > Wert.** `width:100%` gilt ab 900 px abwaerts (dieser Block), > `flex-wrap:wrap` erst ab 640 px abwaerts (style.css:33710). > Dazwischen - 641 bis 900 - gilt das eine ohne das andere. Genau > dort liegen iPad mini (768) und iPad Pro 11" (834). Dieser Block sagt seit v1941d „untereinander" und meint es auch; er hat es nur der REIHE nie gesagt, sondern nur der Leiste und der Kachel. */ #oab-bar.dp-pfbar .dp-pf-row, .dp-pf-scroll .dp-pfbar .dp-pf-row { flex-wrap: wrap !important; } /* ── v2117a · DER ABRUFEN-KNOPF STAND EINGERUECKT UND RANDVOLL ─────── Marcel: „In der Ansicht iPhone 14 Pro Max ist der Abrufen-Button riesig, das ist doch nicht richtig gerendert." GEMESSEN bei 430 px: .dp-pf-tile 398 x 44 @16 <- alle Kacheln #oab-run 356 x 50 @51 <- der Knopf, 83 % der Breite Er ist also WEDER so breit wie die Kacheln NOCH an ihnen ausgerichtet - 35 px eingerueckt und trotzdem fast randvoll. Genau diese Mischung liest sich als „falsch gerendert". Die Ursache sitzt nicht am Knopf, sondern an seiner Huelle: span.dp-pf-rz padding: 0 20px margin-left: 14px Beides stammt aus der Schreibtisch-Fassung, wo die Huelle neben anderen Dingen in einer Zeile steht. Im Spaltenmodus hat sie keine Nachbarn mehr - die Einrueckung bleibt trotzdem stehen. > Der Block hier setzt fuer jedes Kind `min-width:0` und > `max-width:100%`, aber keine Abstaende. Eine Huelle, die ihre > Zeilen-Abstaende in den Spaltenmodus mitnimmt, richtet ihren > Inhalt an etwas aus, das es dort nicht mehr gibt. Der Knopf steht jetzt buendig unter den Kacheln und so breit wie sie - eine Hauptaktion, die zur Spalte gehoert, in der sie steht. */ /* ⚠ Die Geschwister-Fassung MUSS mitgenannt werden. Mein erster Entwurf listete nur `.dp-pf-rz` - und `padding` und `width` griffen, `margin-left` nicht. Der Walker fand den Grund: #oab-bar.dp-pfbar .dp-pf-qr + .dp-pf-rz { margin-left:14px !important } Eine Klasse mehr als meine Fassung, also hoehere Spezifitaet - und ein Medienblock aendert daran nichts, Media-Queries zaehlen nicht mit. Gemessen blieb der Knopf deshalb bei x=31 statt x=16, waehrend Breite und Polsterung laengst stimmten. > Eine Regel, die zur HAELFTE greift, ist schwerer zu sehen als eine, > die gar nicht greift: die Haelfte, die wirkt, sieht aus wie Erfolg. */ #oab-bar.dp-pfbar .dp-pf-rz, #oab-bar.dp-pfbar .dp-pf-qr + .dp-pf-rz, .dp-pf-scroll .dp-pfbar .dp-pf-rz, .dp-pf-scroll .dp-pfbar .dp-pf-qr + .dp-pf-rz { margin-left: 0 !important; margin-right: 0 !important; padding-left: 0 !important; padding-right: 0 !important; width: 100% !important; } #oab-bar.dp-pfbar .dp-pf-rz .dp-pf-launch, .dp-pf-scroll .dp-pfbar .dp-pf-rz .dp-pf-launch { width: 100% !important; justify-content: center !important; } /* ── v1941e · DIESELBE KETTE AUCH AUF DEM HANDY ────────────────────── Nach v1941d standen die Kacheln untereinander und 44 px hoch - aber die Leiste lief weiter um 14 px ueber (369 > 355). Der Grund ist derselbe wie am Schreibtisch: die Zwischenebene (.dp-pf-lead, .dp-pf-seg, .dp-pf-rz) und ihre Nachfahren tragen min-width:auto. Die Regel dafuer stand nur im 901px-Block. > Eine Diagnose gilt fuer die Ursache, nicht fuer die Breite, bei der man > sie gestellt hat. Wer sie in einem Medienblock anwendet, muss den > anderen gleich mitnehmen. */ #oab-bar.dp-pfbar > *, .dp-pf-scroll .dp-pfbar > *, #oab-bar.dp-pfbar *, .dp-pf-scroll .dp-pfbar * { min-width: 0 !important; max-width: 100% !important; } #oab-bar.dp-pfbar, .dp-pf-scroll .dp-pfbar, .dp-pf-scroll { overflow-x: hidden !important; } } /* ============================================================================== v2117 - DIE TABLET-STUFE: ZWEI SPALTEN STATT EINER LANGEN SAEULE Der Block darueber macht aus den Kacheln eine Saeule - richtig auf dem Handy, aber auf einem 768er Tablet werden daraus vier Vollbreit-Kacheln untereinander, und die Leiste wird unnoetig hoch. Marcels Vorgabe im Pruef-Prompt: "Tablet: Ein bis zwei Spalten abhaengig vom verfuegbaren Platz." GEMESSEN, warum zwei und nicht drei: `.dp-pf-tile.tool` traegt eine Mindestbreite von 200 px. Bei 767 px abzueglich Rand und Abstand bleiben rund 695 px nutzbar - drei Spalten waeren 229 px und damit knapp, zwei sind 344 px und tragen auch lange Beschriftungen. Der Abstand der Reihe ist 6 px (gemessen), deshalb 50 % minus 3 px. Die Grenze unten ist 641 px: darunter gilt wieder eine Spalte, und genau dort setzt auch `style.css:33710` seit jeher an. Beide Grenzen liegen jetzt auf demselben Wert - das war der Fehler, den dieser Durchgang gefunden hat. ============================================================================== */ @media (min-width: 641px) and (max-width: 900px) { #oab-bar.dp-pfbar .dp-pf-tile, .dp-pf-scroll .dp-pfbar .dp-pf-tile { width: calc(50% - 3px) !important; max-width: calc(50% - 3px) !important; } /* ── v2118 · DER QR-CODE ZIEHT NEBEN DEN KOPF ─────────────────────── Marcel am 11.10.2026: „Die Positionierung des QR-Codes beim iPad Pro 11 und mini ist nicht gut, der könnte dann eher neben das DealPilot. Dann sparen wir uns Höhe." GEMESSEN bei 833 px, Leiste 761 x 427: .dp-pf-lead 761x70 @0,0 Inhalt nur 129 px breit: „BOARDING PASS", „PRE-FLIGHT", „DealPilot · Boarding" a#oab-pf-qr 54x68 @353,318 <- eigene Zeile, mittig Rechts neben dem Kopf sind **632 px frei**, und die Leiste ist `position:relative`. Der QR passt dort hinein, ohne irgendetwas zu verdraengen - und seine eigene Zeile faellt weg. > Ein Element, das eine ganze Zeile fuer sich beansprucht, waehrend > daneben 632 px leer stehen, kostet Hoehe ohne Gegenwert. Auf einem > Tablet im Hochformat ist Hoehe das Knappe, nicht Breite. Nur in diesem Band: auf dem Handy ist der Kopf schmaler und der QR wuerde den Text beruehren - dort bleibt er, wo er ist. */ #oab-bar.dp-pfbar { position: relative !important; } #oab-bar.dp-pfbar > .dp-pf-qr, #oab-bar.dp-pfbar > a.dp-pf-qr { position: absolute !important; top: 8px !important; right: 16px !important; left: auto !important; bottom: auto !important; margin: 0 !important; z-index: 3 !important; } } /* ============================================================================== v1941a - DIE ZEILE BLEIBT FLACH: SCHRUMPFEN STATT UMBRECHEN Marcel zum Stil Zeile: "Das passt soweit." Nach v1941 war sie von 89 auf 190 px gewachsen - der Umbruch hat die Scrollleiste beseitigt und dafuer eine zweite Reihe erzeugt. Beides wollte er nicht. GEMESSEN, warum es nicht passte: Kachel Breite flex DealPilot123 175 px 0 1 auto Exposé / Marktbericht 183 px 0 1 auto Sprache 107 px 0 1 auto Gefuehrte Eingabe 158 px 0 1 auto ImmoMetrica 136 px 0 1 auto Summe 759 px bei 753 px Platz **Sechs Pixel.** Die Kacheln standen auf `flex: 0 1 auto` - die 0 heisst "waechst nicht", und weil der Text nicht umbricht, schrumpften sie auch nicht. Fuenf Kacheln, die zusammen sechs Pixel zu breit sind, erzeugten eine ganze zweite Reihe. > **Zwischen Schieben und Umbrechen gibt es eine dritte Antwort: teilen.** > Mit `flex: 1 1 auto` und `min-width: 0` nehmen sich die Kacheln den Platz > gemeinsam und geben nach, wenn er knapp wird. Der Umbruch aus v1941 > bleibt als Rueckfall - er greift erst, wenn auch Teilen nicht mehr reicht. Das Label bekommt dafuer eine Ellipse statt eines Ueberlaufs: lieber ein gekuerztes Wort in der Reihe als ein vollstaendiges ausserhalb. ============================================================================== */ @media (min-width: 901px) { /* ── v1941b · NOWRAP, SONST BRICHT ES VOR DEM SCHRUMPFEN ───────────── Nach v1941a stand `flex: 1 1 auto` und `min-width: 0` an den Kacheln - und es brach trotzdem auf zwei Reihen um. Gemessen: Kachel weiterhin 175 px breit, obwohl sie haette nachgeben duerfen. > **Flexbox schrumpft nur INNERHALB einer Zeile.** Mit `flex-wrap: wrap` > schiebt es die Kachel erst in die naechste Reihe und schrumpft sie dort > gar nicht mehr - das Umbrechen kommt VOR dem Teilen. Wer teilen will, > muss das Umbrechen verbieten. Deshalb am Schreibtisch `nowrap`. Auf dem Handy bleibt es dabei, dass die Kacheln untereinander stehen (eigene Regel weiter unten) - dort ist Umbrechen genau richtig. */ /* ══ v2122 · ZURUECKGENOMMEN ═══════════════════════════════════════ Die Deklarationen von v1941a-d standen hier bis zum 11.10.2026 und haben das Gegenteil von v2119 getan: Umbrechen verbieten, alles schrumpfen lassen, Beschriftungen mit einer Ellipse kappen. Marcel am 11.10.2026: "Wenn wir Desktop 1180 ausgewaehlt haben kann man die auswahl nicht lesen unter Daten einlesen." Gemessen bei 1180 px: vier Beschriftungen gekappt, "Sprache" auf 15 von 43 px. Die Ellipse hat genau das getan, was sie sollte. > **v1941 war nicht falsch - es war die bessere von zwei schlechten > Antworten.** Damals ging es um SECHS Pixel Ueberbreite, und ein > Umbruch wegen sechs Pixel ist teurer als eine Ellipse. Die Lage > ist heute eine andere: es fehlen 90 px, nicht 6, und v2119 kann > umbrechen, ohne zu kappen. Sie werden hier AUSGETRAGEN und nicht nur ueberschrieben. Ein Stapel aus zwei Versionen, die sich widersprechen, ist genau das, wovor der Kopf dieser Datei bei v1702d warnt ("Zwei Ebenen bauten dieselbe Flaeche um"). Die Kommentare bleiben stehen - der Befund von damals ist weiter richtig und erklaert, warum hier nichts mehr steht. `overflow-x: hidden` auf Leiste und Wrapper bleibt: mit Umbruch laeuft nichts mehr quer, und wenn doch, soll kein Balken stehen. ══════════════════════════════════════════════════════════════ */ /* ── v1941c · DIE KINDER WAREN DER GRUND, NICHT DIE KACHEL ─────────── Dritter Anlauf an derselben Stelle, und die ersten beiden haben die Kachel angesehen statt ihren Inhalt. GEMESSEN mit einer Probe: `width:80px !important` auf die Kachel erzwungen - sie blieb bei 92 px. Dort liegt ihre Mindestbreite, und sie kommt von unten: .dp-pf-logo 61 px min-width: auto .dp-pf-stufen 60 px min-width: auto .dp-pf-led 9 px min-width: auto > **`min-width: auto` ist der Standard jedes Flex-Kindes, und er wirkt > nach unten durch.** Eine Kachel auf `min-width: 0` zu setzen nuetzt > nichts, solange ihre eigenen Kinder sich weigern. Wer eine Flaeche > schrumpfbar machen will, muss die ganze Kette oeffnen, nicht ihren > obersten Knoten. Fuenf Kacheln a 92 px sind 460 px - das passt in die 753 px zweimal. Damit reicht Teilen, und weder Schieben noch Umbrechen wird gebraucht. */ /* v2122: ausgetragen - siehe Ruecknahme oben. */ /* Und die Leiste selbst darf nicht mehr scrollen - sonst bleibt die Scrollleiste stehen, auch wenn nichts mehr ueberlaeuft. */ #oab-bar.dp-pfbar, .dp-pf-scroll .dp-pfbar, .dp-pf-scroll { overflow-x: hidden !important; } /* v2122: ausgetragen - die Ellipse war Marcels Befund. */ } /* ============================================================================== v1941d - DIE ECHTE KETTE, NACH VIER ANLAEUFEN AUF DER FALSCHEN EBENE v1941, a, b und c haben an `.dp-pf-tile` gearbeitet - den Kacheln. Erst die Auszaehlung ALLER direkten Kinder der Leiste zeigte, dass die Kacheln gar nicht dort liegen: .dp-pf-stripe 753 px (Hintergrundstreifen) .dp-pf-lead 149 px flex: 0 0 auto <- kann nicht schrumpfen .dp-pf-seg 175 px .dp-pf-seg 602 px <- HIER liegen die Kacheln #oab-pf-qr 54 px .dp-pf-rz 208 px min-width: 208px <- fest verdrahtet Zusammen 1188 px plus Luecken = 1267 bei 753 px Platz. > **Vier Anlaeufe lang habe ich die Kacheln gemessen und die Leiste > geaendert, ohne die Ebene dazwischen anzusehen.** Wer eine Breite sucht, > zaehlt die DIREKTEN Kinder des Containers - nicht die Elemente, die er > fuer die Ursache haelt. Die Summe haette den Irrtum beim ersten Mal > gezeigt: 5 x 175 sind 875, gemessen waren 1267. Geoeffnet wird jetzt die ganze Kette: Segmente duerfen schrumpfen, der Abrufknopf verliert seine feste Mindestbreite, und alle Nachfahren geben ihr `min-width: auto` auf. Der Abrufknopf bleibt lesbar - er behaelt sein Polster und schrumpft nur so weit, wie die anderen auch. ============================================================================== */ @media (min-width: 901px) { /* v2122: Segmente duerfen weiter schrumpfen - aber nur bis zu einer Kachel, und das setzt v2119 mit min-width:min-content. Lead und Stub bekommen dort flex:0 0 auto. Hier stehen sie nicht mehr. */ #oab-bar.dp-pfbar > .dp-pf-seg, .dp-pf-scroll .dp-pfbar > .dp-pf-seg { flex: 1 1 auto !important; } /* v2122: AUSGETRAGEN. Das war die schlimmste der fuenf: eine Sammelregel auf JEDEN Nachfahren der Leiste. Sie hat jeden spaeteren Schutz von unten wieder aufgehoben - genau die Form, vor der CLAUDE.md warnt ("nie Sammelregeln auf Container-Kinder"). Was wirklich schrumpfen darf, nennt v2119 einzeln. */ } /* ══ v1953 · DIE BORDKARTE DER DATENAUFNAHME IST ENTFERNT ═══════════════ Marcel am 07.10.2026: "die kann wirklich raus." Entfernt wurden 32 Regeln, die ausschliesslich an html[data-dp-kartenstil="bordkarte"] hingen. GEMESSEN, nicht geschaetzt: 34 Regeln nannten den Wert, davon 32 nur ihn; die beiden anderen sind TRICHTER-Regeln, die die Bordkarte per :not(...) ausschliessen. Die sind geblieben - :not() traegt die Spezifitaet seines Arguments, ein Wegfall haette die Kaskade des Trichters verschoben. Der Wert ist auch ueber ?karte= nicht mehr erreichbar (karten-stil.js), sonst holte die Adresszeile einen Stil zurueck, dessen Regeln es nicht mehr gibt. Die Objektkarten-Bordkarte (data-dp-objkarte="bordkarte") ist eine ANDERE Sache und bleibt - sie ist seit v1915 der Rueckfall der Aktenmappe. ══════════════════════════════════════════════════════════════════ */ /* ================================================================= v1989 - DER QR FAELLT UNTER 640 px Marcel am 08.10.2026: „Da kannst du dann, wenn das nicht passend dargestellt wird, den Barcode fuer die Handy-Version oder auch Tablet-Version rausnehmen." GEMESSEN auf 390 px, Entwurf Kartei: QR-Kasten 64 x 92 nicht quadratisch SVG darin 54 x 68 nicht quadratisch Ursache, mit dem Kaskaden-Walker gefunden: diese Datei setzt `width:92px !important` auf den Kasten - und unter `@media (max-width:900px)` ein `max-width:100% !important` auf JEDES Kind der Leiste. Die Breite wird gekappt, die HOEHE bleibt bei 92. Also ein gestauchter Code. > Ein QR, der nicht quadratisch ist, laesst sich nicht zuverlaessig > scannen. Er sieht aus wie ein Angebot und ist keins. Im Entwurf Buetten ist er 64x64 und damit quadratisch, nimmt aber denselben knappen Platz. Marcels Freigabe deckt beide. Die doppelte Klasse `.dp-pf-qr.dp-pf-qr` ist ABSICHT und steht hier benannt, damit sie niemand fuer einen Tippfehler haelt: vorhanden html[data-dp-kartenstil="kartei"] .dp-pfbar > .dp-pf-qr {display:flex!important} (0,3,2) neu html[data-dp-kartenstil] .dp-pfbar > .dp-pf-qr.dp-pf-qr {display:none!important} (0,4,2) Dieselbe Hausform fuehrt diese Datei weiter oben schon einmal. ================================================================= */ /* v1992 - DIE REGEL AUS v1989 HATTE KEINE ID UND WAR DAMIT WIRKUNGSLOS. Hier stand eine @media (max-width:640px) mit html[data-dp-kartenstil] .dp-pfbar > .dp-pf-qr.dp-pf-qr also (0,4,1). Dagegen steht weiter oben in dieser Datei html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources) .dp-pfbar > .dp-pf-qr{display:flex !important} und :is() erbt die Spezifitaet seines STAERKSTEN Arguments - hier eine ID. Also (1,3,2). Die alte Regel konnte nie gewinnen. Im Browser gegengeprueft (mit echter Wartezeit, sonst misst man den Zustand VOR der eigenen Aenderung): ohne ID -> 64x92, display flex wirkungslos mit ID -> 0x0, display none Grenze 900 px: Marcels Freigabe nennt Handy UND Tablet. */ @media (max-width: 900px){ html[data-dp-kartenstil] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-qr, html[data-dp-kartenstil] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-qr, html[data-dp-kartenstil] .dp-pf-scroll :is(#oab-bar,#qc7-sources) .dp-pf-qr{ display:none !important; } } /* v1992 - DER KASTEN WAR 64 BREIT UND 92 HOCH Zwei Regeln aus zwei Versionen, die nie zusammen gelesen wurden: Z1182 :is(#oab-bar,..) > .dp-pf-qr{width:64px;height:64px} (1,3,2) Z1596 > .dp-pf-qr.dp-pf-qr{min-width:92px;min-height:92px} (0,4,2) Die ID-Regel gewinnt fuer height - aber min-height setzt NIEMAND mit ID, also bleibt die 92 stehen. Und min-height schlaegt height. Ergebnis: 64 breit, 92 hoch. Keine der beiden Regeln ist falsch; zusammen ergeben sie einen schiefen Kasten. Aufgeloest zu 92 x 92 - der Hoehe, die er ohnehin hat. Gemessen: Kasten 92x92, der gezeichnete Code waechst von 54 auf 68 px, die Leiste bleibt 132 px hoch. > Der QR war uebrigens die ganze Zeit scannbar: sein viewBox ist > 0 0 31 31 und ohne preserveAspectRatio gilt xMidYMid meet, das das > Verhaeltnis WAHRT. Schief war der Kasten, nicht der Code. */ @media (min-width: 901px){ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-qr{ width:92px !important; height:92px !important; min-width:92px !important; min-height:92px !important; } } /* ===================================================================== v2119 - DIE LEISTE KNAUTSCHTE, STATT UMZUBRECHEN Marcel am 11.10.2026: "Wenn wir Desktop 1180 ausgewaehlt haben kann man die auswahl nicht lesen unter Daten einlesen und auch das Dealpilot unter Marktbewertung auf der Datenaufnahme Karte. QR Code passt dann garnicht und ueberlappt." GEMESSEN bei 1180 px, Aktenmappe, direkte Kinder von #oab-bar: Leiste 888 x 107 row / NOWRAP SUMME der Kinder 888 "passt" .dp-pf-lead 104 flex 0 1 auto min-width 0 .dp-pf-seg 126 flex 1 1 auto min-width 0 .dp-pf-seg 438 flex 1 1 auto min-width 0 a.dp-pf-qr 39 x 68 natuerlich 47 - SVG darin 54 x 54 .dp-pf-rz 101 natuerlich 109 Beschriftungen sichtbar / Inhalt "Expose / Marktbericht" 67 / 120 "Sprache" 15 / 43 "Gefuehrte Eingabe" 50 / 95 "ImmoMetrica" 35 / 73 > DAS IST KEIN UEBERLAUF. Die Summe der Kinder ist exakt die > Innenbreite - weil jedes Kind schrumpfen DURFTE. `flex-shrink:1` > plus `min-width:0` heisst: lieber alles unleserlich als eine > zweite Zeile. Wer nach einem Ueberlauf sucht, findet hier nichts > und haelt die Leiste fuer gesund. Und es ist ausdruecklich NICHT vom Fenster abhaengig, sondern von der Breite der Leiste selbst - gemessen: Fenster Seitenleiste Leiste 1024 260 1150 (Querscroller, alles voll gross) 1180 380 888 kaputt 1280 380 856 kaputt 1440 380 1016 kaputt 1920 380 1280 heil Deshalb KEIN weiterer Haltepunkt. Haltepunkte sind hier die falsche Form: sie beschreiben das Fenster, der Schaden haengt am Behaelter. Stattdessen wird die Bauart selbst tragfaehig gemacht: 1. Die Leiste darf umbrechen (flex-wrap:wrap) 2. Die Kachelreihen duerfen umbrechen 3. Kacheln und QR schrumpfen NICHT (flex:0 0 auto) Damit regelt sich jede Behaelterbreite von selbst - auch die, die es heute noch nicht gibt. Hoehe statt Unleserlichkeit; Marcel: "wenn etwas nicht gerendert werden kann musst du es anders anzeigen lassen oder umbauen fuer die groesse." Die Grenze 901 ist Absicht: darunter liegt die Leiste bereits als Spalte (flex-direction:column ab Z.1958) und der QR ist ausgeblendet. ===================================================================== */ @media (min-width: 901px){ /* 1 - die Leiste bricht um statt zu stauchen */ :is(#oab-bar,#qc7-sources).dp-pfbar, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar{ flex-wrap: wrap !important; row-gap: 10px !important; } /* 2 - die Kachelreihe bricht um */ :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-row, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-row{ flex-wrap: wrap !important; } /* 3 - Kacheln behalten ihre Beschriftung. flex-basis bleibt `auto`, damit die Spaltenbreiten der schmalen Baender (width:100% / calc(50% - 3px)) weiter greifen - dort gilt dieses Band nicht, aber die Regel soll auch dann nichts umwerfen. */ :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-tile, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-tile{ flex: 0 0 auto !important; min-width: max-content !important; } :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-lbl, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-lbl{ overflow: visible !important; text-overflow: clip !important; white-space: nowrap !important; } /* 4 - der QR bleibt quadratisch und wird nicht zusammengedrueckt. Das SVG darin ist 54 px; der Kasten bekommt 54 plus Luft. */ :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-qr, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-qr{ flex: 0 0 auto !important; min-width: 62px !important; min-height: 62px !important; } /* 5 - der Abruf-Knopf schrumpft nicht unter seine Schrift */ :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-rz, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-rz{ flex: 0 0 auto !important; } :is(#oab-bar,#qc7-sources).dp-pfbar button#oab-run{ flex: 0 0 auto !important; white-space: nowrap !important; } /* 6 - die Segmente duerfen schrumpfen, aber nur bis zu einer Kachel; darunter wandern sie in die naechste Zeile statt die Beschriftungen zu kappen. */ :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg{ min-width: min-content !important; } } /* ===================================================================== v2120 - DER ABRUF-KNOPF WAR GOLD AUF GOLD Marcel am 11.10.2026: "Beim IPhone 14 ist der Abrufbutton fast so gross das es das komplette weisse verdeckt und auch im gleichen gold ton." GEMESSEN auf 390 px, Aktenmappe, kein Kartenstil: #oab-bar 357 x 439 Grund Verlauf rgb(201,170,84) <- GOLD .dp-pf-rz 325 x 57 Grund #ffffff, Rand 1,5 px Gold #oab-run 323 x 50 Grund Verlauf rgb(207,178,96) <- GOLD Beide Befunde sind EIN Befund: der Knopf ist 323 breit in einem Stub von 325 und sitzt mit `margin:6px 0 0` oben an. Links und rechts bleibt je 1 px weiss, unten 1 px. Vom "weissen Boarding-Stub" ist damit ein Strich uebrig - und der Knopf selbst traegt dieselbe Farbe wie die Leiste hinter dem Stub. Kontrast Knopf gegen Leiste: k = 1,07. Das Einzige, was den Knopf noch sichtbar macht, ist der 1 px Rest des Stubs. ── WARUM ER GOLD WAR, UND WARUM DAS EINMAL RICHTIG WAR ──────────── Mit dem Kaskaden-Walker, nicht geraten. Es gewinnt: (2,1,0) ! #obj-action-bar #oab-run.dp-pf-launch background: linear-gradient(180deg,var(--gold-hi),var(--gold)) style.css, Block "v601-oab-gold-hard" Darunter liegen drei Staende derselben Flaeche: v597 weiss + Goldtext, Stub weiss mit Goldrand v599 GOLD + dunkler Text <- die Umstellung v601 dasselbe, noch einmal mit ID festgenagelt Und die Grundregel in style.css:33064 sagt bis heute `background:#050505; color:var(--gold-hi)`. Also: Obsidian mit Goldschrift war der Ausgangszustand, Gold kam spaeter. > v599 war nicht falsch. Die Leiste war damals DUNKEL. Gold auf > dunkel ist der Akzent. Die Leiste hat spaeter den Runway-Verlauf > bekommen - und damit wurde aus dem Akzent dieselbe Farbe wie der > Grund. Keine der beiden Entscheidungen ist fuer sich falsch; > zusammen ergeben sie einen unsichtbaren Knopf. Das ist dieselbe Form wie [[farbe-gilt-nur-zu-ihrem-grund]]: eine Farbe gilt nur zu dem Grund, zu dem sie gewaehlt wurde. Wandert der Grund, wandert die Beziehung nicht mit. ── WAS HIER GESETZT WIRD ────────────────────────────────────────── Der Knopf wird wieder Obsidian mit Goldschrift - die Hausform, die `.dp-pf-lead` und `.dp-pf-tile.tool` in derselben Leiste schon tragen. Damit traegt er Kontrast zu BEIDEN Gruenden: zum weissen Stub und zum goldenen Verlauf dahinter. Und der Stub bekommt Polster, damit er wieder ein Stub ist und nicht ein Rand: 6 px rundum statt 6 px nur oben. Spezifitaet: `:is(#oab-bar,#qc7-sources).dp-pfbar #oab-run.dp-pf-launch` ist (2,2,0) und schlaegt die (2,1,0) von v601 - ohne `#obj-action-bar` zu nennen, damit dieselbe Regel im Quick-Check-Dokument greift, wo es diesen Behaelter nicht gibt. ===================================================================== */ :is(#oab-bar,#qc7-sources).dp-pfbar #oab-run.dp-pf-launch, :is(#oab-bar,#qc7-sources).dp-pfbar #oab-run.dp-pf-launch:hover, :is(#oab-bar,#qc7-sources).dp-pfbar #oab-run.dp-pf-launch:focus, :is(#oab-bar,#qc7-sources).dp-pfbar #oab-run.dp-pf-launch:active, :is(#oab-bar,#qc7-sources).dp-pfbar .qc6-run.dp-pf-launch, :is(#oab-bar,#qc7-sources).dp-pfbar .qc6-run.dp-pf-launch:hover{ background: #0A0A0A !important; background-image: none !important; color: var(--gold-hi, #E8CC7A) !important; border: none !important; box-shadow: 0 2px 8px -3px rgba(0,0,0,.45) !important; letter-spacing: .4px !important; font-weight: 600 !important; } :is(#oab-bar,#qc7-sources).dp-pfbar #oab-run.dp-pf-launch:hover{ background: #141210 !important; } :is(#oab-bar,#qc7-sources).dp-pfbar #oab-run.dp-pf-launch .dp-pf-ic, :is(#oab-bar,#qc7-sources).dp-pfbar #oab-run.dp-pf-launch .dp-pf-ic svg{ color: var(--gold-hi, #E8CC7A) !important; stroke: var(--gold-hi, #E8CC7A) !important; } /* Der Stub bekommt rundum Luft, damit er als Stub lesbar bleibt. `overflow:hidden` steht dort bereits - das Polster kann also nicht durch einen Ueberlauf wieder verschwinden. */ :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-rz{ padding: 6px !important; box-sizing: border-box !important; } :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-rz > #oab-run.dp-pf-launch{ margin: 0 !important; } /* ===================================================================== v2121 - AUF DEM IPAD STAND DIE LEISTE 1263 px BREIT IN 695 px Marcel am 11.10.2026: "fuer mich passt die Datenaufnahme Karte immer noch nicht. Hab in der Messkabien gerade IPad mini auf und es ist alles verzwerrt." GEMESSEN, iPad mini 768 px, Kartenstil "Kartei": .dp-pf-scroll 695 x 383 clientW 695 scrollW 1263 overflow-x: HIDDEN #oab-bar 1263 x 363 width: 1263,32 px min-width: 100% .dp-pf-lead 1261 x 38 flex 1 0 100% .dp-pf-seg 202 x 246 .dp-pf-seg 664 x 246 <- die Kacheln, je ~631 px .dp-pf-rz 1261 x 65 568 px Inhalt liegen ausserhalb des Behaelters, und der Behaelter klippt sie. Kein Balken, kein Hinweis - sie sind einfach weg. ── DIE URSACHE SIND ZWEI REGELN GLEICHER STAERKE ────────────────── Mit dem Kaskaden-Walker am Element, nicht gegrept: (0,2,0) ! .dp-pf-scroll .dp-pfbar width: max-content style.css @(min-width:641px) and (max-width:1100px) (0,1,0) ! .dp-pf-scroll overflow-x: auto style.css @(min-width:641px) and (max-width:1100px) (0,1,0) ! .dp-pf-scroll overflow-x: hidden datenaufnahme.css @(max-width:900px) <- GEWINNT Beide `overflow-x`-Regeln sind (0,1,0) und wichtig. Entschieden hat die BLATTREIHENFOLGE: `datenaufnahme.css` ist Blatt 16, `style.css` Blatt 1. Also gewinnt `hidden`. > v1892 hat das Tablet-Band bewusst zum Wischen gebaut: `max-content` > macht die Leiste erst ueberlaufbreit, damit der Wrapper etwas zu > scrollen HAT. Eine spaetere Regel hat den Wrapper stillgelegt und > die Breite stehen gelassen. Von einem Paar ist eine Haelfte > uebrig - und die uebrige Haelfte ist genau die schaedliche. Und `width:max-content` erklaert auch die 631 px breiten Kacheln: v2117 gibt ihnen im Band 641-900 `calc(50% - 3px)`. 50 % von 1263 sind 631. Die Prozentangabe war richtig, ihr Bezug war es nicht. ── DIE ENTSCHEIDUNG, AUSDRUECKLICH ─────────────────────────────── **Das Wischen wird fuer diese Leiste zurueckgenommen, nicht repariert.** Marcel im Pruefauftrag: "Unbeabsichtigtes horizontales Scrollen" steht dort unter den Fehlern, und "Verkleinere Desktop-Elemente nicht einfach proportional ... Entscheide stattdessen anhand des Inhalts, welche mobile Darstellungsform funktional und gestalterisch am besten geeignet ist." Seit v2119 kann die Leiste das, was sie damals nicht konnte: umbrechen, ohne ihre Beschriftungen zu kappen. Damit braucht sie keinen zweiten Mechanismus mehr. v1892 war nicht falsch - es war die beste Antwort, solange Umbrechen Unleserlichkeit bedeutete. Der Wisch-Hinweis (`.dp-pf-scroll::after`) faellt im selben Band mit: ein Schatten, der "hier geht es weiter" sagt, wo es nicht weitergeht, ist schlimmer als keiner. Fuer "kartei" und `dp-pfzeile` war er schon aus - jetzt fuer jeden Stil. ===================================================================== */ @media (min-width: 641px) and (max-width: 1100px){ /* 1 - keine Ueberlaufbreite mehr. (1,2,0) gegen die (0,2,0) aus v1892. */ .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar, :is(#oab-bar,#qc7-sources).dp-pfbar{ width: auto !important; min-width: 0 !important; max-width: 100% !important; flex-wrap: wrap !important; row-gap: 8px !important; } /* 2 - der Wrapper scrollt nicht mehr und klippt auch nichts. (0,2,0) ueber :has gegen die (0,1,0) beider Vorgaenger. */ .dp-pf-scroll:has(.dp-pfbar){ overflow-x: visible !important; padding-bottom: 0 !important; } /* 3 - der Wisch-Hinweis luegt ohne Wischen. */ .dp-pf-scroll:has(.dp-pfbar)::after{ content: none !important; display: none !important; background: none !important; width: 0 !important; } /* 4 - Lead und Stub hatten `flex:1 0 100%` und damit eine eigene Zeile. Das war fuer die Wischzeile gedacht; beim Umbruch reicht `auto`, dann teilen sie sich eine Zeile, wenn Platz ist. 100 % bleibt als Mindestanspruch NICHT stehen. */ .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-lead, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-rz{ flex: 0 0 auto !important; } } /* ===================================================================== v2121a - TOUCHFLAECHEN AUF DEM TABLET Aus demselben Lauf, 32 Messungen (4 Datenaufnahme-Stile x 8 Geraete): Geraet Abruf-Knopf Kacheln iPad mini 768 33 px - iPad Pro 11 834 33 px - 1180 33 px 34-35 px 1280 33 px 34-35 px Marcel im Pruefauftrag: "Touchflaechen sind ausreichend gross. Buttons lassen sich bequem mit dem Finger bedienen." > **Das Band 1024-1180 ist in Marcels eigener Geraeteliste > "Tablet Querformat"** - das iPad Pro 11 ist im Querformat > 1194 px breit. Eine Breite ueber 1024 heisst also nicht Maus. Deshalb 44 px Mindesthoehe von 641 bis 1200 px, und darueber bleibt es kompakt. `@media (pointer:coarse)` waere der genauere Weg - er ist in der Messkabine aber NICHT pruefbar (das iframe laeuft in einem Chrome mit Maus), und eine Regel, die ich nicht nachmessen kann, ist hier die schlechtere. ===================================================================== */ @media (min-width: 641px) and (max-width: 1200px){ :is(#oab-bar,#qc7-sources).dp-pfbar button#oab-run, :is(#oab-bar,#qc7-sources).dp-pfbar .qc6-run.dp-pf-launch{ min-height: 44px !important; padding-top: 10px !important; padding-bottom: 10px !important; } :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-tile{ min-height: 44px !important; align-items: center !important; } } /* ===================================================================== v2123 - ZWEI RESTE, DIE HOEHE KOSTEN Nach v2119/v2121 ist die Leiste auf allen 48 Messungen heil (0 abgeschnitten, 0 draussen, 0 Ueberschneidung, 0 Querscroller). Sie ist aber hoeher als noetig. Gemessen bei 1180 px, direkte Kinder: .dp-pf-lead 128 x 87 top 0 .dp-pf-seg 693 x 87 top 0 <- EIN Kachel-Segment, 693 breit .dp-pf-seg 604 x 87 top 97 .dp-pf-qr 62 x 68 top 107 .dp-pf-rz 208 x 87 top 97 min-width: 208px Zwei Reste erklaeren beides: 1 · `.dp-pf-seg` traegt `flex: 1 1 auto`. Die 1 vorne heisst WACHSEN. Das erste Segment enthaelt genau EINE Kachel von 173 px und blaeht sich auf 693 px auf - es frisst den freien Platz der ersten Zeile, und alles andere muss in die zweite. > Wachsen und Umbrechen zusammen ergeben die schlechteste > Verteilung: das erste Element nimmt alles, der Rest bricht um. > Wachsen war fuer `nowrap` gedacht (v1941d) - mit `wrap` ist es > genau falsch. 2 · `.dp-pf-rz` traegt `min-width: 208px` (style.css, v597). Die 208 px sind das Mass der Reisszone der BORDKARTE, in der ein Strichcode von 174 x 52 stand. Der Strichcode (`.dp-pf-bc`) ist seit v1639 `display:none` und gemessen 0 x 0. Uebrig ist ein Knopf von 83 px in einem Kasten von 208. > Ein Mass, das fuer einen entfernten Inhalt gesetzt wurde, > bleibt stehen und wirkt weiter. 125 px fuer nichts. Beides im Band 901+ zurueckgenommen. Gegengerechnet: bei 1440 px war die Summe der Kinder 1370 bei 1148 Platz; ohne die 125 px sind es 1245, und ohne das Wachsen verteilt sich der Rest sinnvoll. ── UND EINE RUECKNAHME ──────────────────────────────────────────── Mein Pruefer hat in 10 von 48 Laeufen "QR-SVG schief" gemeldet (kartei 82x68 in 92x92, buetten 52x48 in 64x64). **Das war ein Messfehler, kein Befund.** Gemessen am gezeichneten Code selbst: kartei erstes rect 64 x 64 QUADRATISCH buetten erstes rect 41 x 41 QUADRATISCH Der viewBox ist `0 0 31 31`, und ohne `preserveAspectRatio` gilt `xMidYMid meet` - das Verhaeltnis wird GEWAHRT, der Code sitzt zentriert im Kasten. Schief ist das svg-ELEMENT, nicht das Bild darin. Genau das steht schon im Kommentar bei v1992, und ich habe es trotzdem als Befund gemeldet. Eine Probe mit `aspect-ratio:1` am svg hat es nachweislich VERSCHLECHTERT (buetten: rect von 41x41 auf 36x36), also wird hier nichts geaendert. Der Pruefer misst ab jetzt das `rect`. ===================================================================== */ @media (min-width: 901px){ /* 1 - Segmente wachsen nicht mehr */ :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg{ flex-grow: 0 !important; } /* 2 - der Stub ist so breit wie sein Inhalt, nicht wie ein entfernter Strichcode */ :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-rz, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-rz{ min-width: fit-content !important; } } /* ===================================================================== v2123a - `overflow-x: visible` KAM ALS `auto` HERAUS Gemessen in allen Laeufen im Band 641-1100: `.dp-pf-scroll` meldete `overflow-x: auto`, obwohl v2121 dort `visible !important` setzt und mit (0,2,0) ueber :has gegen (0,1,0) gewinnt. Die Regel gewinnt auch. Sie wird nur UMGERECHNET: steht eine der beiden Achsen auf etwas anderes als `visible`, rechnet der Browser die andere von `visible` auf `auto` um. Und `overflow-y: hidden` steht in demselben Band in style.css. > **Nicht die Kaskade hat entschieden, sondern die Berechnung.** Wer > nur den gemeldeten Wert liest, haelt seine Regel fuer verloren und > sucht an der falschen Stelle nach einem staerkeren Selektor. Heute schadet es nicht (gemessen: 0 Querscroller in 48 Laeufen, es laeuft nichts ueber). Es heisst aber, dass ein Balken erscheinen KANN, sobald doch einmal etwas uebersteht - und dann waere er da, ohne dass jemand ihn gewollt hat. ===================================================================== */ @media (min-width: 641px) and (max-width: 1100px){ .dp-pf-scroll:has(.dp-pfbar){ overflow-y: visible !important; } } /* ===================================================================== v2124 - IM LAPTOP-BAND BRICHT DIE KACHELREIHE, NICHT DIE LEISTE Nach v2119-v2123 ist nichts mehr abgeschnitten und nichts mehr draussen. Die Leiste ist aber bei 1180 px 185 px hoch, und die erste Zeile ist zu zwei Dritteln leer: y 0 lead 128 + perf 1 + seg 173 + sep 1 = 303 von 888 y 97 seg 602 + qr 62 + rz 97 = 761 von 888 Das zweite Segment ist 602 px breit und unteilbar. Es passt nicht neben die 303 - also wandert es in die zweite Zeile und laesst 585 px leer stehen. ── DER UNTERSCHIED, AUF DEN ES ANKOMMT ─────────────────────────── `flex-wrap` auf der LEISTE und `flex-wrap` auf der KACHELREIHE sind zwei verschiedene Dinge, und nur eines von beiden darf wirken: Leiste wrap -> das Segment wandert als Ganzes nach unten Leiste nowrap -> das Segment muss nachgeben, und weil seine eigene Reihe (.dp-pf-row) umbrechen DARF, bricht die Reihe statt die Leiste > **Flexbox bricht um, bevor es schrumpft.** Genau das steht schon im > Kommentar von v1941b. Was dort fehlte: schrumpfen darf der > BEHAELTER, nicht die Kachel. v1941 hat die Kachel schrumpfen lassen > und die Beschriftung gekappt; hier gibt das Segment nach, und die > Kacheln wandern in eine zweite Reihe - in voller Breite. GEMESSEN per Inline-Probe am Element (`style.setProperty(..., 'important')`), 1180 px: wrap 888 x 185 seg2 602 x 87 Reihe 602 x 44 nowrap 888 x 137 seg2 348 x 137 Reihe 348 x 94 48 px weniger, zwei Kachelreihen statt einer halbleeren Leistenzeile, und weiter 0 abgeschnitten / 0 draussen. ── WARUM GENAU 1140 BIS 1400 ───────────────────────────────────── Die Grenzen sind gemessen, nicht gewaehlt. Je Breite wrap gegen nowrap, am laufenden Staging: Breite wrap nowrap 901 581x309 0 581x237 ZWEI DRAUSSEN (+110) 920 600x309 0 600x237 ZWEI DRAUSSEN (+91) 980 660x259 0 660x237 ZWEI DRAUSSEN (+31) 1024 703x248 0 703x237 0 (11 px, nicht wert) 1100 808x183 0 808x187 0 SCHLECHTER 1180 888x185 0 888x137 0 BESSER -48 1280 988x156 0 988x117 0 BESSER -39 1340 1048x134 0 1048x117 0 BESSER -17 1440 1148x 78 0 1148x 78 0 gleich (eine Zeile) 1920 1280x 78 0 1280x 78 0 gleich Unter 1024 reicht die Zeile nicht einmal fuer die Mindestbreiten - `.dp-pf-rz` und der Knopf stehen dann 110 px ausserhalb. Bei 1100 wird es schlechter. Ab 1440 passt alles in eine Zeile, da aendert `nowrap` nichts. Also wirkt es nur dort, wo es gemessen hilft. > Ein Haltepunkt, der nicht an einer Messung haengt, ist eine > Behauptung. Diese beiden haengen an zweiundzwanzig. Der Selektor ist Zeichen fuer Zeichen derselbe wie in v2119 - (1,2,0) gegen (1,2,0), und bei gleicher Spezifitaet gewinnt die SPAETERE Regel. Sie steht deshalb hier unten und nicht dort oben. ===================================================================== */ @media (min-width: 1140px) and (max-width: 1400px){ .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar, :is(#oab-bar,#qc7-sources).dp-pfbar{ flex-wrap: nowrap !important; } /* Die Reihe MUSS umbrechen duerfen - sie ist jetzt die einzige Stelle, an der nachgegeben wird. */ .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-row, :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-row{ flex-wrap: wrap !important; } /* Und die Segmente muessen nachgeben duerfen, bis zu einer Kachel. v2119 setzt das schon; hier noch einmal benannt, damit die Bedingung des Bandes an einer Stelle vollstaendig steht. */ .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg, :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg{ flex: 0 1 auto !important; min-width: min-content !important; } /* Lead, QR und Stub geben NICHT nach - sonst quetscht die Zeile sie statt die Reihe umzubrechen, und genau das war v2119s Befund. */ .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-lead, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-qr, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-rz{ flex: 0 0 auto !important; } } /* ===================================================================== v2126 - ZWEI RESTE AUS DER 72-LAEUFE-ABNAHME Abnahme nach v2124: 4 Kartenstile x 18 Breiten = 72 Messungen. KAPP 0, UEBER 0, ZUBREIT 0, QUER 0, Knopftext k >= 4,5 ueberall. Zwei Dinge blieben. ── 1 · KARTEI: DIE VIER CHIPS STANDEN IN EINER REIHE, DIE NICHT UMBRECHEN DURFTE ────────────────────────────────────────── Gemessen, Kartenstil "Kartei", Reihe `nowrap` gegen `wrap`: Fenster Leiste nowrap wrap 901 581 raus 0 raus 0 940 620 raus 4 raus 0 (Hoehe 320 -> 374) 980 660 raus 2 raus 0 (Hoehe 320 -> 374) 1000 680 raus 0 raus 0 unveraendert 1024 703 raus 0 raus 0 unveraendert 1100 808 raus 0 raus 0 unveraendert 1180 888 raus 0 raus 0 unveraendert 1440 1148 raus 0 raus 0 unveraendert Bei 940 px standen `div.dp-pf-row`, `label.dp-pf-tile` und `span.dp-pf-lbl` **85 px ausserhalb** der Karte. Die Reihe trug `flex-wrap:nowrap` aus dem Kartei-Entwurf (Z. 850) - mit der Begruendung *"Alle vier Chips gleich hoch und gleich gefasst - in einer Reihe faellt jeder Unterschied sofort auf"*. > Die Begruendung stimmt, und sie gilt nur, solange die Reihe passt. > Eine Gestaltungsabsicht, die Inhalt aus der Karte schiebt, ist > keine Gestaltung mehr. `wrap` ist in jeder gemessenen Breite entweder besser oder unveraendert - es greift nur, wenn es muss. Deshalb im ganzen Band 901-1100, nicht nur bei 940. Spezifitaet: der Entwurf nennt html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-row das ist (1,3,1). Hier steht `.dp-pf-scroll` zusaetzlich davor: (1,4,1). ── 2 · EIN PIXEL FENSTERBREITE KOSTETE 17 PX HOEHE ─────────────── Gemessen an der Bandgrenze von v2124: 1400 px Leiste 1108 x 117 nowrap 1401 px Leiste 1109 x 134 wrap <- 17 px hoeher 1440 px Leiste 1148 x 78 eine Zeile Die 1400 war zu frueh gewaehlt. Eine Zeile wird die Leiste erst bei einer Behaelterbreite von rund 1148 px, und die gibt es ab einem Fenster von 1440. Zwischen 1401 und 1439 half `nowrap` also noch - das Band endet jetzt bei 1439. > Eine Bandgrenze, die nicht am Umschlagpunkt liegt, erzeugt einen > Sprung, den niemand gewollt hat. Hier waren es 17 px auf ein Pixel > Fensterbreite. ===================================================================== */ @media (min-width: 901px) and (max-width: 1100px){ html[data-dp-kartenstil="kartei"] .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-row, html[data-dp-kartenstil="kartei"] .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-seg .dp-pf-row{ flex-wrap: wrap !important; } } /* Das Band aus v2124, weitergezogen bis an den gemessenen Umschlagpunkt. Der Selektor ist derselbe; bei gleicher Spezifitaet gewinnt die spaetere Regel, und das ist diese. */ @media (min-width: 1401px) and (max-width: 1439px){ .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar, :is(#oab-bar,#qc7-sources).dp-pfbar{ flex-wrap: nowrap !important; } .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-row, :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-row{ flex-wrap: wrap !important; } .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg, :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-seg{ flex: 0 1 auto !important; min-width: min-content !important; } .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-lead, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-qr, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar > .dp-pf-rz{ flex: 0 0 auto !important; } } /* ===================================================================== v2133a - DER WIEDERBELEBTE ENTWURF BRACHTE EINEN 29-PX-KNOPF MIT Abnahme von v2133: 2 Stile x 10 Breiten. Die Zeile wirkt jetzt (35 von 44 Regeln treffen, Marke gesetzt) und ist sauber - KAPP 0, RAUS 0, ZUBREIT 0, QUER 0, Textkontrast ueberall >= 4,5. Gemessen gegen die Vorgabe: Breite Vorgabe Zeile 360 360x445 Knopf 50 360x334 Knopf 29 390 357x445 Knopf 50 357x334 Knopf 29 430 397x445 Knopf 50 430x334 Knopf 29 768 695x383 Knopf 44 695x253 Knopf 44 834 761x383 Knopf 44 761x253 Knopf 44 1024 703x248 Knopf 44 703x203 Knopf 44 1180 888x137 Knopf 44 888x136 Knopf 44 1280 988x117 Knopf 33 988x114 Knopf 29 1440 1148x 78 Knopf 33 1148x132 Knopf 29 1920 1280x 78 Knopf 33 1280x 80 Knopf 29 Die Leiste wird 111 px flacher - genau das, was der Entwurf verspricht. Der Knopf aber faellt auf **29 px**, weil die Zeile-Regel ausdruecklich `min-height:0` setzt: body.dp-pfzeile .dp-pfbar button#oab-run{ min-height:0 !important; padding:8px 18px !important; font-size:13px !important } Das war richtig: der Kommentar daneben erklaert, dass der 50-px-Knopf die Zeile auf 76 statt 54 px trieb. Nur gab es damals die Touchflaechen-Regel aus v2121a noch nicht. > **Zwischen 641 und 1200 px gewinnt v2121a mit (2,1,1) gegen die > (1,3,2) der Zeile** - deshalb stehen dort 44 px. Unter 641 gilt das > Band nicht, und darunter liegen genau die Handys. Also 44 px bis 900 px, und darueber bleibt die Zeile kompakt - sie ist dort ein Entwurf fuer die Maus. Spezifitaet (2,2,2) gegen die (1,3,2) des Entwurfs. ── OFFEN UND BENANNT ───────────────────────────────────────────── Bei 1440 px ist die Zeile **132 px** hoch, die Vorgabe 78. Bei 1920 px sind es 80. Nichts ist abgeschnitten und nichts laeuft hinaus - die Leiste bricht dort nur eine Zeile mehr um als die Vorgabe. Das ist eine Optikfrage am Entwurf, kein Defekt, und gehoert Marcel gezeigt statt von mir entschieden. ===================================================================== */ @media (max-width: 900px){ body.dp-pfzeile :is(#oab-bar,#qc7-sources).dp-pfbar button#oab-run, body.dp-pfzeile :is(#oab-bar,#qc7-sources).dp-pfbar #oab-run.dp-pf-launch{ min-height: 44px !important; padding-top: 11px !important; padding-bottom: 11px !important; } } /* ===================================================================== v2134 - EINE TOUCHFLAECHE FUER ALLE VIER ENTWUERFE Abnahme der OFFENEN Schublade, 4 Kartenstile x 3 Handys = 12 Laeufe. Geoeffnet per echtem Klick auf `.dp-pf-mtrigger`, danach gemessen: Ausloeser trifft 12 von 12 Schublade offen 12 von 12 Knopf verdeckt 0 Knopf ausserhalb 0 Beschriftung gekappt 0 Inhalt ausserhalb 0 Schliessknopf 45x44, im Bild 12 von 12 Uebrig war ein Mass: Stil Knopf Vorgabe 326-396 x 50 Zeile 332-402 x 44 (v2133a) Kartei 91 x 40 <- vier Pixel zu flach Buetten 355-395 x 50 Vier Pixel sind kein Drama und auch kein Zufall: jeder Entwurf setzt seine eigene Knopfhoehe, und jeder muss die Touchflaeche einzeln mitnehmen. Drei von vier tun es, einer nicht. > **Eine Regel je Entwurf ist eine Regel, die beim fuenften Entwurf > fehlt.** Deshalb steht sie hier EINMAL und stilunabhaengig: unter > 901 px ist der Abruf-Knopf mindestens 44 px hoch, egal welcher > Entwurf gewaehlt ist. Spezifitaet (2,2,0) - sie schlaegt die (1,3,1) der Kartei und die (1,3,2) der Zeile, weil zwei IDs mehr zaehlen als drei Klassen. Ueber 900 px bleibt jeder Entwurf bei seiner eigenen Hoehe; dort ist eine Maus im Spiel. ===================================================================== */ @media (max-width: 900px){ :is(#oab-bar,#qc7-sources).dp-pfbar #oab-run.dp-pf-launch, :is(#oab-bar,#qc7-sources).dp-pfbar .qc6-run.dp-pf-launch{ min-height: 44px !important; } } /* ===================================================================== v2134a - ZWEI PIXEL IN DER KARTEI Schlussabnahme der offenen Schublade, 390 px, alle vier Entwuerfe, Kachel fuer Kachel gemessen: Vorgabe 358 x 44 min-height 44px Polster 6/9 Zeile 364 x 44 min-height 44px Polster 6/11 Buetten 366 x 44 min-height 44px Polster 6/9 Kartei 388 x 42 min-height 42px Polster 0/13 <- hier 42 statt 44. Die Begruendung daneben steht seit v1664: *"Alle vier Chips gleich hoch und gleich gefasst - die Masse sind die der Demo, ohne Unterzeile also flacher."* Die Demo kannte keine Touchflaeche. > **Zwei Pixel sind kein Gestaltungsunterschied, sondern ein > Unterschied zwischen Entwurf und Geraet.** Auf dem Schreibtisch > sieht 42 aus wie 44; unter dem Finger ist es die Grenze. Geaendert wird nur das Mass, und nur unter 901 px. Ueber 901 px behaelt die Kartei ihre 42 px - dort ist eine Maus im Spiel, und die Demo-Proportion bleibt, wo sie gemeint war. Dasselbe fuer den Abruf-Knopf der Kartei (40 px, Z. 1189): den hat `v2134` schon stilunabhaengig auf 44 gehoben, hier steht nur der Nachweis, dass es derselbe Fall ist. ===================================================================== */ /* v2134b: Band auf 1200 verlaengert. Gemessen blieb genau EINE Zeile mit Befund: [kartei] bei 1180 px, Kacheln 42 px. Und 1180 ist das iPad Pro 11 im Querformat (1194 px) - dieselbe Begruendung, mit der v2121a dort schon 44 px setzt. Eine Grenze bei 900 laesst genau das Geraet aus, um das es geht. */ @media (max-width: 1200px){ html[data-dp-kartenstil="kartei"] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-tile{ min-height: 44px !important; } } /* ===================================================================== v2135 - "DEALPILOT" STAND AUF 12 VON 53 PX Marcel am 12.10.2026: "auf dem ipad mini die datenaufnahme DealPilot und die Stufen werden nicht richtig dargestellt." GEMESSEN, iPad mini 768 px, Kartenstil Kartei, die Kachel `[data-src="dealpilot"]` und ihr Inhalt: Kachel 89 x 44 width: 88,941px span.dp-pf-logo.dp 12 sichtbar / 53 Inhalt "DealPilot" span.dp-pf-stufen 12 sichtbar / 17 Inhalt die drei Pillen span.dp-pf-led 12 x 12 Von "DealPilot" waren 12 von 53 px zu sehen, von den Stufen 12 von 17. Beides steht als Rest da, nicht als Beschriftung. ── DER UMFANG, GEMESSEN STATT GESCHAETZT ───────────────────────── 4 Kartenstile x 5 Breiten: **12 von 20 Laeufen betroffen.** Stil 641 768 834 900 901 Vorgabe heil heil heil heil heil Zeile KAPP KAPP KAPP KAPP heil Kartei KAPP KAPP KAPP KAPP heil Buetten KAPP KAPP KAPP KAPP heil Also drei Stile ueber das ganze Band 641-900, und ab 901 ist alles in Ordnung (Kachel 173-184 px, Logo 59/59, Stufen 60/60). ── ZWEI URSACHEN, DIE ZUSAMMEN WIRKEN ──────────────────────────── **1 · Eine Prozentangabe mit zwei verschiedenen Bezugsgroessen.** `v2117` gibt den Kacheln im Band 641-900 `width: calc(50% - 3px)` - zwei Spalten statt einer langen Saeule. Gemessen bei 768 px: .dp-pf-seg (Marktbewertung) Reihe 184 px -> 50 % = 89 px .dp-pf-seg (Daten einlesen) Reihe 664 px -> 50 % = 329 px > **Das erste Segment enthaelt EINE Kachel.** Seine Reihe ist so > breit wie diese Kachel, und die Haelfte davon ist zu wenig fuer > ihren eigenen Inhalt. Die Regel war fuer vier Kacheln gedacht und > trifft eine. Dieselbe Falle wie bei `v2121`: dort waren 50 % von 1263 px plötzlich 631 px. **Eine Prozentangabe ist nur so gut wie ihr Bezug**, und der Bezug ist hier je Segment ein anderer. **2 · Eine Sammelregel nimmt dem Inhalt seine Mindestbreite.** `v1941e` setzt im Band bis 900 px #oab-bar.dp-pfbar * { min-width: 0 !important } auf JEDEN Nachfahren. Ohne sie waere die Kachel bei 89 px uebergelaufen - mit ihr schrumpft stattdessen der Text auf 12 px. Der Ueberlauf ist weg, der Inhalt auch. ── WAS HIER GESETZT WIRD ───────────────────────────────────────── Die Kachel darf nicht schmaler werden als ihr Inhalt (`min-width: max-content`), und der Inhalt bekommt seine Mindestbreite zurueck (`min-width: auto`). Die 50 % bleiben als WUNSCHbreite stehen - wo sie passen, teilen die Kacheln weiter zu zweit; wo sie nicht passen, gewinnt der Inhalt. Spezifitaet: `:is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-tile > *` ist (1,2,0) gegen die (1,1,0) der Sammelregel - die nennt nur EINE Klasse. Bei der Kachel selbst ist es (1,2,0) gegen (1,2,0), also entscheidet die Reihenfolge, und diese Regel steht spaeter. ===================================================================== */ @media (min-width: 641px) and (max-width: 900px){ :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-tile, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-tile{ min-width: max-content !important; } :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-tile > *, .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-tile > *{ min-width: auto !important; } /* Die Reihe muss umbrechen duerfen - sonst schiebt die gewachsene Kachel ihre Nachbarn aus der Karte. In der Kartei steht dort `nowrap` aus dem Entwurf (Z. 850). */ html[data-dp-kartenstil] :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-row, html[data-dp-kartenstil] .dp-pf-scroll :is(#oab-bar,#qc7-sources).dp-pfbar .dp-pf-row{ flex-wrap: wrap !important; } }