Convenciones de nomenclatura y alternativas a la abstracción intensa — Smashing Magazine

A medida que aprendamos los principios básicos de CSS, aprenderemos a escribir estilos que sean modulares, reutilizables y descriptivos para garantizar la mantenibilidad. Sin embargo, cuando los desarrolladores trabajan en aplicaciones reales, a menudo parece imposible agregar funcionalidad de interfaz de usuario sin filtrar estilos en áreas no deseadas.

Este problema a menudo se convierte en una bola de nieve que se convierte en un ciclo autocumplido. Los estilos que teóricamente están limitados a un elemento o clase comienzan a aparecer en lugares a los que no pertenecen. Esto obliga a los desarrolladores a crear selectores más específicos para anular los estilos filtrados, que luego anulan accidentalmente los estilos globales, etc.

Convenciones estrictas de nombres de clases, p. DE ACUERDOes una solución teórica a este problema. este Método BEM (Bloque, Elemento, Modificador) es un Método de nomenclatura del sistema para clases CSS Garantice la reutilización y la estructura dentro de los archivos CSS. Una convención de nomenclatura como esta funcionaría Reduzca la carga cognitiva aprovechando el lenguaje de dominio para describir elementos y sus estados.si se implementa correctamente, Puede hacer que los estilos para aplicaciones grandes sean más fáciles de mantener.

Sin embargo, en el mundo real esto no siempre es así. Las prioridades pueden cambiar y, a medida que cambian, la implementación puede volverse inconsistente. Pequeños cambios en la estructura de HTML pueden requerir la modificación de muchos nombres de clases CSS. Para 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 convenciones de nomenclatura puede socavar la estructura del sistema, negando sus beneficios.

Dados estos desafíos, no sorprende que los desarrolladores estén recurriendo a los marcos, y Tailwind es Los marcos CSS más populares. En lugar de intentar librar una guerra aparentemente imposible de ganar de peculiaridades entre estilos, simplemente renuncia. cascada CSS Y utilice herramientas que garanticen un aislamiento total.

Los desarrolladores confían más en las utilidades

¿Cómo sabemos que algunos desarrolladores desean evitar los estilos en cascada? Este es el auge de las herramientas de interfaz de usuario “modernas”, p. Marco CSS en JS – Diseñado específicamente para este fin. Usar estilos independientes que se limitan estrictamente a componentes específicos parece un soplo de aire fresco. Elimina la necesidad de nombrar las cosas. Sigue siendo una de las tareas front-end más molestas y que consumen más tiempo. – y permite a los desarrolladores ser más productivos sin comprender o aprovechar completamente los beneficios de la herencia CSS.

Pero abandonar CSS Cascade tiene sus propios problemas. Por ejemplo, escribir estilos en JavaScript requiere mucha configuración de compilación y, a menudo, da como resultado que los estilos se mezclen de manera incómoda con el marcado de componentes o HTML. Permitimos que las herramientas de compilación generen automáticamente selectores e identificadores para nosotros en lugar de considerar cuidadosamente las convenciones de nomenclatura (p. ej. .jsx-3130221066), lo que requiere que los desarrolladores se mantengan al día con otro pseudolenguaje. (Como si comprender la carga cognitiva de todos los componentes useEffect¡No se ha hecho lo suficiente! )

Abstraer aún más el trabajo de denominación de clases en 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 tiempo real, como las herramientas de desarrollo.

Es casi como si necesitáramos herramientas de desarrollo para depurar las herramientas que utilizamos para abstraer lo que la web ya ofrece, todo para eliminar el “dolor” de escribir CSS estándar.

Afortunadamente, las características modernas de CSS no solo hacen que la escritura de CSS estándar sea más flexible, sino que también brindan a los desarrolladores como nosotros más capacidad para administrar la cascada y hacer que funcione para nosotros. Capas en cascada CSS es un gran ejemplo, pero hay otra característica que ha recibido una sorprendente falta de atención: aunque está cambiando, recientemente se ha vuelto Compatible con la línea de base.

CSS @scope regla

Creo CSS @scope regla Al convertirse en una cura potencial para el tipo de ansiedad causada por las filtraciones de estilo que hemos discutido, no nos obliga a sacrificar las ventajas de la web nativa por abstracciones y herramientas de compilación adicionales.

