Hacker News dostrzega selektor prefiksu klas CSS, ale prawdziwy test dopiero nadchodzi
Hacker News zwrócił uwagę na propozycję CSS, która przez ponad dwa lata przeszła drogę od skarg deweloperów do zaakceptowanego kierunku standaryzacji. Selektor prefiksu klas pozwoliłby autorom dopasowywać oddzielne tokeny klas współdzielące prefiks, potencjalnie za pomocą zwięzłej składni takiej jak .icon-*.
Brzmi to jak niewielkie ułatwienie. Głębszy konflikt dotyczy tego, czy przeglądarki powinny rozumieć wzorce nazewnictwa, które są już szeroko stosowane przez frameworki narzędziowe, biblioteki ikon i zespoły tworzące aplikacje.
Obecnie autorzy muszą wyliczać każdą powiązaną klasę, dodawać wspólną klasę bazową albo polegać na kruchym obejściu z użyciem selektora atrybutu. CSS Working Group zaakceptowała podstawowy przypadek użycia, ale akceptacja nie oznacza obsługi przez przeglądarki. Między propozycją a witrynami produkcyjnymi nadal stoją testy, tekst specyfikacji, prace implementacyjne i interoperacyjność.
Co Hacker News faktycznie znalazł w propozycji CSS
Wiadomością nie jest to, że przeglądarki nagle wdrożyły wieloznacznikowy selektor klas. Istotna zmiana polega na tym, że CSS Working Group zaakceptowała problem.
Lea Verou otworzyła bazową propozycję CSSWG 26 lutego 2024 roku. Opisała powtarzającą się potrzebę dopasowywania pojedynczych nazw klas współdzielących prefiks.
Zgłoszenie pozostawało otwarte, podczas gdy uczestnicy omawiali przypadki użycia, składnię i szersze kwestie dotyczące selektorów atrybutów. Jest teraz zamknięte, opatrzone etykietą „Accepted by CSSWG Resolution” i przypisane do Selectors Level 5.
Ten status ma znaczenie. Oznacza, że grupa robocza uzgodniła, iż CSS powinien rozwiązać ten przypadek użycia. Nie oznacza, że wstępna notacja .prefix-* stała się stabilnym standardem sieciowym.
Zgłoszenie ma również etykietę „Needs Testcase (WPT)”. WPT oznacza Web Platform Tests, wspólny zestaw testów używany przez przeglądarki do sprawdzania interoperacyjnego zachowania.
Sekcja rozwoju nie wymienia żadnego powiązanego pull requestu. Publiczny szkic Selectors Level 5 również nie przedstawia jeszcze tej funkcji jako ukończonego, gotowego do wdrożenia selektora.
Te szczegóły określają faktyczne wydarzenie. Długo rozwijana propozycja przekroczyła istotny próg standaryzacyjny, podczas gdy proces implementacji pozostaje nieukończony.
Propozycja koncentruje się na tokenach klas, a nie na dowolnym tekście wewnątrz całego atrybutu class. To rozróżnienie wyjaśnia zarówno jej użyteczność, jak i niewystarczalność obecnych obejść.
Rozważmy taki znacznik:
Deweloper może chcieć jednej reguły dopasowującej każdy token klasy zaczynający się od icon-. Pożądana rodzina mogłaby obejmować icon-alert, icon-search i setki dodatkowych ikon.
Proponowany selektor prefiksu klas wyraża tę rodzinę bezpośrednio:
Ten przykład opisuje zamierzony model, a nie gotową do użycia w produkcji składnię. Autorzy nie powinni go wdrażać, dopóki specyfikacje, testy i przeglądarki nie uzgodnią jego zachowania.
Istniejący selektor atrybutu wygląda zwodniczo podobnie:
Jednak ^= sprawdza, czy pełna wartość atrybutu zaczyna się od podanego tekstu. Nie analizuje każdego tokenu klasy niezależnie.
Reguła dopasowuje ten element:
Pomija natomiast ten:
Deweloperzy często kompensują to dwoma selektorami:
Pierwszy obsługuje pasujący token na początku. Drugi wyszukuje pasujący token po spacji.
Ten wzorzec działa w typowych przypadkach HTML, ale wymaga od deweloperów rozumowania o zserializowanym tekście. Selektor klasy powinien rozumować o klasach.
Propozycja dotyczy zatem rzeczywistej luki między modelem dokumentu a językiem selektorów. HTML traktuje class jako zbiór tokenów rozdzielonych spacjami, podczas gdy selektory podłańcuchów działają na zserializowanej wartości atrybutu.
W dostarczonym zrzucie wpis Hacker News otrzymał sześć punktów i jeden komentarz. To ograniczona dyskusja, więc nie może potwierdzać szerokiego konsensusu wśród deweloperów.
Jego wartość leży gdzie indziej. Post skierował uwagę na decyzję standaryzacyjną, która w przeciwnym razie mogłaby pozostać ukryta w wieloletnim zgłoszeniu GitHub.
Dlaczego frameworki narzędziowe i biblioteki ikon odczuwają tę presję
Propozycja wywiera presję na biblioteki, które obecnie duplikują wspólne style lub wymagają dodatkowego znacznika, aby przedstawić jedną konceptualną rodzinę klas.
Frameworki narzędziowe kodują relacje między właściwościami i wartościami w nazwach takich jak pt-6 czy space-y-4. Systemy ikon używają rodzin takich jak fa-* i bi-*.
Te systemy nazewnictwa tworzą dwa rodzaje stylizacji. Każda klasa potrzebuje deklaracji specyficznych dla swojej wartości, podczas gdy cała rodzina często współdzieli deklaracje bazowe.
Rodzina ikon może na przykład wymagać wspólnych reguł wyświetlania, rozmiaru, wyrównania lub renderowania. Poszczególne klasy ikon dostarczają następnie oddzielne glify lub odwołania do obrazów.
Bez dopasowywania prefiksu autorzy bibliotek mają kilka niedoskonałych możliwości. Mogą wyliczać każdą klasę, wymagać oddzielnej klasy bazowej albo manipulować pełnym łańcuchem atrybutu.
Wyliczanie tworzy selektory takie jak ten:
Narzędzie budujące może wygenerować taką listę. Generowanie ogranicza ręczne pisanie, ale nie usuwa wygenerowanych bajtów ani relacji, którą autorzy muszą utrzymywać.
Drugie podejście oddziela wspólne zachowanie od indywidualnej wartości:
Ten projekt jest jawny i często rozsądny. Wymaga też od użytkowników pamiętania o dwóch klasach dla jednego widocznego komponentu.
Bootstrap Icons stosuje ten ogólny wzorzec, używając bazowej klasy bi oraz konkretnej klasy ikony. Propozycja CSSWG wskazuje takie systemy jako dowód, że brakujący selektor tworzy rzeczywiste utrudnienia dla autorów.
Selektor prefiksu klas umożliwiłby taki znacznik:
Selektor rodziny mógłby dostarczać wspólne zachowanie, podczas gdy .icon-alert dostarczałby swoją unikalną deklarację.
Nie oznacza to automatycznie, że znacznik z jedną klasą jest lepszy. Klasy bazowe mogą komunikować intencję, upraszczać debugowanie i zapobiegać nadmiernie szerokiej regule rodziny.
Propozycja daje autorom inną reprezentację. Biblioteki mogłyby zdecydować, czy jawne klasy bazowe, czy wywnioskowane rodziny prefiksów lepiej pasują do ich kontraktów.
CSS z podejściem utility-first tworzy związaną z tym presję. Prefiks taki jak pt- koduje kategorię właściwości, a sufiks identyfikuje wartość.
Framework mógłby użyć selektora rodziny, aby ustawić wspólną właściwość niestandardową, regułę containmentu albo inne zachowanie bazowe. Konkretne klasy mogłyby następnie dostarczać indywidualne wartości.
Natychmiastowe oszczędności mogłyby wyglądać skromnie. Ważniejsza jest korzyść strukturalna, ponieważ arkusz stylów może wyrażać to samo grupowanie, które jest już zakodowane w nazwach klas.
Dlatego propozycja nie jest po prostu cukrem syntaktycznym. Zmiany składni stają się architektoniczne, gdy pozwalają autorom usunąć generowane listy lub redundantny znacznik.
Funkcja nie zastąpi jednak Tailwind, Bootstrap, Sass, PostCSS ani ekstrakcji wykonywanej na etapie budowania. Narzędzia te rozwiązują znacznie szersze problemy niż dopasowywanie prefiksu jednego tokenu.
Tailwind na przykład generuje deklaracje na podstawie skonfigurowanych narzędzi i wykrytego użycia. Natywny selektor nie wygeneruje deklaracji specyficznej dla wartości każdej klasy narzędziowej.
Przeglądarka może dopasować .pt-*, ale nie potrafi wywnioskować, co oznacza każdy sufiks. Arkusz stylów nadal potrzebuje reguł mapujących obsługiwane nazwy na prawidłowe wartości właściwości.
Selektor prefiksu klas dotyczy zatem grupowania, a nie dowolnego generowania klas narzędziowych. Twierdzenia, że eliminuje on narzędzia do budowania CSS, zawyżają jego zakres.
Grupa odbiorców, których to dotyczy, wykracza także poza opiekunów frameworków. Zespoły aplikacyjne często używają nazw takich jak status-*, theme-*, language-* czy priority-*.
System dokumentacji może emitować klasy language-javascript i language-python w blokach kodu. Sama specyfikacja HTML zaleca konwencję nazewnictwa language- dla próbek kodu.
Programy do podświetlania składni muszą następnie identyfikować token języka, nawet gdy inne klasy występują wcześniej. Verou przywołała to jako praktyczny problem dla Prism.
Zespoły utrzymujące duże frontendy powinny zwrócić na to uwagę, ponieważ konwencje stają się infrastrukturą. Gdy tysiące szablonów zależą od wzorca nazewnictwa, każde obejście staje się trudniejsze do zmiany.
Utrzymywanie tych decyzji wymaga również niezawodnej dokumentacji wewnętrznej. Przeszukiwalna baza wiedzy inżynierskiej może zachować konwencje selektorów wraz z notatkami dotyczącymi komponentów i migracji.
Decyzja standaryzacyjna wywiera na opiekunów frameworków i bibliotek presję długoterminową, a nie natychmiastową presję migracyjną. Muszą oni zdecydować, czy relacje prefiksów są istotnymi publicznymi kontraktami.
Mechanizm naprawia dopasowywanie tokenów, a nie tylko skraca składnię
Centralnym mechanizmem jest uwzględniające tokeny dopasowywanie prefiksów, które zasadniczo różni się od przeszukiwania surowego tekstu atrybutu `class`.
CSS zawiera już kilka selektorów atrybutów. Specyfikacja selektorów definiuje operatory dla dokładnych wartości, tokenów rozdzielonych białymi znakami, prefiksów, sufiksów i podłańcuchów.
Każdy operator odpowiada na inne pytanie. [class~="button"] znajduje pełny token button, podczas gdy [class^="button-"] sprawdza początek całej wartości atrybutu.
CSS nie ma natomiast operacji łączonej. Autorzy muszą wybrać jeden token z listy rozdzielonej białymi znakami, a następnie sprawdzić, czy ten token zaczyna się od prefiksu.
Oryginalne zgłoszenie rozważało dwie drogi. Jedna rozszerza znany selektor klasy o składnię wieloznacznikową, taką jak .foo-*.
Druga dodaje operator atrybutu łączący zachowanie ~= i ^=. Proponowane formy obejmowały ~^=, ^~= i ^~.
Notacja klasowa jest łatwiejsza do odczytania, ponieważ pozostaje w obrębie istniejącego słownictwa selektorów klas CSS. Reguła zaczynająca się od kropki wyraźnie komunikuje, że celuje w klasy.
Połączony operator atrybutu byłby bardziej ogólny. Mógłby mieć zastosowanie do atrybutów innych niż class, gdy zawierają one wartości rozdzielone spacjami.
Ogólność tworzy własne koszty. Nowy operator musi pasować do zasad parsowania CSS, pozostać zrozumiały i nie wprowadzać w błąd autorów, którzy już uczą się kilku operatorów atrybutów.
Składnia klas z wieloznacznikiem rodzi również pytania wykraczające poza estetykę. Specyfikacja musi określić escaping, granice dopasowania, rozróżnianie wielkości liter, nieprawidłowe dane wejściowe i specyficzność.
Specyficzność określa, która deklaracja wygrywa, gdy dopasowuje się wiele selektorów. Nowy selektor potrzebuje przewidywalnego zachowania obok zwykłych klas, atrybutów, pseudoklas i reguł zagnieżdżonych.
Proces standaryzacyjny musi również zdecydować, jak selektor zachowuje się w interfejsach API przeglądarek. querySelector(), matches() i parsowanie arkuszy stylów przyjmują składnię selektorów.
Zachowanie nieprawidłowych selektorów ma znaczenie, ponieważ nieobsługiwana składnia może unieważnić listę selektorów. Autorzy potrzebują niezawodnego sposobu korzystania z funkcji bez przypadkowego pomijania niezwiązanych reguł.
Wykrywanie funkcji to kolejna praktyczna kwestia. CSS obsługuje @supports selector(...), aby sprawdzać, czy przeglądarka rozpoznaje selektor.
Przyszły wzorzec stopniowego ulepszania mógłby przypominać ten:
Ta ilustracja pozostaje hipotetyczna, dopóki nie zostanie opublikowana ostateczna gramatyka. Pokazuje, dlaczego szczegóły parsowania mają znaczenie, zanim deweloperzy będą mogli pisać bezpieczne rozwiązania awaryjne.
Kwestie wydajności zasługują na ostrożne traktowanie, ale nie powinny stawać się spekulacją. Przeglądarki już utrzymują zoptymalizowane mechanizmy dopasowywania klas i atrybutów.
Operacja dopasowywania prefiksu uwzględniająca tokeny nie jest automatycznie wolna. Jej koszt zależy od strategii indeksowania silnika, wzorców arkuszy stylów i ostatecznych decyzji specyfikacji.
Podobnie funkcja sama w sobie nie zmusza przeglądarek do skanowania każdej klasy na każdym elemencie przy każdym przeliczeniu stylów. Implementatorzy mogą tworzyć indeksy i skróty dopasowywania.
Tylko prototypy przeglądarek i Web Platform Tests mogą zweryfikować te założenia. Akceptacja standardu wyznacza kierunek, ale nie stanowi dowodu wydajności.
Najmocniejszym argumentem propozycji jest zgodność semantyczna. Deweloperzy postrzegają class="card icon-alert muted" jako trzy tokeny, a nie jeden ciąg znaków zawierający spacje.
Zwykły .icon-alert już korzysta z tego modelu tokenów. Rozszerzenie go na rodzinę klas zachowuje spójność modelu mentalnego.
Ta zgodność semantyczna poprawia również możliwość przeglądu kodu. .icon-* od razu wskazuje zamierzoną przestrzeń nazw lub rodzinę, podczas gdy obejście z parą atrybutów wymaga dokładniejszej inspekcji.
Mimo to zwięzła składnia może ukrywać szeroki zakres dopasowania. Jedna reguła rodziny może wpłynąć na każdą klasę rozpoczynającą się krótkim prefiksem w całej aplikacji.
Nie jest to wada parsera. To problem zarządzania arkuszem stylów, podobny do szerokich selektorów typu lub luźno nazwanych właściwości niestandardowych.
Mechanizm daje CSS czystszy prymityw. Nie przesądza jednak o tym, czy zespół użyje go rozważnie.
Prawdziwym ryzykiem jest nieszczelny CSS, a nie znak wieloznaczny
Selektor prefiksowy może ograniczyć kruchy kod, jednocześnie ułatwiając przypadkowe powiązania, więc po jego wdrożeniu dyscyplina nazewnicza staje się ważniejsza.
Sceptyczna reakcja jest prosta. Jeśli selektor dopasowuje otwartą rodzinę, przyszła klasa może odziedziczyć style, których jej autor nigdy się nie spodziewał.
Załóżmy, że system projektowy definiuje tę regułę:
Kilka miesięcy później inny zespół dodaje card-payment-error na potrzeby analityki lub stanu aplikacji. Ta klasa dołączyłaby do rodziny stylów, mimo że służy innemu celowi.
Klasa bazowa pozwala uniknąć tej niejednoznaczności:
Znaczniki wskazują, że element jest kartą. Konkretna klasa dodaje odrębne znaczenie.
Dopasowanie prefiksowe wywodzi przynależność z pisowni. Może być zwięzłe, ale przekształca konwencje nazewnicze w wykonywalne relacje.
To rozróżnienie przypomina typowanie strukturalne w programowaniu. Nazwa kwalifikuje się, ponieważ ma oczekiwany kształt, a nie dlatego, że autor jawnie zadeklarował przynależność.
Może to dobrze działać w kontrolowanych przestrzeniach nazw. Staje się ryzykowne, gdy krótkie prefiksy obejmują produkty, starsze moduły, widżety innych firm lub niezależnie zarządzane zespoły.
Ta obawa pojawiła się we wczesnych publicznych reakcjach wokół podlinkowanego wpisu. Jeden z komentujących na Reddicie podsumował lęk jako więcej okazji do „leaky css”.
Ta reakcja nie jest argumentem przeciw standardowi. Wskazuje kompromis, którego specyfikacje nie mogą rozwiązać za zespoły aplikacyjne.
Biblioteki musiałyby dokumentować rodziny prefiksów jako stabilne API. Gdy .icon-* ma wspólne zachowanie, każda nowa klasa zaczynająca się od icon- wchodzi w ten kontrakt.
Refaktoryzacja również staje się mniej lokalna. Zmiana nazwy jednej klasy może zmienić zarówno jej konkretną regułę, jak i wszelkie pasujące do niej reguły rodziny z symbolem wieloznacznym.
Narzędzia deweloperskie będą musiały wyraźnie prezentować te relacje. Inspektor powinien pokazywać, że .icon-alert dopasował selektor rodziny, a nie tylko swój dokładny selektor.
Narzędzia wyszukiwania, lintery i mechanizmy inteligencji kodu mogą wymagać podobnych aktualizacji. Analiza statyczna staje się trudniejsza, gdy selektor reprezentuje rozszerzający się zbiór, a nie stałą nazwę.
Propozycja może także zachęcić autorów do kodowania większej ilości danych w nazwach klas. Ten wzorzec jest już powszechny, ale natywne wsparcie może zwiększyć jego atrakcyjność.
Uczestnicy CSSWG pytali, czy niektóre relacje klucz-wartość nie powinny trafiać zamiast tego do atrybutów data-*. Na przykład data-pt="6" strukturalnie rozdziela właściwość i wartość.
Taka reprezentacja jest bardziej jednoznaczna, ale też bardziej rozwlekła. Może nie integrować się z istniejącymi konwencjami frameworków ani narzędziami opartymi na klasach.
Żaden model nie wygrywa uniwersalnie. Klasy pozostają odpowiednie do grupowania i zaczepów stylowania, natomiast atrybuty danych mogą reprezentować stan lub dane aplikacji.
Selektor prefiksu klasy nie powinien stać się wymówką do przenoszenia każdego stanu do skompresowanej nazwy klasy. Natywne dopasowanie nie usuwa potrzeby podejmowania semantycznych decyzji projektowych.
W okresie przejściowym istnieje także ryzyko zgodności. Autorzy nie mogą zakładać, że akceptacja standardu oznacza działanie składni we wszystkich przeglądarkach.
Użycie nierozpoznanego selektora bez mechanizmu zapasowego może po cichu usunąć zamierzone stylowanie. Wdrożenie produkcyjne powinno poczekać na udokumentowane wsparcie i dowody interoperacyjności.
Deweloperzy powinni też powstrzymać się od kopiowania przykładowej składni, zanim się ustabilizuje. Zgłoszenie proponowało .foo-*, ale grupy robocze mogą zmienić gramatykę podczas redagowania specyfikacji.
Nawet gdy jeden silnik zaimplementuje tę funkcję, zespoły powinny sprawdzić, czy inne silniki identycznie obsługują przypadki brzegowe. Historia CSS zna funkcje, które potrzebowały lat, aby osiągnąć niezawodną interoperacyjność.
Ujęcie tematu przez Hacker News może skompresować te etapy do jednego nagłówka. „Przyszły CSS” jest uczciwym określeniem, natomiast „nowy CSS, którego możesz użyć już teraz” byłoby mylące.
Ostrożny zespół tworzący aplikację powinien nadal stosować jawne klasy bazowe, gdy taka struktura komunikuje istotne znaczenie. Generowane listy selektorów pozostają rozsądną opcją, gdy rodzina klas jest skończona.
Obecne obejście z atrybutami nadal sprawdza się w kontrolowanych znacznikach. Autorzy muszą pamiętać, że opiera się ono na białych znakach i serializacji atrybutów, a nie na bezpośredniej semantyce tokenów.
Nie istnieje jedna zasada migracji pasująca do każdej bazy kodu. Funkcja ulepsza dostępny język, ale to architektura nadal decyduje, czy ulepsza aplikację.
Co musi się wydarzyć, zanim selektor prefiksu klasy trafi do przeglądarek
Trzy sygnały zadecydują, czy zaakceptowany pomysł stanie się niezawodnym CSS: tekst specyfikacji, wspólne testy i interoperacyjne implementacje przeglądarek.
Pierwszym sygnałem jest konkretna zmiana w Selectors Level 5. Projekt potrzebuje normatywnej gramatyki i reguł dopasowania, a nie tylko podlinkowanej decyzji GitHub.
Tekst normatywny definiuje, co muszą robić zgodne implementacje. Powinien rozstrzygnąć formę selektora, granice tokenów, znaki ucieczki, specyficzność i zachowanie w API selektorów.
Taka zmiana wzmocniłaby argument, że .prefix-*, lub składnia będąca jej następcą, zmierza w stronę implementacji. Inna gramatyka osłabiłaby założenia oparte na obecnych przykładach.
Drugim sygnałem są postępy w Web Platform Tests. Etykieta testu w zgłoszeniu pokazuje, że grupa robocza oczekuje wykonywalnego pokrycia.
Testy powinny obejmować klasy w różnych pozycjach atrybutu, wiele pasujących tokenów, znaki ucieczki, zachowanie wielkości liter i nieprawidłową składnię.
Powinny również obejmować API selektorów JavaScript. Funkcja CSS pozostaje niepełna, jeśli arkusze stylów i querySelector() nie zgadzają się co do tej samej gramatyki.
Szeroki zestaw testów zwiększyłby pewność, że zespoły przeglądarek dzielą jedną interpretację. Brakujące lub wielokrotnie zmieniane testy wskazywałyby na nierozstrzygnięte szczegóły projektu.
Trzecim sygnałem jest implementacja w różnych silnikach przeglądarek. Jedna eksperymentalna kompilacja może wykazać wykonalność, ale nie może potwierdzić zgodności w sieci.
Deweloperzy powinni obserwować trackery zgłoszeń Chromium, Gecko i WebKit pod kątem prac implementacyjnych. Informacje o wydaniach i dane o zgodności będą ważniejsze niż zainteresowanie w mediach społecznościowych.
Dostępność w wielu silnikach wzmocniłaby architektoniczną wartość propozycji. Długotrwałe wsparcie w jednym silniku utrzymałoby ją w obszarze progressive enhancement.
Eksperymenty frameworków dostarczają dodatkowej wskazówki dotyczącej adopcji, choć następują po tych trzech sygnałach technicznych. Opiekunowie projektów mogą sprawdzić, czy selektor rodziny zmniejsza wynikowy kod lub upraszcza publiczne znaczniki.
Przydatne pomiary obejmują rozmiar generowanych selektorów, złożoność procesu budowania, koszt migracji i przejrzystość debugowania. Wyniki te są ważniejsze niż liczenie znaków w jednym selektorze.
Adopcja przez frameworki nie jest wymagana, aby funkcja odniosła sukces. Mniejsze systemy projektowe, biblioteki ikon i narzędzia do podświetlania składni mogą korzystać z niej niezależnie.
Przykład klas językowych HTML może okazać się szczególnie pouczający. Sprawdza, czy dopasowanie świadome tokenów ulepsza ugruntowaną konwencję poza stylowaniem utility-first.
Deweloperzy nie powinni oczekiwać, że propozycja umożliwi dowolne dopasowanie wzorców. Dyskusja dotyczy prefiksów pojedynczych tokenów klas, a nie wyrażeń regularnych wewnątrz CSS.
Powinni także unikać założenia, że symbole wieloznaczne dla sufiksów i fragmentów pojawią się jednocześnie. Szersze projekty symboli wieloznacznych wymagają osobnego uzasadnienia i prac nad specyfikacją.
Na razie kod produkcyjny powinien traktować selektor jako zaakceptowany kierunek będący w trakcie rozwoju. Zespoły mogą oceniać konwencje nazewnicze bez wdrażania nieobsługiwanej składni.
Takie przygotowanie nadal może być użyteczne. Sprawdź, czy prefiksy reprezentują zamierzone rodziny, przypadkowe podobieństwa czy mieszaninę obu.
Udokumentuj, które prefiksy działają jako publiczne kontrakty stylowania. Wskaż miejsca, w których klasa bazowa komunikuje znaczenie, które wnioskowanie mogłoby ukryć.
Przetestuj obecne obejścia z atrybutami przy zmianie kolejności klas i nieoczekiwanych białych znakach. Wiele baz kodu odkryje, że ich rzekome dopasowanie prefiksów zależy od pozycji tokenu.
Gdy pojawi się natywne wsparcie, migrację należy rozpocząć od wąskich, dobrze zarządzanych przestrzeni nazw. Rodziny ikon i generowane identyfikatory języków oferują wyraźniejsze granice niż ogólne prefiksy.
Stosuj wykrywanie funkcji, dopóki wsparcie pozostaje nierówne. Zachowaj mechanizmy zapasowe, aż dane o zgodności pokażą, że przeglądarki używane przez Twoich odbiorców zachowują się konsekwentnie.
Hacker News prawdopodobnie ponownie omówi ten selektor, gdy pojawi się prototyp przeglądarki. Ta późniejsza dyskusja powinna koncentrować się na testach, zachowaniu i interoperacyjności, a nie wyłącznie na nowości.
Znaczenie propozycji wynika z powracającego wzorca we współczesnym CSS. Przeglądarki przejmują możliwości, które autorzy wcześniej przybliżali za pomocą preprocesorów, generowanego kodu lub kruchych sztuczek z selektorami.
Ta zmiana jest węższa niż zagnieżdżanie, container queries czy :has(). Jej niewielki zakres może być zaletą, ponieważ problem i zamierzone zachowanie są wyjątkowo konkretne.
Pozostała praca jest również konkretna. Redaktorzy muszą napisać regułę, autorzy testów muszą uchwycić jej przypadki brzegowe, a zespoły przeglądarek muszą zaimplementować ten sam rezultat.
Jeśli te kroki się zbiegną, deweloperzy zyskają bezpośredni sposób kierowania stylów do wielu klas CSS według prefiksu. Jeśli się rozejdą, jawne klasy bazowe pozostaną bezpieczniejszym kontraktem.
Właściwym działaniem dziś jest obserwacja, a nie natychmiastowa wymiana. Przejrzyj propozycję, sprawdź przestrzenie nazw swoich klas i wskaż miejsca, w których dopasowanie świadome tokenów usunęłoby rzeczywiste koszty utrzymania.
Następnie obserwuj trzy sygnały w kolejności: normatywny tekst specyfikacji, kompleksowe testy i implementacje w wielu przeglądarkach. Która rodzina prefiksów w Twojej własnej bazie kodu zapewniłaby najczytelniejszy test interoperacyjności?
