I artikkelen om mikrointeraksjoner skrev jeg at transform og opacity animeres på kompositeringstråden, så selv en tung side ikke burde få knappeanimasjonen til å hakke. Det stemmer fortsatt – med ett forbehold den artikkelen ikke nevnte: hvis hovedtråden er blokkert av en lang JS-oppgave, får animasjonen kanskje aldri sjansen til å starte, fordi selve klikk-handleren står og venter i køen. INP er metrikken som måler nøyaktig dette gapet – og scheduler.yield() er en av de få måtene å faktisk lukke det på.
En liste med tusen kommentarer rendrer sakte, så du griper til react-window – og i bytte mot jevn scrolling mister du Ctrl+F, utskrift av siden og delvis skjermleser-navigasjon, fordi elementene utenfor vinduet slutter å fysisk eksistere i DOM-en. content-visibility løser det samme problemet annerledes: elementene blir værende i DOM-en, nettleseren hopper rett og slett over det kostbare layout- og malingsarbeidet for dem helt til de kommer nær det synlige området – og, overraskende nok, kan den midlertidig avsløre dem når du søker etter tekst i dem.
I artikkelen om tilgjengelighet var en modal med display:none, som fortsatt fantes i tilgjengelighetstreet, et eksempel på en feil som følger av å bygge en modal fra bunnen med div-er. Det egentlige spørsmålet er: hvorfor måtte den i det hele tatt bygges fra bunnen? Jeg går gjennom hva den native <dialog> og popover-attributtet gir deg gratis – top layer, fokusfelle, light dismiss – og hvor disse to mekanismene skiller seg så mye at å forveksle dem er en enkel vei til et utilgjengelig grensesnitt.
«Lik»-knappen reagerer umiddelbart, hjertet fyller seg, telleren øker – før serveren i det hele tatt har svart. Dette er ikke bare illusjonen om hastighet fra artikkelen om mikrointeraksjoner, det går lenger: grensesnittet viser en tilstand som ennå ikke eksisterer, og forutsetter at den snart vil gjøre det. Jeg går gjennom hvordan man bygger dette trygt – med reell tilbaketrekning fra løgnen når forutsetningen ikke holder – og hvorfor manuell setState pluss catch er en dårligere versjon av det useOptimistic gir.
Verktøyklassen .mt-4 taper mot regelen .card .card__header .card__title, selv om den logisk sett burde vinne fordi den ble lagt til senere. Dette er ikke tilfeldig – det er spesifisitet som gjør nøyaktig det den er designet for å gjøre. @layer innfører en helt ny akse for å avgjøre konflikter, som virker før spesifisiteten, ikke sammen med den – og har én felle så mot-intuitiv at selv deler av dokumentasjonen på nettet bryter den.
«use server» ser ut som syntaktisk sukker for et fetch-kall til en API-rute – og nettopp derfor behandler de fleste implementasjoner den som et vanlig funksjonskall. Det er en feil med konkrete konsekvenser: hver funksjon merket «use server» blir et offentlig endepunkt på nettet, og et skjema bygget på denne mekanismen fungerer selv før JavaScript rekker å laste. Jeg går gjennom hva som faktisk skjer under dette direktivet, og hvor fellene ligger som ikke er åpenbare ved første blikk i dokumentasjonen.
Et skjemafelt skal lyse rødt når input-en inni er ugyldig. Enkelt nok – bortsett fra at CSS i 25 år ikke kunne spørre et element om hva som skjer inni det, bare motsatt. Jeg går gjennom hvordan :has() snur denne retningen, hvordan den skiller seg fra vanlige kombinatorer, og hvor denne nye kraften faktisk koster ytelse.
Det samme produktkortet ser flott ut i rutenettet og bryter sammen i en smal sidebar – til tross for nøye utvalgte media queries. Problemet ligger ikke i koden din, men i spørsmålet media query faktisk stiller: om bredden på skjermen, ikke om plassen komponenten faktisk fikk tildelt. Jeg går gjennom hvordan container queries flytter dette spørsmålet dit det burde vært stilt fra begynnelsen, og hva som egentlig skjer under overflaten når et element blir en «spørringsbeholder».
Korrekt HTML er bare startpunktet. Se hvordan tilgjengelighetstreet faktisk fungerer, hvorfor ARIA oftere skader enn hjelper enn du skulle tro, og bygg en ekte accordion, en live region og fokushåndtering i Next.js sammen med meg.
To nettbutikker, samme produkt, samme responstid fra serveren – likevel føles den ene raskere og mer tillitvekkende. Forskjellen ligger i mikrointeraksjoner: noen hundre millisekunder med animasjon som avgjør om brukeren stoler på det som skjer på skjermen. Jeg går gjennom dem fra bunnen av – trigger/tilbakemelding-modellen, hva som faktisk skjer inne i nettleserens rendringsmotor, og prefers-reduced-motion.
CSS Houdini er ikke én teknologi, men en samling spesifikasjoner i svært ulik grad av modenhet. Finn ut hvilken del som er produksjonsklar i dag, hvordan @property og paint worklet egentlig fungerer, og hvorfor resten fortsatt er eksperimentell.