“este @scope Las reglas at de CSS le permiten seleccionar elementos dentro de un subárbol DOM específico, posicionar elementos con precisión sin tener que escribir selectores demasiado específicos que sean difíciles de anular y sin acoplar selectores demasiado estrechamente a la estructura DOM. “

— MDN

En otras palabras, podemos usar estilos independientes en instancias específicas. Sin sacrificar la herencia, la cascada o incluso la separación básica de preocupaciones Este es un principio rector de larga data en el desarrollo front-end.

Además, tiene Excelente cobertura del navegador. De hecho, Firefox 146 par añadido @scope diciembre, lo hizo Compatible con la línea de base primero. Aquí hay una comparación simple entre un botón que usa el modo BEM y un botón que usa el modo BEM @scope regla:

<!-- BEM --> 
<button class="button button--primary">
  <span class="button__text">Click me</span>
  <span class="button__icon">→</span>
</button>

<style>
  .button .button__text { /* button text styles */ }
  .button .button__icon { /* button icon styles */ }
  .button--primary { primary button styles */ }
</style>

<!-- @scope --> 
<button class="primary-button">
  <span>Click me</span>
  <span>→</span>
</button>

<style>
  @scope (.primary-button) {
    span:first-child { /* button text styles */ }
    span:last-child { /* button icon styles */ }
  }
</style>

este @scope las reglas lo permiten Menos preciso y menos complejo. Los desarrolladores ya no necesitan crear límites usando nombres de clases, lo que a su vez les permite escribir selectores basados ​​en elementos HTML nativos, eliminando la necesidad de especificar patrones de nombres de clases CSS. Simplemente eliminando la necesidad de gestionar nombres de clases, @scope Puede aliviar los temores relacionados con CSS en proyectos grandes.

Uso básico

Primero, agrega @scope Regla en tu CSS e inserta un selector raíz y los estilos tendrán su alcance dentro de él:

@scope (<selector>) {
  /* Styles scoped to the <selector> */
}

Entonces, por ejemplo, si tuviéramos que limitar el estilo a <nav> elemento, podría verse así:

@scope (nav) {
  a { /* Link styles within nav scope */ }

  a:active { /* Active link styles */ }

  a:active::before { /* Active link with pseudo-element for extra styling */ }

  @media (max-width: 768px) {
    a { /* Responsive adjustments */ }
  }
}

Por sí sola, esta no es una característica innovadora. Sin embargo, se puede agregar un segundo parámetro al alcance para crear límite inferiordefiniendo efectivamente los puntos inicial y final del rango.

/* Any `a` element inside `ul` will not have the styles applied */
@scope (nav) to (ul) {
  a {
    font-size: 14px;
  }
}

Esta práctica se llama alcance del donuty Hay varias maneras Se puede utilizar, incluida una serie de selectores similares y altamente específicos estrechamente acoplados a la estructura DOM, :not Pseudo-selector, o asignación de un nombre de clase específico <a> elementos dentro <nav> para manejar diferentes CSS.

Independientemente de otros métodos, @scope El método es más sencillo. Más importante aún, evita el riesgo de corrupción de estilo cuando se cambian o se utilizan incorrectamente los nombres de las clases, o cuando se modifica la estructura HTML. ahora que @scope Compatible con la línea de base, ¡ya no necesitamos una solución alternativa!

Además, podemos tomar múltiples límites finales para crear un “estilo en forma de ocho”:

/* Any <a> or <p> element inside <aside> or <nav> will not have the styles applied */
@scope (main) to (aside, nav) {
  a {
    font-size: 14px;
  }
  p {
    line-height: 16px;
    color: darkgrey;
  }
}

Compárelo con la versión sin procesar. @scope Regla, los desarrolladores deben “restablecer” los estilos a sus valores predeterminados:

main a {
  font-size: 14px;
}

main p {
  line-height: 16px;
  color: darkgrey;
}

main aside a,
main nav a {
  font-size: inherit; /* or whatever the default should be */
}

main aside p,
main nav p {
  line-height: inherit; /* or whatever the default should be */
  color: inherit; /* or a specific color */
}

