ui5-search: expose inner ui5-select (scope dropdown) via CSS ::part() to allow host styling

[Sobyt483]

Summary

<ui5-search> renders an inner <ui5-select> for the scope dropdown, but the element is not exposed as a CSS part. This makes it impossible to style the scope select from outside the component using the standard ::part() mechanism.

Current behaviour

The scope select is hard-coded with max-width: 10rem (160 px) inside the <ui5-search> shadow root:

/* inside ui5-search shadow root — adoptedStyleSheets */
[ui5-select] {
  max-width: 10rem;
  ...
}

Additionally, .ui5-select-label-root inside the <ui5-select> shadow root has overflow: hidden; text-overflow: ellipsis, so any label text longer than ~160 px is truncated with no way to override it through the public API.

Expected behaviour

1. <ui5-select> inside <ui5-search> is exposed as a named CSS part (e.g. part="scope-select"), allowing host applications to write:

ui5-search::part(scope-select) {
  max-width: none;
  min-width: fit-content;
}

Workaround

Currently the only reliable workaround is imperative DOM patching through nested shadow roots at runtime, which is fragile and breaks encapsulation:

const ui5Select = ui5Search.shadowRoot?.querySelector('ui5-select') as HTMLElement;
ui5Select.style.maxWidth = 'none';
ui5Select.style.minWidth = 'fit-content';

const label = ui5Select.shadowRoot?.querySelector('.ui5-select-label-root') as HTMLElement;
label.style.overflow = 'visible';
label.style.textOverflow = 'clip';

Use case

Scope labels such as "My Contributions" or any other localised string longer than ~11 characters are visually truncated even when there is ample space available in the toolbar. This is a real UX regression for applications that use <ui5-search> with named scopes.

Environment

• @ui5/webcomponents-fiori version: 2.22.0
• Browser: Chrome 149

[nnaydenow]

Hello @UI5/ui5-team-ctr-ril,

Please take a look.

[OlgaFlaccus]

ticket created: FIORITECHP1-36159

[Vonahz]

Hi @Sobyt483 ,

Thank you for reporting this! To help us better understand your use case, could you share which organization you're from? Specifically, are you part of SAP or an external partner/customer?

Regarding the CSS part exposure for the search scope dropdown: we intentionally keep this component's internal styling encapsulated to ensure visual consistency across all use cases. The scope dropdown is designed to maintain a uniform appearance throughout the Fiori ecosystem, which is important for providing a cohesive user experience across all SAP applications.

That said, we understand that the current 10rem max-width constraint can cause truncation issues with longer localized labels. Rather than exposing internal parts (which would allow arbitrary styling that could break the intended design).

Could you provide more details about your specific scenario? How long are your typical scope labels, and what would be an ideal width for your use case?

This will help us determine the best approach that balances flexibility with design consistency.

Regards,
Milen K.

[Sobyt483]

Hi @Vonahz
Thanks for the response!

I'm part of Platform-mesh and OpenMFP organisations and I'm responsible for building a set of Web Components that internally use UI5 components.

In our case, we cannot reliably predict the length of the scope labels in advance. The components are consumed by different applications and teams, and the labels are provided by the consumers, so they may vary significantly in length, especially with localization.

Because of that, we would ideally like either:

to allow the consuming application to configure the width or max-width of the scope dropdown, or
to have the dropdown automatically adjust its width based on its content.

A fixed 10rem max-width can be quite restrictive for longer labels and may lead to unnecessary truncation. We understand the concern about exposing arbitrary internal styling and maintaining visual consistency, so we are not necessarily tied to CSS part exposure specifically. Any supported API that provides some control over the dropdown width would work for our use case.

Regards,
Andrian