Shadow DOM

Shadow DOM es una función del navegador que permite a los sitios web definir elementos HTML autocontenidos . Estos elementos, denominados árboles de sombra, permiten a los desarrolladores web agrupar código HTML y estilos CSS relacionados de forma que el código y el estilo no afecten a otros elementos circundantes. Esto resuelve un problema recurrente al que se enfrentan los desarrolladores web: la interferencia no deseada entre componentes, donde las reglas CSS escritas para una parte de la página pueden afectar accidentalmente a otras partes del sitio web.

La función Shadow DOM se originó como parte de la iniciativa Web Components de Google, junto con otras propuestas como Custom Elements y el elemento de plantilla HTML en 2013. Tras las críticas de Apple y Mozilla a la primera versión de la propuesta Shadow DOM, denominada diseño "v0", se publicó una nueva propuesta llamada diseño "v1", que posteriormente fue adoptada por todos los principales navegadores web.

Shadow DOM tiene sus orígenes en discusiones entre 2010 y 2011 entre ingenieros de Google y otros colaboradores en las listas de correo públicas del W3C , donde se exploraron por primera vez ideas para la encapsulación del DOM. ^{[ 1 ]} Una especificación inicial "v0", publicada como un borrador de trabajo del W3C en 2013, introdujo características que incluían múltiples árboles de sombra por elemento anfitrión y un <content>elemento para la proyección de contenido. ^{[ 2 ]} Google lanzó v0 en Chrome junto con Custom Elements v0 e HTML Imports , pero otros proveedores de navegadores no lo hicieron. ^{[ 3 ]}

El equipo WebKit de Apple planteó preocupaciones sobre la complejidad de v0 y propuso una API más simple basada en ranuras. ^{[ 3 ] [ 1 ]} El equipo Firefox de Mozilla se alineó con el equipo WebKit al oponerse a muchos detalles de implementación de la API v0. ^{[ 3 ] [ 4 ]} Los desacuerdos entre los proveedores de navegadores sobre la forma y la implementación de la API llevaron a una reunión "cara a cara" del Grupo de Trabajo de Aplicaciones Web del W3C en Mountain View en abril de 2015. ^{[ 4 ] [ 3 ] [ 1 ]} La discusión posterior a la reunión resultó en que los proveedores de navegadores acordaran un diseño "v1" que eliminó múltiples shadow roots por host, reemplazó <content>con <slot>, y cambió hacia una API más declarativa. ^{[ 1 ]} En 2018, el W3C publicó una Nota del Grupo de Trabajo que indicaba que la nueva versión de la API Shadow DOM se incorporaría a varias especificaciones web en lugar de publicarse a través de Borradores de Trabajo. ^{[ 5 ]} El estándar DOM de WHATWG ahora define árboles de sombra, raíces de sombra y despacho de eventos a través de límites de sombra como parte del estándar vivo. ^{[ 6 ]}

Chrome lanzó Shadow DOM v1 en la versión 53 (2016), ^{[ 7 ]} Safari lo hizo más tarde ese mismo año, ^{[ 8 ]} y Firefox agregó soporte en 2018. ^{[ 9 ]} Microsoft Edge obtuvo soporte en la versión 79, en la que hizo la transición al motor Chromium . ^{[ 10 ] [ 11 ]} Chrome dejó de dar soporte y eliminó Shadow DOM v0, Custom Elements v0 e HTML Imports en 2019. ^{[ 12 ]} Una nueva adición a las especificaciones, Shadow DOM declarativo, se ha lanzado en navegadores basados ​​en Chromium y Safari a partir de 2024.. ^{[ 13 ] [ 14 ]}

Shadow DOM es una de las tres tecnologías principales del conjunto de Web Components , junto con Custom Elements y el elemento de plantilla HTML . ^{[ 15 ] [ 16 ]} Juntos permiten la creación de componentes reutilizables y encapsulados que combinan marcado , estilo y comportamiento de forma nativa en la web. Los árboles Shadow permiten que dichos componentes rendericen la estructura interna sin exponerla como parte del DOM principal de la página. ^{[ 6 ] [ 17 ]} Los navegadores han utilizado internamente mecanismos similares a Shadow durante mucho tiempo para implementar elementos integrados complejos . Elementos como y renderizan sus controles a través de árboles Shadow internos mientras presentan una interfaz simple en el DOM claro. Shadow DOM extiende la misma capacidad a los elementos definidos por el desarrollador. ^{[ 18 ]}<video>...</video><details>...</details>

