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

Preview Give feedback

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

Explore using native Dialog within the system

Preview Give feedback

1. Refactor Modal to use native dialog behind a feature flag #17086
   role: dev 🤖 type: enhancement 💡 type: infrastructure 🤖 +3
2. Export <Dialog> as experimental #18243
   +0
3. Move to stable , work through stable checklist (code, website docs, etc.)
4. Add Dialog and associated refactors/usages/etc. to @carbon/web-components
5. Evaluate how dialog fits into the system - It's a primitive, no styling. How do people know when to use it. When would i use dialog over popover. Why would i use modal dialog over the actual modal component?
6. ...

[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

[lee-chase]

Unfortunately the transition behavior to allow-discrete is not well supported and would need script

https://caniuse.com/?search=transition-behavior

[lee-chase]

Experimented and created this based on the native dialog.
#15926

[tay1orjones]

I've updated this issue with continued direction now that the initial exploration has been merged in. Logical next step would be to refactor modal behind a feature flag to use Dialog

Unfortunately the transition behavior to allow-discrete is not well supported and would need script

In #15926 we landed on not trying to polyfill this. Since it doesn't break anything other than the animation, we can consider it a case of progressive enhancement. It works in chrome/edge now and should work in safari this fall since it's already in the TP. Firefox users just won't see the animation until it's implemented there.

[sstrubberg]

Testing, VRT
Rollout strategy
Flags
Modal, Composed Modal
Tearsheets, Side Panels(?), NotificationsPanel, Interstitial, TagSet.
Stacking in Tearsheets makes more sense in Dialogs than in Modals.
Check in with @lee-chase

Might need design to weigh in: method by with we animate the modal in and out.