feat(OVERLAY): All overlays should use the Popover API (once it reaches stable)

[Akxe]

Feature Description

The Popover API should be used for overlay and, therefore, by extension, dialog, tooltips, select and more.

This feature should be implemented using feature detection because of Firefox probably and some more obscure browsers. The Popover API should be used for overlay and, therefore, by extension, dialogue, tooltips, select and more. As a fallback to the Popover API, the dialog element could be used.

Use Case

If some other API were to use the Popover API or dialog element and the angular components would not, it would mean that Angular would stay behind.

Ex: Having a matTooltip inside a native <dialog> element does show the tooltip behind the dialog and its backdrop.
https://stackblitz.com/edit/components-issue-4wx2az

[k3nsei]

Yeah we should be embracing web standards here.

[Akxe]

@wagnermaciel I would argue that this issue is P3 or maybe above since there is no workaround...

• The dialog API has been stable since 2022, and it does affect all overlays. Meaning that all listed below are affected:
  • Tooltip
  • Overlay
  • Select (menu)
  • Autocomplete
  • Datepicker
  • Menu
  • Sidenav
  • SnackBar
  • and maybe more
• There is no workaround. If something is using the underlying top layer API, it will always be on top
• The severity of this issue will grow in time as more libraries and extensions start using these APIs

[k3nsei]

@Akxe I think they just need to redo implementation of cdk overlay how it works and modals. Other stuff should be fine because it's uses cdk overlays.

[Akxe]

@Akxe I think they just need to redo implementation of cdk overlay how it works and modals. Other stuff should be fine because it's uses cdk overlays.

Indeed, but it means that every API that is using overlay is affected and without workaround

[kbrilla]

I say the are not compatible, not completely. For example popover/dialog or more fundamental overlay api has layers, which does not exist on popover api and what’s more will not be implemented. One way could be to move main container of overlay api to top layer to keep existing layer behavior but also keep eveything in one top layer. But then we go into anchor size/position etc… so Ii would rather have new api to work with native popover, and leave css where css is due. Also now that we can create top layer elements from anywhere in dom we don’t need to keep container element and fight with passing data to dialog through injector , have close on router navigation etc.. all that can be done more easily now that dialog/popover can just use native host injectors - of course does not need to, we can still have more similar api to todays one that provide ability to create router independent dialogs. But now we can for example just create those dialogs/popover elements inside root node,not outside it etc. Mayby those two apis should be separate even

[Akxe]

I say the are not compatible, not completely. For example popover/dialog or more fundamental overlay api has layers, which does not exist on popover api and what’s more will not be implemented.

Do you have an example of component using this behaviour? I am not sure I know of any

The řešit is well thought, well done 😊