Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong or mistakable "<dialog> elements are not top-layer" statement in PopoverAPI introduction #31757

Closed
teetotum opened this issue Jan 17, 2024 · 2 comments · Fixed by #31866
Labels
Content:Glossary Glossary entries Content:HTML Hypertext Markup Language docs Content:Performance Web performance docs Content:WebAPI Web API docs needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened.

Comments

@teetotum
Copy link
Contributor

teetotum commented Jan 17, 2024

MDN URL

https://developer.mozilla.org/en-US/docs/Web/API/Popover_API

What specific section or headline is this issue about?

Concepts and usage

What information was incorrect, unhelpful, or incomplete?

[...]although bear in mind that <dialog> elements are not put in the top layer by default[...]

What did you expect to see?

According to the mdn documentation for the <dialog> element dialogs are promoted to the top-layer when visible - so exactly like popovers, and there really is not any difference between popover and dialog with regard to the top-layer usage.
So as far as I understood the quoted section the statement is wrong. (Maybe it was right with regard to an old draft of the spec?)
If I misunderstood the meaning of the quoted part then the wording is misleading and would benefit from rewording.

Do you have any supporting links, references, or citations?

<dialog>s are set to display: none; when hidden and display: block; when shown, as well as being removed from / added to the top layer and the accessibility tree.

Source: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog#animating_dialogs

Do you have anything more you want to share?

No response

MDN metadata

Page report details
@teetotum teetotum added the needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. label Jan 17, 2024
@github-actions github-actions bot added Content:Glossary Glossary entries Content:HTML Hypertext Markup Language docs Content:Performance Web performance docs Content:WebAPI Web API docs labels Jan 17, 2024
@wbamberg
Copy link
Collaborator

@chrisdavidmills , this came from your PR to add docs for the Popover API (#26413), can you remember why we say this? Is it from https://open-ui.org/components/popover.research.explainer/#popover-vs-dialog , which is a little different:

A <div popover=manual> is in the top layer, so it draws on top of other content. The same is not true for a non-modal <dialog>. This is likely the most impactful difference, as it tends to be difficult to ensure that a non-modal <dialog> is painted on top of other page content.

...so it's only non-modal dialogs that are not top-layer, and the spec seems to confirm this (https://html.spec.whatwg.org/multipage/interactive-elements.html#dom-dialog-showmodal, section 8).

WDYT? In general I found "by default" here a bit hard to understand and think we could be more explicit.

@chrisdavidmills
Copy link
Contributor

@wbamberg ha! I couldn't remember what the rationale for this text was, so I decided to create a simple test case — https://test-dialog-toplayer.glitch.me/ — where one button opens the <dialog> with showModal(), and the other opens it with show() (i.e. non-modally).

Sure enough, looking at the Chrome DOM inspector while testing it, I can observe that the modal <dialog> is put in the top layer, while the non-modal one is not.

@teetotum, you're absolutely right, thanks for reporting this. I'll open a PR to fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Content:Glossary Glossary entries Content:HTML Hypertext Markup Language docs Content:Performance Web performance docs Content:WebAPI Web API docs needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants