Todo widget de terceros tiene el mismo riesgo: su CSS se cuela en tu página, o tu CSS se cuela en él, y alguien pierde una tarde con las devtools. Provedly se muestra dentro de un Shadow DOM, lo que significa que el propio navegador traza un límite que los selectores CSS normales no pueden cruzar en ninguna dirección. En este artículo explicamos qué hace ese límite, de qué te protege y el puñado de cosas que deliberadamente no aísla.
Qué es el Shadow DOM
El Shadow DOM es un estándar del navegador que permite a un script adjuntar a un elemento un árbol DOM aparte y encapsulado. Los estilos definidos dentro del árbol shadow solo se aplican dentro de él, y los estilos definidos en la página no llegan adentro. Es el mecanismo detrás de elementos nativos como los controles de <video>, y está disponible en todos los navegadores actuales.
Cuando se ejecuta el cargador de Provedly, crea un elemento anfitrión, le adjunta un shadow root y muestra la notificación, el contador o la barra dentro de ese root con su propia hoja de estilos. Desde el punto de vista de tu página, hay un único elemento aparentemente vacío al final de <body>.
<!-- what your page sees -->
<provedly-widget></provedly-widget>
#shadow-root
<style>
…widget styles…
</style>
<div class="toast">…</div>
De qué te protege
Tus resets no aplastan el widget. Un * { box-sizing: border-box; margin: 0 } global o el preflight de Tailwind no se aplican dentro del shadow root. La notificación se ve igual en un sitio con resets agresivos que en uno sin ninguno.
Las clases del widget no chocan con las tuyas. El widget puede usar una clase llamada .toast o .badge y nunca coincidirá con un elemento de tu página, y tu regla .badge nunca coincidirá con las del widget.
Tus reglas !important siguen siendo tuyas. Un tema que declara p { font-size: 18px !important } normalmente se impondría sobre cualquier párrafo de un widget. Dentro de un shadow root, simplemente queda fuera de alcance.
El CSS de tu framework se queda en su sitio. CSS Modules, styled-components, estilos scoped de Vue o de Svelte: ninguno interactúa con el widget, y el widget no interactúa con ellos. Por eso la instalación en Next.js, Webflow, WordPress y Shopify es la misma etiqueta script; no hay que trabajar hojas de estilo por plataforma. Consulta Cómo añadir prueba social a una app de Next.js.
Las fuentes son predecibles. La hoja de estilos del propio widget controla su tipografía, así que una fuente decorativa declarada en tu body no convierte una notificación en un titular.
Lo que no aísla, a propósito
El Shadow DOM acota los estilos. No acota el viewport, el contexto de apilamiento ni la interacción del usuario, y hay algunos puntos donde tu página y el widget siguen compartiendo espacio.
| Compartido | Por qué importa | Qué hacer |
|---|---|---|
| Posición en el viewport | La notificación es position: fixed y compite con tus otros elementos fijos |
Elige una esquina libre; usa la segmentación por dispositivo si el móvil está saturado |
| Orden de apilamiento | El elemento anfitrión tiene un z-index; un elemento de la página con uno mayor puede taparlo | Poco frecuente; suele ser un overlay a pantalla completa, que de todos modos debería taparlo |
body { overflow: hidden } |
No afecta al widget, pero tus propios modales pueden esperar que la esquina esté vacía | Nada, salvo que quieras ocultar la notificación durante los modales; usa segmentación por URL para rutas distintas |
| Propiedades CSS personalizadas heredadas | Las custom properties cruzan el límite shadow por diseño | El widget no depende de variables de la página, así que no hay ningún efecto visible |
| Eventos del puntero | Al hacer clic en la insignia se abre la página de verificación, como cualquier enlace | Nada |
La única colisión práctica es con otros elementos de posición fija: lanzadores de chat, banners de cookies, botones fijos de añadir al carrito. El Shadow DOM no puede hacer que dos cosas ocupen la misma esquina. Elige posiciones para que no ocurra.
Cómo dar estilo al widget
Como no puedes llegar al interior del shadow root desde tu hoja de estilos, los controles de diseño están en el panel: cinco temas (Clean white, Deep ocean, Midnight, Electric violet, Sunset blaze), posición, estilo de avatar, formatos de nombre y ubicación, y en las barras, layout, estilo de dígitos, tamaño de fuente, ancho máximo y colores del botón. Es una limitación y a la vez una ventaja: garantiza que la vista previa del panel es lo que ven los visitantes, en cualquier sitio, sea cual sea su CSS. Consulta Cómo elegir un tema de notificación que encaje con tu marca.
Si necesitas algo que los controles no ofrecen, la solución no es perforar el shadow root con ::part ni recorrer shadowRoot con JavaScript. Esos enfoques se rompen con la siguiente versión del widget.
Implicaciones de rendimiento
El shadow root se crea una vez por carga de página. Los estilos de su interior se analizan una sola vez y no provocan que se recalculen los estilos de tu página, porque el navegador trata los dos árboles por separado a efectos de la cascada. El paquete del widget pesa unos 6 KB comprimido con gzip, carga con async defer y muestra elementos de posición fija que no participan en tu layout, así que no hay ningún salto de diseño que medir. Más en Velocidad de página y scripts de prueba social.
Depuración
En las devtools, el widget aparece como el elemento anfitrión con un hijo #shadow-root (open). Despliégalo para inspeccionar la notificación como cualquier otro elemento. Las versiones actuales de Chrome y Firefox muestran los árboles shadow por defecto; si tu navegador los oculta, busca una opción del tipo "show user agent shadow DOM" en la configuración de las devtools. Si la notificación no se ve en absoluto, las causas habituales están fuera del shadow root: el dominio no está en la lista de dominios permitidos del sitio, el widget no tiene registros o la página está excluida por la segmentación por URL.
Preguntas frecuentes
¿El Shadow DOM funciona en todos los navegadores que usan mis visitantes?
Todos los navegadores evergreen soportan el Shadow DOM desde hace años. Provedly no está pensado para navegadores que no lo tengan.
¿Mi Content Security Policy puede bloquear los estilos inline dentro del shadow root?
Un style-src estricto sin 'unsafe-inline' puede afectar a cómo se aplican los estilos dentro de un shadow root, según el navegador. Si usas una política así, prueba el widget en un entorno de pruebas y consulta la documentación para ver las entradas CSP recomendadas para provedly.app.
¿El contador en vivo usa el mismo shadow root?
La notificación y el contador de un mismo token de widget se muestran dentro del mismo anfitrión. Una barra CTA cargada desde cta.js tiene su propio anfitrión y su propio shadow root.
Comprueba el aislamiento en tu propio sitio con una sola etiqueta script: instala gratis.