New feature proposal: Popover API

mfreed7 commented 2 years ago

This is quite related to https://github.com/whatwg/html/issues/6349, which was previously discussed in WHATWG. However, over the course of the last year or so, the OpenUI CG has been working through issues and maturing the proposal with the help of great feedback and brainstorming from both developers and implementers. The latest explainer (https://open-ui.org/components/popup.research.explainer) has changed the shape of the API from a new element (<popup>) to a content attribute (popup), and has changed several of the details, primarily to improve accessibility and broaden the applicability of the API.

Importantly, the OpenUI group resolved that this proposal looks good enough to start prototyping. I have started that process for Chromium.

While there are still many open issues that we're working through, I think the shape of the API is in a good enough shape to bring before WHATWG for implementer interest and (importantly!) input / feedback / guidance. Hence this issue.

For convenience, here are the background and goals sections from the explainer:

Background

There is a need in the Web Platform for an API to create "popup UI". This is a general class of UI that always appear on top of all other content, and have both one-at-a-time and "light-dismiss" behaviors. This document proposes a set of APIs to make this type of UI easy to build.

Goals

Here are the goals for this API:

Allow any* element and its (arbitrary) descendants to be rendered on top of all other content in the host web application.
Include “light dismiss” management functionality, to remove the element/descendants from the top-layer upon certain actions such as hitting Esc (or any close signal) or clicking outside the element bounds.
Allow this “top layer” content to be fully styled, including properties which require compositing with other layers of the host web application (e.g. the box-shadow or backdrop-filter CSS properties).
Allow these top layer elements to reside at semantically-relevant positions in the DOM. I.e. it should not be required to re-parent a top layer element as the last child of the document.body simply to escape ancestor containment and transforms.
Allow this “top layer” content to be sized and positioned to the author's discretion. Include an appropriate user input and focus management experience, with flexibility to modify behaviors such as initial focus.
Accessible by default, with the ability to further extend semantics/behaviors as needed for the author's specific use case.
Avoid developer footguns, such as improper stacking of dialogs and popups, and incorrect accessibility mappings.
Avoid the need for Javascript for the common cases.

annevk commented 2 years ago

I just realized that this naming clashes with window.open()'s popup feature as I initially thought this was about the new API for window.open() that we've been discussing. Perhaps it's enough if we can refer to this as viewport popups or some such, or perhaps we need slightly different name.

mfreed7 commented 2 years ago

Yep, that’s unfortunate. More so because I worked on both of them, and should have thought of this potential confusion earlier. We are anyway bikeshedding the attribute name, so perhaps add your thoughts there?

mfreed7 commented 2 years ago

Ok, per the triage meeting, my action item was to organize and summarize the open issues for Popup. Hopefully this helps:

Behavior:

Bikeshedding:

Documentation / spec:

Resolved, just needs implementation/testing:

https://github.com/openui/open-ui/issues/379

Relationships to other APIs:

Other:

https://github.com/openui/open-ui/issues/312

mfreed7 commented 2 years ago

Quick update on this thread: the feedback from the HTML spec triage meeting on April 7 was that there were too many open issues for Pop-Up, and we should work to resolve them. OpenUI has been hard at work for the last 4 months discussing those issues and proposing ways forward. As of today, the open issues have been reduced to these 7 issues. The complex issues (see bigger list above, or this list of resolved issues) have been discussed at length and resolved (in the OpenUI sense), and the remainder are what I'd consider to be smaller issues. They still need a resolution, but I'm fairly confident we're on a path to that soon.

@josepharhar has been hard at work on a draft spec PR that explains all of the behaviors of the Pop-Up API, as designed and discussed within OpenUI. Stay tuned!

josepharhar commented 2 years ago

I have opened a PR: https://github.com/whatwg/html/pull/8221

mfreed7 commented 2 years ago

I just wanted to give a quick status update:

The HTML spec PR for the Pop-up API is at #8221. We've received some comments, but would really appreciate some good, detailed reviews.
For background and motivation, the best reference would be the explainer, which I've kept up-to-date as this feature has evolved in OpenUI. There is also this recent blog post, which has some nice working examples.
The open issues list remains small, with nothing that I would consider a fundamental or blocking concern.

Generally, we're looking for feedback and input for this feature, to make sure it works as expected, solves the problems it is trying to solve, and plays nicely with the rest of the platform. Thanks in advance!

annevk commented 2 years ago

One problem I noticed is that the spelling conflicts with https://whatwg.org/style-guide. We have popup as a non-hyphenated-all-lowercase word.

The explainer also doesn't cover IDL attributes for the other attributes, such as defaultopen.

josepharhar commented 2 years ago

One problem I noticed is that the spelling conflicts with https://whatwg.org/style-guide. We have popup as a non-hyphenated-all-lowercase word.

I believe "pop-up" was decided here: https://github.com/openui/open-ui/issues/546#issuecomment-1156988124

@domenic do you have any thoughts about the style guide dictionary?

annevk commented 2 years ago

E.g., we spell it allow-popups-to-escape-sandbox not allow-pop-ups-to-escape-sandbox. I think it would be confusing if we did something else here. It's also confusing that it reuses the term to mean something completely different, of course.

domenic commented 2 years ago

I didn't realize we had existing web-developer-exposed uses of the word popups on the web platform. I don't have any guidance on how to resolve that. Maybe go back to my suggestion of a toplayer="" attribute.

annevk commented 2 years ago

@josepharhar the PR isn't really reviewable for me anymore through GitHub's UI. Perhaps you can squash the commits and force push?

Also, if there's some more history around why a CSS property was not the solution for this feature that would be appreciated. The summary seems to be that it would require some scripting and that there's a conflict with dialog and Fullscreen, but not a lot of details around that are provided. And in particular it seems that rendering would end up relying on CSS anyway.

josepharhar commented 2 years ago

the PR isn't really reviewable for me anymore through GitHub's UI. Perhaps you can squash the commits and force push?

