Mikrointeraktioita käsittelevässä artikkelissa kirjoitin, että transform ja opacity animoituvat kompositorisäikeellä, joten edes raskas sivu ei saisi nykiä painikkeen animaatiossa. Tämä pitää yhä paikkansa – yhdellä varauksella, josta tuo artikkeli vaikeni: jos pääsäie on tukossa pitkän JS-tehtävän vuoksi, animaatio ei ehkä koskaan saa tilaisuutta käynnistyä, koska itse klikkauskäsittelijä odottaa jonossa. INP on mittari, joka mittaa juuri tätä aukkoa – ja scheduler.yield() on yksi harvoista tavoista sulkea se todella.
Tuhannen kommentin lista renderöityy hitaasti, joten tartut react-windowiin – ja sulavan vierityksen vastineeksi menetät Ctrl+F:n, sivun tulostuksen ja osittain ruudunlukijan navigoinnin, koska ikkunan ulkopuoliset elementit lakkaavat fyysisesti olemasta DOM:ssa. content-visibility ratkaisee saman ongelman toisin: elementit pysyvät DOM:ssa, selain vain jättää niiden kohdalla väliin kalliin layout- ja piirtotyön, kunnes ne ovat lähellä näkyvää aluetta – ja, yllättäen, se osaa tilapäisesti paljastaa ne, kun etsit niistä tekstiä.
Saavutettavuusartikkelissa display:none-määrityksellä piilotettu modaali, joka oli silti olemassa saavutettavuuspuussa, oli esimerkki virheestä, joka syntyy, kun modaali rakennetaan tyhjästä diveillä. Todellinen kysymys kuuluu: miksi se piti ylipäätään rakentaa tyhjästä? Tarkastelen, mitä natiivi <dialog> ja popover-attribuutti antavat ilmaiseksi – top layerin, fokusloukun, light dismissin – ja missä nämä kaksi mekanismia eroavat toisistaan niin paljon, että niiden sekoittaminen on suora tie saavuttamattomaan käyttöliittymään.
'Tykkää'-painike reagoi välittömästi, sydän täyttyy, laskuri kasvaa – ennen kuin palvelin on edes vastannut. Tämä ei ole mikrointeraktioartikkelin nopeuden illuusio, vaan jotain pidemmälle menevää: käyttöliittymä näyttää tilan, jota ei vielä ole olemassa, ja olettaa, että se kohta on. Tarkastelen, miten tämä rakennetaan turvallisesti – aidolla perääntymisellä valheesta, kun oletus ei pidäkään paikkaansa, ja miksi käsin kirjoitettu setState plus catch on huonompi versio siitä, mitä useOptimistic tarjoaa.
'use server' näyttää pelkältä syntaktiselta sokerilta fetch-kutsulle API-reittiin – ja juuri siksi useimmat toteutukset kohtelevat sitä kuin tavallista funktiokutsua. Tämä on virhe, jolla on konkreettisia seurauksia: jokaisesta 'use server' -merkinnällä varustetusta funktiosta tulee julkinen päätepiste verkossa, ja tähän mekanismiin rakennettu lomake toimii jopa ennen kuin JavaScript ehtii latautua. Tarkastelen, mitä tämän direktiivin alla oikeasti tapahtuu, ja missä piilevät sudenkuopat, joita dokumentaatiosta ei ensi silmäyksellä huomaa.
Oikea HTML on vasta lähtökohta. Katso, miten saavutettavuuspuu oikeasti toimii, miksi ARIA aiheuttaa haittaa useammin kuin luulisit, ja rakenna kanssani oikea accordion, live-region ja fokuksenhallinta Next.js:ssä.
