Când învățați principiile CSS de bază, cineva este învățat să scrie stiluri modulare, reutilizabile și descriptive pentru a asigura mentenabilitatea. Dar atunci când dezvoltatorii se implică în aplicații din lumea reală, de multe ori pare imposibil să adăugați funcții de UI fără ca stilurile să se scurgă în zone neintenționate. Această problemă se transformă adesea într-o buclă auto-împlinită; stilurile care sunt teoretic încadrate într-un element sau clasă încep să apară acolo unde nu le aparțin. Acest lucru forțează dezvoltatorul să creeze selectoare și mai specifice pentru a suprascrie stilurile scurse, care apoi anulează accidental stilurile globale și așa mai departe. Convențiile rigide ale numelor de clasă, cum ar fi BEM, sunt o soluție teoretică la această problemă. Metodologia BEM (Block, Element, Modifier) este o modalitate sistematică de denumire a claselor CSS pentru a asigura reutilizarea și structura în fișierele CSS. Convențiile de denumire ca aceasta pot reduce încărcătura cognitivă prin valorificarea limbajului de domeniu pentru a descrie elementele și starea acestora și, dacă sunt implementate corect, pot face stilurile pentru aplicațiile mari mai ușor de întreținut. În lumea reală, însă, nu merge întotdeauna așa. Prioritățile se pot schimba și, odată cu schimbare, implementarea devine inconsecventă. Micile modificări aduse structurii HTML pot necesita multe revizuiri ale numelui clasei CSS. Cu aplicațiile front-end extrem de interactive, numele claselor care urmează modelul BEM pot deveni lungi și greoaie (de exemplu, app-user-overview__status--is-authenticating), iar nerespectarea completă a regulilor de denumire rupe structura sistemului, anulând astfel beneficiile acestuia. Având în vedere aceste provocări, nu este de mirare că dezvoltatorii au apelat la cadre, Tailwind fiind cel mai popular cadru CSS. În loc să încerci să lupți cu ceea ce pare a fi un război specific de neînvins între stiluri, este mai ușor să renunți la cascada CSS și să folosești instrumente care garantează o izolare completă. Dezvoltatorii se bazează mai mult pe utilități De unde știm că unii dezvoltatori sunt dornici să evite stilurile în cascadă? Este ascensiunea instrumentelor front-end „moderne” – cum ar fi cadrele CSS-in-JS – concepute special pentru acest scop. Lucrul cu stiluri izolate care sunt strâns legate de componente specifice poate părea o gură de aer proaspăt. Îndepărtează nevoia de a denumi lucruri – încă una dintre cele mai urâte și consumatoare de timp sarcini frontale – și permite dezvoltatorilor să fie productivi fără a înțelege pe deplin sau a valorifica beneficiile moștenirii CSS. Dar renunțarea la cascada CSS vine cu propriile sale probleme. De exemplu, compunerea stilurilor în JavaScript necesită configurații grele de construcție și adesea duce la amestecarea stânjenitoare de stiluri cu marcajul componentelor sau HTML. În loc să luăm în considerare convențiile de denumire cu atenție, permitem instrumente de construcție care să genereze automat selectoare și identificatori pentru noi (de exemplu, .jsx-3130221066), solicitând dezvoltatorilor să țină pasul cu un alt pseudo-limbaj în sine. (De parcă încărcătura cognitivă de a înțelege ce fac toate efectele componentelor tale nu ar fi deja suficientă!) Abstracția în continuare a sarcinii de denumire a claselor la instrumente înseamnă că depanarea de bază este adesea constrânsă la versiuni specifice de aplicații compilate pentru dezvoltare, mai degrabă decât să folosească funcțiile native ale browserului care acceptă depanarea în timp real, cum ar fi Instrumentele pentru dezvoltatori. Este aproape ca și cum ar trebui să dezvoltăm instrumente pentru a depana instrumentele pe care le folosim pentru a abstrage ceea ce web-ul oferă deja - totul de dragul de a fugi de „durerea” de a scrie CSS standard. Din fericire, funcțiile CSS moderne nu numai că fac scrierea CSS standard mai flexibilă, dar oferă și dezvoltatorilor ca noi mult mai multă putere de a gestiona cascada și de a o face să funcționeze pentru noi. Straturile în cascadă CSS sunt un exemplu grozav, dar există o altă caracteristică care primește o lipsă surprinzătoare de atenție - deși acest lucru se schimbă acum că a devenit recent compatibil cu Baseline. Regula CSS @scope At-Rule Consider că regula CSS @scope at-at este un remediu potențial pentru tipul de anxietate indusă de scurgeri de stil pe care l-am acoperit, una care nu ne obligă să compromitem avantajele web native pentru abstracții și instrumente suplimentare de construcție. „Regula @scope CSS at vă permite să selectați elemente din subarborele DOM specific, țințind elemente precis, fără a scrie selectoare prea specifice, care sunt greu de suprascris și fără a vă cupla selectoare prea strâns la structura DOM.” - MDN
Cu alte cuvinte, putem lucra cu stiluri izolate în cazuri specifice fără a sacrifica moștenirea, cascada sau chiar separarea de bază a preocupărilor.acesta a fost un principiu călăuzitor de lungă durată al dezvoltării front-end. În plus, are o acoperire excelentă în browser. De fapt, Firefox 146 a adăugat suport pentru @scope în decembrie, făcându-l compatibil Baseline pentru prima dată. Iată o comparație simplă între un buton care utilizează modelul BEM și regula @scope:
Regula @scope permite precizie cu mai puțină complexitate. Dezvoltatorul nu mai trebuie să creeze limite folosind nume de clasă, ceea ce, la rândul său, le permite să scrie selectoare bazate pe elemente HTML native, eliminând astfel nevoia de modele prescriptive de nume de clasă CSS. Pur și simplu eliminând nevoia de gestionare a numelor de clasă, @scope poate atenua teama asociată cu CSS în proiectele mari.
Utilizare de bază
Pentru a începe, adăugați regula @scope la CSS-ul dvs. și inserați un selector de rădăcină în care stilurile vor fi incluse:
@scop (
Deci, de exemplu, dacă ar fi să definim stilurile la un element
@scop (nav) { a { /* Link stiluri în domeniul de navigare */ }
a:active { /* Stiluri de linkuri active */ }
a:active::before { /* Link activ cu pseudo-element pentru stil suplimentar */ }
@media (lățime maximă: 768 px) { a { /* Ajustări de răspuns */ } } }
Aceasta, în sine, nu este o caracteristică inovatoare. Cu toate acestea, un al doilea argument poate fi adăugat la domeniul de aplicare pentru a crea o limită inferioară, definind efectiv punctele de început și de sfârșit ale domeniului.
/* Orice element din ul nu va avea stilurile aplicate */ @scope (nav) la (ul) { un { dimensiunea fontului: 14px; } }
Această practică se numește sfera de acoperire a gogoșilor și există mai multe abordări pe care le-ar putea folosi, inclusiv o serie de selectoare similare, foarte specifice, cuplate strâns la structura DOM, un pseudo-selector :not sau atribuirea unor nume de clasă specifice elementelor din
Concluzie Cadrele CSS de utilitate, cum ar fi Tailwind, funcționează bine pentru prototipuri și proiecte mai mici. Beneficiile lor se diminuează rapid, totuși, atunci când sunt utilizate în proiecte mai mari care implică mai mult de câțiva dezvoltatori. Dezvoltarea front-end a devenit din ce în ce mai complicată în ultimii ani, iar CSS nu face excepție. Deși regula @scope nu este un remediu, poate reduce nevoia de instrumente complexe. Când este utilizat în locul sau alături de denumirea strategică a clasei, @scope poate face mai ușor și mai distractiv să scrieți CSS care poate fi întreținut. Lectură suplimentară
CSS @scope (MDN) „CSS @scope”, Juan Diego Rodríguez (CSS-Tricks) Note de lansare pentru Firefox 146 (Firefox) Suport pentru browser (CanIUse) Framework CSS populare (Starea CSS 2024) „C” în CSS: Cascade”, Thomas Yip (CSS-Tricks) Introducere BEM (Obțineți BEM)
