Ao aprender os princípios básicos do CSS, aprendemos a escrever estilos modulares, reutilizáveis e descritivos para garantir a manutenção. Mas quando os desenvolvedores se envolvem com aplicativos do mundo real, muitas vezes parece impossível adicionar recursos de UI sem que os estilos vazem para áreas não intencionais. Esse problema muitas vezes se transforma em uma bola de neve que se transforma em um ciclo auto-realizável; estilos que teoricamente têm como escopo um elemento ou classe começam a aparecer onde não pertencem. Isso força o desenvolvedor a criar seletores ainda mais específicos para substituir os estilos vazados, que então substituem acidentalmente os estilos globais e assim por diante. Convenções rígidas de nomes de classes, como BEM, são uma solução teórica para esse problema. A metodologia BEM (Block, Element, Modifier) é uma forma sistemática de nomear classes CSS para garantir a reutilização e estrutura dos arquivos CSS. Convenções de nomenclatura como essa podem reduzir a carga cognitiva aproveitando a linguagem de domínio para descrever elementos e seu estado e, se implementadas corretamente, podem facilitar a manutenção de estilos para aplicativos grandes. No mundo real, porém, nem sempre funciona assim. As prioridades podem mudar e, com a mudança, a implementação torna-se inconsistente. Pequenas alterações na estrutura HTML podem exigir muitas revisões de nomes de classes CSS. Com aplicativos front-end altamente interativos, os nomes de classes que seguem o padrão BEM podem se tornar longos e difíceis de manejar (por exemplo, app-user-overview__status--is-authenticating), e não aderir totalmente às regras de nomenclatura quebra a estrutura do sistema, negando assim seus benefícios. Dados esses desafios, não é de admirar que os desenvolvedores tenham recorrido a frameworks, sendo o Tailwind o framework CSS mais popular. Em vez de tentar travar o que parece ser uma guerra invencível de especificidade entre estilos, é mais fácil desistir do CSS Cascade e usar ferramentas que garantam isolamento completo. Os desenvolvedores confiam mais nos utilitários Como sabemos que alguns desenvolvedores desejam evitar estilos em cascata? É a ascensão de ferramentas de front-end “modernas” – como estruturas CSS-in-JS – projetadas especificamente para esse propósito. Trabalhar com estilos isolados com escopo restrito a componentes específicos pode parecer uma lufada de ar fresco. Ele elimina a necessidade de nomear as coisas – ainda uma das tarefas de front-end mais odiadas e demoradas – e permite que os desenvolvedores sejam produtivos sem compreender totalmente ou aproveitar os benefícios da herança CSS. Mas abandonar o CSS Cascade traz seus próprios problemas. Por exemplo, compor estilos em JavaScript requer configurações de construção pesadas e muitas vezes leva a estilos que se misturam de maneira estranha com marcação de componente ou HTML. Em vez de convenções de nomenclatura cuidadosamente consideradas, permitimos ferramentas de construção para gerar automaticamente seletores e identificadores para nós (por exemplo, .jsx-3130221066), exigindo que os desenvolvedores acompanhem mais uma pseudolinguagem por si só. (Como se a carga cognitiva de entender o que todos os useEffects do seu componente fazem já não fosse suficiente!) Abstrair ainda mais o trabalho de nomear classes para ferramentas significa que a depuração básica geralmente fica restrita a versões específicas de aplicativos compiladas para desenvolvimento, em vez de aproveitar recursos nativos do navegador que suportam depuração em tempo real, como ferramentas de desenvolvedor. É quase como se precisássemos desenvolver ferramentas para depurar as ferramentas que usamos para abstrair o que a web já fornece – tudo para fugir da “dor” de escrever CSS padrão. Felizmente, os recursos CSS modernos não apenas tornam a escrita de CSS padrão mais flexível, mas também dão a desenvolvedores como nós muito mais poder para gerenciar a cascata e fazê-la funcionar para nós. CSS Cascade Layers são um ótimo exemplo, mas há outro recurso que recebe uma surpreendente falta de atenção - embora isso esteja mudando agora que recentemente se tornou compatível com o Baseline. A regra CSS @scope Considero a regra CSS @scope uma cura potencial para o tipo de ansiedade induzida por vazamento de estilo que abordamos, uma que não nos força a comprometer as vantagens nativas da web por abstrações e ferramentas extras de construção. “A regra CSS @scope permite que você selecione elementos em subárvores DOM específicas, direcionando elementos com precisão, sem escrever seletores excessivamente específicos que são difíceis de substituir e sem acoplar seus seletores com muita força à estrutura DOM.”
Em outras palavras, podemos trabalhar com estilos isolados em instâncias específicas sem sacrificar a herança, o cascateamento ou mesmo a separação básica de interesses.esse tem sido um princípio orientador de longa data do desenvolvimento front-end. Além disso, possui excelente cobertura do navegador. Na verdade, o Firefox 146 adicionou suporte para @scope em dezembro, tornando-o compatível com o Baseline pela primeira vez. Aqui está uma comparação simples entre um botão usando o padrão BEM e a regra @scope:
A regra @scope permite precisão com menos complexidade. O desenvolvedor não precisa mais criar limites usando nomes de classes, o que, por sua vez, permite escrever seletores baseados em elementos HTML nativos, eliminando assim a necessidade de padrões prescritivos de nomes de classes CSS. Simplesmente eliminando a necessidade de gerenciamento de nomes de classes, o @scope pode aliviar o medo associado ao CSS em grandes projetos.
Uso Básico
Para começar, adicione a regra @scope ao seu CSS e insira um seletor raiz no qual os estilos terão escopo:
@scope (
Então, por exemplo, se definirmos o escopo dos estilos para um elemento
@escopo (navegação) { a { /* Estilos de link dentro do escopo de navegação */ }
a:active { /* Estilos de links ativos */ }
a:active::before { /* Link ativo com pseudoelemento para estilo extra */ }
@media (largura máxima: 768px) { a { /* Ajustes responsivos */ } } }
Isso, por si só, não é um recurso inovador. No entanto, um segundo argumento pode ser adicionado ao escopo para criar um limite inferior, definindo efetivamente os pontos inicial e final do escopo.
/* Qualquer elemento a dentro de ul não terá os estilos aplicados */ @scope (nav) para (ul) { um { tamanho da fonte: 14px; } }
Essa prática é chamada de escopo de donut, e há diversas abordagens que podem ser usadas, incluindo uma série de seletores similares e altamente específicos acoplados firmemente à estrutura DOM, um pseudo-seletor :not ou a atribuição de nomes de classes específicos a elementos dentro do
Conclusão Frameworks CSS utilitários, como Tailwind, funcionam bem para prototipagem e projetos menores. Seus benefícios diminuem rapidamente, entretanto, quando usados em projetos maiores que envolvem mais do que alguns desenvolvedores. O desenvolvimento front-end tornou-se cada vez mais complicado nos últimos anos, e o CSS não é exceção. Embora a regra @scope não seja uma panacéia, ela pode reduzir a necessidade de ferramentas complexas. Quando usado no lugar ou junto com a nomenclatura estratégica de classes, @scope pode tornar mais fácil e divertido escrever CSS sustentável. Leitura adicional
CSS @escopo (MDN) “CSS @scope”, Juan Diego Rodríguez (CSS-Tricks) Notas de versão do Firefox 146 (Firefox) Suporte ao navegador (CanIUse) Frameworks CSS populares (estado do CSS 2024) “O “C” em CSS: Cascade”, Thomas Yip (CSS-Tricks) Introdução ao BEM (obter BEM)
