Skip to main content
Remark’s widgets are custom elements, such as <remark-chat-widget> for the floating chat and <remark-qa-activator> for the embedded chat (also known as the inline activator). Every Remark element carries a data-remark attribute and shares the same theme system. You can customize them at two levels: through widget settings in the Remark dashboard, and through custom CSS targeting Shadow DOM parts and CSS custom properties. Widget settings handle the most common adjustments. Custom CSS picks up where widget settings leave off, giving you control over individual elements.

Widget Settings

Configure colors, typography, spacing, layout, and behavior from the dashboard.

CSS Custom Properties

Override sizing tokens and reference generated color tokens.

Shadow DOM Parts

Target specific elements using the ::part() pseudo-element.

Full Example

A complete example combining tokens and part selectors.

Widget Settings

The Remark dashboard provides visual controls for theming, layout, and behavior across three pages — no CSS required.

Appearance

The Appearance page (Settings > Appearance) is the primary way to theme Remark’s widgets. These settings apply to all of them together unless you limit them with Use theme in…. Each palette color is optional. When a value isn’t provided, the theme system generates an appropriate color from the brand color automatically, with both light and dark mode variants. The Appearance page also includes a Custom CSS field for advanced overrides (see sections 2 and 3 below). Every selector must include a Remark element: [data-remark] matches all of them at once, or name one, such as remark-chat-widget. The Custom CSS field supports @media, @supports, and other at-rules, so you can write responsive ::part() overrides directly in the dashboard.

Chat Settings

The Chat page (Settings > Features > Chat) controls the floating chat widget’s layout and behavior.

Inline Activator Settings

The Inline Activator page (Settings > Features > Inline Activator) controls the embedded chat.
We recommend using widget settings over custom CSS when possible. Settings available in the dashboard have been tested to work cohesively and adapt to light and dark mode automatically.

CSS Custom Properties

The chat widget’s theme system generates CSS custom properties that you can reference in custom CSS rules. These properties are grouped into sizing tokens (which can be overridden directly) and color tokens (which are generated from widget settings).

Sizing and Typography

These properties correspond to dashboard settings but can also be overridden in custom CSS when finer control is needed. --hem is set on the Remark element itself, so override it on [data-remark] or a specific element such as remark-qa-activator. The other three are set on the theme-root part inside the widget, so override them on [data-remark]::part(theme-root). --hem stands for “host em” — it serves the same role as rem but is scoped to the widget’s shadow DOM root rather than the page’s <html> element. This means the widget’s typography scales independently of the host page’s font size. Font sizes are not exposed as individual variables; they are calculated as ratios of --hem (e.g., base text = --hem, small text = calc(var(--hem) * 14 / 16)). To scale all text proportionally, adjust the font size in the dashboard or override --hem in custom CSS.
--hem is already responsive to the host page’s root font size. If your site already adjusts font-size on <html> for different viewports, the widget may scale along with it automatically depending on your configuration.

Distance from the Screen Edge

The floating chat and its activator sit a fixed distance from the viewport edge, controlled by two custom properties. Both default to 24px and are independent of --remark-spacing-multiplier, which scales spacing inside the widget. Set them on ::part(theme-root) to move the activator and the open chat panel together. To move only one, scope the override to its part — ::part(activator-parent) for the activator, ::part(app-parent) for the open chat panel:
This applies to the floating chat only; the embedded chat follows normal page flow. On mobile, the open chat panel fills the screen and ignores the bottom distance, but the activator still respects it. At the full height size, the open panel docks to the screen edge on larger screens and ignores both distances.

Colors

Color tokens are generated from the brand color and palette overrides configured in the dashboard. They follow the naming pattern --remark-colors-{name} and have separate light and dark mode values. These tokens are set on the theme-root part — an internal element within the shadow DOM. You can reference the tokens in ::part() rules, but to change colors, use the dashboard palette settings rather than overriding variables directly.

