[Popup] popup vs dialog

[tlouisse]

Hi,

My colleagues (@daKmoR, @erikkroes) pointed me to the spec proposal for the popup element.
Being an author contributing to an overlay system of a white label component library myself, I think it's a great proposal. It could simplify our code and make it more performant.

The goals stated in your introduction perfectly align with our library goals to have an accessible, functional layer of components that can be used as the fundament for any Design System.

I have a few questions though, about the difference between popups and dialogs.
Sorry for the long text, thanks in advance for reading :)

popup vs dialog

As you mention, you considered making the <popup> an extension of the <dialog>, but this was
not pursued, because it would result in a mashed up api.
Could you elaborate on how apis would clash?

For me, from the spec, it's not completely clear what is the 'cutoff point' between a <dialog> and <popup>.
Roughly speaking, my impression is that a <dialog> would be used for elements positioned relative to the viewport and a <popup> relative to the anchor/invoker.
Maybe this assumption is not correct, let me know if that is the case :)

For me the line between the two would be blurry when looking at the variety of overlay ui components built in practice by different Design Systems.
So in that regard extending/adjusting the dialog (especially when looking at its w3c definition) with more features would make more sense to me.

Differences

In the spec you mention the following differences between <dialog> and <popup>:

popups have lightweight UI that dismises automatically when the user interacts with other UI, or when a task is completed within the popup (such as selecting an option).

