Det finns en anledning till att JavaScript-parallax alltid ser lite fel ut — lite frånkopplat, som om lagren simmar en halv frame bakom sidan. Det är inte slarvig kod. Det beror på att scroll-händelser når JavaScript efter att webbläsaren redan har ritat rullningen. Webbläsaren löste det här en gång, när den förvandlade klibbiga rubriker till position: sticky. Scroll-driven animations är samma drag, tillämpat på alla scroll-bundna effekter på en gång.
I tio år innebar animering av en miniatyrbild till en hero-bild en enda teknik: mät elementet före, mät efter, fejka skillnaden med en transform och spela upp. FLIP. Varje animationsbibliotek gör det, och varje betalar för det med JavaScript på huvudtråden vid det sämsta möjliga tillfället. View Transitions API flyttar hela tricket in i webbläsaren — och sedan React 19.2 och Next.js 16 består hela kontraktet av en enda prop kallad name.
En lista med tusen kommentarer renderas långsamt, så du griper efter react-window – och i utbyte mot smidig scrollning förlorar du Ctrl+F, sidutskrift och delvis skärmläsarnavigering, eftersom elementen utanför fönstret helt slutar existera i DOM. content-visibility löser samma problem på ett annat sätt: elementen finns kvar i DOM, webbläsaren hoppar bara över det kostsamma layout- och målningsarbetet för dem tills de hamnar nära det synliga området – och, förvånande nog, kan tillfälligt avslöja dem när du söker efter text i dem.
I artikeln om tillgänglighet var en modal med display:none, som ändå fanns kvar i tillgänglighetsträdet, ett exempel på ett fel som uppstod ur att bygga en modal från grunden med divar. Den verkliga frågan är: varför behövde den överhuvudtaget byggas från grunden? Jag går igenom vad den nativa <dialog> och attributet popover ger dig gratis – top layer, fokusfälla, light dismiss – och var de här två mekanismerna skiljer sig så pass mycket att man med lätthet bygger ett otillgängligt gränssnitt genom att blanda ihop dem.
Hjälpklassen .mt-4 förlorar mot regeln .card .card__header .card__title, trots att den logiskt sett borde vinna eftersom den lades till senare. Det är ingen slump – det är specificitet som gör exakt det den är designad för. @layer inför en helt ny axel för att avgöra konflikter, som verkar före specificiteten, inte tillsammans med den – och den har en fallgrop så okontraintuitiv att till och med en del dokumentation på nätet får den fel.
Ett formulärfält ska lysa rött när input:en inuti är ogiltig. En enkel sak – förutom att CSS i 25 år inte kunde fråga ett element om vad som händer i dess inre, bara tvärtom. Jag går igenom hur :has() vänder på den riktningen, hur den skiljer sig från vanliga kombinatorer, och var den här nya kraften faktiskt kostar prestanda.
