Refactor popover overflow behavior and consolidate parameters

[danielchalmers]

We could change the default to something more expected

[danielchalmers]

Also:

if you open a submenu that just hits the bottom of the viewport, it clips slightly instead of flipping. That's because flip margin is 0. Changing it was a breaking change.

[danielchalmers]

Also:

combine flip margin and contentpadding for popover options

[danielchalmers]

@versile2 Do you think we should go ahead with these changes? We talk about it before but I don't remember the full context, apologies. I think it was mostly about aligning with typical menus like in Edge/Chrome etc

[versile2]

yes, I will need to ask a few questions before I implement. Basically tell me what we want.

Basically: Do we need 2 parameters. FlipMargin should be the amount of pixels between the edge and the popover to say hey I need to flip. OverflowPadding (probably not aptly named) is currently the minimum space between the edge and the popover. Frankly this shouldn't be necessary, but moves popovers from into view leaving a minimum of that padding between the edge of the popover and the edge of the screen. I know this was helpful particularly when we had more prevalent popover problems, I'm not sure how helpful it is now. It's designed to keep a popover in view until the entire popover would be off screen.

Tooltips should not participate in OverflowPadding if we use it is my thought?

What else is there? I will likely have more questions when I go to implement.

[danielchalmers]

I would like to see it "just work (tm)" by using appropriate defaults or consolidating parameters, for example:

• Remove DropdownSettings
  • Keep Fixed per-component and rename to e.g. FixedPopover
  • Move OverflowBehavior to MudGlobal
• Remove FlipMargin and just use OverflowPadding
• Move OverflowPadding to a parameter on MudPopover for full control (a building-block component)
  • Then we can set OverflowPadding=0 on the Tooltip itself.

I think it suffers from excessive customizability at the moment.

[versile2]

ok so I have effectively removed OverflowPadding and FlipMargin from PopoverOptions and added a parameter to MudPopover for OverflowPadding that translates to the mudPopover.js. Just to confirm the plan is to add the OverflowPadding to each component? (Select, Autocomplete, Menu?) obviously for tooltip it's 0 (I just don't add the parameter and it defaults to 0).

I'll also wait to submit this PR until the other one is merged since I need to modify Docs to include it.

Link to my current changes: https://github.com/versile2/MudBlazor/tree/popover/combine_consolidate_overflowpadding_flipmargin

[versile2]

My current branch added logic to prevent left/right movement when it's inside a MudSelect/Autocomplete/Menu (they are all mudlist on the outside). It also added logic for right shift in other situations. Left top shift like it is, and auto scroll for lists longer than the entire screen like they are now. All of these rely on OverflowPadding for the basis, which can be set on the Popover or left null (for 0)

@danielchalmers

[danielchalmers]

Just to confirm the plan is to add the OverflowPadding to each component? (Select, Autocomplete, Menu?)

An internal OverflowPadding is probably appropriate but not exposed to the public API for now to keep it simpler unless we have to change that later

I was curious if it would work if we deleted OverflowBehavior from each one too and solely used the MudGlobal value. For the sake of reducing the number of properties.

Do you think going in that direction (of eliminating individual configuration) would be a good idea?