Add native `dialog` element support

[tay1orjones]

Context

An initial exploration and delivery of a Dialog component was done a while ago:

• Dialog Component #8826
• feat(react): add dialog component #9496

This experimental work was never exported or shown in storybook but still lives in the codebase. Most of the spec of that work stream was focused on managing focus and handling interactions such as escape closing the dialog.

The current state

Since then, there has been some progress on the native dialog element spec and much of this focus and interaction behavior is now provided natively by browsers.

• https://www.scottohara.me/blog/2023/01/26/use-the-dialog-element.html
• https://www.youtube.com/watch?v=ywtkJkxJsdg
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog
• https://www.makethingsaccessible.com/guides/modal-vs-non-modal-dialogs

Proposal

This issue is to propose considering using the native dialog element in place of the existing implementation that uses the FocusScope primitive.

Depending on what we consider to be "must have" functionality of a Dialog, it might be that the bulk of the requirements might be met by the dialog element. It might be a simple wrapper around that element is all we need.

Pieces solved in #15926

• Evaluate the interaction provided via the native element
• Compare the native implementation to the one we have in the codebase today
• Determine what we may need to provide to consumers in addition to what is provided by default by the browser implementation
• Potentially refactor the implementation to not manage focus via the FocusScope helpers (potentially remove these helpers if they're not being used)

Outstanding items that still need to be made into sub-issues

• Add Dialog and associated refactors/usages/etc. to @carbon/web-components
• Move to stable , work through stable checklist (code, website docs, etc.)
• ...

[mbgower]

Some considerations for the assessment:

• granularity for placing focus when dialog appears (on dialog element, on controls inside dialog)
• effect on scrolling inside dialog, depending on focus placement
• keyboard retention in modal dialog
• naming/title for the dialog

In addition, for the non-modal version of the dialog, the following should be assessed, to discover potential issues meeting WCAG 2.2's Focus Not Obscured (Minimum) requirement as well as other existing requirements and conventions on focus handling, prior point of regard, focus indicators, etc. :

• dismissal mechanisms
• persistence on loss of focus
• positioning in DOM

[tay1orjones]

As part of #14156 @guidari and I tested the native dialog functionality as a potential fix but couldn't get the focus wrap behavior to work at all. I'm not sure if it's behind a flag for now or perhaps chrome/firefox hasn't implemented it yet fully?

Either way I think we're blocked until we can confirm the new native dialog behavior functions as expected in all supported browsers.

[tay1orjones]

We'll also need to evaluate and document how other top layer elements interact with a dialog. Initial assumptions/questions I have:

• Portals will not work as expected. Elements rendered via portals will always render behind the dialog.
• What is the behavior of our Popover (Tooltip, Toggletip, etc) - do these render above or below the native dialog when placed within it?
• Does a Popover with autoAlign work as intended, is it the same as non-autoAlign popovers?
• If an element within the dialog uses the native Popover API, which element sits on top?
• If an element using the native Popover API renders a dialog, which element sits on top?

[lee-chase]

@tay1orjones it would appear that completely trapping focus is not desired. Tabbing to browser/environment controls is desirable, page content controls are blocked.

whatwg/html#8339 (comment)

[lee-chase]

Use of the the native dialog component

https://codepen.io/lee-chase/pen/QWPbRLp/9c8c3f23b42a395dc519839e12f5d647