/* =========================================================================== Arcturis · Nachbesserungen am Entwurf --------------------------------------------------------------------------- Wird als LETZTE Stilvorlage geladen und gewinnt dadurch ohne !important. Warum eine eigene Datei und nicht dreizehn geänderte: Der Entwurf bleibt unberührt und damit vergleichbar — bei jeder Änderung lässt sich zeigen, dass sie nur hier steht. Und alles, was die schmale Ansicht betrifft, steht an einer Stelle statt verteilt über leistung.css, preise.css, websites.css und die übrigen. Regel für jeden Eintrag hier: · so eng wie möglich — was nur die schmale Ansicht betrifft, steht in einer Media Query und lässt die breite unberührt · ein Satz, der sagt WARUM — nicht was · jede Korrektur ist gemessen, nicht geraten =========================================================================== */ /* ── /preise · Der Nachtkopf darf auf dem Telefon nicht kleben ───────────── preise.css:50 heftet den Kopfabschnitt mit position:sticky an den oberen Rand, damit sich das Papier darüberschiebt. Am großen Schirm ist das der gewollte Effekt. Auf dem Telefon ist der Block 620 px hoch bei 844 px Fensterhöhe — er belegt drei Viertel des Bildschirms und bleibt dort. Auf iOS kommt hinzu, dass die Höhe in svh angegeben ist: Fährt die Adressleiste ein oder aus, ändert sich svh, der geheftete Block wird neu vermessen und blitzt zwischen den hellen Abschnitten wieder auf. Die Datei kennt diese Abschaltung bereits — Zeile 59 nimmt sie bei prefers-reduced-motion vor. Hier dieselbe Abschaltung für schmale Schirme. */ @media (max-width: 899px) { .arc-preise section[data-block="01-kopf"] { position: relative; top: auto; /* Nachtrag: Der Kopf tauchte auf dem Gerät weiterhin auf, wenn man von ganz unten wieder hochscrollt — obwohl er nachgemessen an beiden Ständen auf position:relative steht und am Dokumentanfang sitzt; in Chromium ist er beim Hochscrollen kein einziges Mal zu sehen, wo er nicht hingehört. Bleibt als Ursache das, was in diesem Abschnitt eine eigene Zeichenebene aufmacht: die Sternenleinwand .arc-psterne, absolut auf inset:0. Eine bewegte Leinwand landet in Safari auf einer eigenen Ebene, und die kann beim schnellen Zurückscrollen einen Takt zu spät zusammengesetzt werden — sie erscheint dann kurz über dem hellen Inhalt, der eigentlich davorliegt. overflow:clip bindet sie an den Kopf. Für die Anordnung ändert das nichts, die Leinwand füllt den Abschnitt ohnehin genau aus; es verhindert nur, dass außerhalb gezeichnet wird. z-index:0 wird aufgehoben, damit der Abschnitt keine eigene Stapelebene mehr aufspannt und der helle Inhalt sicher darüberliegt. */ overflow: clip; z-index: auto; } } /* ── /leistungen/website-betreuung · Der Knoten am unteren Rand der Preiskarte Die Grundregel zentriert jeden Knoten der Preiskarte auf seinen Punkt: .lr-pk-punkt{ top:var(--y); transform:translate3d(-50%, -50% + …, 0) } Für einen Knoten mit data-anker="unten" schaltet leistung.css:1135 auf bottom um — damit der Knoten nach oben wächst und nicht unten aus der Tafel läuft. Der Kommentar dort erklärt das ausführlich. Übersehen wurde dabei das -50% in der Y-Achse. Es zieht den Knoten zusätzlich um seine halbe Höhe nach oben, obwohl er jetzt an seiner Unterkante hängt. Gemessen an vier Breiten: der Knoten "Übernahme mit Sicherheitsarbeiten" (166 bis 187 px hoch) überlappt dadurch den Mitteltext der Karte um 74 px bei 1164 px Fensterbreite, 89 px bei 1440, 104 px bei 1280 — also überall. Hier bleibt die waagerechte Zentrierung und der Tiefenlauf; nur die halbe Höhe in der Senkrechten fällt weg. Der Knoten steht damit auf der Standlinie, die --y ihm zuweist. Dazu 24 px tiefer: ohne sie blieben in flacheren Fenstern 16 px (1280x800) bzw. 9 px (1024x768) Überdeckung auf der Zeile "Vollständig auf der Preisseite" stehen. Nach unten sind 67 bis 69 px Luft bis zum Tafelrand — die 24 px passen überall hinein, ohne dass der Knoten wieder herausläuft. */ .lr-pk-punkt[data-anker="unten"] { transform: translate3d( calc(-50% + var(--dx, 0px) * (1 - clamp(0, (var(--pr-ein, 1) - var(--s, .3)) * 3, 1))), calc(24px + var(--dy, 0px) * (1 - clamp(0, (var(--pr-ein, 1) - var(--s, .3)) * 3, 1)) + var(--pr-lauf, 0) * var(--tiefe, 0) * 1px), 0); } /* ═══════════════════════════════════════════════════════════════════════════ /leistungen/websites · vier Korrekturen für die schmale Ansicht Alle vier überschreiben Regeln aus websites.css, die dort im Block @media (max-width:1023px) stehen. Derselbe Geltungsbereich hier, damit die breite Ansicht unberührt bleibt. ═══════════════════════════════════════════════════════════════════════════ */ @media (max-width: 1023px) { /* ── 1 · Der Abstand zwischen Satz und Bewegungsbild ──────────────────── Gemessen bei 390 px: 264 px Leerraum zwischen dem Text und dem Bild darunter. Ursache: .wb-teil steht in einer klebenden Bühne über die volle Zeilenhöhe und wird darin mittig ausgerichtet — der Rest der Zeile bleibt als Loch stehen. align-self:start setzt es nach oben an den Satz, aspect-ratio gibt ihm seine eigene Höhe statt der ganzen Zeile. (websites.css:1949) */ [data-bewegung="ja"] .wb-hero .wb-teil { align-self: start; aspect-ratio: 16 / 9; max-height: 100%; } /* ── 2 · Der Balken endet bei "Gestaltung" ────────────────────────────── Die Leiste lief bis bottom:0 ihres Ankers .wb-quer — und darin liegt hinter den fünf Stationen auch .wb-ring-feld mit height:480vh, also die sechs Gestaltungskarten. Der Balken lief mitten durch sie hindurch. bottom:480vh endet ihn genau an der Oberkante des Ringfeldes: dort, wo "Gestaltung" anfängt. Dieselbe Einheit wie die Feldhöhe, also bei jeder Fensterhöhe deckungsgleich — wer die 480vh dort ändert, muss sie hier mitändern. (websites.css:1976) */ [data-bewegung="ja"] .wb-leiste { bottom: 480vh; } /* ── 3 · Die Schrift über den sechs Stilvorlagen ──────────────────────── .wb-ring-satz stand auf top:clamp(96px,14vh,150px) und überschnitt damit die erste Karte — auch noch, während er ausblendet, weil er weiter Platz beansprucht. 9svh statt 14vh: svh rechnet mit der kleinen Fensterhöhe des Telefons, vh mit der großen und liegt dort um die Höhe der Adressleiste zu tief. (websites.css:2054) */ .wb-ring-satz { top: clamp(64px, 9svh, 120px); } /* ── 4 · Die Vorschauseiten des Musterbetriebs ────────────────────────── Nicht die sechs Gestaltungskarten sind zu eng — das sind die Vorschau- fenster. Ihr Rollfeld ist nur so breit wie der Schirm und klippt waagerecht (overflow-x:hidden): was breiter ist, ist weg, nicht scrollbar. Drei Stellen standen noch auf Breitmaß und liefen deshalb hinaus — darunter die Zeile "Anfrage", die dir aufgefallen ist: · die Kopfzeile als Flexzeile ohne Umbruch (gemessen 445–489 px) · die Preisliste mit gesperrten Kopfzellen (Mindestmaß 476–587 px) · in Stil 05 das Leistungsraster, dessen eigene Regel die Einspaltenregel darüber schlägt (websites.css:2028) */ .wb-w-kopf { flex-wrap: wrap; row-gap: 12px; } .wb-w-tab thead th:nth-child(2), .wb-w-tab thead th:last-child, .wb-w-tab tbody td:nth-child(2) { white-space: normal; } .wb-w-leist .wb-w-gitter, .wb-w-schritte .wb-w-gitter { grid-template-columns: 1fr; } } /* ── Startseite · Das Ruckeln beim Größerwerden ──────────────────────────── Der wachsende Kasten ist nicht die Ursache — die .arc-glut daneben ist es. Gemessen an der echten Seite (Rasterzeit einer Neuzeichnung, Median aus sechs Wiederholungen, 390x844): Bühne mit Glut ............................ 7,15 ms dieselbe Ebene ohne .arc-glut ............. 0,25 ms (−96 %) Kasten ohne seinen Schatten ............... 6,91 ms (kein Unterschied) Die Glut trägt also 6,6 der 6,9 ms. start.js schreibt je Bild --kn auf sie, start.css:331 hängt daran opacity — und weil sie keine eigene Ebene hat, wird der 1266 px große Radialverlauf mit filter:blur(30px) in JEDEM Bild neu gerastert. Gemessen: 33 Neuzeichnungen in zwei Sekunden Zoom. Warum nur auf dem Telefon: width:150vmax löst im Hochformat gegen die HÖHE auf — auf 390x844 sind das 1266 px, also das 3,25-fache der Bildschirm- breite; auf 1440x900 nur das 0,94-fache. Dazu die um ein Vielfaches langsamere Füllrate eines Telefons: aus 7 ms werden 30 bis 40 ms je Bild, und das Budget von 16,7 ms ist gesprengt. will-change:opacity gibt ihr eine eigene Kompositionsebene: die Deckkraft ändert sich dann auf der Grafikkarte, ohne neu zu zeichnen. nachher: 0,39 ms je Bild, erzeugte Bilder in denselben 2 s: 33 → 109. Ehrlich zum Preis: die erste Rasterung dieser Ebene kostet einmalig rund 15 ms (auf einem Mittelklassetelefon 60 bis 90), wenn die Bühne zum ersten Mal ins Bild kommt — statt 7 ms in jedem Bild über die ganze Strecke. Dazu rund 5 MB Grafikspeicher. Netto klar ein Gewinn. Die breite Ansicht bleibt unberührt: dort kostet dieselbe Fläche 21 ms je Neuzeichnung, das Problem ist also größer, nicht kleiner — aber es zu ändern wäre ein eigener Schritt mit eigener Prüfung. (start.css:331) */ @media (max-width: 899px) { .arc-glut { will-change: opacity; } } /* ── Startseite · Die dunkle Haarlinie zwischen zwei hellen Abschnitten ──── Gemessen: sechs Abschnittskanten der Startseite liegen auf krummen Bildpunkt-Positionen — 02-befund 4346.266 04-beleg 8429.654 02b-ablauf 5512.594 06-wege 10136.297 03-leistungen 7248.063 07-fuss 11009.856 Bei Gerätefaktor 3 wird aus 4346.266 die Gerätezeile 13038,8. Der obere Abschnitt rundet seine Unterkante ab, der untere seine Oberkante auf — und dazwischen bleibt eine Gerätepunktzeile offen. Dahinter steht der Körper, und der ist nachtfarben (rgb(7,10,20)). Ergebnis: eine dunkle Haarlinie zwischen zwei hellen Flächen, sichtbar nur auf dem Telefon, weil dort der Gerätefaktor 3 ist und die Kanten anders fallen. Der Grund einer Fläche steht in --eigen. Ein box-shadow mit 1 px Ausdehnung in genau dieser Farbe malt sie einen Punkt über ihre Oberkante hinaus und schließt die Naht — ohne das Layout zu berühren, denn ein Schatten belegt keinen Platz. Bewusst nur zwischen ZWEI HELLEN Abschnitten (Nachbarschaftsselektor): an einer Grenze hell/dunkel würde derselbe Kniff eine helle Linie in die dunkle Fläche malen — ein neuer Fehler statt eines behobenen. Dort fällt die Naht ohnehin nicht auf, weil der Körpergrund dieselbe Nachtfarbe hat. */ @media (max-width: 899px) { /* Der 1-px-Schatten in der eigenen Farbe füllt die Fuge — solange er nicht verdeckt wird. Der obere Block liegt aber auf einer höheren Stapelebene (02-befund hat z-index 3), der Schatten des unteren liegt also dahinter und kommt an der Fuge gar nicht zum Vorschein. Deshalb zusätzlich ein echter Überlapp: der untere Block wird um ein Pixel hochgezogen und deckt die Fuge mit seinem eigenen Grund ab. Gemessen sind alle Blockhöhen gebrochen (2151,875 · 1166,328 · 1735,469 …). Genau dort entsteht die Fuge, und zwar abhängig vom Renderer — in Chromium nicht nachstellbar, auf dem Gerät sichtbar. Ein Überlapp behebt sie unabhängig davon, weil dann gar keine Lücke mehr entstehen kann. Beide Gründe sind deckend, ein Pixel ist nicht zu sehen. */ /* NACHTRAG — die erste Fassung griff an der entscheidenden Stelle nicht. Sie war auf [data-grund="tag"] + [data-grund="tag"] gestellt, also auf zwei aufeinanderfolgende helle Blöcke. Gemessen sind aber genau die zwei hellen Blöcke ungeschützt geblieben, die auf einen NACHT-Block folgen: 01b-fenster (nacht) → 02-befund ← die Stelle aus dem Bild 04-beleg (nacht) → 06-wege Und 01b-fenster hat gar keinen eigenen Grund (background: rgba(0,0,0,0)). Es zeigt, was dahinterliegt — den Körpergrund rgb(7,10,20). Optisch wirkt die Bühne hell, weil sie ihren Grund beim Scrollen überblendet; in einer Fuge blitzt aber die echte Farbe durch, und die ist fast schwarz. Deshalb erscheint der Strich zwischen zwei scheinbar hellen Flächen. In Chromium ist er nicht nachstellbar: die ganze Seite bei dreifacher Pixeldichte abgetastet, null dunkle Bänder. Er entsteht nur in Safari. Deshalb wird hier nicht die Fuge gesucht, sondern ihr Erscheinen unmöglich gemacht: JEDER helle Block legt seinen eigenen Grund ein Pixel nach oben und unten. Was zwischen zwei Blöcken auch immer aufreißt, ist dann in Papierfarbe gefüllt statt in Nacht. Kein heller Block trägt einen gestalteten Schatten (nachgemessen: 02-befund ausdrücklich none, 06-wege none) — hier wird also keiner überschrieben. Die drei Blätter mit ihrem großen Schatten sind alle "nacht" und bleiben unberührt. [data-block] steht mit Absicht davor: ohne diese Einschränkung träfe die Regel auch .arc-kasten (320x692, --eigen #F0EEE6) mitten in einem Abschnitt und legte dort einen sichtbaren hellen Rand an. Nur ganze Blöcke stoßen aneinander, nur sie brauchen die Füllung. */ [data-block][data-grund="tag"] { box-shadow: 0 -1px 0 0 var(--eigen), 0 1px 0 0 var(--eigen); } [data-grund="tag"] + [data-grund="tag"] { margin-top: -1px; } } /* ── Die Marke verliert nach dem Überfahren Farbe ────────────────────────── Beim Überfahren bekommt die Rose einen Schein: .arc-marke:hover .arc-rose{ filter:drop-shadow(…) } Im Grundzustand ist gar kein filter gesetzt. Der Wechsel geht also von "kein Filter" zu "Filter" und zurück — und genau das ist das Problem: mit einem Filter kommt das Bild auf eine eigene Zeichenebene, ohne ihn fällt es zurück. Beim Zurückfallen wird es neu gerastert, und die Spitze verliert sichtbar Sättigung, weil die Ebene im engeren Farbraum liegt. Es reicht, den Filter nie zu entfernen: im Grundzustand steht derselbe Schein in durchsichtig. Damit bleibt die Zeichenebene bestehen, es wird nichts neu gerastert, und der Übergang läuft weiterhin über die Farbe des Scheins — sichtbar ist genau dasselbe wie vorher, nur ohne den Farbverlust danach. Gilt für alle Seiten, weil dieselbe Regel in start.css und analyse.css steht. */ .arc-marke .arc-rose { filter: drop-shadow(0 0 10px transparent); } /* ── Startseite · Der Fußbereich springt beim schnellen Scrollen ─────────── Zweiter Teil der Behebung; der erste steht in start.js (Deckel auf den Zielpunkt). Die drei "Blätter" tragen einen negativen oberen Abstand und eine ausgleichende Verschiebung um denselben Weg. Eine Verschiebung ändert die Anordnung nicht, sie vergrößert aber den scrollbaren Überhang: die Seite meldet 42 svh mehr Höhe, als sich tatsächlich erreichen lässt. Gemessen bei 1440x900: das Dokument meldete 9335 als größten Scrollwert, tatsächlich erreichbar waren 8957 — genau die 378 px des Weges. Die Rechnung in start.js zielte damit auf einen Punkt hinter dem Ende; --ueber blieb stehen, der Fußbereich stand halb über dem oberen Rand und sprang beim schnellen Scrollen zurück. Nur das UNTERSTE Blatt ist betroffen — über den beiden anderen liegt noch Inhalt, ihr Überhang fällt nicht ins Gewicht. Der negative untere Abstand hebt den Überhang in jeder Stellung genau auf: bei --ueber 1 stehen +42 svh Verschiebung gegen -42 svh Abstand, bei 0 sind beide 0. Die Dokumenthöhe bleibt dadurch konstant, egal wo die Bewegung gerade steht. */ [data-block="07-fuss"] { margin-bottom: calc(var(--ueber, 1) * -42svh); } @media (max-width: 639px) { [data-block="07-fuss"] { margin-bottom: calc(var(--ueber, 1) * -24svh); } }