I merged with the latest tip of main, how does it look now? I can also squash all the commits into one but then github won't show me what lines all of the previous comments were made on, which is still helpful to me.

Also, if there's some more history around why a CSS property was not the solution for this feature that would be appreciated.

I believe these issues contain discussion about this: https://github.com/w3c/csswg-drafts/issues/6965 https://github.com/openui/open-ui/issues/410 https://github.com/openui/open-ui/issues/417

annevk commented 2 years ago

I strongly suspect some amount of squashing is needed to resolve that, but you don't have to squash all I think.

Thanks for the pointer to the CSS WG issue, I think that explains it best.

https://github.com/w3c/csswg-drafts/issues/7319 also seems relevant here. Left a comment there about naming the pseudo-classes consistently with the API.

mfreed7 commented 2 years ago

Thanks for the pointer to the CSS WG issue, I think that explains it best.

There’s also this whole document that goes through the alternatives considered, including the linked section about a CSS property.

annevk commented 2 years ago

Yeah, that is actually what prompted me to ask for more details. 😊

mfreed7 commented 2 years ago

Yeah, that is actually what prompted me to ask for more details. 😊

Oh ok! Well then I’m glad https://github.com/w3c/csswg-drafts/issues/6965 also helped. Perhaps I should link to that issue from the alternative doc.

josepharhar commented 2 years ago

I strongly suspect some amount of squashing is needed to resolve that, but you don't have to squash all I think.

Ah I see I was able to reproduce the same error. I squashed everything down to one commit and it looks like it is working now!

mfreed7 commented 2 years ago

Yeah, that is actually what prompted me to ask for more details. 😊

Oh ok! Well then I’m glad w3c/csswg-drafts#6965 also helped. Perhaps I should link to that issue from the alternative doc.

https://github.com/openui/open-ui/pull/618

mfreed7 commented 2 years ago

E.g., we spell it allow-popups-to-escape-sandbox not allow-pop-ups-to-escape-sandbox. I think it would be confusing if we did something else here. It's also confusing that it reuses the term to mean something completely different, of course.

So the proposed content attribute is called popup, which would seem to align very well with allow-popups, allow-popups-to-escape-sandbox, and window.open(..,..,"popup"), right? And those are the only three API uses of the word "popup" in the spec, correct? To me at least, all of those feel very natural and consistent, from a developer's point of view. Would you disagree? Is the issue just the prose usage of the word "pop-up"? Or perhaps the capital "U" in the IDL attribute popUp? I'm trying to understand where you think the issue (for the developer) really lies, so we can find an appropriate solution. I don't think renaming to "top-layer" is a solution (for developers) because developers don't know what a "top layer" is. They definitely do know what a "pop-up" or "popup" is. I think picking a slightly different name (e.g. "popover") is also more confusing to developers, since there are then two names for roughly the same concept. Searching for answers becomes harder when there are two words for "things that pop up".

annevk commented 2 years ago

Yeah, the IDL attribute would have to be popup. It still strikes me as somewhat bad to have a feature that conflicts in name so heavily with an already existing feature. E.g., in #7485 window.openPopup() was proposed.

mfreed7 commented 2 years ago

Yeah, the IDL attribute would have to be popup. It still strikes me as somewhat bad to have a feature that conflicts in name so heavily with an already existing feature. E.g., in #7485 window.openPopup() was proposed.

Right - so as I think you know, an IDL attribute called popup (lowercase "u") is not web compatible: https://github.com/openui/open-ui/issues/546

Can you elaborate on why this is "heavy conflict" between popup and popUp and "pop-up"? I.e. I assume you are anticipating some kind of developer confusion around this - would you help me understand what that might be? I.e. the concept is called a "pop-up" (with or without the dash) for developers, and when they go to use this API, they'll invariably start typing "pop" and find what they need pretty quickly. I'd anticipate much greater confusion if they are looking for how to make a "pop-up" and end up finding the attribute called toplayer.

domenic commented 2 years ago

I thought @annevk's concern was not with the hyphen vs. not, but with the idea that "popup" as it is today exposed to web developers, means a new Window object created by window.open() or target=_blank. I had previously thought that we only used the term "popup" for those informally or in spec prose, but he pointed out that we actually use it in exposed APIs.

So indeed, it seems unfortunate if, e.g., sandbox without allow-popups set, still allows popup="" attributes in the sandboxed iframe, due to the fact that popup="" is reusing the term "pop(-)up" for something different than what it's meant in web APIs so far.

annevk commented 2 years ago

Yeah, I think both are problematic.

(I'm also not really sure why you are asking me to defend consistent naming. It's an established principle.)

gregwhitworth commented 2 years ago

(I'm also not really sure why you are asking me to defend consistent naming. It's an established principle.)

Ironically, I think we're hitting an issue where we're all going for consistent naming here, you all with HTML and us with what component libraries and design systems used and voted for.

I'm going to be honest that I don't think there is a good solution here because I see cons in both directions as you all have pointed out in the confusion of allow-popups but popup still works; and Open UI not naming it something that does not align with what devs/designers refer to them as.

@mfreed7 I think it's worth raising this with the group to get discussion going, as noted above these are valid concerns and I think it's worth the group coming to some alignment that takes these specific collisions into account.

mfreed7 commented 2 years ago

Yeah, I think both are problematic.

(I'm also not really sure why you are asking me to defend consistent naming. It's an established principle.)

I'm totally supportive of consistent naming, because it helps developers reason about the platform. It's a good thing when developers can follow a pattern and get good results, and not have to search for the right property or function to use. I'm not supportive of consistent naming just for theoretical purity, if it conflicts with the interests of developers. And we should all acknowledge that there are grey areas where judgement is needed. I believe this is one of them.

Currently, developers call these things "popups" or "pop-ups". They don't call them "top layers". And that applies to things opened by both window.open and the new pop-up API: both are regions of content that "pop up" on top of the other content. Yes, there are differences between them, such as whether they escape iframe bounds or the browser window. But I also don't think they're completely different things, just nuanced versions of the same general idea. Having two names for one general idea sounds confusing to developers.

