Ucząc się zasad podstawowego CSS, uczy się pisać style modułowe, wielokrotnego użytku i opisowe, aby zapewnić łatwość konserwacji. Kiedy jednak programiści zajmują się aplikacjami w świecie rzeczywistym, często wydaje się niemożliwe dodawanie funkcji interfejsu użytkownika bez przedostawania się stylów do niezamierzonych obszarów. Problem ten często zamienia się w samospełniającą się pętlę; style teoretycznie ograniczone do jednego elementu lub klasy zaczynają pojawiać się tam, gdzie nie powinny. Zmusza to programistę do utworzenia jeszcze bardziej szczegółowych selektorów w celu zastąpienia stylów, które wyciekły, a które następnie przypadkowo zastępują style globalne i tak dalej. Jednym z teoretycznych rozwiązań tego problemu są sztywne konwencje nazw klas, takie jak BEM. Metodologia BEM (Block, Element, Modifier) to systematyczny sposób nazewnictwa klas CSS w celu zapewnienia możliwości ponownego użycia i struktury plików CSS. Takie konwencje nazewnictwa mogą zmniejszyć obciążenie poznawcze poprzez wykorzystanie języka domeny do opisu elementów i ich stanu, a jeśli zostaną poprawnie zaimplementowane, mogą ułatwić utrzymanie stylów dla dużych aplikacji. Jednak w prawdziwym świecie nie zawsze tak to wygląda. Priorytety mogą się zmieniać, a wraz ze zmianami wdrażanie staje się niespójne. Małe zmiany w strukturze HTML mogą wymagać wielu zmian nazw klas CSS. W przypadku wysoce interaktywnych aplikacji front-end nazwy klas zgodne ze wzorcem BEM mogą stać się długie i nieporęczne (np. app-user-overview__status--is-authenticating), a niepełne przestrzeganie zasad nazewnictwa łamie strukturę systemu, negując w ten sposób jego zalety. Biorąc pod uwagę te wyzwania, nic dziwnego, że programiści zwrócili się ku frameworkom, a Tailwind jest najpopularniejszym frameworkiem CSS. Zamiast walczyć z czymś, co wydaje się niemożliwą do wygrania wojną specyficzności pomiędzy stylami, łatwiej jest zrezygnować z CSS Cascade i skorzystać z narzędzi gwarantujących całkowitą izolację. Deweloperzy bardziej skupiają się na narzędziach Skąd wiemy, że niektórzy programiści chętnie unikają stylów kaskadowych? To rozwój „nowoczesnych” narzędzi front-endowych – takich jak frameworki CSS-in-JS – zaprojektowanych specjalnie do tego celu. Praca z izolowanymi stylami, które są ściśle powiązane z konkretnymi komponentami, może wydawać się powiewem świeżego powietrza. Eliminuje potrzebę nazywania rzeczy – wciąż jedno z najbardziej znienawidzonych i czasochłonnych zadań front-endu – i pozwala programistom na produktywność bez pełnego zrozumienia lub wykorzystania zalet dziedziczenia CSS. Ale porzucenie CSS Cascade wiąże się z własnymi problemami. Na przykład komponowanie stylów w JavaScript wymaga skomplikowanych konfiguracji kompilacji i często prowadzi do niezręcznego mieszania się stylów ze znacznikami komponentów lub HTML. Zamiast dokładnie przemyślanych konwencji nazewnictwa, umożliwiamy budowanie narzędzi do automatycznego generowania dla nas selektorów i identyfikatorów (np. .jsx-3130221066), co wymaga od programistów nadążania za kolejnym pseudojęzykiem samym w sobie. (Jakby obciążenie poznawcze związane ze zrozumieniem, co robią wszystkie efekty useEffects twojego komponentu, nie było już wystarczające!) Dalsze abstrahowanie zadania nazewnictwa klas do narzędzi oznacza, że podstawowe debugowanie jest często ograniczone do określonych wersji aplikacji skompilowanych na potrzeby programowania, zamiast wykorzystywać natywne funkcje przeglądarki, które obsługują debugowanie na żywo, takie jak narzędzia programistyczne. To prawie tak, jakbyśmy musieli opracować narzędzia do debugowania narzędzi, których używamy do abstrakcji tego, co już oferuje sieć — a wszystko po to, aby uciec od „bólu” pisania standardowego CSS. Na szczęście nowoczesne funkcje CSS nie tylko czynią pisanie standardowego CSS bardziej elastycznym, ale także dają programistom takim jak my znacznie więcej możliwości zarządzania kaskadą i sprawiania, by działała ona dla nas. Warstwy kaskadowe CSS są doskonałym przykładem, ale jest jeszcze jedna funkcja, na którą zaskakująco brakuje uwagi — choć teraz się to zmienia, ponieważ niedawno stała się kompatybilna z wersją Baseline. Reguła CSS @scope At Uważam, że reguła CSS @scope at jest potencjalnym lekarstwem na omawiany przez nas rodzaj niepokoju wywołanego wyciekiem stylu, który nie zmusza nas do rezygnowania z zalet natywnej sieci na rzecz abstrakcji i dodatkowych narzędzi do kompilacji. „Reguła @scope CSS at umożliwia wybieranie elementów w określonych poddrzewach DOM, precyzyjne kierowanie na elementy bez pisania zbyt szczegółowych selektorów, które trudno zastąpić, i bez zbyt ścisłego łączenia selektorów ze strukturą DOM.” — MDN
Innymi słowy, w określonych przypadkach możemy pracować z izolowanymi stylami, nie rezygnując z dziedziczenia, kaskadowania czy nawet podstawowego rozdzielania zagadnień.to była od dawna naczelna zasada rozwoju front-endu. Ponadto ma doskonały zasięg przeglądarki. W rzeczywistości Firefox 146 dodał obsługę @scope w grudniu, dzięki czemu po raz pierwszy jest kompatybilny z wersją Baseline. Oto proste porównanie przycisku korzystającego ze wzorca BEM z regułą @scope:
Reguła @scope pozwala na precyzję przy mniejszej złożoności. Programista nie musi już tworzyć granic przy użyciu nazw klas, co z kolei pozwala mu pisać selektory w oparciu o natywne elementy HTML, eliminując w ten sposób potrzebę stosowania normatywnych wzorców nazw klas CSS. Po prostu eliminując potrzebę zarządzania nazwami klas, @scope może złagodzić strach związany z CSS w dużych projektach.
Podstawowe użycie
Aby rozpocząć, dodaj regułę @scope do swojego CSS i wstaw selektor główny, do którego style będą objęte zakresem:
@zakres (
Jeśli na przykład ograniczymy style do elementu
@scope (nawigacja) { a { /* Style łączy w zakresie nawigacji */ }
a:active { /* Aktywne style linków */ }
a:active::before { /* Aktywny link z pseudoelementem dla dodatkowej stylizacji */ }
@media (maksymalna szerokość: 768 pikseli) { a { /* Responsywne dostosowania */ } } }
Nie jest to samo w sobie przełomowa funkcja. Jednakże do zakresu można dodać drugi argument, aby utworzyć dolną granicę, skutecznie definiując punkt początkowy i końcowy zakresu.
/* Żaden element wewnątrz ul nie będzie miał zastosowanych stylów */ @scope (nav) do (ul) { za { rozmiar czcionki: 14px; } }
Praktykę tę nazywa się określaniem zakresu pierścieniowego i można zastosować kilka podejść, w tym serię podobnych, wysoce specyficznych selektorów ściśle powiązanych ze strukturą DOM, pseudoselektor :not lub przypisywanie określonych nazw klas do elementów w
Wniosek Frameworki CSS zorientowane na użyteczność, takie jak Tailwind, dobrze sprawdzają się w prototypowaniu i mniejszych projektach. Ich zalety szybko jednak maleją, jeśli zostaną zastosowane w większych projektach, w których bierze udział więcej niż kilku programistów. W ciągu ostatnich kilku lat rozwój front-endu stał się coraz bardziej skomplikowany, a CSS nie jest wyjątkiem. Chociaż zasada @scope nie jest panaceum na wszystko, może zmniejszyć potrzebę stosowania skomplikowanych narzędzi. Użyty zamiast lub obok strategicznego nazewnictwa klas, @scope może sprawić, że pisanie CSS będzie łatwiejsze i przyjemniejsze. Dalsze czytanie
CSS @zakres (MDN) „CSS @scope”, Juan Diego Rodríguez (CSS-Tricks) Informacje o wydaniu Firefoksa 146 (Firefox) Obsługa przeglądarek (CanIUse) Popularne frameworki CSS (stan CSS 2024) „C” w CSS: Cascade”, Thomas Yip (CSS-Tricks) Wprowadzenie do BEM (Pobierz BEM)