Content

Backgrounds

Borders

Brand

Action

These correspond to the Button color override in the dashboard.

Status

Elevated Surfaces

Overlays and Inverse

Shadow DOM Parts

Every Remark element exposes internal elements through the part attribute. You can target those elements from outside the shadow tree with the ::part() pseudo-element. The widget has three scenes: landing (before the conversation starts), chat (active conversation), and paused (embedded chat only, while the conversation continues in the floating chat on the same page). The element reports the current scene in its data-scene attribute, so you can style the same part differently per scene. For example, remark-chat-widget::part(widget-header) matches the header in any scene, while remark-chat-widget[data-scene='landing']::part(widget-header) targets only the landing screen header. Some elements also expose a skeleton token during loading states for styling placeholders.

Floating Activators

These parts control the entry point to the floating chat — the button or text bar that visitors click to open the conversation. They are not present on the embedded chat (inline activator).

Shared Parts

The remaining parts are shared by both the floating chat and the embedded chat (inline activator).

Widget Shell

The outermost structural elements that wrap the widget’s header, content area, and footer. Combine them with data-scene to style each section differently on the landing screen, during an active conversation, or while paused.

Chat Header

The header bar at the top of the chat, showing brand and expert info. Visible once the widget is open (floating) or always visible (embedded).

Header Menus

Dropdown menus accessible from the header — including options to mute, request a human, and adjust widget layout. The layout menu is only present in the floating chat.

Expert Intro

An introductory card shown before the conversation starts. Appears on the landing scene in both compact (embedded) and hero (floating) variants, depending on the activator type setting.

Paused Scene

Shown in the embedded chat while the visitor’s conversation is open in the floating chat on the same page. Displays the matched expert’s avatar, a status message, suggested prompts, and a button that moves the conversation into the embedded chat.

Expert Profile Drawer

A slide-over panel with the expert’s full profile, including bio and credentials. Opens when the visitor clicks the expert in the chat header (chat-header-expert-trigger), for experts with a full profile.

Welcome Message

The expert’s opening message, shown at the start of a new conversation before the visitor sends anything.

Messages

The conversation thread. Expert messages are grouped with an avatar; user messages appear on the opposite side. Each message bubble wraps markdown content.

Message Prose

Markdown rendered in a message carries part="prose" on its container, and every element inside it is stamped with prose-<tag> — prose-p, prose-a, prose-h2, prose-li, and so on — so any rendered element can be styled individually. Links carry message-link alongside prose-a. Block spacing inside prose is driven by custom properties set on the container, overridable through ::part(prose). Prefer these over margin overrides on the per-element parts — a variable keeps the first/last-child edge resets intact and covers grouped elements in one declaration:

Typing and Input

The text input area at the bottom of the chat, plus indicators shown while the expert or AI is composing a response.

Attachments

Files the visitor attaches to a message, when attachments are enabled for your workspace. Staged files show in a preview strip above the input. Sent files that aren’t images show as a list on the message, and sent images use the gallery parts in Messages.

Prompts

Suggested questions shown on the landing screen, during a paused conversation, or as conversation starters. Visitors click a prompt to send it as their first message. The prompt-button part also appears on prompt-skeleton placeholders and on the live try-on prompt, so a rule on ::part(prompt-button) styles those too.

Product Recommendations

Product cards shown inline when an expert or AI recommends items. Each card links to the product page and displays a thumbnail carousel, name, and price. The add-to-cart button adds the product directly, or opens a variant picker sheet when the product has options; a post-add toast offers checkout.

Presented Showcases

Scene-style imagery the agent generates from products in the catalog and presents inline in the conversation. A summary header introduces the showcase; hotspots on the rendered image let visitors hover for product details and add items directly to cart.

Content Previews

Rich previews for URLs shared in the conversation. Open Graph previews display an image, title, and optional price. YouTube links render an embedded video player.

Inline Cards

