Een lijst van duizend reacties rendert traag, dus grijp je naar react-window – en in ruil voor soepel scrollen verlies je Ctrl+F, het afdrukken van de pagina en gedeeltelijk de navigatie van schermlezers, omdat elementen buiten het venster fysiek ophouden te bestaan in de DOM. content-visibility lost hetzelfde probleem anders op: de elementen blijven in de DOM, de browser slaat alleen het kostbare layout- en paintwerk ervoor over totdat ze dicht bij het zichtbare gebied komen – en, verrassend genoeg, kan ze tijdelijk weer tonen zodra je er tekst in zoekt.
In het artikel over toegankelijkheid was een modal met display:none, die nog steeds in de accessibility-boom stond, een voorbeeld van een fout die ontstaat door een modal van nul op te bouwen met divs. De echte vraag is: waarom moest hij überhaupt van nul worden opgebouwd? Ik zoek uit wat de native <dialog> en het popover-attribuut gratis bieden – top layer, focus trap, light dismiss – en waar deze twee mechanismen zo sterk verschillen dat ze door elkaar halen zo naar een ontoegankelijke interface leidt.
De utility-klasse .mt-4 verliest het van de regel .card .card__header .card__title, ondanks dat ze logisch zou moeten winnen omdat ze later is toegevoegd. Dat is geen toeval – dat is specificiteit die precies doet waarvoor ze is ontworpen. @layer introduceert een compleet nieuwe as voor het oplossen van conflicten, die vóór specificiteit werkt, niet ernaast – met één valkuil zo contra-intuïtief dat zelfs een deel van de documentatie op het web hem verkeerd beschrijft.
Een formulierveld moet rood oplichten zodra de input erbinnen ongeldig is. Simpel genoeg – behalve dat CSS 25 jaar lang niet in staat was om een element te vragen wat er in zijn binnenste gebeurt, alleen andersom. Ik zoek uit hoe :has() die richting omdraait, hoe het verschilt van gewone combinators, en waar deze nieuwe kracht echt performance kost.
Dezelfde productkaart ziet er in een grid geweldig uit en breekt in een smalle sidebar – ondanks zorgvuldig gekozen media queries. Het probleem zit niet in je code, maar in de vraag die een media query stelt: die gaat over de breedte van het scherm, niet over de ruimte die het component daadwerkelijk heeft gekregen. Ik zoek uit hoe container queries die vraag terugbrengen naar waar ze vanaf het begin had moeten liggen, en wat er echt onder de motorkap gebeurt zodra een element een 'query-container' wordt.
CSS Houdini is niet één technologie, maar een verzameling specificaties in zeer uiteenlopende stadia van volwassenheid. Ontdek welk deel ervan vandaag productieklaar is, hoe `@property` en de paint worklet echt werken, en waarom de rest nog steeds experimenteel is.
