Question: Top and Bottom padding for flyouts - can it be removed?

[mdtauk]

All flyout menus have uneven padding at the top and bottom, compared to the sides. Why is this the case, and should it be removed so menu items will be flush with the edges of the flyout - or at least even padding on all edges?

Adding the rounded corners may be an opportunity to reconsider this design choice, as similar menu controls in other Microsoft UI frameworks don't do this.

FastDNA Dropdown and ComboBox

Fabric Web ComboBox and ContextualMenu

Office UWP XAML

[chigy]

Checking with our design team.

[chigy]

In theory, we agree with the question that we probably don't need these added padding anymore with changes happening with the visuals. That said, in practice, there could be a consequence by doing so, one question I have is if it would look nice with the focus rect. And this is not a priority so we will address it when we have a chance. I'll add this to the visual change backlog.

[mdtauk]

@chigy the Xbox shell already had a focus visual that extends beyond the bounds of the control. I think there is precedence there

[chigy]

@chigy the Xbox shell already had a focus visual that extends beyond the bounds of the control. I think there is precedence there

@mdtauk , can you point out where this is seen?

[mdtauk]

@chigy the Xbox shell already had a focus visual that extends beyond the bounds of the control. I think there is precedence there

@mdtauk , can you point out where this is seen?

I added some lines to this screenshot. You see the controls are lined up, and the Focus Visual appears around the outside of the control

[chigy]

@mdtauk , thank you!

What you are showing, though, the focus rect is still flesh with the control border so they do not leave gaps whereas if we have a focus rect on flyout without the padding, there's going to be some gap between the flyout and focus rect.

Talked with the design team and maybe it is not bad given the rounded corner is subtle but will have to look at what happens. This is part of the reason we are guiding not to use too big of a rounded corner.

[mdtauk]

I don't think the focus rect looks too bad extending outside of the Flyout

[chigy]

I don't think the focus rect looks too bad extending outside of the Flyout

@mdtauk , you missed the one in question. Please put the focus on the item that is actually rounded... Also, we draw focus rect inside, not outside of the menus.

[mdtauk]

I don't think the focus rect looks too bad extending outside of the Flyout

@mdtauk , you missed the one in question. Please put the focus on the item that is actually rounded... Also, we draw focus rect inside, not outside of the menus.

In the bottom example, the top item is rounded. The focus rectangle remains squared off as is the guidance.

Without the top and bottom padding, the top and bottom items will be rounded by the clipping. But Focus Visuals render above AFAIK - so wont be clipped by the flyout.

[JustinXinLiu]

I do like some top and bottom paddings for each group sections. One of the reasons is that this way, we don't need to provide a different border style for the very top or bottom menu item. I believe this is how Material Design has done it too.

However, we should get rid of the left and right paddings.

[mdtauk]

I do like some top and bottom paddings for each group sections. One of the reasons is that this way, we don't need to provide a different border style for the very top or bottom menu item. I believe this is how Material Design has done it too.

However, we should get rid of the left and right paddings.

Material Design Menu

Not sure I agree with your reasoning there. I find the top and bottom padding to be a little distracting, it adds more visual clutter, seeing the small gaps between separators, and selection backgrounds.

Not sure what border style you are talking about, if you mean the hover background for the Flyout Menu items, that should be clipped by the flyout itself right?

Also not every flyout is consistent with this top and bottom padding...

[JustinXinLiu]

I am referring to the corner radius of the context menu.

If there’s no gap, then the top most menu item will have a different corner radius than zero, same as the bottom most one.

Potentially, they could be taller than the rest of the menu items too if you ever want to give the context menu a padding.

[mdtauk]

I am referring to the corner radius of the context menu.

If there’s no gap, then the top most menu item will have a different corner radius than zero, same as the bottom most one.

Potentially, they could be taller than the rest of the menu items too if you ever want to give the context menu a padding.

The flyout shape would crop, so the rounded corners would come for free essentially. I don't see the rounding being a problem personally.

Like most panel controls, the internal padding would affect the contents, I would imagine the flyout template padding would be set to 0, so by default, they would look as they should.

This also feeds into a question I have. At the moment, flyout menus adapt to whether they were invoked by Touch or Pointer. What about Date and Time, Calendar flyouts? Shouldn't these adapt too?

