calcite-design-system icon indicating copy to clipboard operation
calcite-design-system copied to clipboard

Modal - improve user control over fullscreen behavior

Open ashetland opened this issue 2 years ago • 3 comments

Description

Current behavior

Currently, when the viewport is small enough, a Modal 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 Modal's fullscreen behaviors.

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

Acceptance Criteria

  1. Automatic behaviors removed
  2. fullscreen prop always makes Modal 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

Modal

Example Use Case

No response

Esri team

Calcite (design)

ashetland avatar Dec 28 '22 19:12 ashetland

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

macandcheese avatar Jan 05 '23 17:01 macandcheese

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

jcfranco avatar Jan 25 '23 06:01 jcfranco

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

macandcheese avatar Jan 25 '23 06:01 macandcheese