Style engagement widgets with CSS

The chat bubble, question bar, inline button and Starters render inside a shadow root, so your storefront's CSS can't reach them by accident, and can't restyle them by accident either. Two mechanisms are open on purpose:

• CSS custom properties: recolour a widget. Use these first.
• Shadow parts (::part): reach an element directly when a custom property doesn't cover what you need.

Both are written in your own stylesheet. Neither needs a new Content Security Policy directive: the rules are yours, served from your origin, under the style-src you already have. Nothing here replaces the dashboard's appearance fields. Reach for CSS when the structured fields don't express what you want.

Host selectorsCopy Anchor Link

Every widget the tag renders on a page has a host element you write your rules against. The two floating formats append theirs to <body>; an inline widget's host (the inline button's or Starters' alike) is at its mount point, and which selector reaches it depends on the mount mode:

All inline forms share the same host selectors, whichever inline format renders inside them. This is part of the contract, so renaming or removing any of it is a breaking change.

The host carries no widget id, so a rule written against these selectors applies to every widget of that type on the page. If you run two launchers on one site, you can't target one of them from CSS. Configure them separately in the dashboard instead. An inline widget is the one exception in practice: in the custom-element mode you can narrow to a single widget through the slot you chose, iadvize-widget[data-iadvize-slot='product-cta'].

CSS custom propertiesCopy Anchor Link

Recommended, because they don't depend on the widget's internal structure: if we restructure the DOM later, your rules keep working.

Only colours are exposed. Size, corner radius, and shadow are not themeable this way: set them from the widget's Design card, or reach for a part.

Set a property on the host, or on any ancestor it inherits from (:root, body, a wrapper):

[data-iadvize-launcher-host] {
  --iadvize-launcher-bg: #111111;
  --iadvize-launcher-fg: #ffffff;
}

Chat bubble and inline buttonCopy Anchor Link

Question barCopy Anchor Link

StartersCopy Anchor Link

Starter questionsCopy Anchor Link

The starter-question chips a widget renders above itself. Both formats use the same two properties, set on whichever host the chips belong to.

Unset, a chip inverts its widget's own resolved colours: the widget's foreground becomes the chip's background, and vice versa.

Leave a property unset and the widget renders the value resolved from its dashboard configuration and your site's branding. An unset property changes nothing.

The loader stores these as var() references, so they resolve live. A media query, a dark-mode block, or a runtime setProperty() call all take effect immediately:

@media (prefers-color-scheme: dark) {
  [data-iadvize-launcher-host] {
    --iadvize-launcher-bg: #f5f5f5;
    --iadvize-launcher-fg: #111111;
  }
}

Shadow partsCopy Anchor Link

Nine elements carry a part name. Nothing else does.

[data-iadvize-launcher-host]::part(launcher) {
  box-shadow: none;
  border: 2px solid #111111;
}

/* The same three parts reach an inline button. */
iadvize-widget[data-iadvize-slot='product-cta']::part(launcher) {
  border-radius: 4px;
}

[data-iadvize-launcher-host]::part(launcher-label) {
  letter-spacing: 0.04em;
  text-transform: uppercase;
}

[data-iadvize-composer-host]::part(composer-send) {
  border-radius: 8px;
}

A ::part() rule from your stylesheet beats the inline styles the loader applies, so you don't need !important to override a property we already set. The loader sets box-shadow, border, and border-radius itself, and all three examples above still take effect as written.

Two limits are worth knowing before you build on parts:

• A part freezes internal structure. These eight names are a public API we're committed to, but the elements around them aren't. Prefer a custom property when one covers your case.
• You can't select inside a part. ::part() accepts pseudo-classes (::part(launcher):hover works) but not descendant selectors: there's no way to reach an element nested inside a named part.

The label inherits your page's font, on both the chat bubble and the inline button, because a shadow root inherits inheritable properties from its host. That's the default with no CSS from you; setting font-family on the host or on ::part(launcher-label) changes it. There is no font field in the dashboard and the tag requests no font file, so this stylesheet is the only place a face is chosen.

One thing you can only do here, and it matters for an inline button: reserve its space, so nothing on the page moves when it appears. See Reserve the space.

What this surface doesn't coverCopy Anchor Link

• The conversation panel and everything inside it. The conversation runs in a cross-origin iframe, which your CSS cannot style at all. Its colours, font, and logo come from Site → Settings → Branding. See Branding.
• Geometry, via custom properties. There is no custom property for size, corner radius, or shadow. Use the widget's Design card, or a ::part(launcher) / ::part(composer) rule.
• The page-side override. iadvize('set', { launcher: … }) accepts enabled, offsetBottom, and offsetSide only. There is no page-side way to change a widget's appearance from JavaScript: that's the dashboard's job, or this stylesheet's.
• The AI-transparency disclosure. Every control's accessible name and title always carry it (the chat bubble's and the inline button's alike), and so does every starter-question chip's accessible name. No CSS you write, and no field you set, removes it.