Der er en grund til at JavaScript-parallax altid ser lidt forkert ud — lidt frakoblet, som om lagene svømmer en halv frame bag siden. Det er ikke sjusket kode. Det skyldes at scroll-hændelser når JavaScript efter browseren allerede har tegnet rulningen. Browseren løste dette én gang, da den forvandlede klæbrige overskrifter til position: sticky. Scroll-driven animations er det samme træk, anvendt på alle scroll-bundne effekter på én gang.
I ti år betød animering af et miniaturebillede til et hero-billede én teknik: mål elementet før, mål efter, forfalsk forskellen med en transform og afspil. FLIP. Hvert animationsbibliotek gør det, og hvert betaler for det med JavaScript på hovedtråden på det værst mulige tidspunkt. View Transitions API flytter hele tricket ind i browseren — og siden React 19.2 og Next.js 16 består hele kontrakten af én prop kaldet name.
En liste med tusind kommentarer renderer langsomt, så du griber til react-window – og til gengæld for en flydende scroll mister du Ctrl+F, sideudskrift og delvist skærmlæserens navigation, fordi elementer uden for vinduet holder op med at eksistere fysisk i DOM'en. content-visibility løser det samme problem på en anden måde: elementerne bliver i DOM'en, browseren springer bare det dyre layout- og maling-arbejde over for dem, indtil de kommer tæt på det synlige område – og kan overraskende nok midlertidigt afsløre dem, når du søger efter tekst i dem.
I artiklen om tilgængelighed var en modal med display:none, som stadig fandtes i tilgængelighedstræet, et eksempel på en fejl, der opstod ved at bygge en modal fra bunden med divs. Det reelle spørgsmål er: hvorfor skulle den overhovedet bygges fra bunden? Jeg undersøger, hvad det native <dialog>-element og popover-attributten giver dig gratis – top layer, fokusfælde, light dismiss – og hvor de to mekanismer adskiller sig så meget, at det er let at forveksle dem og ende med en utilgængelig grænseflade.
Hjælpeklassen .mt-4 taber til reglen .card .card__header .card__title, selvom den logisk burde vinde, fordi den blev tilføjet senere. Det er ikke tilfældigt – det er specificitet, der gør præcis det, den er designet til. @layer indfører en helt ny akse til at afgøre konflikter, som virker før specificiteten, ikke sammen med den – og har én faldgrube så kontraintuitiv, at selv en del af dokumentationen på nettet får den galt.
Et formularfelt skal lyse rødt op, når inputtet indeni er ugyldigt. En enkel ting – bortset fra at CSS i 25 år ikke kunne spørge et element om, hvad der foregik i dets indre, kun det modsatte. Jeg undersøger, hvordan :has() vender den retning om, hvordan den adskiller sig fra almindelige kombinatorer, og hvor den nye kraft reelt koster ydelse.
