Skip to content

[Overlay] Review management of overlay stack in relationship to a new stack root. #1783

@Westbrook

Description

@Westbrook

Code of conduct

  • I agree to follow this project's code of conduct.

Description of issue

Clarify usage documentation and/or API surface of the Overlay API around the support of multiple "overlay roots". This comes into play when two sibling overlay triggers exist and one of the triggers have a complex trail of overlays open without using type="modal" to occlude interaction with the second sibling. How should the library/a user manage interactions with the second trigger?

Context:

Questions:

  • should this close the first popover?
    • always
    • sometimes
    • never
  • Complex Popover[type="modal"] prevents interaction with "Second Popover" until closed, should this be the suggested usage?
    • modal traps tab
    • modal currently passes contextmenu interaction to the page once the popover is closed, should more things do that?
  • The stack:
    • The overlay system is currently a single stack where we generally push and pop the last item, should there be there be a deeper concept of "groups" or similar in the stack that close all at once?
    • Should "groups" be a usage location concept that a developer needs to manage in some way themselves?
    • This come to bear in the concept of sub/flyout menus, as well:

cc: @spdev3000 @jstoeckm

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions