Lista tysiąca komentarzy renderuje się wolno, więc sięgasz po react-window – i w zamian za płynny scroll tracisz Ctrl+F, drukowanie strony i częściowo nawigację czytnika ekranu, bo elementy poza oknem przestają fizycznie istnieć w DOM. content-visibility rozwiązuje ten sam problem inaczej: elementy zostają w DOM, przeglądarka po prostu pomija dla nich kosztowną pracę layoutu i malowania, dopóki nie znajdą się blisko widocznego obszaru – i, co zaskakujące, potrafi je tymczasowo odsłonić, gdy szukasz w nich tekstu.
W artykule o dostępności modal z display:none, który dalej istniał w drzewie dostępności, był przykładem błędu wynikającego z budowania modala od zera na divach. Prawdziwe pytanie brzmi: dlaczego w ogóle trzeba było go budować od zera? Sprawdzam, co daje za darmo natywny <dialog> i atrybut popover – top layer, pułapkę fokusu, light dismiss – i gdzie te dwa mechanizmy się różnią na tyle, że pomylenie ich to prosta droga do niedostępnego interfejsu.
Klasa narzędziowa .mt-4 przegrywa z regułą .card .card__header .card__title, mimo że logicznie powinna wygrać, bo dodano ją później. To nie przypadek – to specyficzność robiąca dokładnie to, do czego została zaprojektowana. @layer wprowadza całkiem nową oś rozstrzygania konfliktów, która działa przed specyficznością, nie razem z nią – i ma jedną pułapkę tak nieintuicyjną, że łamie ją nawet część dokumentacji w sieci.
Pole formularza ma się podświetlić na czerwono, gdy input w środku jest niepoprawny. Prosta rzecz – tylko że CSS przez 25 lat nie potrafił zapytać elementu o to, co się dzieje w jego wnętrzu, a jedynie na odwrót. Sprawdzam, jak :has() odwraca ten kierunek, czym różni się od zwykłych kombinatorów i gdzie ta nowa moc realnie kosztuje wydajność.
Ta sama karta produktu wygląda świetnie w gridzie i łamie się w wąskim sidebarze – mimo starannie dobranych media query. Problem nie leży w Twoim kodzie, tylko w pytaniu, jakie zadaje media query: o szerokość ekranu, nie o miejsce, jakie komponent faktycznie dostał. Sprawdzam, jak container queries przenoszą to pytanie tam, gdzie powinno paść od początku, i co naprawdę dzieje się pod spodem, gdy element staje się „kontenerem zapytania”.
CSS Houdini to nie jedna technologia, tylko zbiór specyfikacji w bardzo różnym stanie dojrzałości. Sprawdź, która jego część nadaje się dziś do produkcji, jak naprawdę działa @property i paint worklet, i dlaczego reszta wciąż jest eksperymentem.