El Shadow DOM consta de múltiples árboles de sombra que son árboles DOM HTML cuya raíz se llama raíz de sombra , adjunta a un elemento llamado elemento anfitrión en el árbol DOM normal de la página de un sitio web. La raíz de sombra en sí no forma parte del DOM del documento regular , existe como un árbol separado accesible solo a través de la shadowRootpropiedad del elemento anfitrión (en modo abierto) o no accesible en absoluto (en modo cerrado). ^{[ 19 ]} Los borradores v0 anteriores permitían múltiples árboles de sombra por anfitrión, pero v1 eliminó esto en favor de una composición basada en ranuras más simple que solo permite un árbol de sombra por anfitrión. ^{[ 20 ]} Los elementos fuera del Shadow DOM se llaman Light DOM. ^{[ 21 ]}

Una raíz de sombra se crea llamando attachShadow()a un elemento, pasando un objeto de opciones con una modepropiedad. Una llamada de la forma element.attachShadow({mode: 'open'})devuelve una referencia a la nueva raíz de sombra, después de la cual se pueden agregar nodos hijos, atributos y estilos utilizando las API DOM estándar . ^{[ 22 ] [ 23 ]} En la práctica, los autores suelen llamar attachShadow()dentro de un constructor de elemento personalizado o rellenar el árbol de sombra clonando el contenido de un elemento. ^{[ 24 ] [ 25 ]} El contenido del elemento es inerte hasta que se instancia. El elemento de plantilla expone una propiedad que se puede insertar directamente en el árbol de sombra. ^{[ 25 ]}<template>...</template><template>contentDocumentFragment

Los navegadores han utilizado durante mucho tiempo árboles de sombra internos para implementar elementos de interfaz de usuario integrados, como controles de formulario y reproductores multimedia , ocultando los detalles de implementación del DOM de la página. El Shadow DOM estandarizado extiende esta capacidad a componentes definidos por el autor, lo que permite elementos personalizados que exponen una API simple mientras mantienen el marcado y los estilos internos encapsulados. ^{[ 18 ]} Los desarrolladores pueden usar Shadow DOM al crear sistemas de diseño , widgets de interfaz de usuario reutilizables y componentes integrables que deben coexistir con páginas host arbitrarias sin colisiones de CSS . ^{[ 26 ]} El Shadow DOM declarativo extiende estos patrones a entornos renderizados en el servidor , lo que permite que los componentes lleguen completamente estructurados desde el servidor sin depender de JavaScript del lado del cliente. ^{[ 30 ]}

El alcance de estilo de Shadow DOM permite a los autores reutilizar nombres de clase comunes dentro de diferentes componentes sin riesgo de conflictos con hojas de estilo globales , y reduce la dependencia de selectores anidados profundamente . ^{[ 31 ]} Los componentes pueden gestionar su propio DOM y CSS de forma independiente, lo que puede mejorar la mantenibilidad al disminuir las colisiones de nombres y el comportamiento en cascada inesperado en aplicaciones grandes compuestas por muchos widgets. ^{[ 31 ] [ 32 ]} Esto ha llevado a que los frameworks de JavaScript adopten Shadow DOM como límite de componente. Frameworks como Polymer y su sucesor Lit están construidos directamente sobre Shadow DOM y sus polyfills , utilizan los términos DOM local para el árbol de sombra de un componente y DOM ligero para describir los elementos gestionados por el framework. ^{[ 33 ] [ 34 ]} Otros frameworks como Angular , Vue y Svelte admiten el uso de la API de Shadow DOM para encapsular estilos dentro de sus componentes. ^{[ 35 ] [ 36 ] [ 37 ]}

Shadow DOM v0 recibió críticas por su complejidad y por aspectos de su modelo de encapsulación que dificultaban la creación de subclases , lo que contribuyó a su limitada adopción fuera de Chrome y motivó el rediseño de la versión 1. ^{[ 1 ] [ 3 ] [ 4 ]}

La API v1 introduce una complejidad adicional para las herramientas y la depuración , particularmente en aplicaciones que combinan Web Components con marcos existentes o que dependen de CSS global. La encapsulación puede dificultar la inspección de la semántica y la prueba del árbol de accesibilidad compuesto , lo que requiere una atención deliberada a los roles WAI-ARIA y la navegación del teclado a través de los límites de sombra. ^{[ 21 ]} La participación en el formulario tampoco es automática: las entradas dentro de un árbol de sombra no envían sus valores con un formulario DOM ligero contenedor de forma predeterminada, y los estados de validación del formulario no se propagan a través del límite de sombra. ^{[ 25 ] [ 18 ]}

Shadow DOM es una herramienta para la composición y encapsulación del DOM, no un límite de seguridad . La shadowRootpropiedad del elemento anfitrión en modo abierto, junto con varias otras API del DOM, puede exponer el contenido del árbol de sombra a los scripts de la página. ^{[ 38 ] [ 39 ]}