I artikeln om mikrointeraktioner skrev jag att transform och opacity animeras på kompositeringstråden, så även en tung sida borde inte hacka en knappanimation. Det stämmer fortfarande – med ett förbehåll som den artikeln teg om: om huvudtråden är blockerad av en lång JS-uppgift kanske animationen aldrig får chansen att starta, eftersom själva klick-handlern väntar i kön. INP är måttet som mäter exakt den luckan – och scheduler.yield() är ett av få sätt att faktiskt stänga den.
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.
'Gilla'-knappen reagerar direkt, hjärtat fylls i, räknaren ökar – innan servern ens har svarat. Det är inte samma hastighetsillusion som i artikeln om mikrointeraktioner, det är något som går längre: gränssnittet visar ett tillstånd som ännu inte finns, och antar att det strax kommer att göra det. Jag går igenom hur man bygger det säkert – med en verklig reträtt från lögnen när antagandet visar sig fel, och varför manuell setState plus catch är en sämre version av det useOptimistic ger.
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.
'use server' ser ut som syntaktiskt socker för ett fetch-anrop till en API-route – och just därför behandlar de flesta implementationer det som ett vanligt funktionsanrop. Det är ett misstag med konkreta konsekvenser: varje funktion märkt 'use server' blir en offentlig slutpunkt på nätet, och ett formulär byggt på den här mekanismen fungerar även innan JavaScript hunnit laddas. Jag går igenom vad som faktiskt händer bakom det direktivet, och var fallgroparna finns som inte syns i dokumentationen vid första anblicken.
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.
Samma produktkort ser perfekt ut i griden men går sönder i den smala sidopanelen – trots noggrant avvägda media queries. Problemet ligger inte i din kod, utan i frågan som media query faktiskt ställer: hur bred är fönstret, inte hur mycket plats komponenten faktiskt fick. Jag går igenom hur container queries flyttar frågan dit den borde ha ställts från början, och vad som egentligen händer under ytan när ett element blir en 'query container'.
Korrekt HTML är bara startpunkten. Se hur tillgänglighetsträdet faktiskt fungerar, varför ARIA oftare gör skada än nytta än du tror, och bygg en riktig accordion, en live region och fokushantering i Next.js tillsammans med mig.
Två butiker, samma produkt, samma svarstid från servern – ändå känns den ena snabbare och mer pålitlig. Skillnaden handlar om mikrointeraktioner: några hundra millisekunder animation som avgör om användaren litar på det som visas på skärmen. Jag bryter ner dem från grunden – trigger/feedback-modellen, vad som faktiskt händer i webbläsarens renderingsmotor, och prefers-reduced-motion.
CSS Houdini är inte en enda teknik, utan en samling specifikationer i mycket olika mognadsgrad. Ta reda på vilken del som duger för produktion idag, hur @property och paint worklet egentligen fungerar, och varför resten fortfarande är ett experiment.
