Al aprender los principios del CSS básico, se le enseña a escribir estilos modulares, reutilizables y descriptivos para garantizar la mantenibilidad. Pero cuando los desarrolladores se involucran con aplicaciones del mundo real, a menudo parece imposible agregar funciones de interfaz de usuario sin que los estilos se filtren en áreas no deseadas. Este problema a menudo se convierte en una bola de nieve que se autocumple; Los estilos que teóricamente están limitados a un elemento o clase comienzan a aparecer donde no pertenecen. Esto obliga al desarrollador a crear selectores aún más específicos para anular los estilos filtrados, que luego anulan accidentalmente los estilos globales, y así sucesivamente. Las convenciones rígidas de nombres de clases, como BEM, son una solución teórica a este problema. La metodología BEM (Bloque, Elemento, Modificador) es una forma sistemática de nombrar clases CSS para garantizar la reutilización y la estructura dentro de los archivos CSS. Convenciones de nomenclatura como esta pueden reducir la carga cognitiva al aprovechar el lenguaje de dominio para describir elementos y su estado y, si se implementan correctamente, pueden hacer que los estilos para aplicaciones grandes sean más fáciles de mantener. Sin embargo, en el mundo real las cosas no siempre funcionan así. Las prioridades pueden cambiar y, con el cambio, la implementación se vuelve inconsistente. Pequeños cambios en la estructura HTML pueden requerir muchas revisiones de nombres de clases CSS. Con aplicaciones de front-end altamente interactivas, los nombres de clases que siguen el patrón BEM pueden volverse largos y difíciles de manejar (por ejemplo, app-user-overview__status--is-authenticating), y no cumplir plenamente con las reglas de nomenclatura rompe la estructura del sistema, negando así sus beneficios. Teniendo en cuenta estos desafíos, no es de extrañar que los desarrolladores hayan recurrido a los marcos, siendo Tailwind el marco CSS más popular. En lugar de intentar librar lo que parece una guerra de especificidad entre estilos imposible de ganar, es más fácil renunciar a CSS Cascade y utilizar herramientas que garanticen un aislamiento completo. Los desarrolladores se apoyan más en las utilidades ¿Cómo sabemos que algunos desarrolladores desean evitar los estilos en cascada? Es el surgimiento de herramientas de interfaz de usuario "modernas", como los marcos CSS-in-JS, diseñadas específicamente para ese propósito. Trabajar con estilos aislados que se limitan estrictamente a componentes específicos puede parecer un soplo de aire fresco. Elimina la necesidad de nombrar cosas (que sigue siendo una de las tareas de front-end más odiadas y que consumen más tiempo) y permite a los desarrolladores ser productivos sin comprender o aprovechar completamente los beneficios de la herencia de CSS. Pero deshacerse de CSS Cascade conlleva sus propios problemas. Por ejemplo, componer estilos en JavaScript requiere configuraciones de compilación pesadas y, a menudo, conduce a que los estilos se entremezclen de manera incómoda con el marcado de componentes o HTML. En lugar de convenciones de nomenclatura cuidadosamente consideradas, permitimos que las herramientas de compilación generen automáticamente selectores e identificadores (por ejemplo, .jsx-3130221066), lo que requiere que los desarrolladores se mantengan al día con otro pseudolenguaje en sí mismo. (¡Como si la carga cognitiva de comprender lo que hacen todos los efectos y uso de tus componentes no fuera suficiente!) Abstraer aún más el trabajo de nombrar clases para herramientas significa que la depuración básica a menudo se limita a versiones de aplicaciones específicas compiladas para el desarrollo, en lugar de aprovechar las funciones nativas del navegador que admiten la depuración en vivo, como las herramientas de desarrollo. Es casi como si necesitáramos desarrollar herramientas para depurar las herramientas que utilizamos para abstraer lo que la web ya proporciona, todo con el fin de evitar el "dolor" de escribir CSS estándar. Afortunadamente, las características modernas de CSS no sólo hacen que la escritura de CSS estándar sea más flexible, sino que también brindan a los desarrolladores como nosotros mucho más poder para administrar la cascada y hacer que funcione para nosotros. CSS Cascade Layers es un gran ejemplo, pero hay otra característica que sorprendentemente recibe una falta de atención, aunque eso está cambiando ahora que recientemente se ha vuelto compatible con Baseline. La regla @scope At de CSS Considero que la regla @scope at de CSS es una cura potencial para el tipo de ansiedad inducida por las fugas de estilo que hemos cubierto, una que no nos obliga a comprometer las ventajas web nativas por abstracciones y herramientas de compilación adicionales. "La regla at @scope CSS le permite seleccionar elementos en subárboles DOM específicos, apuntando a elementos con precisión sin escribir selectores demasiado específicos que sean difíciles de anular, y sin acoplar sus selectores demasiado estrechamente a la estructura DOM". - MDN
En otras palabras, podemos trabajar con estilos aislados en instancias específicas sin sacrificar la herencia, la cascada o incluso la separación básica de preocupaciones.ese ha sido un principio rector de larga data del desarrollo front-end.
Además, tiene una excelente cobertura de navegador. De hecho, Firefox 146 agregó soporte para @scope en diciembre, haciéndolo compatible con Baseline por primera vez. Aquí hay una comparación simple entre un botón que usa el patrón BEM versus la regla @scope:
La regla @scope permite precisión con menos complejidad. El desarrollador ya no necesita crear límites usando nombres de clases, lo que, a su vez, les permite escribir selectores basados en elementos HTML nativos, eliminando así la necesidad de patrones de nombres de clases CSS prescriptivos. Simplemente eliminando la necesidad de administrar nombres de clases, @scope puede aliviar el miedo asociado con CSS en proyectos grandes.
Uso básico
Para comenzar, agregue la regla @scope a su CSS e inserte un selector raíz al cual se aplicará el alcance de los estilos:
@alcance (
Entonces, por ejemplo, si aplicáramos estilos a un elemento
@scope (navegación) { a { /* Estilos de enlace dentro del alcance de navegación */ }
a:active { /* Estilos de enlaces activos */ }
a:active::before { /* Enlace activo con pseudoelemento para estilo adicional */ }
@media (ancho máximo: 768 px) { a { /* Ajustes responsivos */ } } }
Esto, por sí solo, no es una característica innovadora. Sin embargo, se puede agregar un segundo argumento al alcance para crear un límite inferior, definiendo efectivamente los puntos inicial y final del alcance.
/* Cualquier elemento dentro de ul no tendrá los estilos aplicados */ @scope (navegación) a (ul) { un { tamaño de fuente: 14px; } }
Esta práctica se llama alcance de donut y hay varios enfoques que se podrían usar, incluida una serie de selectores similares y altamente específicos acoplados estrechamente a la estructura DOM, un pseudoselector :not o la asignación de nombres de clase específicos a elementos dentro del
Conclusión Los marcos CSS de utilidad, como Tailwind, funcionan bien para la creación de prototipos y proyectos más pequeños. Sin embargo, sus beneficios disminuyen rápidamente cuando se utilizan en proyectos más grandes que involucran a más de un par de desarrolladores. El desarrollo front-end se ha vuelto cada vez más complicado en los últimos años y CSS no es una excepción. Si bien la regla @scope no es una panacea, puede reducir la necesidad de herramientas complejas. Cuando se usa en lugar o junto con nombres de clases estratégicos, @scope puede hacer que sea más fácil y divertido escribir CSS mantenible. Lectura adicional
CSS @alcance (MDN) “CSS @scope”, Juan Diego Rodríguez (CSS-Trucos) Notas de la versión de Firefox 146 (Firefox) Soporte de navegador (CanIUse) Marcos CSS populares (estado de CSS 2024) “La “C” en CSS: Cascade”, Thomas Yip (CSS-Tricks) Introducción a BEM (Obtener BEM)
