En liste med tusen kommentarer rendrer sakte, så du griper til react-window – og i bytte mot jevn scrolling mister du Ctrl+F, utskrift av siden og delvis skjermleser-navigasjon, fordi elementene utenfor vinduet slutter å fysisk eksistere i DOM-en. content-visibility løser det samme problemet annerledes: elementene blir værende i DOM-en, nettleseren hopper rett og slett over det kostbare layout- og malingsarbeidet for dem helt til de kommer nær det synlige området – og, overraskende nok, kan den midlertidig avsløre dem når du søker etter tekst i dem.
I artikkelen om tilgjengelighet var en modal med display:none, som fortsatt fantes i tilgjengelighetstreet, et eksempel på en feil som følger av å bygge en modal fra bunnen med div-er. Det egentlige spørsmålet er: hvorfor måtte den i det hele tatt bygges fra bunnen? Jeg går gjennom hva den native <dialog> og popover-attributtet gir deg gratis – top layer, fokusfelle, light dismiss – og hvor disse to mekanismene skiller seg så mye at å forveksle dem er en enkel vei til et utilgjengelig grensesnitt.
Verktøyklassen .mt-4 taper mot regelen .card .card__header .card__title, selv om den logisk sett burde vinne fordi den ble lagt til senere. Dette er ikke tilfeldig – det er spesifisitet som gjør nøyaktig det den er designet for å gjøre. @layer innfører en helt ny akse for å avgjøre konflikter, som virker før spesifisiteten, ikke sammen med den – og har én felle så mot-intuitiv at selv deler av dokumentasjonen på nettet bryter den.
Et skjemafelt skal lyse rødt når input-en inni er ugyldig. Enkelt nok – bortsett fra at CSS i 25 år ikke kunne spørre et element om hva som skjer inni det, bare motsatt. Jeg går gjennom hvordan :has() snur denne retningen, hvordan den skiller seg fra vanlige kombinatorer, og hvor denne nye kraften faktisk koster ytelse.
Det samme produktkortet ser flott ut i rutenettet og bryter sammen i en smal sidebar – til tross for nøye utvalgte media queries. Problemet ligger ikke i koden din, men i spørsmålet media query faktisk stiller: om bredden på skjermen, ikke om plassen komponenten faktisk fikk tildelt. Jeg går gjennom hvordan container queries flytter dette spørsmålet dit det burde vært stilt fra begynnelsen, og hva som egentlig skjer under overflaten når et element blir en «spørringsbeholder».
CSS Houdini er ikke én teknologi, men en samling spesifikasjoner i svært ulik grad av modenhet. Finn ut hvilken del som er produksjonsklar i dag, hvordan @property og paint worklet egentlig fungerer, og hvorfor resten fortsatt er eksperimentell.
