Skip to main content
Remark ships two custom elements: <remark-chat-widget> for the floating chat and <remark-qa-activator> for the embedded chat (also known as the inline activator). Both share the same theme system and can be customized 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 both widgets. These settings apply to the floating chat and the embedded chat together. 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). Custom rules must target remark-chat-widget or remark-qa-activator in their selectors. 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 are set on the widget’s root element — <remark-chat-widget> or <remark-qa-activator>. Override them by targeting that element directly in your CSS, the same way you’d style any other HTML element. They correspond to dashboard settings but can also be overridden in custom CSS when finer control is needed. --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 the host element (or ::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.

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

Both remark-chat-widget and remark-qa-activator expose internal elements through the part attribute. You can target those elements from outside the shadow tree with the ::part() pseudo-element. Many parts carry scene suffixes so you can style the same structural element differently depending on context. The widget has three scenes: landing (before the conversation starts), chat (active conversation), and paused (conversation active on another device). For example, widget-header matches the header in any scene, while widget-header-landing 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. Scene suffixes let you 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). The header-content container carries a scene suffix so you can style the header differently on the landing screen vs. during a conversation.

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. Menu button parts carry scene suffixes (e.g., header-menu-close-button-chat) so you can style them differently on the landing screen vs. during a conversation.

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 when the visitor has an active conversation on another device or tab. Displays the matched expert’s avatar, a status message, suggested prompts, and a button to resume the conversation here.

Expert Profile Card

A summary card for the matched expert, displayed after a conversation starts. Includes a photo gallery and a button to open the full profile drawer.

Expert Profile Drawer

A slide-over panel with the expert’s full profile, including bio and credentials. Opens when the visitor clicks “View Profile” on the expert profile card.

Welcome Card

A greeting area shown when the chat first opens, before the visitor sends a message. Displays one or more welcome messages from the brand or expert.

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.

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. Individual prompt buttons carry scene suffixes (e.g., prompt-button-landing) so you can style prompts differently by context.

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) and also carry the skeleton token, so you can target a specific placeholder or style all loading states at once.

Targeting Parts in Your CSS

Use ::part() on the host custom element. Replace the element name with whichever widget you are styling — remark-chat-widget for the floating chat or remark-qa-activator for the embedded chat (inline activator):
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.
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 header-content or product-recommendation over incidental containers.
  • Use scene suffixes for targeted styling. Parts like widget-header, header-menu-close-button, and prompt-button match all scenes. Append a scene name (e.g., widget-header-landing, header-menu-close-button-chat) to scope styles to a specific context.
  • 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.