Reported from the Consulting application on 8.0.0-alpha7 (react view UI, Issue #94).

The problem

A list with a detail can only be expressed as a <split-panel>, so the detail holds its share of the width permanently, whether or not anything is selected and whether or not the user is looking at it. In our business views the detail ends up with 50–60% of the pane:

<pane min-size="280" size="40" unit="%">   <!-- the table -->
<pane size="60" unit="%">                  <!-- the detail form -->

The list pays for that in cut-off values. In our client table the //Address// column holds a contact person, a street, a city and a phone number in roughly 660px; about half of it is visible. #29497 exists because of exactly this — a tooltip so the invisible half can be read at all.

The detail is also not the frequent case. Asked what the panel is for, our own answer was: navigating on to the object's files, projects and tasks — the master data behind those fields is edited rarely. So the layout gives the majority of the screen to the minority of the interaction.

What is missing

A detail that //overlays// the list instead of dividing it: anchored to an edge (right, in a left-to-right reading order), opened when something is selected, closed with Escape and with a close affordance, the list keeping its full width underneath.

What exists today and does not cover it:

• <split-panel> — divides, never overlays.
• <window> / open-dialog — modal and centred; the wrong shape for "inspect the selected row", and it takes the list away entirely.
• <adaptive-detail> — the closest: it already holds <selector>, <detail> and a shared selection channel, and it already switches presentation by display class. But the only two presentations are side-by-side (REGULAR) and full-bleed replacement (COMPACT).
• <sidebar> has a drawer mechanism (drawer-open-slot-name), but it belongs to the navigation sidebar and only to the compact viewport.

Suggested shape

Rather than a new element, a third presentation on <adaptive-detail> — it already carries selector, detail and selection, so only the rendering differs:

{{{#!xml <adaptive-detail selection="selectedClient" detail-display="drawer" detail-size="420">

<selector> <table .../> </selector>
<detail> <form .../> </detail>

</adaptive-detail> }}}

with detail-display defaulting to today's split, so nothing existing changes. Points worth deciding in the design:

• **Not modal.** The list stays scrollable and selectable underneath; picking another row swaps the drawer's content rather than closing and reopening it.
• Escape closes, and closing clears the selection (or does not — that is a real choice: keeping it lets the user reopen without re-finding the row).
• Focus moves into the drawer on open and returns to the row on close.
• Width configurable, and the drawer never wider than the viewport on a compact display, where the existing full-bleed behaviour is still the right one.

Why not build it in the application

It would mean re-creating anchoring, the open/close transition, Escape, focus handling and the ARIA wiring from outside a framework component — the same reasoning as in #29491. Our application deliberately does not.

Related

• #29497 — table cell tooltips; the workaround there exists because the table is too narrow, which is this ticket's symptom.
• #29491 — the field help text should be an anchored overlay; same class of missing overlay support.
• #29475 — no configurable column width on <table>.

Solution

<adaptive-detail> gets a third presentation, exactly in the suggested shape:

{{{#!xml <adaptive-detail selection="selectedClient" detail-display="drawer" detail-size="420">

<selector> <table .../> </selector>
<detail> <form .../> </detail>

</adaptive-detail> }}}

• detail-display — split (default, unchanged behaviour) or drawer. On a wide (REGULAR) viewport the drawer presentation renders the selector at full width and the detail in a slide-in panel anchored to the right edge of the element's own area (not the viewport: app bar, sidebar and the enclosing panel stay uncovered). On a compact viewport the full-bleed drill-in with breadcrumb is kept regardless of the setting.
• detail-size — the drawer width in pixels (default 420); the drawer is never wider than its container.
• The drawer is not modal: the list stays scrollable and selectable underneath. It opens when the selection channel receives a value and closes when the channel becomes empty; selecting another row swaps the content, the drawer stays open. The detail content is built once and stays bound to the selection channel, as in the split presentation.
• Closing clears the selection. Escape and the close button in the drawer header write null to the selection channel — so the row is no longer marked and the same row can be selected (and the drawer reopened) again. A form with unsaved input blocks the close with the usual dirty-confirm dialog.
• The drawer header shows the label of the selected object and the close button.
• Focus moves into the drawer on open and returns to the previously focused element on close.

Technically the presentation reuses the existing generic slide-in drawer control (ReactDrawerControl / TLDrawer), which gains two general options: an anchor mode (viewport, as before, or container = positioned inside the enclosing element) and a pixel width in addition to its named sizes. ReactAdaptiveDetailControl pushes the selector as its content and the drawer as an overlay child. A demo view ("Detail Drawer Demo") in tl-demo-react shows the presentation next to the responsive master-detail demo.