search

Esri / calcite-design-system

A monorepo containing the packages for Esri's Calcite Design System
https://developers.arcgis.com/calcite-design-system/
Other
281 stars 77 forks source link

Modal - improve user control over fullscreen behavior #6191

Open ashetland opened 1 year ago

ashetland commented 1 year ago

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)

macandcheese commented 1 year ago

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 commented 1 year ago

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

macandcheese commented 1 year ago

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