Quando si imparano i principi dei CSS di base, viene insegnato a scrivere stili modulari, riutilizzabili e descrittivi per garantire la manutenibilità. Ma quando gli sviluppatori vengono coinvolti in applicazioni del mondo reale, spesso sembra impossibile aggiungere funzionalità dell'interfaccia utente senza che gli stili si diffondano in aree non previste. Questo problema spesso si trasforma in un ciclo che si autoavvera; gli stili che teoricamente hanno come ambito un elemento o una classe iniziano a comparire dove non appartengono. Ciò costringe lo sviluppatore a creare selettori ancora più specifici per sovrascrivere gli stili trapelati, che poi sovrascrivono accidentalmente gli stili globali e così via. Le rigide convenzioni sui nomi delle classi, come BEM, sono una soluzione teorica a questo problema. La metodologia BEM (Blocco, Elemento, Modificatore) è un modo sistematico di denominare le classi CSS per garantire la riusabilità e la struttura all'interno dei file CSS. Convenzioni di denominazione come questa possono ridurre il carico cognitivo sfruttando il linguaggio del dominio per descrivere gli elementi e il loro stato e, se implementate correttamente, possono rendere più facile la manutenzione degli stili per applicazioni di grandi dimensioni. Nel mondo reale, però, non sempre funziona così. Le priorità possono cambiare e, con il cambiamento, l’implementazione diventa incoerente. Piccole modifiche alla struttura HTML possono richiedere molte revisioni del nome della classe CSS. Con applicazioni front-end altamente interattive, i nomi delle classi che seguono il modello BEM possono diventare lunghi e ingombranti (ad esempio, app-user-overview__status--is-authenticating) e il mancato rispetto completo delle regole di denominazione interrompe la struttura del sistema, annullandone così i vantaggi. Date queste sfide, non c’è da meravigliarsi che gli sviluppatori si siano rivolti ai framework, essendo Tailwind il framework CSS più popolare. Piuttosto che cercare di combattere quella che sembra una guerra di specificità tra stili impossibile da vincere, è più facile rinunciare alla Cascade CSS e utilizzare strumenti che garantiscano il completo isolamento. Gli sviluppatori si affidano di più alle utilità Come facciamo a sapere che alcuni sviluppatori desiderano evitare gli stili a cascata? È l’ascesa di strumenti front-end “moderni” – come i framework CSS-in-JS – progettati specificamente per questo scopo. Lavorare con stili isolati strettamente legati a componenti specifici può sembrare una boccata d'aria fresca. Elimina la necessità di dare un nome alle cose, che è ancora una delle attività front-end più odiate e dispendiose in termini di tempo, e consente agli sviluppatori di essere produttivi senza comprendere o sfruttare appieno i vantaggi dell'ereditarietà CSS. Ma abbandonare il CSS Cascade comporta i suoi problemi. Ad esempio, la composizione di stili in JavaScript richiede configurazioni di build pesanti e spesso porta a stili che si mescolano goffamente con il markup dei componenti o HTML. Invece di considerare attentamente le convenzioni di denominazione, consentiamo agli strumenti di creazione di generare automaticamente selettori e identificatori per noi (ad esempio, .jsx-3130221066), richiedendo agli sviluppatori di tenere il passo con un altro pseudo-linguaggio in sé e per sé. (Come se il carico cognitivo di capire cosa fanno tutti gli useEffects del tuo componente non fosse già abbastanza!) Astrarre ulteriormente il compito di denominare le classi in strumenti significa che il debug di base è spesso limitato a versioni specifiche dell'applicazione compilate per lo sviluppo, piuttosto che sfruttare funzionalità native del browser che supportano il debug in tempo reale, come gli strumenti per sviluppatori. È quasi come se dovessimo sviluppare strumenti per eseguire il debug degli strumenti che stiamo utilizzando per astrarre ciò che il web già fornisce, tutto per il bene di scappare dal “dolore” di scrivere CSS standard. Fortunatamente, le moderne funzionalità CSS non solo rendono più flessibile la scrittura di CSS standard, ma danno anche agli sviluppatori come noi molto più potere per gestire la cascata e farlo funzionare per noi. I CSS Cascade Layers sono un ottimo esempio, ma c’è un’altra caratteristica che riceve una sorprendente mancanza di attenzione, anche se questo sta cambiando ora che è recentemente diventato compatibile con Baseline. Il CSS @scope At-Rule Considero la regola @scope CSS una potenziale cura per il tipo di ansia indotta dalla perdita di stile di cui abbiamo parlato, una che non ci costringe a compromettere i vantaggi del web nativo per astrazioni e strumenti di creazione aggiuntivi. "La regola @scope CSS ti consente di selezionare elementi in sottoalberi DOM specifici, mirando agli elementi con precisione senza scrivere selettori eccessivamente specifici che sono difficili da sovrascrivere e senza accoppiare troppo strettamente i tuoi selettori alla struttura DOM."— MDN
In altre parole, possiamo lavorare con stili isolati in casi specifici senza sacrificare l’ereditarietà, la cascata o anche la fondamentale separazione degli interessi.questo è stato un principio guida di lunga data dello sviluppo front-end. Inoltre, ha un'eccellente copertura del browser. Infatti, Firefox 146 ha aggiunto il supporto per @scope a dicembre, rendendolo compatibile con Baseline per la prima volta. Ecco un semplice confronto tra un pulsante che utilizza il modello BEM e la regola @scope:
La regola @scope consente precisione con minore complessità. Lo sviluppatore non ha più bisogno di creare limiti utilizzando i nomi delle classi, il che, a sua volta, consente loro di scrivere selettori basati su elementi HTML nativi, eliminando così la necessità di modelli prescrittivi di nomi di classi CSS. Eliminando semplicemente la necessità di gestire i nomi delle classi, @scope può alleviare la paura associata ai CSS nei progetti di grandi dimensioni.
Utilizzo di base
Per iniziare, aggiungi la regola @scope al tuo CSS e inserisci un selettore radice a cui verrà ambito gli stili:
@scope (
Quindi, ad esempio, se dovessimo definire l'ambito degli stili in un elemento
@scope (navigazione) { a { /* Stili di collegamento nell'ambito di navigazione */ }
a:active { /* Stili di collegamento attivi */ }
a:active::before { /* Collegamento attivo con pseudo-elemento per uno stile extra */ }
@media (larghezza massima: 768px) { a { /* Aggiustamenti reattivi */ } } }
Questa, di per sé, non è una caratteristica innovativa. Tuttavia, è possibile aggiungere un secondo argomento all'ambito per creare un limite inferiore, definendo effettivamente i punti iniziale e finale dell'ambito.
/* A qualsiasi elemento all'interno di ul non verranno applicati gli stili */ @scope (nav) a (ul) { un { dimensione carattere: 14px; } }
Questa pratica è chiamata ambito ciambella, e ci sono diversi approcci che si potrebbero usare, inclusa una serie di selettori simili, altamente specifici accoppiati strettamente alla struttura DOM, uno :not pseudo-selettore, o l'assegnazione di nomi di classe specifici a elementi all'interno del
Conclusione I framework CSS incentrati sull'utilità, come Tailwind, funzionano bene per la prototipazione e progetti più piccoli. I loro vantaggi, tuttavia, diminuiscono rapidamente se utilizzati in progetti più ampi che coinvolgono più di un paio di sviluppatori. Lo sviluppo front-end è diventato sempre più complicato negli ultimi anni e i CSS non fanno eccezione. Sebbene la regola @scope non sia una panacea, può ridurre la necessità di strumenti complessi. Se utilizzato al posto o insieme alla denominazione strategica delle classi, @scope può rendere più semplice e divertente scrivere CSS manutenibile. Ulteriori letture
CSS @ambito (MDN) “CSS @scope”, Juan Diego Rodríguez (CSS-Tricks) Note sulla versione di Firefox 146 (Firefox) Supporto browser (CanIUse) Framework CSS popolari (Stato dei CSS 2024) “La “C” in CSS: Cascade”, Thomas Yip (CSS-Tricks) Introduzione al BEM (Ottieni BEM)
