# OverlayHostOptions
interface
The configuration of an [`OverlayHost`](module_ui_overlayhost-OverlayHost.md): callbacks resolving where the feature UI lives, called on every [`sync`](module_ui_overlayhost-OverlayHost.md#function-sync), and optional borrowed collaborators.
[See source](https://github.com/ckeditor/ckeditor5/blob/master/packages/ckeditor5-ui/src/overlayhost.ts#L233)
## Properties
### `bodyCollection?: BodyCollection`
An existing body collection to host instead of creating one – used by [`EditorUI`](module_ui_editorui_editorui-EditorUI.md), whose collection belongs to the [`EditorUIView`](module_ui_editorui_editoruiview-EditorUIView.md). A borrowed collection is not destroyed by [`destroy`](module_ui_overlayhost-OverlayHost.md#function-destroy); its owner destroys it.
[See source](https://github.com/ckeditor/ckeditor5/blob/master/packages/ckeditor5-ui/src/overlayhost.ts#L287)
### `resolveInlineContainer?: () => ( ShadowRoot | HTMLElement | null | undefined )`
Resolves the DOM node holding the feature's _inline_ UI – the parts the feature renders directly into its own container (buttons, badges, and similar), as opposed to the floating views it puts into the [`bodyCollection`](module_ui_overlayhost-OverlayHost.md#member-bodyCollection). Usually the container element itself, but it may also be a shadow root, when that root is all the feature knows of the tree its inline UI lives in.
The host registers this node with its [`shadowRootRegistry`](module_ui_overlayhost-OverlayHost.md#member-shadowRootRegistry) so the shared [`TooltipManager`](module_ui_tooltipmanager-TooltipManager.md) can drive the tooltips of that inline UI. This matters when the inline UI sits inside a shadow root: in events observed at the document level the elements inside the root are hidden behind their shadow host, so the tooltip manager has to attach its listeners inside each registered root – without this node being registered, the tooltips of the feature's inline UI would never fire. The node is re-resolved on every [`sync`](module_ui_overlayhost-OverlayHost.md#function-sync), so the registration follows the feature if it moves to a different container.
Omit it when the feature has no tooltip-bearing UI outside the body collection, or when those nodes are registered directly with the [`shadowRootRegistry`](module_ui_overlayhost-OverlayHost.md#member-shadowRootRegistry) instead.
[See source](https://github.com/ckeditor/ckeditor5/blob/master/packages/ckeditor5-ui/src/overlayhost.ts#L279)
### `resolveMountTarget: () => ( ShadowRoot | HTMLElement | null )`
Resolves the element or shadow root the [`bodyCollection`](module_ui_overlayhost-OverlayHost.md#member-bodyCollection) should be mounted in – that is, where the feature's floating views end up in the DOM. The collection is appended as a top-level child of this target, which should meet two requirements at once:
* it adopts the same styles as the root the feature's UI lives in – typically a shadow root sharing that root's adopted stylesheets – so the floating views are styled like the rest of the feature's UI;
* it sits at the end of `document.body`, both so that `overflow` on the ancestors between the feature and the document body cannot clip the floating UI, and so that it paints above the rest of the UI (DOM order decides paint order within a stacking context) instead of below it.
A dedicated shadow root appended at the end of `document.body` that mirrors those styles satisfies both. The target is therefore not required to be the feature's own root, and to stay unclipped and on top it usually should not be nested inside the feature's container.
Return `null` to keep the collection unmounted – for example while the feature's container is not connected to the document yet, so there is no root to resolve. The target is re-resolved on every [`sync`](module_ui_overlayhost-OverlayHost.md#function-sync), so the collection is re-mounted if the feature moves to a different root and unmounted once its container goes away.
[`getOverlayMountRoot`](module_utils_dom_getoverlaymountroot.md#function-getOverlayMountRoot) covers the common resolution from an anchor node (the feature's container): the anchor's shadow root when it lives in one, `document.body` in the light DOM, or `null` while the anchor is detached.
[See source](https://github.com/ckeditor/ckeditor5/blob/master/packages/ckeditor5-ui/src/overlayhost.ts#L259)
### `shadowRootRegistry?: ShadowRootRegistry`
An existing shadow root registry to use instead of creating one – used by [`EditorUI`](module_ui_editorui_editorui-EditorUI.md), which feeds its registry from many places (editables, toolbars, the menu bar) and shares it with other features. A borrowed registry is not destroyed by [`destroy`](module_ui_overlayhost-OverlayHost.md#function-destroy); its owner destroys it.
[See source](https://github.com/ckeditor/ckeditor5/blob/master/packages/ckeditor5-ui/src/overlayhost.ts#L295)
### `tooltipManager?: TooltipManager`
A borrowed reference to the shared tooltip manager to register the body collection with, instead of the host [acquiring](module_ui_tooltipmanager-TooltipManager.md#static-function-for) (and on destroy [releasing](module_ui_tooltipmanager-TooltipManager.md#function-release)) a reference of its own – used by [`EditorUI`](module_ui_editorui_editorui-EditorUI.md), so an editor keeps counting as a single holder of the singleton. The holder of the borrowed reference releases it.
[See source](https://github.com/ckeditor/ckeditor5/blob/master/packages/ckeditor5-ui/src/overlayhost.ts#L304)
### `updateEmitter?: Emitter`
An emitter whose `update` event signals that the UI may have moved or re-rendered (an editor passes its [`EditorUI`](module_ui_editorui_editorui-EditorUI.md)). The host [re-syncs](module_ui_overlayhost-OverlayHost.md#function-sync) on every such event and the shared tooltip manager repositions a pinned tooltip.
[See source](https://github.com/ckeditor/ckeditor5/blob/master/packages/ckeditor5-ui/src/overlayhost.ts#L311)
---
Full index of the CKEditor 5 API reference: [llms.txt](llms.txt)