As for consistent property naming, I don't see a difference between <div popup> and window.open(..,..,"popup") and `. Yes, there is a "u" vs. "U" difference for the JS, which is unfortunate but necessary for web compat. But I don't see how "u" vs. "U" causes developer confusion. Likely consternation, but not confusion.</p> <p>We can, of course, rename the feature. And teach developers to use the new name for <strong>this</strong> kind of pop-up, and the word "popup" for the <strong>other</strong> kind of pop-up. I just want to make sure we're doing it to benefit developers, and not to benefit the purity of the spec. So I asked about the motivation for changing the name.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/gregwhitworth"><img src="https://avatars.githubusercontent.com/u/865244?v=4" />gregwhitworth</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>We can, of course, rename the feature. And teach developers to use the new name for this kind of pop-up, and the word "popup" for the other kind of pop-up. I just want to make sure we're doing it to benefit developers, and not to benefit the purity of the spec. So I asked about the motivation for changing the name.</p> </blockquote> <p>I 100% agree with this sentiment. The Open UI calls are open to anyone; we'll discuss this next week - anyone on this thread is welcome to attend</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/tomayac"><img src="https://avatars.githubusercontent.com/u/145676?v=4" />tomayac</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>See <a href="https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/438">https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/438</a> for the initial naming issue, which then continued over in <a href="https://github.com/openui/open-ui/issues/296">https://github.com/openui/open-ui/issues/296</a>. </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/mfreed7"><img src="https://avatars.githubusercontent.com/u/29559695?v=4" />mfreed7</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>See <a href="https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/438">MicrosoftEdge/MSEdgeExplainers#438</a> for the initial naming issue, which then continued over in <a href="https://github.com/openui/open-ui/issues/296">openui/open-ui#296</a>.</p> </blockquote> <p>Thanks, I meant to post that context.</p> <p>@gregwhitworth has opened <a href="https://github.com/openui/open-ui/issues/627">https://github.com/openui/open-ui/issues/627</a> in OpenUI so we can brainstorm a new name.</p> <p>@annevk I'm really hoping you might have a chance to take a look at the <strong>rest</strong> of this feature (besides the name), to see if there are any other major changes needed. It'd be helpful to the folks testing the feature to have all of the breakages happen at the same time. Not required, of course, it's just a prototype. But immensely helpful.</p> <p>As a pre-check, here's a list of the names we've already discussed for this feature. It's very likely we'll go back to this list to pick a new name. Should any of these be ruled out for spec/conflict reasons?</p> <ul> <li>float</li> <li>floatable</li> <li>popover</li> <li>positioned</li> <li>overlay</li> <li>popout</li> <li>popper</li> </ul> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/mfreed7"><img src="https://avatars.githubusercontent.com/u/29559695?v=4" />mfreed7</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>So the OpenUI just discussed the renaming of this feature. We had some good debate centering on developer understanding of the feature and general ergonomics, and we <a href="https://github.com/openui/open-ui/issues/627#issuecomment-1293918937">resolved to rename the entire feature to <code>popover</code> (one word)</a>.</p> <p>I am going to move forward with the rather large task of renaming everything from <code>popup</code> to <code>popover</code> now, and get the web compat checks started for that new name, which will take several months.</p> <p>I would very much appreciate a few things from the WHATWG here:</p> <ol> <li>Please <strong>speak now</strong> if there's a spec or platform problem with an attribute called <code>popover</code>, and its associated uses (e.g. <code>.showPopover()</code>, <code>popovertoggletarget</code>, <code>popoverhide</code>, etc.). @annevk @domenic </li> <li>With the naming conflict hopefully resolved, please take a look at the <strong>rest</strong> of the feature, and make sure there are no similar major breaking changes that we need to tackle.</li> </ol> <p>Thanks!</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domenic"><img src="https://avatars.githubusercontent.com/u/617481?v=4" />domenic</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Thanks for working on that!</p> <p>My remaining bigger concerns are:</p> <ul> <li> <p>It's weird that <code>defaultopen=""</code> is named generically but only applies to <code>popover=""</code> elements, not e.g. <code><details></code>, <code><dialog></code>, or (perhaps) <code><select></code>. Perhaps it should be called <code>popoverdefaultopen=""</code>.</p> </li> <li> <p>I'm also slightly concerned about the the <code>anchor=""</code> attribute. Although it's not as confusing (versus <code>defaultopen=""</code> which seems like it should be related to existing <code>open=""</code> attributes), perhaps it should be <code>popoveranchor=""</code>.</p> </li> <li> <p>I am pretty concerned about the (ab)use of event listener mechanisms in the spec. This is less likely to result in highly-breaking changes, but might need the most spec work, so let me explain it in more detail.</p> </li> </ul> <p>About event listeners: event listeners are generally meant for use by author code, not other specifications. See e.g. some discussion in <a href="https://github.com/whatwg/html/pull/8382#issuecomment-1279929852">https://github.com/whatwg/html/pull/8382#issuecomment-1279929852</a> about an analogous case. Also note that <code>document.open()</code> will clear all event listeners, which might not be what you want.</p> <p>I don't have any good suggestions though on the correct path, and if I recall correctly @annevk feels more strongly about this sort of events layering issue than I do, so I'd prefer to take any suggestions from him. In other words, I'm just looking for something that meets these requirements:</p> <ul> <li> <p>@annevk is happy</p> </li> <li> <p>There are no weird observable consequences of using the event listener infrastructure. Such as (but not limited to):</p> <ul> <li><code>document.open()</code> breaking all popovers</li> <li>Popover logic executing before some author code and after other author code (e.g. capturing vs. non-capturing listeners)</li> <li>Popover logic being subject to interference with <code>document.onpointerdown = e => e.preventDefault()</code></li> <li>Popover logic being subject to triggering using <code>document.body.dispatchEvent(new PointerEvent("pointerup"))</code> (or perhaps worse, <code>document.body.dispatchEvent(new ProgressEvent("pointerup"))</code>).</li> <li>Popover dismiss logic only being doable using the <kbd>Esc</kbd> key, and not other close signals (compare to how the <code><dialog></code> element <a href="https://html.spec.whatwg.org/#canceling-dialogs">works more generically</a>)</li> </ul> </li> </ul> <p>My brief skim of the current setup in <a href="https://github.com/whatwg/dom/pull/1117">https://github.com/whatwg/dom/pull/1117</a> is that it avoids some of these problems, but not all. Tests for them would also be good, as IIUC Chromium's implementation might be done via actual event listeners, which <em>do</em> hit all of the above problems.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/mfreed7"><img src="https://avatars.githubusercontent.com/u/29559695?v=4" />mfreed7</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>My remaining bigger concerns are:</p> </blockquote> <p>Awesome, thanks for the detailed list!</p> <blockquote> <ul> <li>It's weird that <code>defaultopen=""</code> is named generically but only applies to <code>popover=""</code> elements, not e.g. <code><details></code>, <code><dialog></code>, or (perhaps) <code><select></code>. Perhaps it should be called <code>popoverdefaultopen=""</code>.</li> </ul> </blockquote> <p>So @annevk actually opened <a href="https://github.com/openui/open-ui/issues/500">https://github.com/openui/open-ui/issues/500</a> because he wanted an "easier" name. We ended that discussion resolving on <code>defaultopen</code>. We can re-open it if you feel strongly. Quite a bit of the discussion centered on this being a semi-common pattern, so perhaps another alternative is to generalize <code>defaultopen</code> to apply to more things? Off hand, I don't have specific suggestions though. Basically, let me know what you think (you too, @annevk), and then I can re-open the bikeshed for <code>defaultopen</code> with your input.</p> <blockquote> <ul> <li>I'm also slightly concerned about the the <code>anchor=""</code> attribute. Although it's not as confusing (versus <code>defaultopen=""</code> which seems like it should be related to existing <code>open=""</code> attributes), perhaps it should be <code>popoveranchor=""</code>.</li> </ul> </blockquote> <p>Here, the <code>anchor</code> attribute definitely wants to be general. This is, first and foremost, a hook into the Anchor Positioning feature's <a href="https://tabatkins.github.io/specs/css-anchor-position/#implicit-anchor-elements">implicit anchor element</a> concept. It allows HTML-based connections between the anchored element and the anchor. In the case of popovers, this anchor connection also naturally sets up a relationship between nested popovers. But the attribute, I think, really should be general purpose. Would you agree? If needed, we could split that part out of this PR, but then this PR would be dependent on that one, so I'd hope we could get it landed first.</p> <blockquote> <ul> <li>I am pretty concerned about the (ab)use of event listener mechanisms in the spec. This is less likely to result in highly-breaking changes, but might need the most spec work, so let me explain it in more detail. {...} My brief skim of the current setup in <a href="https://github.com/whatwg/dom/pull/1117">whatwg/dom#1117</a> is that it avoids some of these problems, but not all. Tests for them would also be good, as IIUC Chromium's implementation might be done via actual event listeners, which <em>do</em> hit all of the above problems.</li> </ul> </blockquote> <p>These are definitely all things I'd be concerned about, so I appreciate the detailed input! I'd love to hear more from @annevk in terms of suggestions for improvement. In the meantime, I'll work on adding test cases for the problem scenarios you listed.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domenic"><img src="https://avatars.githubusercontent.com/u/617481?v=4" />domenic</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>So @annevk actually opened <a href="https://github.com/openui/open-ui/issues/500">openui/open-ui#500</a> because he wanted an "easier" name. We ended that discussion resolving on <code>defaultopen</code></p> </blockquote> <p>Well, (a) that discussion was about "initially" vs. "default", not about prefixes; (b) that discussion was for the <code><popup></code> API, not for the attribute-based version.</p> <p>So I would think we should either have <code>defaultopen=""</code> be generic (i.e., apply at least to <code><details></code> and <code><dialog></code> as well, with well-defined interaction with their <code>open=""</code> attributes) or it should be namespaced with a prefix.</p> <blockquote> <p>But the attribute, I think, really should be general purpose. Would you agree? If needed, we could split that part out of this PR, but then this PR would be dependent on that one, so I'd hope we could get it landed first.</p> </blockquote> <p>If things work out like you predict, then keeping it general makes sense. However, what I worry about is a future where CSS anchored positioning evolves away from a HTML attribute-based design, or never ends up shipping, or similar. Then we will be stuck with an <code>anchor=""</code> attribute in the spec, which only applies to popovers.</p> <p>My understanding is that implementation interest and activity is higher for popover than for anchored positioning. If that is correct, I think the ideal sequence would be for popover to be specified (and shipped) with zero interaction with any anchor-related stuff. Then, later, when we have implementation interest and imminent shipping for anchor positioning, we'd send a separate PR to HTML to add it, including modifications to the popover spec.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/mfreed7"><img src="https://avatars.githubusercontent.com/u/29559695?v=4" />mfreed7</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>Well, (a) that discussion was about "initially" vs. "default", not about prefixes; (b) that discussion was for the <code><popup></code> API, not for the attribute-based version.</p> </blockquote> <p>True.</p> <blockquote> <p>So I would think we should either have <code>defaultopen=""</code> be generic (i.e., apply at least to <code><details></code> and <code><dialog></code> as well, with well-defined interaction with their <code>open=""</code> attributes) or it should be namespaced with a prefix.</p> </blockquote> <p>Any preferences? I think mine would be to make <code>defaultopen</code> generic, but how much (spec) work do you think that would be? For now, it sounds like the list of elements is <code><details></code> and <code><dialog></code>, plus the <code>popover</code> attribute. And most of the effort would be defining the timing, which would be good to do for popover anyway. Thoughts?</p> <blockquote> <blockquote> <p>But the attribute, I think, really should be general purpose. Would you agree? If needed, we could split that part out of this PR, but then this PR would be dependent on that one, so I'd hope we could get it landed first.</p> </blockquote> <p>If things work out like you predict, then keeping it general makes sense. However, what I worry about is a future where CSS anchored positioning evolves away from a HTML attribute-based design, or never ends up shipping, or similar. Then we will be stuck with an <code>anchor=""</code> attribute in the spec, which only applies to popovers.</p> <p>My understanding is that implementation interest and activity is higher for popover than for anchored positioning. If that is correct, I think the ideal sequence would be for popover to be specified (and shipped) with zero interaction with any anchor-related stuff. Then, later, when we have implementation interest and imminent shipping for anchor positioning, we'd send a separate PR to HTML to add it, including modifications to the popover spec.</p> </blockquote> <p>I'm definitely ok splitting out <code>anchor</code> from this PR, and landing it as a separate PR for anchor positioning and the tie-in to popover, once <a href="https://drafts4.csswg.org/css-anchor-1/">anchor positioning</a> reaches WD (or CR?). @josepharhar WDYT? Mind pulling <code>anchor</code> out of the PR?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domenic"><img src="https://avatars.githubusercontent.com/u/617481?v=4" />domenic</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>Any preferences? I think mine would be to make <code>defaultopen</code> generic, but how much (spec) work do you think that would be? For now, it sounds like the list of elements is <code><details></code> and <code><dialog></code>, plus the <code>popover</code> attribute. And most of the effort would be defining the timing, which would be good to do for popover anyway. Thoughts?</p> </blockquote> <p>I lean toward making it popover-specific, because I think defining the interaction between <code>open=""</code> and <code>defaultopen=""</code> might be confusing. (E.g., should <code>open=""</code> also work with <code>popover=""</code>? What if <code>defaultopen=""</code> is specified but <code>open=""</code> is not? What about vice-versa?) But if you have a concrete proposal for how they should interact, then maybe it'll work out fine.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/josepharhar"><img src="https://avatars.githubusercontent.com/u/7681467?v=4" />josepharhar</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>In the PR I have renamed from popup to popover and I have removed the anchor attribute</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/mfreed7"><img src="https://avatars.githubusercontent.com/u/29559695?v=4" />mfreed7</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Ok, I've added tests, <a href="https://chromium-review.googlesource.com/c/chromium/src/+/3995612">here in Chromium</a>, soon upstreamed to WPT.</p> <blockquote> <ul> <li><code>document.open()</code> breaking all popovers</li> </ul> </blockquote> <p>Since <code>document.open()</code> wipes out all Nodes, including any potential popovers, I think the only concerns here are implementation ones, like memory leaks. Is there a way to call <code>document.open()</code> without that being the case? Perhaps I'm missing something.</p> <blockquote> <ul> <li>Popover logic executing before some author code and after other author code (e.g. capturing vs. non-capturing listeners)</li> </ul> </blockquote> <p>I added a test that <em>capturing</em> <code>cancel</code>/<code>finish</code> listeners can't re-add another animation and keep the popover waiting. Are there other cases you're worried about?</p> <blockquote> <ul> <li>Popover logic being subject to interference with <code>document.onpointerdown = e => e.preventDefault()</code></li> </ul> </blockquote> <p>I added tests to verify that cancelling <code>pointerdown</code>/<code>pointerup</code>/<code>mousedown</code>/<code>mouseup</code> events doesn't break/prevent light dismiss on click.</p> <blockquote> <ul> <li>Popover logic being subject to triggering using <code>document.body.dispatchEvent(new PointerEvent("pointerup"))</code> (or perhaps worse, <code>document.body.dispatchEvent(new ProgressEvent("pointerup"))</code>).</li> </ul> </blockquote> <p>So this is two things:</p> <ul> <li>Allowing a synthetic <code>pointerup</code> event to trigger light dismiss behaviors. Can you help me understand why we don't want to allow this? It feels convenient for developers. It's easy to disallow it, I just want to understand why.</li> <li>Allowing the <em>wrong</em> event type (e.g. <code>ProgressEvent</code>) from triggering light dismiss. I added a test case for this.</li> </ul> <blockquote> <ul> <li>Popover dismiss logic only being doable using the Esc key, and not other close signals (compare to how the <code><dialog></code> element <a href="https://html.spec.whatwg.org/#canceling-dialogs">works more generically</a>)</li> </ul> </blockquote> <p>So adding tests for this gets tough, right? I.e. <code><dialog></code> is only <a href="https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/html/semantics/interactive-elements/the-dialog-element/dialog-canceling.html;l=48;drc=62f66f54d465f6d0afbcb57eb6068ba97677a0df">tested with ESC</a>, unless I missed a test. There are <a href="https://source.chromium.org/search?q=f:.tentative&sq=&ss=chromium%2Fchromium%2Fsrc:third_party%2Fblink%2Fweb_tests%2Fexternal%2Fwpt%2Fhtml%2Fsemantics%2Finteractive-elements%2Fthe-dialog-element%2F"><code>.tentative</code> tests</a> that test it with CloseWatcher, and I plan to add support for that to popover. But it's not a landed spec, right?</p> <p>If you were suggesting with this point that <a href="https://github.com/whatwg/html/pull/8221/files#diff-41cf6794ba4200b839c53531555f0f3998df4cbb01a4d5cb0b94e3ca5e23947dR82166">the spec PR</a> be changed to make it more like <code><dialog></code>, and leave it "vague" about how the UA does that, I'm ok. But I do think the language should be stronger than <code><dialog></code>: Escape and similar close signals <strong>should always</strong> trigger the light dismiss behavior, vs. "may trigger".</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/mfreed7"><img src="https://avatars.githubusercontent.com/u/29559695?v=4" />mfreed7</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>I lean toward making it popover-specific, because I think defining the interaction between <code>open=""</code> and <code>defaultopen=""</code> might be confusing. (E.g., should <code>open=""</code> also work with <code>popover=""</code>? What if <code>defaultopen=""</code> is specified but <code>open=""</code> is not? What about vice-versa?) But if you have a concrete proposal for how they should interact, then maybe it'll work out fine.</p> </blockquote> <p>Ok, fair enough. There are definitely a number of open questions there, so perhaps this is not the time to open that can of worms. I've opened <a href="https://github.com/openui/open-ui/issues/631">https://github.com/openui/open-ui/issues/631</a> to bikeshed a new name for this attribute.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domenic"><img src="https://avatars.githubusercontent.com/u/617481?v=4" />domenic</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>Since <code>document.open()</code> wipes out all Nodes, including any potential popovers, I think the only concerns here are implementation ones, like memory leaks. Is there a way to call <code>document.open()</code> without that being the case? Perhaps I'm missing something.</p> </blockquote> <p>What I am worried about is using <code>document.open()</code> to wipe out all event listeners, including the one that handles light dismiss behaviors. Then, you add a new <code>popover=""</code> element. And light dismiss fails to work for it.</p> <blockquote> <p>I added a test that <em>capturing</em> <code>cancel</code>/<code>finish</code> listeners can't re-add another animation and keep the popover waiting. Are there other cases you're worried about?</p> </blockquote> <p>I'm worried about the sequence between these three things: non-capturing author listeners, capturing author listeners, and light dismiss behaviors. Light dismiss behaviors should not be between these two; they should be after both, I believe.</p> <blockquote> <ul> <li>Can you help me understand why we don't want to allow this? It feels convenient for developers. It's easy to disallow it, I just want to understand why.</li> </ul> </blockquote> <p>Dispatching events isn't a mechanism for causing things to happen. It's a mechanism for notifying about something that already happened. See <a href="https://dom.spec.whatwg.org/#action-versus-occurrence">https://dom.spec.whatwg.org/#action-versus-occurrence</a> .</p> <blockquote> <p>So adding tests for this gets tough, right? I.e. <code><dialog></code> is only <a href="https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/html/semantics/interactive-elements/the-dialog-element/dialog-canceling.html;l=48;drc=62f66f54d465f6d0afbcb57eb6068ba97677a0df">tested with ESC</a>, unless I missed a test. There are <a href="https://source.chromium.org/search?q=f:.tentative&sq=&ss=chromium%2Fchromium%2Fsrc:third_party%2Fblink%2Fweb_tests%2Fexternal%2Fwpt%2Fhtml%2Fsemantics%2Finteractive-elements%2Fthe-dialog-element%2F"><code>.tentative</code> tests</a> that test it with CloseWatcher, and I plan to add support for that to popover. But it's not a landed spec, right?</p> </blockquote> <p>Yeah, this is more of a spec concern. Note how <code><dialog></code> is <a href="https://html.spec.whatwg.org/#canceling-dialogs">currently specced</a>, which makes no reference to specific keys or input modalities.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/bkardell"><img src="https://avatars.githubusercontent.com/u/870501?v=4" />bkardell</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Before we take this back to openui again, can we just take a beat and be sure that's the right thing to do - or at least be clear as possible about the feedback and parameters? It seems to me that quite a lot of thought and rationale and reflection (and input from several channels) has gone into creating a name/patten that many of us like to use as more generic idea - I <em>believe</em> some recent aria work has even adopted that idea. To me that implies that we'd like consistency (I would!) and it seems like making it specific doesn't do favors to our future selves... it kind of seems to make that goal even harder in my mind. </p> <p>Throughout, it also seems to me @domenic has expressed his concerns on this rather mildly 'I lean slightly' or (in a linked issue) 'I think I'm agnostic.' Yes, there is currently an unxplained disconnect between open as used by two elements and a new concept of default open - but what is the real feedback here? I can kind of interpret this a few ways and it seems silly to keep bouncing between the groups without a clearer set of parameters.</p> <p>Like, It seems to me not <em>that</em> hard to explain the relationship conceptually of defaultopen and open if we needed to. Do we? Would that resolve this? Is it necessary initially? I'm not sure? Are their concepts of 'open' the same enough? Or is it potentially overloading the term in a way that is problematic? Would a new attribute name that was also global but still generic resolve this (<code>initiallyopen</code> was suggested at some point, but <a href="https://github.com/openui/open-ui/issues/500#issuecomment-1095460947">I explained why that pattern is less ideal to me than default</a> if we imagine setting some useful precedent here)? I'm not sure how it would because the relationship to open still seems to apply.</p> <p>Idk, I guess what I am getting at is... can you help us understand some more discrete options/parameters?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/mfreed7"><img src="https://avatars.githubusercontent.com/u/29559695?v=4" />mfreed7</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>What I am worried about is using <code>document.open()</code> to wipe out all event listeners, including the one that handles light dismiss behaviors. Then, you add a new <code>popover=""</code> element. And light dismiss fails to work for it.</p> </blockquote> <p>Ahh, ok. I'll add a test for this. This can't happen with at least the Chromium implementation, since light dismiss isn't actually implemented using event listeners. Perhaps that indicates an issue with how we've written up this part of the spec? <a href="https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/node.cc;l=2891;drc=af07b3e7e43bd39dc707d11c3e32e12606c1d3bb">Here's the Chromium code</a> - light dismiss behavior happens just before events are fired. Is there a more standard way to spec this timing?</p> <blockquote> <p>I'm worried about the sequence between these three things: non-capturing author listeners, capturing author listeners, and light dismiss behaviors. Light dismiss behaviors should not be between these two; they should be after both, I believe.</p> </blockquote> <p>So as implemented, and as desired (I think!), light dismiss behaviors come before event listeners (capturing or non-capturing). This makes them not-developer-cancelable, so that the light dismiss is guaranteed to happen. We discussed this behavior several times, first <a href="https://github.com/openui/open-ui/issues/321#issuecomment-1138893574">resolving</a> that neither show/hide should be cancelable, then <a href="https://github.com/openui/open-ui/issues/579#issuecomment-1219808092">lightening the restriction on show but leaving hide non-cancelable</a>. The concern is that the management of popovers is complex, particularly in nested cases and eventually when <code>popover=hint</code> is added back, and there are too many footguns present if the developer can cancel the hiding of a popover. For the same reasons, it seems to me that light dismiss (another way popovers get hidden) should have the same non-cancelable behavior. Thoughts?</p> <blockquote> <p>Dispatching events isn't a mechanism for causing things to happen. It's a mechanism for notifying about something that already happened. See <a href="https://dom.spec.whatwg.org/#action-versus-occurrence">https://dom.spec.whatwg.org/#action-versus-occurrence</a> .</p> </blockquote> <p>Ahh, thanks for the link. Ok, makes sense to me. I'll modify the behavior to only trigger via trusted events, and add tests for this. @josepharhar we need to add this to the spec PR, probably.</p> <blockquote> <p>Yeah, this is more of a spec concern. Note how <code><dialog></code> is <a href="https://html.spec.whatwg.org/#canceling-dialogs">currently specced</a>, which makes no reference to specific keys or input modalities.</p> </blockquote> <p>Ok, that makes total sense to me. @josepharhar another spec change here.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domenic"><img src="https://avatars.githubusercontent.com/u/617481?v=4" />domenic</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>Ahh, ok. I'll add a test for this. This can't happen with at least the Chromium implementation, since light dismiss isn't actually implemented using event listeners. Perhaps that indicates an issue with how we've written up this part of the spec? <a href="https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/node.cc;l=2891;drc=af07b3e7e43bd39dc707d11c3e32e12606c1d3bb">Here's the Chromium code</a> - light dismiss behavior happens just before events are fired. Is there a more standard way to spec this timing?</p> </blockquote> <p>This looks solid! I think we're on the right track. I believe an earlier version of Joey's spec might have used event listeners, or have used language that an implementer might mistake for being event listener based, so that's what I wanted to guard against. His latest work in <a href="https://github.com/whatwg/dom/pull/1117">https://github.com/whatwg/dom/pull/1117</a> does not use event listeners, and avoids the problem.</p> <blockquote> <p>For the same reasons, it seems to me that light dismiss (another way popovers get hidden) should have the same non-cancelable behavior. Thoughts?</p> </blockquote> <p>Sounds good to me! I should have been clearer I didn't really know whether "before" or "after" was more correct; I was just pretty sure that "in between" was incorrect. If the choice of "before" is deliberate then let's go with that.</p> <p>I'm not fully sure that matches what's specced in <a href="https://whatpr.org/dom/1117/bf5f6c2...f4cef07.html">https://whatpr.org/dom/1117/bf5f6c2...f4cef07.html</a> , in particular the way that the light dismiss call is done as part of a loop implies that there will be a sequence like: light dismiss, capturing, light dismiss, capturing, light dismiss, capturing. But I haven't looked at the details of exactly what that loop is covering...</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/josepharhar"><img src="https://avatars.githubusercontent.com/u/7681467?v=4" />josepharhar</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <blockquote> <blockquote> <blockquote> <p>Popover dismiss logic only being doable using the Esc key, and not other close signals (compare to how the <dialog> element <a href="https://html.spec.whatwg.org/#canceling-dialogs">works more generically</a>)</p> </blockquote> <p>So adding tests for this gets tough, right? I.e. <dialog> is only <a href="https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/html/semantics/interactive-elements/the-dialog-element/dialog-canceling.html;l=48;drc=62f66f54d465f6d0afbcb57eb6068ba97677a0df">tested with ESC</a>, unless I missed a test. There are <a href="https://source.chromium.org/search?q=f:.tentative&sq=&ss=chromium%2Fchromium%2Fsrc:third_party%2Fblink%2Fweb_tests%2Fexternal%2Fwpt%2Fhtml%2Fsemantics%2Finteractive-elements%2Fthe-dialog-element%2F">.tentative tests</a> that test it with CloseWatcher, and I plan to add support for that to popover. But it's not a landed spec, right?</p> </blockquote> <p>Yeah, this is more of a spec concern. Note how <dialog> is <a href="https://html.spec.whatwg.org/#canceling-dialogs">currently specced</a>, which makes no reference to specific keys or input modalities.</p> </blockquote> <p>Ok, that makes total sense to me. @josepharhar another spec change here.</p> </blockquote> <p>So is the idea to replace the entire light dismiss integration/implementation in the spec with some text like <a href="https://html.spec.whatwg.org/multipage/interactive-elements.html#canceling-dialogs">canceling-dialogs</a> that just says something along the lines of "user agents may provide a user interface that, upon activation, closes all open popovers"? (I'm ok with that, just want to make sure - that would also mean getting rid of the DOM PR)</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domenic"><img src="https://avatars.githubusercontent.com/u/617481?v=4" />domenic</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>So is the idea to replace the entire light dismiss integration/implementation in the spec with some text like <a href="https://html.spec.whatwg.org/multipage/interactive-elements.html#canceling-dialogs">canceling-dialogs</a> that just says something along the lines of "user agents may provide a user interface that, upon activation, closes all open popovers"?</p> </blockquote> <p>To be clear, we want to have the triggering condition be vague (for now, until <a href="https://wicg.github.io/close-watcher/#close-signals">https://wicg.github.io/close-watcher/#close-signals</a> gets merged into HTML). But the triggered action needs be detailed and precise. So if "closes all open popovers" is a detailed algorithm, then this sounds like the right track.</p> <blockquote> <p>(I'm ok with that, just want to make sure - that would also mean getting rid of the DOM PR)</p> </blockquote> <p>I wasn't intending that we get rid of all of the DOM PR. Only the Esc key handling portion. I think the pointerup and pointerdown handling is still good as-is.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/josepharhar"><img src="https://avatars.githubusercontent.com/u/7681467?v=4" />josepharhar</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>I wasn't intending that we get rid of all of the DOM PR. Only the Esc key handling portion. I think the pointerup and pointerdown handling is still good as-is.</p> </blockquote> <p>Ok, I replaced the Esc key part with a paragraph modeled after canceling-dialogs. How does it look?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/mfreed7"><img src="https://avatars.githubusercontent.com/u/29559695?v=4" />mfreed7</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <blockquote> <p>I lean toward making it popover-specific, because I think defining the interaction between <code>open=""</code> and <code>defaultopen=""</code> might be confusing. (E.g., should <code>open=""</code> also work with <code>popover=""</code>? What if <code>defaultopen=""</code> is specified but <code>open=""</code> is not? What about vice-versa?) But if you have a concrete proposal for how they should interact, then maybe it'll work out fine.</p> </blockquote> <p>Ok, fair enough. There are definitely a number of open questions there, so perhaps this is not the time to open that can of worms. I've opened <a href="https://github.com/openui/open-ui/issues/631">openui/open-ui#631</a> to bikeshed a new name for this attribute.</p> </blockquote> <p>I just wanted to come back here with the results of <a href="https://github.com/openui/open-ui/issues/631">https://github.com/openui/open-ui/issues/631</a>. We <a href="https://github.com/openui/open-ui/issues/631#issuecomment-1310815390">resolved</a> today to <strong>drop</strong> the <code>defaultopen</code> functionality and attribute entirely. There was fairly strong pushback to something like <code>popoverdefaultopen</code> primarily because it feels like the wrong direction to take the platform. That means anything else that comes along that needs "default open" behavior needs to mint <code>newthingdefaultopen</code> also. The feeling was that the best would be to go back in time and not add <code>open</code> to <code><details></code> and <code><dialog></code> and instead provide <code>defaultopen</code>.</p> <p>Perhand now that we have <code>:open</code> and <code>:closed</code> pseudo classes, most/all of the use cases for the <code>open</code> attribute can be replaced by those pseudo classes and the existing hooks to trigger changes, for <code><dialog></code> and <code><details></code>, and we could think about introducing a generic <code>defaultopen</code> attribute and simultaneously deprecating the <code>open</code> attribute. That would, for example, allow us to remove <a href="https://html.spec.whatwg.org/multipage/interactive-elements.html#the-dialog-element:~:text=Removing%20the%20open%20attribute%20will%20usually%20hide%20the%20dialog">the giant note for <code><dialog></code></a> that basically says "please don't touch the <code>open</code> attribute".</p> <p>This is a long winded way of saying: we're removing <code>defaultopen</code> from this PR. @domenic I'd love to hear your thoughts before I go ahead and open a WHATWG issue to discuss the above.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domenic"><img src="https://avatars.githubusercontent.com/u/617481?v=4" />domenic</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Removing complexity from popover is always welcome to me.</p> <p>I think <code>open</code> on <code><dialog></code> and <code><details></code> are nice. I don't recall all the discussions on why popover did not follow that model, but I don't think we should change them or try to deprecate them. I think we can fix <code>open</code> on <code><dialog></code>; there's an open issue tracking that: <a href="https://github.com/whatwg/html/issues/5802">https://github.com/whatwg/html/issues/5802</a></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/mfreed7"><img src="https://avatars.githubusercontent.com/u/29559695?v=4" />mfreed7</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>I think <code>open</code> on <code><dialog></code> and <code><details></code> are nice. I don't recall all the discussions on why popover did not follow that model, but I don't think we should change them or try to deprecate them. I think we can fix <code>open</code> on <code><dialog></code>; there's an open issue tracking that: #5802</p> </blockquote> <p>So the flavor of issue with Popover is that e.g. <code>popover.remove()</code> for a popover that has descendent nested popovers will trigger the hiding of those nested popovers <em>before</em> the hiding of <code>popover</code>. That would, if <code>open</code> was live, try to remove the <code>open</code> attribute during the Element removal, which seems bad. At least in Chromium, that (along with firing the associated events) <a href="https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/node.h;l=830;drc=0c8d6b8d8321fe0c4203259bbbb6f32406958c0c">is outlawed</a>. If we just leave the <code>open</code> attribute on those disconnected popovers, more weirdness happens when you re-insert them into the document.</p> <p>I see the use case for an "initially open" attribute that shows the dialog or opens the details. That seems to be the predominate use case, right? Can you expand on the use case for needing <code>dialog.setAttribute('open','')</code> to work, vs. requiring <code>dialog.show()</code>? Perhaps there would be a need for a <code>details.toggle()</code> type method, of course, but assuming that was available?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/annevk"><img src="https://avatars.githubusercontent.com/u/1544111?v=4" />annevk</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Did you consider <code>popover=open</code> for initially open?</p> <hr /> <p>For animations, is the primary motivation for tackling them the transition out of the top layer? If that applies more generally to elements transitioning out of the top layer, perhaps the integration should happen there and transitioning out of the top layer should be asynchronous operation? cc @heycam </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/heycam"><img src="https://avatars.githubusercontent.com/u/1484434?v=4" />heycam</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>For animations, is the primary motivation for tackling them the transition out of the top layer? If that applies more generally to elements transitioning out of the top layer, perhaps the integration should happen there and transitioning out of the top layer should be asynchronous operation?</p> </blockquote> <p>Having an explicit API for the author to use to indicate when their animations are done (via providing a Promise?) seems more understandable to me than the automatic capture and comparison of running animations, but you definitely lose the conciseness of just adding a transition on a <code>:open</code> rule.</p> <p>Not being able to use transitions on elements that go from <code>display: none</code> to displayed, and vice versa, seems like a general problem. How do authors solve this now? Should we be trying to solve that generally rather than within popup's show/hide steps?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domenic"><img src="https://avatars.githubusercontent.com/u/617481?v=4" />domenic</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>+1 to a general solution if possible. At least for top layer (i.e., anything done here should work just as well for modal <code><dialog></code> as for popover), but maybe even more generally.</p> </div> </div> <div class="page-bar-simple"> <a href="/whatwg/html/7785?page=2" class="next">Next</a> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>

whatwg / html

New feature proposal: Popover API #7785

Background

Goals