What is the interaction between popup and other top layer elements

[mfreed7]

This was raised by @emilio as part of the discussion of #470. We need to fully define the interactions between top layer element types. What happens when a popup is showing and a modal dialog is opened? What happens if you call .showPopup() on an already-modal <dialog>? What about a closed <dialog>? What if you want to open a tooltip (via Popup) on top of a fullscreen element?

We need to carefully consider these interactions and specify them.

[mfreed7]

Proposal:

• Allow showPopup() to "work" on any element type, with only the exceptions below.

• Do not allow showPopup() for an already-modal <dialog> element. So:

  const dialog = document.body.appendChild(document.createElement('dialog'));
  dialog.showModal(); // Modal dialog shows
  dialog.showPopup(); // Throws exception

• Do not allow showPopup() for a fullscreen element. E.g.:

  const div = document.body.appendChild(document.createElement('div'));
  div.requestFullscreen()   // Div goes fullscreen
      .then(() => div.showPopup()); // Throws exception

Note that the above would allow dialog.showPopup() to work if it wasn't already modal. This is intentional: it might be a desired UI pattern to show something that is semantically role="dialog", but that exhibits light dismiss behaviors. Note that this also allows something like dialog.show(); dialog.showPopup();, which will first show a non-modal dialog, and then move it to the top layer with showPopup(). In this case, it'll wear the open attribute from the .show() call.

In addition to these exceptions, as already stated in the explainer, an already-displayed popup will be hidden if a modal dialog is opened or an element goes fullscreen.

I also think it should be perfectly allowed to open a nested popup on top of an already-open modal <dialog> or fullscreen element. That sounds logical, since you might want e.g. a tooltip or a select-menu within a dialog or fullscreen experience.

Thoughts? Objections?

[mfreed7]

On #581, @tbondwilkinson points out that this seems like a big footgun:

<dialog popup>

<script>
const dialog = document.querySelector('dialog[popup]');
dialog.showModal(); // What? But it is, or can be, a non-modal pop-up also.
</script>

The proposal is:

1. Allow <dialog popup>.
2. Allow dialog.showPopUp() in this case.
3. Throw a NotSupported exception for dialog.showModal() in this case.

A question arises: what happens if the popup attribute is added to an already-modal <dialog> element? I would think we'd want to .close() the <dialog> but that feels a bit odd. Thoughts?

For fullscreen elements, would we want to do the same thing? Throw an exception (or rather reject the promise I guess) if requestFullscreen() is called on an element with the popup attribute? This is a bit different from modal dialogs, so we could alternatively stick by my suggestion above, to throw an exception if .showPopUp() is called on an already-fullscreen element.

Thoughts, overall?

[tbondwilkinson]

Is there any precedent for throwing an error if you set an attribute in a way that is incompatible with how that element is behaving? It does seem like setAttribute can throw.... I think ideally setting popup on an already-modal <dialog> should not set the attribute and throw. close feels weird since it seems like we should tell the page they requested some combination of controls that isn't sensible or supported?

I do feel like requestFullscreen() has the same general problem here, in that you wouldn't want something to be displaying as a fullscreen root AND attributed with popup.

[scottaohara]

A question arises: what happens if the popup attribute is added to an already-modal element? I would think we'd want to .close() the but that feels a bit odd. Thoughts?

i actually like this idea, but that's because I like the idea of making developers immediately aware that something they've done is invalid, and causing an unwanted outcome helps drive that home :) HTML's permissiveness in mitigating author error has often allowed for content to render, but not in an entirely accessible manner. More overt "breakages" that are visually obvious will mean that people don't just assume "things are fine". In other words, if it's going to cause a problem, it should cause a problem for everyone.

however, i understand that this is not a "popular" idea. In which case if a dialog has already been set to render as modal, then popup should be disregarded outright.

The fullscreen use case is rather interesting.... because while the content beneath a full screen element should be considered inert - effectively making the element 'modal' - it's not like a modal dialog where one might be able see the content 'beneath' the full screen element. I could potentially see a use case where someone wants an element to be popup for common use, but allow for a full screen option, allowing the popup to 'graduate' to fullscreen status.

[mfreed7]

Is there any precedent for throwing an error if you set an attribute in a way that is incompatible with how that element is behaving? It does seem like setAttribute can throw.... I think ideally setting popup on an already-modal <dialog> should not set the attribute and throw. close feels weird since it seems like we should tell the page they requested some combination of controls that isn't sensible or supported?

Interesting idea, I'm not sure if there's a precedent for making setAttribute throw in a way similar to this. @domenic ?

i actually like this idea, but that's because I like the idea of making developers immediately aware that something they've done is invalid, and causing an unwanted outcome helps drive that home :) HTML's permissiveness in mitigating author error has often allowed for content to render, but not in an entirely accessible manner. More overt "breakages" that are visually obvious will mean that people don't just assume "things are fine". In other words, if it's going to cause a problem, it should cause a problem for everyone.