What would be the 'cutoff point' for lightweight ui? What category would the google-apps menu fit in for instance (it's positioned relative to its anchore/invoker and has quite some content)?

What about the content of a toast or alertdialog (which is usally lightweight content)?

dialogs are more persistent and are generally dismissed explicitly by the user.

It seems that a <dialog> invoked via showModal() will be dismissed when pressing escape.
See: https://jsfiddle.net/d6k0xp92/6/

Only one popup can be shown at a time / More than one dialog can be presented at a time.

What is the rationale behind this?
If I look at different Design Systems I worked on in the past, it was possible to have tooltips
(or maybe they were actually more like toggle tips).
that have no 'light dismiss' behavior (they would only hide when the invoker was pressed, but not on
outside click/blur).
What is the exact reasoning behind having one popup visible at a time?

Another likely scenario would be to have popups that hide with a delay (or fade out) after they lose focus
(usually on hover). This could be kind of a must inside flyout menus for user friendliness.
In such cases, when the next popup is hovered/activated, two could need be displayed simultaneuosly (when the previous one needs to fade out).

I could imagine showing multiple coachmarks
on a page could also be a use case.

dialog can be modal, such that user interaction with other UX elements is prevented.

How does a <popup> exactly differ from a non modal <dialog> (invoked via show())?

Which components would be considered popups ?

If we build overlays with the current platform toolset (aria roles), I would consider the following components
popups:

• a select (or dropdown listbox)

<button>open/close</button>
<popup role="listbox/grid"></popup>

• a combobox

<input role="combobox" /> 
<popup role="listbox/grid/tree"></popup>

• a dropdown menu

<button> open/close </button> 
<popup role="menu"> </popup>

• a popover

<input role="combobox" />
<popup role="dialog">some interactive content...</popup>

• a tooltip

<button aria-describedby="myPopup"></button>
 <popup role="tooltip" id="myPopup"></popup>

• a datepicker

<button>calendar icon</button>
<popup role="dialog">
  <div role="grid">...</div>
</popup>

All of the components above can also be implemented like this (wrapped in [role=dialog])
when a 'surrounding UI' is needed:

<button>open / close</button>
<popup role="dialog">
  <!-- additional ui (feedback/chips etc.) required by Design System -->
  <div role="listbox/menu/grid/tree">...</div>
  <!-- additional ui (feedback/chips etc.) required by Design System -->
</popup>

Would the <popup> fit in all situations above? Or would I need a dialog for the last example when there would be more 'surrounding ui'?

I read a custom tooltip would not fit as a popup. Why exactly? (When consulting the w3c specs, a tooltip has its own role and other overlays have role 'dialog' (or listbox/grid/tree/menu when the 'root' of the overlay fits that role))

Switching context based on viewport

For many Design Systems it's common to have an overlay behaving like a <dialog> on mobile
(or below a certain screen size) and a <popup> on desktop.
Take for instance the datepicker...
it could behave like a dropdown/popover on desktop (see link), but on mobile an Android / iOS like
experience is required: usually a bottom sheet or modal dialog centered in the viewport (also think of behavior of a <select> on mobile).

Of course it would be possible to make a switch in code between a <dialog> and <popup> component,
but, especially when used in conjunction with content projection, this would not be ideal as dom nodes
need to be moved around:

<my-datepicker>
  <!-- if desktop screen size -->
  <popup><slot></slot></popup>
  <!-- if mobile screen size (move slot content?) -->
  <dialog></dialog>
</my-datepicker>

[melanierichards]

Thanks for filing this issue and apologies that it's taking some time working through the list!

All of the components you specified would be a good fit for popup, with the exception of tooltip. We think that custom tooltips could warrant their own purpose-built solution/element, because they are a common enough use case that have their own unique semantic needs and interaction model. I would say the most notable point of unique-ness is the content model. Tooltips should only take text contents, owing to the fact that they are used for descriptive text, and any children of tooltips would be inaccessible to keyboard users due to the typical tooltip interaction model. popup, on the other hand, can take fairly arbitrary contents, including interactive elements.

As for the difference between popup and dialog, that is a great question and to our minds the key here is transience. Authors can show multiple dialogs which can be modal, persistent, and non-mutually exclusive (you can show multiple at once). popups are shown one at a time (unless chained in ancestry) and are hidden when a very specific user task is completed (e.g. picking a menu option) or upon light dismiss behaviors (e.g. loss of focus). I would say it's less about positioning, but you're close in that popup is a good element to reach for when build a composited component that has some transient bit that pops up, for example a listbox within a combobox component.

All that being said, your point that multiple coachmarks might be shown at once is a good one. I think that experience could be designed such that only one coachmark is shown at a time, but it's true that some experiences are not designed that way today.

[Yay295]

Regarding tooltips being their own element limited to only text, we basically already have that with the title attribute. The only difference would be in being able to change how it looks, which is more the domain of CSS.

[melanierichards]

@Yay295 yeah, I don't want to be overly prescriptive about the solution for tooltip (hence my slight hand-waving i.e. "own purpose-built solution/element" 😅). CSS seems like the natural tool for styling title tooltips, but TBD on the feasibility of that given how those tooltips are drawn.

[tlouisse]

Thanks for filing this issue and apologies that it's taking some time working through the list!

No problem, I probably shouldn't have made such a long issue ;)

tooltip component

Sounds like a great idea to make a distinct component for this 👍

popup vs dialog

Good to know that all examples above (except for tooltip) can be built with the popup. For some experiences (especially on mobile) a backdrop might come in handy still (like in this example: #445 (comment)).
I think that on desktop all described patterns make sense, on mobile they might be a bit different:

default role

Makes sense to stick to semantics and separate presentation from it.
If I understood this post correctly, all native html should have a default role. Would that be dialog for the popup?

mutual exclusiveness

Sounds like a sensible UX default to make popups mutually exclusive (for coach marks a different solution could be found). Would it still be possible (this is more a design concern) to have multiple popups fading in/out simultaneously?

[tlouisse]

@Yay295 yeah, I don't want to be overly prescriptive about the solution for tooltip (hence my slight hand-waving i.e. "own purpose-built solution/element" 😅). CSS seems like the natural tool for styling title tooltips, but TBD on the feasibility of that given how those tooltips are drawn.

@Yay295
I really like the simplicity/DX of the title attribute indeed.
But what you can't do is add presentational/non interactive html like: <button title="My <b>tooltip</b>">.
Also, I think you should be able to specify whether it should function via aria-labelledby or aria-describedby.

[melanierichards]

Thanks again for filing this, @tlouisse! Closing out this issue, but if there's anything that feels like it's still an open issue please feel free to file one on https://github.com/WICG/open-ui/issues, where we are incubating the popup proposal. Thanks!