494946386a7509005f6192e42e1f5e1a2bd87a0c
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
494946386a |
Verwaltung: die Kacheln werden zu geschliffenen Glasplatten
Buehne und Zeigerlicht bleiben unveraendert. Diesmal geht es nur um die Kacheln selbst. SIE LIEGEN IM RAUM, NICHT AUF DER SEITE Faehrt der Zeiger darueber, neigt sich die Kachel ihm entgegen -- als wuerde man eine echte Glasplatte kippen. Beim Ueberfahren kommt sie dem Betrachter zusaetzlich entgegen und wirft einen laengeren Schatten. Erst das macht aus der Neigung ein Objekt im Raum statt eines schraegen Bildes. Der Ausschlag liegt bei hoechstens 7 Grad (gemessen 6,7). Alles darueber verzerrt die Schrift sichtbar, und auf diesen Kacheln wird gearbeitet, nicht nur geschaut. DER INHALT STEHT VOR DER FLAECHE Ueberschriften weiter vorn als Fliesstext. Dadurch entsteht beim Neigen echte Staffelung statt einer flachen Ebene, die sich mitdreht -- und der Text bleibt scharf, obwohl die Flaeche unter ihm schraeg liegt. DAZU EIN GLANZSTREIFEN UND UNGLEICHE ECKEN Ein schmales Licht laeuft ueber die Platte und wandert mit der Neigung. Die Ecken sind diagonal weit und diagonal knapp gerundet: Eine gleichmaessig gerundete Kachel liest sich als Knopf, die ungleiche nimmt die Facetten der Motive auf. DIE FALLE, DIE ICH SCHON KANNTE Die Auftauch-Animation der Kacheln nutzte "transform" und haelt ihren Endwert fest -- eine Animation schlaegt jede normale Regel, die Neigung waere also wirkungslos geblieben. Genau dieselbe Falle wie zuvor bei der Buehne, nur eine Ebene tiefer. Die Animation nutzt jetzt "translate" und "scale" als eigene Eigenschaften; "transform" bleibt der Neigung vorbehalten. DREI FEHLER IM TEST, NICHT IN DER SEITE - Der Staffelungstest raeumte die Probekachel leer. Danach fehlten ihr Ueberschrift und Text, und der Neigungstest stuerzte ab, weil er auf ein nicht vorhandenes Element zugriff. Er hat jetzt einen eigenen Behaelter. - Die Winkelrechnung las die "3" aus "matrix3d" als erste Zahl mit und verschob damit jeden Eintrag um eine Stelle. Der Winkel kam als 0,4 Grad heraus statt als 6,7 -- die Pruefung "flach genug" waere also immer gruen gewesen, egal wie stark die Kachel kippt. - Der Schwellwert fuer den senkrechten Ausschlag war zu streng. Eine flache Kachel ist nur gut 100 Punkte hoch; 20 Punkte vom Rand liegen dort schon fast in der Mitte. Geprueft wird jetzt der Vorzeichenwechsel statt eines festen Betrags. Bei prefers-reduced-motion ist alles davon aus: keine Neigung, keine Tiefe, kein Glanz. Ohne feinen Zeiger entfaellt es ebenfalls -- auf einem Telefon gibt es kein Schweben. Geprueft: 260 Pruefungen gruen (Verwaltung 62, Portfolio 15, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
|
4c0941c6da |
Verwaltung: Zeigerlampe, Prisma-Kanten, schwebende Partikel
Drei Dinge, die zusammen ein Konzept ergeben: Das Bild reagiert auf den Zeiger, die Kacheln brechen das Licht wie Eis, und im Raum schwebt etwas. 1. DIE ZEIGERLAMPE Ein weicher Lichtkegel wandert ueber die Buehne und hellt die Kristalle dort auf, wo der Zeiger steht. Damit wird das Bild zu einer Flaeche, die auf einen reagiert, statt nur dazuzuliegen. Der Kniff steckt in mix-blend-mode: soft-light. Ein normaler heller Verlauf wuerde das Bild ueberdecken und milchig machen. "soft-light" rechnet stattdessen mit dem, was darunter liegt -- dunkle Stellen bleiben dunkel, vorhandene Lichtkanten der Kristalle werden verstaerkt. Das Bild wird nicht ueberstrahlt, es wird beleuchtet. Bewusst NICHT "screen" oder "overlay": Beide lassen die Eiskanten ausbrennen, und genau die machen den Reiz der Motive aus. 2. PRISMA-SCHIMMER AN DEN KACHELKANTEN Am hellsten Punkt sitzt die Leitfarbe, daneben faechert die Kante in Nachbartoene auf -- wie Licht, das sich in einer Glaskante bricht. Bewusst KEIN Regenbogen: Volle Spektralfarben sehen nach Seifenblase aus, nicht nach geschliffenem Eis. Es bleibt in der kalten Haelfte der Palette. Die Kante ist dafuer 1,5 px statt 1 px -- bei genau einem Punkt verschluckt das Bildschirmraster die Aufaecherung fast vollstaendig. 3. SCHWEBENDE PARTIKEL Neun Lichtpunkte steigen sehr langsam auf, jeder mit eigener Bahn, Dauer und Startzeit. Rein aus CSS, ohne Zeichenflaeche -- eine Zeichenflaeche wuerde dauerhaft Rechenzeit kosten, und das auf einer Seite, auf der man arbeitet. Es soll wirken wie Staub im Lichtkegel, nicht wie Schneefall. DER FEHLER, DEN ERST DER SCREENSHOT ZEIGTE: Die Lampe legte sich als gruenlicher Fleck mitten auf eine Kachel. Ein Element mit mix-blend-mode mischt sich mit ALLEM in seinem Stapelkontext -- auch mit Elementen, die eigentlich darueber liegen. Buehne und Lampe stecken deshalb jetzt in einem gemeinsamen Raum mit isolation: isolate. Dort endet die Mischung, und die Lampe beleuchtet nur noch das Bild. Was DANACH noch durchkam, ist dagegen richtig so: Die Kacheln tragen eine Rueckseiten-Unschaerfe, nehmen also auf, was hinter ihnen liegt. Licht, das durch Milchglas scheint. Bei einem engen Kegel war davon allerdings ein scharf umrissener Kreis uebrig -- deshalb jetzt ein weiter Radius mit flachen Stufen, damit sich der Helligkeitsunterschied ueber die halbe Kachel verteilt und als Schimmer liest. Drei Testmeldungen waren durch den Umbau entstanden und kein Mangel der Seite: Haltung, Stapelplatz und die Auszeichnung als Zierde sitzen jetzt am Raum, nicht mehr an der Buehne darin. Der Test prueft sie dort. Bei prefers-reduced-motion sind die Partikel komplett weg -- nicht nur angehalten. Ein eingefrorener Punkt mitten im Bild waere ein Fleck ohne Sinn. Ohne feinen Zeiger entfaellt die Lampe ganz. Geprueft: 252 Pruefungen gruen (Verwaltung 54, Portfolio 15, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
|
fdf3e5349e |
Verwaltung: gleitender Leuchtbalken, gestaffelte Kacheln, Reiterlicht
Drei weitere Stufen auf der Buehne.
1. DER GLEITENDE LEUCHTBALKEN
Unter der Reiterreihe liegt ein Balken in der Leitfarbe. Beim Wechsel
springt er nicht, sondern gleitet zum neuen Reiter und faerbt sich dabei
um.
Position und Breite kommen aus dem ECHTEN Reiter, im Browser gemessen.
Feste Werte waeren hier zwangslaeufig falsch: Die Reiter sind
unterschiedlich breit ("Kunden" gegen "Zahlungen"), sie verschieben sich
beim Sprachwechsel, und auf schmalen Schirmen brechen sie um -- deshalb
wandert auch die Hoehe mit, nicht nur die Seite.
2. DIE KACHELN TAUCHEN GESTAFFELT AUF
Beim Bereichswechsel erscheinen sie nacheinander statt alle auf einmal.
Nur die ersten acht bekommen einen Versatz -- bei einer langen Liste
kaeme die letzte Kachel sonst spuerbar spaeter, und das fuehlt sich
nicht mehr elegant an, sondern langsam.
3. DAS LICHT FOLGT AUCH AUF DEN REITERN
Die Verfolgung im Grundsystem greift ausdruecklich nur auf Karten. Fuer
die Reiter ist sie hier ergaenzt, gedrosselt ueber
requestAnimationFrame -- aus demselben Grund wie dort.
ZWEI FEHLER, DIE DER TEST GEFUNDEN HAT:
Der Balken stand auf Breite 0 und blieb unsichtbar. Ein blosser
"resize"-Horcher reicht naemlich nicht: Der haeufigste Fall ist gar
keine Fenstergroessenaenderung, sondern das Sichtbarwerden. Beim Start
ist der Arbeitsbereich versteckt, die Leiste also 0 Punkte breit -- und
ein verstecktes Element loest kein resize aus. Jetzt beobachtet ein
ResizeObserver die Leiste; das deckt Sichtbarwerden, Umbrechen und
Sprachwechsel gleichermassen ab.
Und die Messung hing allein am Klick-Listener. Wechselt der Bereich auf
einem anderen Weg -- etwa direkt nach dem Anmelden, wenn der
Arbeitsbereich zum ersten Mal auftaucht -- wurde nie nachgemessen.
balkenSetzen ist deshalb jetzt nach aussen verfuegbar.
Alles Bewegte bleibt bei prefers-reduced-motion aus: kein Gleiten, kein
Auftauchen, keine Parallaxe, kein Reflex. Die Buehne bleibt sichtbar.
Ein Wort zum Test selbst: Er prueft "der Balken springt" nicht mehr auf
wortwoertlich "0s". Die Testumgebung emuliert reduzierte Bewegung, indem
sie Uebergaenge auf eine Mikrosekunde setzt statt auf null -- gemeldet
wird "1e-06s". Wahrnehmbar ist das identisch; ein Test auf exakt "0s"
haette nur die Emulation gemessen, nicht die Regel.
Geprueft: 244 Pruefungen gruen (Verwaltung 46, Portfolio 15, CRYONOVA 53,
Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
|
99b5dd4eb2 |
CRYONOVA Schritt 3: Feldfokus, Blickfaenge, Testkorrekturen
Der Feldfokus zeigt jetzt den Ion-Rand und den weichen Schein, den das
Design-System auf Seite 15 verlangt. Er fehlte, weil der allgemeine
Tastaturring seinen dunklen Innenring darueberlegte: Dessen Selektor hat
Spezifitaet 0,3,0, die Feldregel nur 0,2,1 -- und Spezifitaet schlaegt
Reihenfolge, egal wie weit unten die Regel steht. Eingabefelder sind
jetzt vom Innenring ausgenommen; sie brauchen ihn nicht, weil sie selbst
eine dunkle Flaeche sind. Der Aqua-Umriss bleibt fuer alle erhalten.
Die zwei Blickfang-Motive stehen jetzt auch wirklich auf einer Seite:
das Wappen auf "Ueber mich", direkt nach dem Absatz ueber die Herkunft
des Namens, der Monolith auf "Portfolio" zwischen Einleitung und den
echten Projekten. Beide als Zierbild ausgezeichnet -- ihre Aussage steht
schon im Text daneben. Auf dem Handy laedt automatisch die kleine
Fassung.
Vier Fehler steckten in der Pruefung selbst, nicht im Stilblatt:
- Sie griff das erste "input" der Anfrageseite. Das sind aber sechs
optisch versteckte Auswahl-Radios, kein Textfeld.
- Sie mass ohne Fensterfokus. Ein Browser wendet :focus nur an, wenn das
Fenster selbst den Fokus hat -- das DOM meldet trotzdem brav
matches(":focus") === true, die Farbe bleibt die alte.
- Sie mass mitten im Uebergang, bevor die Animation stand.
- Und sie zaehlte Schattenebenen an "),", einem Muster, das in keinem
Schattenwert je vorkommt. Geprueft wird jetzt die Anforderung selbst:
Ion-Farbe und ein Weichzeichner ueber 0.
Geprueft: 334 Pruefungen gruen (CRYONOVA 53, Blickfang 13, Abmelden 16,
Angebot 54, Abbruch 42, System 5, Automatik 55, Angebote 56, Kette 40).
Co-Authored-By: Claude Opus 5 <[email protected]>
|