Appearance
Layouts
data-nam-layout decides where the conversation renders. There are two values and the default is inline.
inline
The conversation stands where the fields were. The SDK hides the wrapper around each field it is currently asking about and mounts its own host element in that place, so the page's heading, disclosure and submit button stay exactly where the visitor saw them.
The thread keeps a bounded height and scrolls, following the newest message unless the visitor has scrolled up to re-read. Override the default of min(60vh, 520px) with --nam-thread-max — see Theming.
This is the right choice for a form that is already the centre of the page.
panel
html
<form data-nam-layout="panel" data-nam-brand="Kestrel" …>A full-height dialog: a header carrying your brand, a scrolling stage, and a composer pinned to the bottom. It is the layout the richer blocks were designed for — question units with image tiles, option cards, and sheets all want the room.
While the panel is open:
- the host element is appended to
<body>, not inserted into the form. A fixed panel inside a transformed ancestor is positioned against that ancestor rather than the viewport, so it cannot live where the fields are; <html>getsoverflow: hidden, so nothing behind it scrolls;- every other direct child of
<body>is setinert, so nothing behind it takes focus.
Both are recorded and reversed on dock or on restore.
Looking for the widget in the DOM?
In inline layout the host sits inside your form. In panel layout it is a child of <body> until it docks. A selector scoped to the form finds nothing in panel mode and the panel is working perfectly — check for [data-nam-host] at the document level.
It docks before the end
At the confirm step the panel comes down: the host is moved to sit immediately before your first field's wrapper, the page unlocks, and the layout attribute is rewritten to inline.
This is deliberate and it is the whole reason the panel can be used at all. The disclosure the visitor reads and the button they press are your page's own, in their own context — not a button we drew inside a dialog. See Submit.
data-nam-brand
The panel header's title, with its first letter as the round mark beside it. Without it the header falls back to the goal label, which falls back to your submit button's text.
Which to choose
inline | panel | |
|---|---|---|
| Where it renders | In place of the fields | Over the page, docking back at the end |
| Page keeps scrolling | Yes | No, until it docks |
| Best for | A form that is already the focus | A form low on a long page; anything using cards or sheets |
| Advertises | cards, sheet, visual_ask | those plus panel |
The SDK tells the agent which of these it can draw on every message, so a page still running an older bundle is simply offered the five field actions and never sent a block it cannot render.