Interactive cards the agent renders inline in the conversation, such as discount codes and return-portal links. Every card shares the generic card part and a common anatomy, so you can style all cards at once, a specific kind by its own part, or a specific element by its anatomy part.

Assistant Indicator

A small tag shown alongside messages to indicate whether the response came from an AI assistant or a human expert. The bar at the bottom of the chat, containing terms of service text and Remark branding.
Avoid hiding the chat footer, terms text, or terms of service controls with custom CSS. These elements may contain legal disclosures or consent prompts that visitors need to see before using chat.

Data Collection

Forms and prompts for collecting visitor information (email, name, phone) and feedback. These appear at specific points during the conversation flow. The NPS survey itself opens in a bottom sheet built from the widget’s standard dialog elements; its rating request and summary appear in the message stream.

Skeleton and Loading

Placeholder elements shown while the widget loads. Skeleton elements use a -skeleton suffix (e.g., chat-header-avatar-skeleton). The shimmering placeholder blocks also carry the skeleton token, so you can target a specific placeholder or style them all at once.

Live Try-On and Review Summaries

These parts apply to workspaces with live try-on or review summaries enabled. Their dialogs open outside the element that launched them, so style these parts with [data-remark] (see Targeting Parts in Your CSS).

Live Try-On

Other live try-on parts use the live-view- prefix.

Review Summaries

Targeting Parts in Your CSS

Use ::part() on a Remark element. [data-remark] styles a part wherever it appears, which suits brand-wide rules. Name a specific element, such as remark-chat-widget for the floating chat or remark-qa-activator for the embedded chat (inline activator), to style only that surface:
Live view and the review breakdown open in a full-page layer attached to the end of the page rather than inside the element that launched them. Style their parts with [data-remark], such as [data-remark]::part(review-breakdown), since an element name like remark-reviews doesn’t reach them. A common use case for the embedded chat is adding spacing above or below the widget to separate it from surrounding page content:
You can use nested media queries to apply different styles at different viewport sizes:
In this example, the embedded chat uses the default base font size (16 px) on smaller screens and bumps it up on larger viewports. CSS nesting works inside an element selector, as in the example above, but not inside a ::part() rule. A rule nested in a ::part() block never matches, while the outer rule still applies, so the mistake is easy to miss. Attach pseudo-classes and pseudo-elements to the part directly:
Some parts are only present in specific UI states. For example, more-options-menu and layout-menu are only rendered while those dropdowns are open, and skeleton parts are only present while the widget is loading.

Full Example

This example shows custom CSS that adjusts sizing tokens and styles individual parts. Colors and font family would typically be set through the dashboard rather than in CSS.

Best Practices

  • Use widget settings first. The dashboard handles colors, typography, spacing, and border radius with built-in dark mode support. Reach for custom CSS only when you need to style a specific element differently.
  • Reference token variables in ::part() rules. When writing custom CSS, use the --remark-colors-* tokens rather than hardcoded color values so your overrides adapt to light and dark mode.
  • Style semantic parts, not layout wrappers. Prefer parts like widget-header or product-recommendation over incidental containers.
  • Scope by scene with data-scene. Parts like widget-header, header-menu-close-button, and prompt-button match all scenes. Add a scene to the element selector (e.g., remark-chat-widget[data-scene='chat']::part(widget-header)) to style a specific context. Keep base styling in unscoped rules, because the element sets data-scene only after the widget loads.
  • Account for stateful parts. Menu, loading, and prompt parts may only render in specific states. Test your overrides in those states.
  • Check responsive layouts. Header menus, product cards, activators, and input affordances can shift across screen sizes.

Beyond CSS

For designs that go further than settings and custom CSS can reach — a fully custom activator built into your product grid, redesigned widget surfaces, or a bespoke theme — Remark supports brand-specific widget extensions built and maintained by our team. If you have a design in mind, contact your Remark representative to discuss what’s possible.