Tout widget tiers comporte le même risque : son CSS déborde sur votre page, ou votre CSS déborde sur lui, et quelqu'un passe un après-midi dans les devtools. Provedly s'affiche à l'intérieur d'un Shadow DOM, ce qui signifie que le navigateur lui-même trace une frontière que les sélecteurs CSS ordinaires ne peuvent franchir dans aucun sens. Cet article explique ce que fait cette frontière, ce dont elle vous protège, et les quelques éléments qu'elle n'isole volontairement pas.
Qu'est-ce que le Shadow DOM
Le Shadow DOM est un standard du navigateur qui permet à un script d'attacher à un élément un arbre DOM séparé et encapsulé. Les styles définis dans l'arbre shadow ne s'appliquent qu'à l'intérieur ; les styles définis dans la page n'y entrent pas. C'est le mécanisme qui se cache derrière des éléments natifs comme les contrôles de <video>, et il est disponible dans tous les navigateurs actuels.
Quand le loader de Provedly s'exécute, il crée un élément hôte, y attache un shadow root, et affiche la notification, le compteur ou la barre à l'intérieur de ce root avec sa propre feuille de style. Du point de vue de votre page, il n'y a qu'un élément apparemment vide à la fin du <body>.
<!-- what your page sees -->
<provedly-widget></provedly-widget>
#shadow-root
<style>
…widget styles…
</style>
<div class="toast">…</div>
Ce dont il vous protège
Vos resets n'écrasent pas le widget. Un * { box-sizing: border-box; margin: 0 } global ou un preflight Tailwind ne s'applique pas à l'intérieur du shadow root. La notification a le même aspect sur un site aux resets agressifs que sur un site qui n'en a aucun.
Les classes du widget n'entrent pas en collision avec les vôtres. Le widget peut utiliser une classe nommée .toast ou .badge sans jamais cibler un élément de votre page, et votre règle .badge ne ciblera jamais celui du widget.
Vos règles !important restent les vôtres. Un thème qui déclare p { font-size: 18px !important } écraserait normalement n'importe quel paragraphe du widget. À l'intérieur d'un shadow root, cette règle n'a tout simplement aucune portée.
Le CSS de votre framework reste à sa place. CSS Modules, styled-components, styles scoped de Vue ou de Svelte : aucun n'interagit avec le widget, et le widget n'interagit avec aucun d'eux. C'est pour cela que l'installation sur Next.js, Webflow, WordPress et Shopify se résume à la même balise script ; aucun travail de feuille de style par plateforme. Voir Adding social proof to a Next.js app.
Les polices restent prévisibles. La feuille de style du widget contrôle sa typographie, si bien qu'une police d'affichage déclarée sur votre body ne transforme pas une notification en gros titre.
Ce qu'il n'isole pas, volontairement
Le Shadow DOM délimite les styles. Il ne délimite ni le viewport, ni le contexte d'empilement, ni les interactions de l'utilisateur, et il reste quelques endroits où votre page et le widget partagent l'espace.
| Partagé | Pourquoi c'est important | Que faire |
|---|---|---|
| Position dans le viewport | La notification est en position: fixed et rivalise avec vos autres éléments fixes |
Choisissez un coin libre ; utilisez le ciblage par appareil si le mobile est encombré |
| Ordre d'empilement | L'élément hôte a un z-index ; un élément de la page avec un z-index supérieur peut le recouvrir | Rare ; en général une surcouche plein écran, qui doit de toute façon le recouvrir |
body { overflow: hidden } |
N'affecte pas le widget, mais vos propres modales peuvent s'attendre à ce que le coin soit vide | Rien, sauf si vous voulez masquer la notification pendant les modales ; utilisez le ciblage par URL pour des routes distinctes |
| Propriétés CSS personnalisées héritées | Les custom properties traversent la frontière shadow par conception | Le widget ne dépend pas des variables de la page, donc aucun effet visible |
| Événements de pointeur | Cliquer sur le badge ouvre la page de vérification, comme n'importe quel lien | Rien |
La seule collision concrète concerne les autres éléments en position fixe : lanceurs de chat, bandeaux de cookies, boutons d'ajout au panier collants. Le Shadow DOM ne peut pas faire tenir deux éléments dans le même coin. Choisissez les positions pour qu'ils ne se chevauchent pas.
Personnaliser le widget
Comme votre feuille de style ne peut pas atteindre l'intérieur du shadow root, les réglages de design se trouvent dans le dashboard : cinq thèmes (Clean white, Deep ocean, Midnight, Electric violet, Sunset blaze), la position, le style d'avatar, les formats de nom et de localisation, et pour les barres, la disposition, le style des chiffres, la taille de police, la largeur maximale et les couleurs des boutons. C'est à la fois une contrainte et un avantage : l'aperçu du dashboard est garanti identique à ce que voient les visiteurs, sur chaque site, quel que soit son CSS. Voir Choosing a toast theme that matches your brand.
Si vous avez besoin de quelque chose que les réglages ne proposent pas, la solution n'est pas de percer le shadow root avec ::part ou en parcourant shadowRoot en JavaScript. Ces approches cassent à la prochaine version du widget.
Conséquences sur les performances
Le shadow root est créé une fois par chargement de page. Les styles qu'il contient sont analysés une seule fois et ne déclenchent pas de recalcul des styles de votre page, car le navigateur traite les deux arbres séparément pour la cascade. Le bundle du widget pèse environ 6 Ko compressés en gzip, se charge en async defer et affiche des éléments en position fixe qui ne participent pas à votre mise en page : il n'y a donc aucun décalage de mise en page à mesurer. Plus de détails dans Page speed and social proof scripts.
Débogage
Dans les devtools, le widget apparaît comme l'élément hôte avec un enfant #shadow-root (open). Dépliez-le pour inspecter la notification comme n'importe quel autre élément. Les versions actuelles de Chrome et de Firefox affichent les arbres shadow par défaut ; si votre navigateur les masque, cherchez une option du type « show user agent shadow DOM » dans les paramètres des devtools. Si la notification n'apparaît pas du tout, les causes habituelles se situent hors du shadow root : le domaine ne figure pas dans la liste des domaines autorisés du site, le widget n'a aucun enregistrement, ou la page est exclue par le ciblage par URL.
Questions fréquentes
Le Shadow DOM fonctionne-t-il dans tous les navigateurs de mes visiteurs ?
Le Shadow DOM est pris en charge par tous les navigateurs evergreen depuis des années. Provedly ne cible pas les navigateurs qui ne le gèrent pas.
Ma Content Security Policy peut-elle bloquer les styles inline dans le shadow root ?
Une directive style-src stricte sans 'unsafe-inline' peut, selon le navigateur, influer sur la façon dont les styles sont appliqués dans un shadow root. Si vous appliquez une telle politique, testez le widget en préproduction et consultez la documentation pour les entrées CSP recommandées pour provedly.app.
Le compteur en direct utilise-t-il le même shadow root ?
La notification et le compteur issus d'un même jeton de widget s'affichent dans le même hôte. Une barre CTA chargée depuis cta.js a son propre hôte et son propre shadow root.
Constatez l'isolation sur votre propre site avec une seule balise script : installer gratuitement.