I artiklen om mikrointeraktioner skrev jeg, at transform og opacity animeres på kompositørens tråd, så selv en tung side ikke burde få en knapanimation til at hakke. Det er stadig sandt – med ét forbehold, som den artikel ikke nævnte: hvis hovedtråden er blokeret af en lang JS-opgave, får animationen måske aldrig chancen for at starte, fordi selve klik-handleren venter i kø. INP er den metrik, der måler præcis dette hul – og scheduler.yield() er en af de få måder, man reelt kan lukke det på.
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.
'Synes godt om'-knappen reagerer øjeblikkeligt, hjertet fyldes ud, tælleren stiger – før serveren overhovedet har svaret. Det er ikke den hastighedsillusion fra artiklen om mikrointeraktioner, det er noget mere vidtgående: grænsefladen viser en tilstand, der endnu ikke findes, og går ud fra, at den snart vil gøre det. Jeg undersøger, hvordan man bygger det sikkert – med en reel tilbagerulning, når antagelsen ikke holder – og hvorfor manuel setState plus catch er en dårligere version af det, useOptimistic giver.
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.
'use server' ligner syntaktisk sukker på en fetch til en API-rute – og netop derfor behandler de fleste implementeringer det som et almindeligt funktionskald. Det er en fejl med konkrete konsekvenser: enhver funktion mærket 'use server' bliver et offentligt netværksendepunkt, og en formular bygget på den mekanisme virker, selv før JavaScript når at indlæses. Jeg undersøger, hvad der reelt sker under det direktiv, og hvor faldgruberne ligger, som ikke er indlysende ved første blik i dokumentationen.
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.
Det samme produktkort ser fantastisk ud i et grid og går i stykker i en smal sidebar – på trods af omhyggeligt udvalgte media queries. Problemet ligger ikke i din kode, men i det spørgsmål, media queries stiller: om skærmens bredde, ikke om den plads, komponenten faktisk har fået. Jeg undersøger, hvordan container queries flytter det spørgsmål derhen, hvor det burde have været stillet fra begyndelsen, og hvad der reelt sker under motorhjelmen, når et element bliver en 'query-container'.
Korrekt HTML er kun begyndelsen. Se hvordan tilgængelighedstræet faktisk fungerer, hvorfor ARIA oftere gør skade end gavn end du tror, og byg en rigtig accordion, en live region og Next.js-fokushåndtering sammen med mig.
To webshops, samme produkt, samme svartid fra serveren – alligevel føles den ene hurtigere og mere troværdig. Forskellen ligger i mikrointeraktioner: nogle få hundrede millisekunders animation, der afgør, om brugeren stoler på det, der sker på skærmen. Jeg gennemgår dem fra bunden – trigger/feedback-modellen, hvad der reelt sker inde i browserens rendering engine, og prefers-reduced-motion.
CSS Houdini er ikke én teknologi, men en samling af specifikationer i meget forskellige modenhedsstadier. Find ud af, hvilken del der i dag er klar til produktion, hvordan @property og paint worklet egentlig fungerer, og hvorfor resten stadig er eksperimentel.
