Interface FormDropdownList<T>

If set to true, then the dropdown button will be considered an icon action (without normal border and sized for icons only).

On a phone, show the menu as a sheet rising from the bottom of the screen over a dimmed page, the way the app's other mobile menus appear. No effect on a desktop layout.

Prefer this to setting the pieces by hand. A menu left to place itself on mobile lands as a narrow box adrift in the middle of the page — Popper computes an offset that the app's own body.mobile .dropdown-menu { position: fixed } then measures from somewhere else — and one opened inside a dialog needs portalToBody besides, since a transformed .modal-dialog is both the box a fixed menu is placed against and a stacking context the backdrop, painting above the whole modal, would otherwise dim the menu through.

Drop the tn-dropdown-list class the menu otherwise carries by default.

That class exists for scrollable menus: it moves the theme's backdrop blur off the menu's ::before layer — which a scrollable menu would scroll away with its content — and onto the menu element itself. The element-level filter is the fragile one, though: opened over note content it blurs nothing at all, leaving the menu merely translucent and reading as see-through over anything dark.

So set this on any menu that doesn't scroll (i.e. nearly every action menu) to keep it on the working pseudo-element layer.

Render the dropdown menu into document.body instead of nesting it next to the toggle.

Use this when an ancestor establishes a containment/backdrop root (e.g. container-type, transform, filter) which would otherwise flatten the menu's backdrop-filter blur into a flat tint. The menu is wrapped in a <div class="tn-dropdown-portal {className}"> so any CSS scoped under that class keeps applying even though the menu no longer lives inside the toggle's wrapper, and so the menu outranks whatever stacking context it was lifted out of.