Consulte los ejemplos a continuación. ¿Has notado lo fácil que es apuntar a ciertos selectores anidados e ignorar otros?

Considere un escenario en el que es necesario aplicar un estilo único al contenido ranurado dentro componentes de red. Cuando coloca contenido en un componente web, el contenido pasa a formar parte de Shadow DOM pero aún hereda los estilos del documento principal. Es posible que los desarrolladores quieran implementar diferentes estilos según el componente web donde reside el contenido:

<!-- Same <user-card> content, different contexts -->
<product-showcase>
  <user-card slot="reviewer">
    <img src="https://smashingmagazine.com/2026/02/css-scope-alternative-naming-conventions/avatar.jpg" slot="avatar">
    <span slot="name">Jane Doe</span>
  </user-card>
</product-showcase>

<team-roster>
  <user-card slot="member">
    <img src="https://smashingmagazine.com/2026/02/css-scope-alternative-naming-conventions/avatar.jpg" slot="avatar">
    <span slot="name">Jane Doe</span>
  </user-card>
</team-roster>

En este ejemplo, el desarrollador podría querer <user-card> Solo tenga estilos diferentes al renderizar internamente <team-roster>:

@scope (team-roster) {
  user-card {
    display: inline-flex;
    align-items: center;
    gap: 0.5rem;
  }
  
  user-card img {
    border-radius: 50%;
    width: 40px;
    height: 40px;
  }
}

Más beneficios

Hay otras formas de hacer esto. @scope Puede eliminar la necesidad de gestión de clases sin recurrir a utilidades o nombres de clases generados por JavaScript. Por ejemplo, @scope Abre la posibilidad de una fácil implementación los descendientes objetivo de cualquier selectorno solo el nombre de la clase:

/* Only div elements with a direct child button are included in the root scope */
@scope (div:has(> button)) {
  p {
    font-size: 14px;
  }
}

y ellos Se puede anidarcrea un rango dentro de un rango:

@scope (main) {
  p {
    font-size: 16px;
    color: black;
  }
  @scope (section) {
    p {
      font-size: 14px;
      color: blue;
    }
    @scope (.highlight) {
      p {
        background-color: yellow;
        font-weight: bold;
      }
    }
  }
}

Alternativamente, el alcance raíz puede estar en @scope regla:

/* Applies to elements inside direct child `section` elements of `main`, but stops at any direct `aside` that is a direct chiled of those sections */
@scope (main > section) to (:scope > aside) {
  p {
    background-color: lightblue;
    color: blue;
  }
  /* Applies to ul elements that are immediate siblings of root scope  */
  :scope + ul {
    list-style: none;
  }
}

este @scope at-rule también introduce una nueva Proximidad Dimensiones específicas de resolución CSS. En CSS tradicional, cuando dos selectores coinciden con el mismo elemento, gana el selector con mayor especificidad. y @scopecuando dos elementos tienen la misma especificidad, gana el elemento cuya raíz de rango esté más cerca del elemento coincidente. Esto elimina la necesidad de anular los estilos principales agregando manualmente la especificidad del elemento, ya que los componentes internos reemplazarán naturalmente los estilos de los elementos externos.

<style>
  @scope (.container) {
    .title { color: green; } 
  }
  <!-- The <h2> is closer to .container than to .sidebar so "color: green" wins. -->
  @scope (.sidebar) {
    .title { color: red; }
  }
</style>

<div class="sidebar">
  <div class="container">
    <h2 class="title">Hello</h2>
  </div>
</div>

en conclusión

Los marcos CSS de utilidad, como Tailwind, son excelentes para la creación de prototipos y proyectos pequeños. Sin embargo, sus beneficios disminuyen rápidamente cuando se utilizan en proyectos grandes que involucran a varios desarrolladores.

El desarrollo front-end se ha vuelto cada vez más complejo en los últimos años y CSS no es una excepción. A pesar de @scope Las reglas no son una panacea y pueden reducir la necesidad de herramientas complejas. Cuando se utiliza en lugar de o junto con la denominación de clases de estrategia, @scope Hace que escribir CSS mantenible sea más fácil y divertido.

lectura adicional

(gg, yk)