Dialog - improve user control over fullscreen behavior

[ashetland]

Description

Current behavior

Currently, when the viewport is small enough, a Dialog will snap to fullscreen without fullscreen being set. This behavior may be undesired and should be something the developer / designer should be able to define.

Proposed changes

The following proposal would give the developer and designer more control over the component's fullscreen behaviors.

1. Remove the automatic snapping to fullscreen behavior.
2. Setting fullscreen would always make a dialog fullscreen.
3. Add ability for user to define a viewport width at which snapping to fullscreen does occur. If left undefined, dialog would never snap to fullscreen.

Acceptance Criteria

1. Automatic behaviors removed
2. fullscreen prop always makes dialog fullscreen
3. User-definable viewport width for snapping to fullscreen, when desired

Relevant Info

cc @macandcheese, @asangma, @mitc7862, @paulcpederson for thoughts and opinions.

Which Component

Dialog

Example Use Case

No response

Esri team

Calcite (design)

[macandcheese]

Hit close instead of Comment, 😬 whoops.

I’d like to get these in for 1.0 if possible. I’d like to hopefully clarify some of the above:

Fullscreen, when true, always makes a modal fullscreen - should css var for modal height and width override this?

It is proposed that the “snap to full” is removed except when opted into. Should this be a prop, with the same “default widths” snapping to fullscreen as current, as well as support a separate custom width to do this?

“Snapping to full” currently makes the buttons full width when that change occurs. Does this need to be a separate opt-in? “Always fullscreen” will still need a px width at which this swap occurs.

How valuable is having the default s/m/l width with proposed css variables for width / height? Do we need these or a single default with customizability cover those cases?

Please advise on above from a design perspective :) @ashetland @SkyeSeitz

[jcfranco]

@ashetland @macandcheese The referenced PR above is already merged. Is there anything pending for this or can it be marked as installed?

[macandcheese]

No, these would all be additive or breaking changes to make for future enhancements, nothing immediate.

[github-actions]

cc @geospatialem, @brittneytewks

[geospatialem]

This may have visual changes and/or breaking changes implications, adding a spike to determine next steps.

[geospatialem]

Needs re-evaluation/expertise from design with the dialog component addition in 2024, is this still valid, and if so, what is the recommended approach?

[macandcheese]

I think it’s valid, ideally “cover” or “fullscreen” behavior is always opted into by a user and doesn’t occur automatically, which can be unexpected.

Existing widths should probably respond by ensuring a small margin is always present around Dialog, when the viewport is smaller than the content. Apps can opt-in to the cover behavior as needed.

[SkyeSeitz]

Dialog MVP simply matched the behavior of Modal, but I agree - this is still a needed change. The current margin is 32px which can continue to be used instead of automatically snapping to cover.

[github-actions]

cc @geospatialem, @brittneytewks