Unplanned
Last Updated: 03 Nov 2026 08:50 by ADMIN
Beat
Created on: 02 Nov 2026 15:30
Category: Dialog
Type: Feature Request
0
Global hook to style popups and dialogs appended outside their originating component

Feature request: a global hook to style popups and dialogs that are appended outside their originating component

Environment

  • @progress/kendo-angular-popup, -dialog, -dropdowns, -tooltip, -menu and -grid 25.2.0
  • @progress/kendo-theme-default 14.5.0, Angular 21.2

Use case

Our application lets the user zoom single views, not the whole page (Ctrl+mouse wheel). A view is scaled by re-declaring the Kendo theme size custom properties (spacing, font sizes, line heights, ...) on the view element, multiplied by a factor in a custom property. Everything inside the view scales correctly with the theme, including the Kendo components.

Kendo popups and dialogs, however, are appended to the application root, outside the scaled view, so they do not inherit the view's custom properties and appear unscaled. This affects the DropDownList, ComboBox and DatePicker popups, tooltips, menus and context menus, the Grid's column menu and filter popups, and dialogs opened through DialogService.

The same need arises for any styling that is scoped to a part of the page: per-area themes, density modes, or a CSS class that marks a region.

Current options and their limits

  • POPUP_CONTAINER only moves the popups into another container element. Placing them inside the view lets them inherit its styles, but clips them at the view's edges and puts them under its stacking context.
  • popupSettings.popupClass and DialogSettings.cssClass work per component instance or per call. Many popups do not expose them (e.g. the Grid's internal popups, the tooltip and menu popups of other components), and a class cannot carry a value that changes at runtime, such as the zoom factor.
  • The components provide their own PopupService instances (in their component or module providers), so an application-level replacement provider is never used.
  • Dialogs opened by shared libraries cannot be given per-call settings without changing those libraries' APIs.

Why a common container or appendTo is not sufficient

The suggestions we received recommend a global POPUP_CONTAINER with shared styles, or popupSettings.appendTo to render the popup inside the originating component. We evaluated both:

  • The zoom factor is a property of each view, not of the application. Several views with different factors are visible at the same time, so one shared container cannot carry the right value for every popup. It would have to be changed on every open, which again needs a hook at open time.
  • appendTo: 'component' (or a container inside the view) inherits the right styles, but clips the popup at every ancestor with overflow: hidden or auto (grid cells, scrollable views, windows), and puts it under the stacking context of the view.
  • appendTo is not available for all popups, e.g. the Grid's internal popups, tooltips and menus of other components, and dialogs opened from shared libraries.

We understand that an earlier request to add CSS classes based on the creating component was declined. This request is more general: it does not ask Kendo to decide which classes to add, only for a supported point where the application can adjust the created element itself.

Request

A global, supported way to adjust the element of every popup and dialog when it is opened, for example one of:

  • an injection token for a callback that PopupService.open() and DialogService.open() (and WindowService.open()) call with the created element and the anchor or the originating element, or
  • an injection token for a default class and inline style applied to every popup and dialog element, or
  • an option that copies selected custom properties or classes from the anchor's ancestors onto the popup element.

Ideally the hook is also called when an open popup is repositioned, so that a changed scale can be applied without reopening it.

If such a hook is not planned, it would already help to document PopupService.open() and DialogService.open() as stable extension points, i.e. that every component opens its popups through them and that the returned references keep giving access to the created element.

Workaround we use

We wrap PopupService.prototype.open and DialogService.prototype.open. After the original call, we read the scale factor inherited by the popup's anchor (or, for dialogs, by the focused element or the last pressed element) and set the scale class and the custom property on the returned popup or dialog element. Kendo positions the popup after the next render, so the position is computed from the scaled size.

This works, but depends on the prototypes and on what open() returns, which may change in any release. One detail we noticed: PopupSettings.anchor is declared as ElementRef, but some components pass a plain HTMLElement, so our wrapper has to handle both.


1 comment
ADMIN
Martin Bechev
Posted on: 03 Nov 2026 08:50

Hello Beat,

Thank you for the detailed feature request and for sharing your use case. We understand that the current popup and dialog styling options do not adequately support application-scoped styling patterns like view-level zoom or density modes, which affect a large number of components across the Kendo Angular suite.

Your request for a global, supported hook is reasonable and aligns with real-world styling needs. The ability to apply custom properties and classes to popup elements based on their anchor's context would unblock view-scoped theming patterns that many applications need.

In the short term, your current workaround (wrapping PopupService.prototype.open() and DialogService.prototype.open()) is a viable approach. To make it more maintainable:
   - Document which PopupService methods are being wrapped (e.g., `.open()`, `.show()`)
   - Add assertions to handle both `ElementRef` and plain `HTMLElement` anchors to future-proof against refactoring
   - Consider wrapping at initialization time rather than repeatedly at runtime

We appreciate the detailed context and the transparency about your current implementation. This helps the team understand the real impact and prioritize accordingly.

I am converting this ticket to a feature request item in our Feedback portal. This way, we can track the customer demand for this type of feature and implement it based on the interest.

Regards,
Martin Bechev
Progress Telerik

Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.