I agree, within the confines of "normal" for the web. Since the proposal here is to throw an exception in some circumstances, and since exceptions are very descriptive, I'd say this is a well established way to "break" bad behavior.

I could potentially see a use case where someone wants an element to be popup for common use, but allow for a full screen option, allowing the popup to 'graduate' to fullscreen status.

I agree that sounds like a potential use case. But in that rather corner case, do you think it'd be ok for the developer to have to do just a bit of extra work:

popUp.removeAttribute('popup');
popUp.requestFullscreen();

? That will ensure it's an intentional behavioral choice, and not an accident that someone made a pop-up also fullscreen.

The fullscreen use case is rather interesting.... because while the content beneath a full screen element should be considered inert - effectively making the element 'modal' - it's not like a modal dialog where one might be able see the content 'beneath' the full screen element.

So you can indeed make the content underneath a fullscreen element visible with ::backdrop {background-color:transparent;}, but you can't make it interactive, since fullscreen makes the page inert (at least in some browsers).

[domenic]

Interesting idea, I'm not sure if there's a precedent for making setAttribute throw in a way similar to this. @domenic ?

No precedent. HTML elements need to be able to deal with any combination of attribute values and states, usually with some sort of invalid default behavior. Recall that the parser can also set attributes, and that can't throw in most cases.

[mfreed7]

No precedent. HTML elements need to be able to deal with any combination of attribute values and states, usually with some sort of invalid default behavior. Recall that the parser can also set attributes, and that can't throw in most cases.

Ok, thanks. That's what I expected to hear. And yeah, of course we can't throw from the parser, so that's a bad corner case.

I think we're down to two ways to "disallow" this case (adding popup to an already-modal <dialog> or an already-fullscreen element):

1. Call dialog.close() or document.exitFullscreen() when popup is added to that element.
2. Allow the attribute to be added, but disallow (via exception) calling .showPopUp(). There's also the case that an invoking attribute (e.g. popuptoggletarget) points to the <dialog popup> or <div id=fullscreen popup>. That can't throw an exception, so it'd have to just (at worst) console warn and not show the pop-up.

I'm inclined to think #1 is cleaner, but neither are terribly nice. Important to remember, though, that this is quite the corner case.

[tbondwilkinson]

Maybe the cleanest way to approach this is to establish a precedence among behaviors here. Maybe we propose that popup is a higher precedence than fullscreen or dialog, so you cannot display anything with a popup attribute modally using fullscreen or dialog. That means that choice #1 is correct, since as soon as you attribute something as a popup, it starts behaving as a popup and not as whatever else it's currently being shown as.

[css-meeting-bot]

The Open UI Community Group just discussed [popup] What is the interaction between popup and other top layer elements #520.

The full IRC log of that discussion