What about when a Picker control is using a compact density, shouldn't that also affect the flyout it shows?

[chigy]

This also feeds into a question I have. At the moment, flyout menus adapt to whether they were invoked by Touch or Pointer. What about Date and Time, Calendar flyouts? Shouldn't these adapt too?

@mdtauk , We considered that and we ended up not having enough resources to implement. As far as I am aware, no user has complained to us about the sizing being an issue.

[mdtauk]

@chigy Compact density has not really been implemented in any first party apps, to have gathered feedback on. But it seems a shame to allow this inconsistency to continue, because of a lack of interest or resources, the second being understandable, the former very disappointing.

The fact the selected part of the flyout is taller than the control which is summoning it, looks like a bug, rather than an intended design.

[chigy]

The fact the selected part of the flyout is taller than the control which is summoning it, looks like a bug, rather than an intended design.

@LucasHaines to comment on the fact compact density entry point would open up non-compact one causing the sizes to be inconsistent. Do we have a backlog on this or is this intentional?

[chigy]

it seems a shame to allow this inconsistency to continue, because of a lack of interest or resources, the second being understandable, the former very disappointing.

@mdtauk , I understand. However we do not have unlimited resources so we need to prioritize our work. We do try to prioritize things customers see often and are commonly used first. And we know the Date/Time picker is not used very much by our customers so we cannot justify spending a lot of time on it.

[mdtauk]

it seems a shame to allow this inconsistency to continue, because of a lack of interest or resources, the second being understandable, the former very disappointing.

@mdtauk , I understand. However we do not have unlimited resources so we need to prioritize our work. We do try to prioritize things customers see often and are commonly used first. And we know the Date/Time picker is not used very much by our customers so we cannot justify spending a lot of time on it.

I understand why, but it is still unfortunate.

[chigy]

I understand why, but it is still unfortunate.

@mdtauk , what you could do if you want to make a difference here and any other issue like this is if you could make a case from usability perspective. Inconsistency sometimes cause usability issues. Those are types of issues that is easier to get traction than a small annoyance. I know that small issues become a bigger annoyance (thousand paper-cuts) but we have to start somewhere... And if we are to start somewhere, we should start from the issues we can prove we are making the difference.

[mdtauk]

@chigy I don't have the data to put forward a detailed case, other than the fact it visually looks like a bug, and is inconsistent to other controls which both adapt to touch/cursor input, and Compact Density.

ComboBox flyouts are larger when you use a touch screen to make it drop down, compared to using a cursor.
Calendar, Date and Time Pickers, do not, and perhaps they should.

The design of the Date and Time picker centres the flyout above the control, and so the selection matches the 32px height, so it appears seamless, as if the whole control is expanding out.

When Compact Density is used, the control becomes 24px, but the flyout isn't affected. This is not what you would expect, and appears to be a bug.

If some of the proposals ( #918 #735 #905 ) are considered, then this disconnect between the flyout and the control it expands from, will look even more stark.

[chigy]

@mdtauk , I am not debating it is indeed a bug or something we should fix. I am letting you know that we do not have the resources to fix everything so we use the severity and data to make a call. In this case, this issue does not meet the bar. However as you mentioned, if we do the other proposals, then this should be considered. You should mention this bug in the other 3 proposals but I cannot justify fixing this issue by itself. BTW, did you open a bug for this issue? If not, you should and mention it on the other 2 proposals you mentioned. This proposal will not be tracking fixing that because this proposal does not make the issue worse.

[mdtauk]

Thank you @chigy, now it is considered a bug, I have submitted it as such. #1148

I wasn't sure if it was considered a bug or "by design", I had submitted an issue about it before, and it was mentioned as something being worked on. #925

[chigy]

@jevansaks , I have the design decision for this item. Does this item need to be turned into a bug or can we reuse this question item?

1. Design would like the Left and Right pudding to be removed.
2. Please DO NOT remove Top and Bottom margins.

@mdtauk FYI
The reason for not removing top/bottom margin is because they would like retain optical vertical rhythm seen below. Without the top/bottom margin, the first and last items appear too close to the edge.

[mdtauk]

It is only when you hover over a top or bottom item, that the gap looks awkward. Ideally the top and bottom items would have a different size with a top and bottom padding, so hovering over would look flush with the edge of the flyout.

But it seems that this will not be changed, so it makes sense to close this.