I’d like to request support for reusable custom containers that can host native Workshop widgets while preserving their native editing controls.
At the simplest level, this could be a site wrapper or section component. A frontend developer defines the layout, spacing, borders, responsive behavior, and theme once, then shares it across applications. Authors place native widgets inside it without needing to understand or repeatedly configure all the underlying design rules.
The same approach could support more advanced containers, such as tabbed sections or layouts with custom interactions.
User story
As a frontend developer, I want to create shared containers with configurable content slots, so that application authors can build consistent experiences using native Workshop widgets while the container encapsulates the layout and styling rules.
As a Workshop author, I want to add and configure native widgets inside those containers using the familiar Workshop editor, with only the relevant container settings exposed to me.
Current challenge
My understanding is that a custom widget is treated as a single rendering surface. Components implemented inside it do not become native Workshop children with their own editor controls.
This creates a gap between using native layouts with their available configuration options and building the contents in custom code.
Even basic presentation changes can involve coupled settings. For example, Workshop instructs builders to set the background to transparent and elevation to borderless to remove widget padding. A reusable section wrapper could encapsulate a consistent design without requiring authors to work through these dependencies each time.
Requested behavior
Allow a custom container to declare one or more named slots that accept native Workshop widgets.
For example:
- A site wrapper with header, navigation, and main-content slots.
- A section or card with a title, toolbar, and content slot.
- A tabbed container whose panels accept native widgets.
The application author chooses what goes inside. A native Object Table, filter, or Action button would remain a native widget, with its existing configuration controls and integrations.
The intent is to build on Palantir’s native components and Blueprint foundation, rather than replace or recreate them.
Acceptance criteria
- Authors can add, select, configure, reorder, and remove native widgets within custom-container slots.
- Child widgets retain their native editor panels, variable bindings, Ontology integration, and Actions.
- Containers and their children remain individually visible and selectable in the Workshop layout tree.
- Developers can encapsulate layout and styling rules, exposing only the container options authors need.
- Containers can be shared and versioned across applications, with updates preserving each instance’s content and child-widget configuration.
- A supported interface coordinates container state and child visibility, including focus and keyboard behavior where applicable.
- Styling uses supported boundaries and theme inputs rather than depending on private Workshop CSS selectors.
Why this matters
This would make a shared design system usable within Workshop’s authoring experience. Teams could maintain approved wrappers and sections centrally, reduce repeated configuration, and introduce basic or advanced UI behavior without rebuilding native functionality.
It would also provide more control over accessibility at the layout and interaction level. It would not automatically resolve accessibility issues within native widgets, but would give developers a clearer way to manage how those widgets are composed.
Is this capability planned, or is there an existing supported approach that allows custom containers while retaining native child-widget editing?