<hdv> Topic: [popup] What is the interaction between popup and other top layer elements #520
<hdv> github: https://github.com//issues/520
<hdv> masonf: this issue applies to dialog and popup… the proposal needs to allow the dialog to be used together with popups
<hdv> masonf: so for instance a dialog that wants to use behaviors that are provided by the popup API, like light dismiss
<JonathanNeal> q+
<hdv> masonf: the proposal is to allow that, and to avoid confusion and a11y issues, you outlaw the otehr APIs when you call showModal on popup, it would warn you that that's something you can't do
<hdv> masonf: or when you call the full screen API it would reject the promise
<JonathanNeal> q?
<hdv> ack JonathanNeal
<vmpstr> q+
<hdv> JonathanNeal: I would agree to worry about the prop at a later time and focus on the attribute for now
<hdv> ack vm
<masonf> That's pronounced "vampster"
<emilio> q+
<hdv> vmpstr: I'm a little worried about the behavior when it comes to existing sites… when you are full screen and somebody decides to add a popup to it… would that not break? is that a valid case or not?
<hdv> masonf: I do think that's a concern to think about… it's a bit like when you add a popup attribute to an element, it becomes `display: none`, which is also a worry
<hdv> masonf: the spec says you cannot add your own invented attributes that don't contain a dash… but yeah if people do it it would break things
<JonathanNeal> q?
<hdv> vmpstr: making this API such that it throws an exception because something has an attribute, was my concern
<hdv> masonf: ah so it's not a web compat concern, more of a development concern?
<hdv> vmpstr: yes
<hdv> masonf: that's kind of the point of throwing the exception… to warn developers to do something that is not good, that would really not work, we should let folks know
<hdv> emilio: given you kind of need to deal with that already, dynamically… the decision of throwing is not bad, but I feel we need to do with it in other ways… I'm not objecting but wanted to point that out
<hdv> emilio: using the popup attribute makes something `display: none`… makes me worry if it is done with `!important`
<scotto__> q+
<hdv> masonf: the consensus right now seems to be, and this is in a different issue, to remove that `!important`
<JonathanNeal> q?
<JonathanNeal> ack emilio
<hdv> masonf: feel free to propose a way to deal with it in a good way… we don't have many proposals now
<hdv> ack scott
<hdv> scotto__: another idea… what are the concerns with mixed states with the popup being light dismiss, that someone couldn't tab away from what should have been a modal dialog… I'm curious if… as long as the full screen item still covers the content underneath it, the content should be hidden from the accessibility tree… so it still defaults to modal… but wanting to have light dismiss on that, could that be allowed?
<hdv> scotto__: so people still can't get to the content outside of it with AT… I wonder if we need to merge the two without causing a conflict?
<JonathanNeal> If a warning is possible at this step, I would back that proposal, too.
<hdv> masonf: instead of throwing an exception we could issue a warning that lets the author know they've done something wrong, without throwing an exception… to the second point… if you have a dialog that is modal it has gotten that way by author calling showModal(), removing that would be a whole can of worms probably
<hdv> scotto__: I understand that… is someone declares something as modal it should be modal, not kind -of-modal
<JonathanNeal> q?
<hdv> scotto__: so good to default to the modal behavior and remove the popup behavior
<hdv> JonathanNeal: do you have a resolution you want to go for or discuss it a bit further, masonf ?
<hdv> masonf: my resolution would be to throw an error… I wonder if people would object to that?
<hdv> scotto__: there's a lot of cases where people could add dynamic attributes to content when it breaks things… easy to make elements into a Frankenstein monster… 
<hdv> vmpstr: if you throw the warning, would the full screen still behave in the same way as it normally would?
<hdv> scotto__: my thought is that a modal dialog in full screen would remain to behave the way it should
<hdv> masonf: there would still be a UA stylesheet rule that makes it hidden when it has the attribute but is not open… there's a couple of that kind of things that we would need to deal with
<hdv> masonf: or what if it is triggered by a button?
<hdv> masonf: I think it should be outlawed in _some_ appropriate way to use those two APIs at the same time
<JonathanNeal> q?
<hdv> JonathanNeal: I would say that…  I find both reasonable… is it fair to say there is still time to adjust this if this is a serious thing to U-turn on? or is this something that if we do it now, it is really locked in?
<hdv> masonf: I hope/think they are corner cases
<JonathanNeal> I support either proposal.
<hdv> masonf: we could probably change them later
<vmpstr> i support outlawing both at the same time, it's just a question of which takes priority

[mfreed7]

So from the conversation just now, it sounds like there's rough consensus that it might be "ok" to allow a <dialog> or fullscreen element to also have the popup attribute, even while modal/fullscreen. Perhaps this should generate a console warning, to notify the developer that they should likely choose one or the other.

However, there is then the question of which API takes precedence, in case the developer tries to "use" both APIs at the same time. For example:

<dialog popup id=foo>I'm a pop-up and a dialog</dialog>
<button popuptoggletarget=foo>Activation button</button>

<script>
  const dialog = document.querySelector('dialog[popup]');
  const button = document.querySelector('button');

  dialog.showModal(); // First show modal dialog
  dialog.showPopUp(); // Case 1. pop-up after modal
  button.click();     // Case 2. pop-up activated by triggering element  
  dialog.close();     // Reset

  dialog.showPopUp(); // First show pop-up
  dialog.showModal(); // Case 3. modal after pop-up
  dialog.hidePopUp(); // Reset
</script>

There are three points that I can see where something needs to be done. For Case 1 and Case 3, there would seem to be two ways to think about it:

1. First come first served. If the element is already modal, throw an exception when .showPopUp() is called. If the element is already a pop-up, throw an exception when .showModal() is called.
2. Decide that one API takes precedence over the other. In that case, we've been advocating that <dialog> and fullscreen have higher precedence than pop-up: when either of those APIs opens, the explainer says that all pop-ups should be force-closed. So that would mean Case 1 would throw an exception ("element is already modal") or perhaps just not be shown (?), while Case 3 would have the element first hide (because a modal dialog is about to show) and then be shown again as a modal dialog.

Of these two, the first come first serve approach seems easier to follow, at least to me. Thoughts appreciated.

Another question arises for Case 2. There, an exception cannot be thrown, so I think the only option would be to issue a console warning, and not do anything to the modal <dialog popup>. Are there other ideas?

I think whatever answers we arrive at for <dialog> above should be applied in exactly the same way to the fullscreen API. Unless people see important differences?

[mfreed7]

One other side-point. The UA stylesheet has two separate rules that apply display:none to non-showing pop-ups and non-open <dialog>s:

dialog:not([open]) {
    display: none;
}
/* See https://github.com/openui/open-ui/issues/561 */
[popup]:{spec language for "is hidden"} {
  display: none;
}

Those rules will need to be modified to know about each other, otherwise one of them will always be in effect and the <dialog popup> will stay hidden always. That would mean something like this:

dialog:not([open],[popup]:{spec language for "is *NOT* hidden"}) {
  display:none;
}
[popup]:{spec language for "is hidden"}:not(dialog[open]) {
  display:none;
}

Surely there must be a better way to write/do that. CSS folks, help me!