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.
Apuluokka .mt-4 häviää säännölle .card .card__header .card__title, vaikka sen loogisesti pitäisi voittaa, koska se lisättiin myöhemmin. Tämä ei ole sattumaa – tämä on spesifisyys, joka tekee juuri sitä, mitä varten se on suunniteltu. @layer tuo täysin uuden akselin konfliktien ratkaisuun, joka toimii ennen spesifisyyttä, ei sen rinnalla – ja siinä on yksi sudenkuoppa niin epäintuitiivinen, että sen rikkoo jopa osa verkon dokumentaatiosta.
'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.
Lomakekentän pitäisi korostua punaisena, kun sen sisällä oleva input on virheellinen. Yksinkertainen asia – paitsi että CSS ei 25 vuoteen kyennyt kysymään elementiltä, mitä sen sisällä tapahtuu, vain päinvastoin. Tarkastelen, miten :has() kääntää tämän suunnan, miten se eroaa tavallisista kombinaattoreista ja missä tämä uusi voima todella maksaa suorituskyvyssä.
Sama tuotekortti näyttää hienolta ruudukossa ja hajoaa kapeassa sivupalkissa – huolellisesti valituista media querysta huolimatta. Ongelma ei ole koodissasi, vaan siinä kysymyksessä, jonka media query esittää: näytön leveydestä, ei siitä tilasta, jonka komponentti todellisuudessa sai. Tarkastelen, miten container queryt siirtävät tämän kysymyksen sinne, missä sen olisi pitänyt olla alusta asti, ja mitä konepellin alla oikeasti tapahtuu, kun elementistä tulee "kyselysäiliö".
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ä.
Kaksi verkkokauppaa, sama tuote, sama palvelimen vasteaika – silti toinen tuntuu nopeammalta ja luotettavammalta. Ero syntyy mikrointeraktioista: muutamasta sadasta millisekunnista animaatiota, jotka ratkaisevat, luottaako käyttäjä näkemäänsä. Puran ilmiön perusteista lähtien – trigger/feedback-mallista, siitä mitä selaimen renderöintimoottorin sisällä oikeasti tapahtuu, sekä prefers-reduced-motion-asetuksesta.
CSS Houdini ei ole yksi teknologia, vaan joukko spesifikaatioita hyvin eri kypsyysasteilla. Selvitä, mikä sen osista sopii jo tuotantokäyttöön, miten @property ja paint worklet oikeasti toimivat, ja miksi loput ovat yhä kokeellisia.
