open-ui icon indicating copy to clipboard operation
open-ui copied to clipboard

[Popup] Consider modal-ness as a spectrum in the platform

Open melanierichards opened this issue 3 years ago • 3 comments

On https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/445, @erikkroes said of the <popup> proposal:

I see the "light dismiss" behaviour as the most interesting part of this exploration. We currently have elements in a page that can have a show/hide or open/close state like <summary> and <details>. On the other side of the spectrum you can have a fully modal dialog.

The modal dialog has a lot of interesting aspects. You shouldn't be able to interact with the rest of the page which introduces a lot of caveats. A modal dialog is like a new page (but without the URL). It gives an entirely new context and removes you from the original context both visually, and non-visually.

It feels like the idea of a light dismiss tries to find a middle ground. It could be interesting for a proposal like this to explore the ideas behind modal behaviour (like defined with aria-modal). Some elements are clearly not modal and some are completely modal, following the binary choices of aria-modal. What elements belong to the first group, which belong to the second, and which go into the category of the (semi-modal?) light dismiss. Likewise, what characteristics does it share with a modal dialog, and which doesn't it share?

A venn diagram of modal and non-modal behaviour could be made. And following, a venn diagram of (possible) elements. The current proposal is for an element, but the element is part of a system. When you want to improve a sytem by adding something, you need to consider the entire system.

@maltenuhn said:

There is another dimension to the venn diagram (or spectrum) from modal to non-modal behaviour, namely whether UI events are passed through when interacting with the area outside it - including the click-outside-to-dismiss.

In our web based design tool (https://github.com/concrete-utopia/utopia) we have three classes of controls that might be modelled with <popup /> or <dialog />:

  1. A colour picker "popup" style control with swatches. It dismisses when clicking outside it. It also needs to pass through that "click", as well as the hover events we use to draw hover outlines on other elements. Basically, the outside of the popup is transparent to all mouse events, including the click to dismiss.
  2. An "uploading files" modal. Clicking outside it dismisses the modal, but neither the click outside nor the hover events should be passed through, but clicking outside does dismiss it.
  3. A heavy "select" type of control. Here the click outside of it (to dismiss) should be passed through, but while the popup is visible, other events (e.g. hover) are not.

In practice we achieve this with a combination of React portals, fixed positioned elements with pointerEvents, global event handlers, and z-index contortions. In particular, we either have to draw a div to act as a click / hover catcher, or use global event handlers via JS. Because the click catchers need to have the right net z-index (behind the popup, in front of everything else), and cover an area contiguous to either the full screen or a part of it, we have to combine a number of techniques to achieve it (z-index, React portals, global event handlers, manually "positioning" the popup part).

There's obviously a number of ways to support it, but if the intention is for popup and dialog to cater for these use cases, having some control over what happens outside of the modal would be very welcome.

@tlouisse added:

Great examples @maltenuhn. I would like to add another example where light dismiss boundaries are not clear. The gif below shows what happens to the github dropdown when screensize is changed from 'desktop' to 'mobile':

githubSwitch

Question arises: does the mobile screen still fit the 'light dismiss criterium'?

Since it has a backdrop, the only way to build this dropdown, would be with a <dialog>, since popups don't have backdrops? See: https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/432

I confess that I'm not exactly certain what the desired outcomes would be here. Potentially:

  • More precise definition of "light dismiss" behaviors and which events are(n't) passed through? (This would apply not just to popup but other elements with light dismiss behaviors as well)
  • Some design change to <popup> interaction behaviors?
  • A separate primitive to control modal-ness along a spectrum?

@erikkroes, do you want to take a stab at a proposal for us to consider in Open UI?

melanierichards avatar Apr 12 '21 19:04 melanierichards

No idea what I'm doing yet, but I made a little something at https://github.com/openui/open-ui/pull/352

Getting to know the workflow, and can hopefully build from there.

erikkroes avatar Jun 03 '21 20:06 erikkroes

Hey @erikkroes, I saw that your PR is in draft, are you ready for feedback or not quite yet?

melanierichards avatar Jul 15 '21 22:07 melanierichards

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

github-actions[bot] avatar Mar 19 '22 00:03 github-actions[bot]

a lot has changed with popover since this issue was filed. a popover is not modal, light dismiss behavior is being defined in HTML for modal dialogs. Closing this issue per the evolution of where this topic has gone.

scottaohara avatar Mar 21 '24 18:03 scottaohara

Also fine to close it as "Erik will probably never get to it" 😄

erikkroes avatar Mar 21 '24 19:03 erikkroes