Cando se aprenden os principios do CSS básico, ensínaselle a escribir estilos modulares, reutilizables e descritivos para garantir o mantemento. Pero cando os desenvolvedores se involucran con aplicacións do mundo real, moitas veces parece imposible engadir funcións de IU sen que os estilos se filtren en áreas non desexadas. Este problema adoita converterse nun bucle autocumplido; os estilos que teoricamente están limitados a un elemento ou clase comezan a aparecer onde non pertencen. Isto obriga ao desenvolvedor a crear selectores aínda máis específicos para anular os estilos filtrados, que despois anulan accidentalmente os estilos globais, etc. As convencións de nomes de clase ríxidas, como BEM, son unha solución teórica a este problema. A metodoloxía BEM (Block, Element, Modifier) é unha forma sistemática de nomear clases CSS para garantir a reutilización e a estrutura dos ficheiros CSS. Convencións de nomenclatura como esta poden reducir a carga cognitiva ao aproveitar a linguaxe do dominio para describir os elementos e o seu estado e, se se implementan correctamente, poden facilitar o mantemento dos estilos para grandes aplicacións. No mundo real, con todo, non sempre funciona así. As prioridades poden cambiar e, co cambio, a implementación vólvese inconsistente. Os pequenos cambios na estrutura HTML poden requirir moitas revisións do nome de clase CSS. Con aplicacións front-end altamente interactivas, os nomes de clases que seguen o patrón BEM poden chegar a ser longos e difíciles de manexar (por exemplo, app-user-overview__status--est-autenticando), e non se adhiren totalmente ás regras de nomenclatura rompe a estrutura do sistema e, polo tanto, anula os seus beneficios. Tendo en conta estes desafíos, non é de estrañar que os desenvolvedores recurran aos frameworks, sendo Tailwind o framework CSS máis popular. En lugar de tratar de loitar contra o que parece unha guerra de especificidade invencible entre estilos, é máis fácil renunciar á Cascada CSS e utilizar ferramentas que garanten un illamento completo. Os desenvolvedores apóianse máis en utilidades Como sabemos que algúns desenvolvedores están interesados en evitar estilos en cascada? É o auxe das ferramentas front-end "modernas", como marcos CSS-in-JS, deseñadas especificamente para ese propósito. Traballar con estilos illados que están estreitamente adaptados a compoñentes específicos pode parecer un sopro de aire fresco. Elimina a necesidade de poñerlle nomes ás cousas, aínda unha das tarefas front-end máis odiadas e que consumen moito tempo, e permite que os desenvolvedores sexan produtivos sen comprender nin aproveitar completamente os beneficios da herdanza CSS. Pero abandonar a cascada CSS vén cos seus propios problemas. Por exemplo, a composición de estilos en JavaScript require configuracións de compilación pesadas e moitas veces leva a estilos que se mesturan de forma torpe co marcado de compoñentes ou HTML. En lugar de considerar coidadosamente as convencións de nomenclatura, permitimos crear ferramentas para xerar automaticamente selectores e identificadores (por exemplo, .jsx-3130221066), o que esixe aos desenvolvedores que se manteñan ao día doutro pseudo-idioma en si mesmo. (Coma se a carga cognitiva de comprender o que fan todos os efectos do seu compoñente non fose suficiente!) Abstraer aínda máis o traballo de nomear clases ás ferramentas significa que a depuración básica adoita estar restrinxida a versións de aplicacións específicas compiladas para o desenvolvemento, en lugar de aproveitar as funcións nativas do navegador que admiten a depuración en directo, como as ferramentas para programadores. É case como se necesitamos desenvolver ferramentas para depurar as ferramentas que estamos a usar para abstraer o que a web xa ofrece, todo para fuxir da "dor" de escribir CSS estándar. Afortunadamente, as funcións CSS modernas non só fan que a escritura de CSS estándar sexa máis flexible, senón que tamén proporcionan aos desenvolvedores como nós moito máis poder para xestionar a cascada e facelo funcionar para nós. As capas en cascada CSS son un gran exemplo, pero hai outra característica que recibe unha sorprendente falta de atención, aínda que iso está a cambiar agora que recentemente se fixo compatible con Baseline. O CSS @scope At-Rule Considero que a regra CSS @scope at-rela é unha cura potencial para o tipo de ansiedade inducida pola fuga de estilo que cubrimos, que non nos obriga a comprometer as vantaxes da web nativa para as abstraccións e as ferramentas de compilación extra. "A regra at-CSS de @scope permítelle seleccionar elementos en subárbores DOM específicas, apuntando a elementos precisamente sen escribir selectores demasiado específicos que son difíciles de anular e sen acoplar demasiado os seus selectores á estrutura DOM." - MDN
Noutras palabras, podemos traballar con estilos illados en casos específicos sen sacrificar a herdanza, a cascada ou mesmo a separación básica de preocupacións.ese foi un principio reitor de longa duración do desenvolvemento front-end. Ademais, ten unha excelente cobertura do navegador. De feito, Firefox 146 engadiu soporte para @scope en decembro, polo que é compatible Baseline por primeira vez. Aquí tes unha comparación sinxela entre un botón que usa o patrón BEM e a regra @scope:
A regra @scope permite precisión con menos complexidade. O desenvolvedor xa non necesita crear límites usando nomes de clases, o que, á súa vez, permítelles escribir selectores baseados en elementos HTML nativos, eliminando así a necesidade de patróns prescritivos de nomes de clase CSS. Simplemente eliminando a necesidade de xestionar o nome de clase, @scope pode aliviar o medo asociado a CSS en grandes proxectos.
Uso básico
Para comezar, engade a regra @scope ao teu CSS e insira un selector raíz para o que se aplicarán os estilos:
@ámbito (
Así, por exemplo, se estiveramos os estilos a un elemento
@ámbito (nav) { a { /* Estilos de ligazón dentro do ámbito de navegación */ }
a:active { /* Estilos de ligazón activos */ }
a:active::before { /* Ligazón activa con pseudoelemento para estilo adicional */ }
@media (ancho máximo: 768 px) { a { /* Axustes de resposta */ } } }
Esta, por si só, non é unha característica innovadora. Non obstante, pódese engadir un segundo argumento ao ámbito para crear un límite inferior, definindo efectivamente os puntos de inicio e final do ámbito.
/* Calquera elemento dentro de ul non terá os estilos aplicados */ @scope (nav) a (ul) { un { tamaño da fonte: 14px; } }
Esta práctica chámase alcance de rosquillas, e hai varios enfoques que se poden usar, incluíndo unha serie de selectores similares e moi específicos acoplados estreitamente á estrutura DOM, un pseudo-selector :not ou asignar nomes de clases específicos a elementos dentro do
Conclusión Os frameworks CSS de utilidade, como Tailwind, funcionan ben para prototipos e proxectos máis pequenos. Non obstante, os seus beneficios diminúen rapidamente cando se usan en proxectos máis grandes nos que participan máis dun par de desenvolvedores. O desenvolvemento front-end volveuse cada vez máis complicado nos últimos anos e CSS non é unha excepción. Aínda que a regra @scope non é unha solución, pode reducir a necesidade de ferramentas complexas. Cando se usa en lugar dos nomes de clases estratéxicos ou xunto con @scope, pode facer máis doado e divertido escribir CSS mantendo. Lecturas complementarias
CSS @scope (MDN) “CSS @scope”, Juan Diego Rodríguez (CSS-Tricks) Notas da versión de Firefox 146 (Firefox) Soporte de navegador (CanIUse) Marcos CSS populares (Estado de CSS 2024) "A "C" en CSS: Cascade", Thomas Yip (CSS-Trucos) Introdución a BEM (Obter BEM)
