What is the interaction between popup and other top layer elements

@emilio

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.

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?

@tbondwilkinson

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:

Allow <dialog popup>.
Allow dialog.showPopUp() in this case.
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?

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.

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.

@domenic

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.

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):

Call dialog.close() or document.exitFullscreen() when popup is added to that element.
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.

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.

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

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:

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.
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?

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!

Modify the UA stylesheet to allow `<dialog popup>`

Bug 1788307 [wpt PR 35652] - Modify the UA stylesheet to allow `<dial…

Yeah but perhaps this does make a good case for a shared pseudoclass that applies to both dialog AND popup, so you can just have styling for the one pseudoclass rather than having to style dialog and popup separately and then have them refer to one another.

Yeah, I think I am starting to agree. In fact, perhaps the cleanest/best way to do this would be to propose two pseudo classes:

:open - applies to:
- pop-ups that are fully showing (not in the transition state)
- dialogs that are shown or shown modally (plus other stuff).
- open <details>, etc.
:closed - applies to:
- pop-ups that are fully hidden (not in the transition state)
- dialogs that are closed.
- closed <details>, etc.

That addresses people's desire to have opposing pseudos, plus it allows for the transitional pop-up state to be selected with [popup]:not(:open,:closed) which is nice.

I've Agenda+'d the CSSWG issue about :open which also contains the suggestion to add :closed.

Note that the other part of this issue, described in this comment, is still pending discussion/resolution. We have decided to allow <dialog popup> and the same for fullscreen, but we need to work out the behavior in the corner case that the developer does "both". Console warnings, throw exceptions, do nothing, etc.?

The Open UI Community Group just discussed [Popup] What is the interaction between popup and other top layer elements #520, and agreed to the following:

RESOLVED: <dialog popup> and <div popup>.requestFullscreen() are supported. If one API is "in use" (e.g. dialog.showModal()), a call to the other API (e.g. dialog.showPopUp()) will throw an exception. Declarative invocations will issue a console warning, and will not do anything.

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: we discussed this one a few times…what happens when you have a combination of things in the top layer, like a modal layer with a popup attribute, or something full screen
<scotto> q+
<hdv> masonf: Last time the tone of the conversation was pretty much that we want to solve these things… there were several issues here resolved. The main question that is left is @@@
<bkardell_> q+
<scottkellum> q+
<hdv> masonf: option one: if you call showpopup it becomes a popup and calling showmodal after would throw an error, and the other way around. Option two would be that there is some kind of order in which one takes precedence
<hdv> masonf: there are some edge cases, like when you open using a declarative button and through JS at the same time
<hdv> scotto: I thought it was resolved that modal dialogs cannot be a popup?
<hdv> masonf: if you do dialog.showModal() it becomes a modal… if you then run dialog.showPopup, you shouldn't be able to then convert it ?
<JonathanNeal> ack scotto
<hdv> masonf: dialog.show() is not a modal, just a dialog that shows, dialog.showModal() is
<hdv> scotto: I think there's a case for dialogs that are not modal but do want to be light dismissable
<hdv> scotto: to your question… I think modal always wins, because that's pretty heavy semantics
<hdv> masonf: so your vote is if you call dialog.showPopup() you have a popup, if you then call dialog.showModal(), it closes and reopens modally?
<hdv> scotto: yes that's quite a strong indication semantically I would say
<hdv> scotto: if modal is called that should be respected, if not, could be problematic
<hdv> masonf: I do consider it a site bug though if you do both, seems to me like as an author you're undecided there
<hdv> scotto: I can see that… probably want to throw a console warning too for that
<JonathanNeal> q?
<hdv> scotto: but right now I feel if something is declared as modal that is something to respect… thinking about use cases but not sure
<JonathanNeal> ack bkardell_
<hdv> bkardell_: if I understand what you're saying… if you have some thing that can trigger manually…if you call showPopup, it shows in the top layer as a popup. If you then call hidePopup and then showDialog that is fine?
<hdv> masonf: yes
<hdv> bkardell_: the second is when user clicks a button that has popuptoggletarget, would that put the popup in the top layer?
<hdv> masonf: yes
<hdv> bkardell_: I know we've been saying there are blurry lines between when something is a dialog vs a popup… it feels weird?
<hdv> bkardell_: so you could have a dialog element that you can make a popup?
<hdv> masonf: there are two things: semantically you're saying it is a dialog. You want a list of options to be presented to the users. Then there's behavior: how is it presented (on top of all other things, or not)
<hdv> masonf: the reason people would make something a dialog, they would have something that is like a dialog… but a modalless dialog today isn't great today, because things like clicking outside of it don't work with it… with popup attr they could add such behaviors if they want it
<hdv> bkardell_: then what is a modalless dialog and why is it not in the top layer? feels like most people would want it to be in the top layer and have most of those behaviors?
<hdv> masonf: in my view… we probably could deprecate the modalless dialog, because it is pretty useless. And you can't animate it, and there's other behaviors you can't do with it. But that's all separate from the fact that what you put in there, it is a dialog
<JonathanNeal> ack scottkellum
<hdv> scottkellum: are we talking about the interplay between modals and popups? or if multiple popups are called is it also an issue to resolve what takes precedence?
<hdv> masonf: just the first things. Multiple popups are handled by the spec pretty well. It is just the interplay between dialog and fullscreen elements on the one hand, and popup behavior on the other
<masonf> q?
<masonf> Proposed resolution: <dialog popup> and <div popup>.requestFullscreen() are supported. If one API is "in use" (e.g. dialog.showModal()), a call to the other API (e.g. dialog.showPopUp()) will throw an exception. Declarative invocations will issue a console warning, and will not do anything.
<bkardell_> q+
<hdv> masonf: so in this resolution I've put the 'option one' (first come, first served)
<hdv> JonathanNeal: isn't there a certain one that people would want to win?
<JonathanNeal> q?
<hdv> scotto: if for implementation reasons, first come first served is easier, I can understand it as well. But I have slight preference for option two, giving precedence to one, and make that showModal, because showModal is a strong indication
<hdv> scotto: but yeah, we could also throw an error in the console
<hdv> bkardell_: this had me thinking about that dialogs have this `open` attribute… could you end up with a situation where you have two declarative forms that disagree? like the dialog is open in markup, and you have the toggle, should that throw? it looks like in the spec they throw an invalid state when you throw open on a dialog that is already shown
<JonathanNeal> q?
<JonathanNeal> ack bkardell_
<hdv> bkardell_: is the proposal to just do that?
<JonathanNeal> tantek: it was so great to have these discussions with you again.
<JonathanNeal> thank you for joining!
<hdv> bkardell_: there is this concept of openness, and when it is already open, sorry, it is already open
<hdv> masonf: yes that would be my proposal, like first come first served
<bkardell_> that sounds good to me then
<bkardell_> +1
<hdv> q?
<hdv> JonathanNeal: any concerns on the proposal?
<hdv> bkardell_: I like it
<sarahhigley_> +1
<hdv> +1 to proposed (not strongly; but seems like an author problem)
<hdv> bkardell_: what if you have open and defaultopen at the same time… like you want them to toggle but it is also open by default?
<hdv> masonf: it can't throw, that would be a parser behavior… would have to decide, haven't thought about that
<JonathanNeal> I would also back +1. A bit foggy on the nitty gritty, but it feels generally helpful.
<JonathanNeal> +1 from me
<JonathanNeal> q?
<hdv> JonathanNeal: any objections? I'm seeing more of a consensus now
<masonf> RESOLVED: <dialog popup> and <div popup>.requestFullscreen() are supported. If one API is "in use" (e.g. dialog.showModal()), a call to the other API (e.g. dialog.showPopUp()) will throw an exception. Declarative invocations will issue a console warning, and will not do anything.
<bkardell_> to be clear I think there are two questions masonf - I wasn't thinking of the one you said exactly
<bkardell_> I was thinking you had a popuptoggletarget='foo' and a `<dialog id="foo" open>`
<hdv> Zakim, end meeting
<Zakim> As of this point the attendees have been masonf, JonathanNeal, hdv, dandclark, tbondwilkinson, chrishtr, dbaron, scotto, tantek, scottkellum, sarahhigley_, BrianKardell, bkardell_
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/10/06-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, hdv; please remember to excuse RRSAgent. Goodbye
<masonf> bkardell: I realized one thing about <dialog open> - that's just visible, but not in the top layer. So I think it's actually
<masonf> ok to do <dialog open popup defaultopen>
<bkardell_> eek
<masonf> That would be made top-layer as a pop-up. It still wears 'open' so it's an "open dialog" but that's ok too.
<masonf> And yeah eek is right.
<bkardell_> cool but also eek
<masonf> Thanks for the convo today
<bkardell_> `<dialog no-really-the-thing-iexpected-it-to-do-please open defaultopen please halp toplayer ohgod>`
<bkardell_> :-p
<bkardell_> in any case, that's a lot of characters but at least it is a nice decalative way to achive the thing some people will want without js
<bkardell_> so maybe that's actually a iwn
<bkardell_> win, even
<hdv> this has been extremely interesting
<hdv> I wrote a loong blog post draft last week on what the difference is between dialogs, modals and popups, and learned a few things today :-) thanks all
<masonf> topic

Thanks for the good discussion!

I've Agenda+'d the CSSWG issue about :open which also contains the suggestion to add :closed.

Quick note that CSSWG resolved to add :open and :closed, so I think we're good there.

Disallow "combined" top layer APIs

Bug 1800158 [wpt PR 36918] - Disallow "combined" top layer APIs, a=te…

Navigation Menu

Repository navigation

What is the interaction between popup and other top layer elements #520

8 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

What is the interaction between popup and other top layer elements #520

Description

Activity

mfreed7 commented on May 16, 2022

mfreed7 commented on Aug 22, 2022

tbondwilkinson commented on Aug 22, 2022

scottaohara commented on Aug 22, 2022

mfreed7 commented on Aug 23, 2022

domenic commented on Aug 23, 2022

mfreed7 commented on Aug 23, 2022

tbondwilkinson commented on Aug 23, 2022

css-meeting-bot commented on Aug 25, 2022

mfreed7 commented on Aug 25, 2022

mfreed7 commented on Aug 26, 2022

8 remaining items

mfreed7 commented on Sep 6, 2022

mfreed7 commented on Oct 5, 2022

css-meeting-bot commented on Oct 6, 2022

mfreed7 commented on Oct 6, 2022

mfreed7 commented on Oct 12, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions