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.
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.
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ö".
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.
