paper-menu button-animation causes text to reflow while opening

[mgiuffrida]

When opening the paper-menu, long items are wrapped while the menu animates:

and then they are unwrapped when the menu has finished animating in: .

Fiddle.

[cdata]

This definitely seems undesirable, but I'm not 100% sure what the fix should be. Any suggestions?

[mgiuffrida]

overflow: hidden? I would defer to a Material designer but that would make sense to me so the menu size and its items don't jump around while opening.

[ElsewhereGames]

white-space: nowrap; perhaps?

[mgiuffrida]

I think this definitely needs a fix, though I'm not sure what it should be. @cdata can you remove pending-response and find somebody to come up with a response? :-)

[tjsavage]

Digging in to some of the material design videos, my guess at the correct behavior might be to wait until the menu area has expanded to its full width before fading in the text.

[danbeam]

fwiw: we just used white-space: nowrap; in Chrome's download page

[danbeam]

i don't know if white-space: nowrap; would be right for all users (i.e. what https://github.com/PolymerElements/paper-menu-button/pull/102 is doing)

maybe we should just fix this on our end if there's not a good generic solution

[JanMiksovsky]

Since it's quite rare for a menu item to wrap, I think using nowrap is a good default generally, and a reasonable solution here. In the rare case where a menu item needs to wrap, users can specify white-space: normal to explicitly enable wrapping.

[danbeam]

Since it's quite rare for a menu item to wrap,

citation needed

I'm not sure I'd expect this as a default style. and yes, we could let people turn it off... but it'd probably be nicer to allow folks to turn it on because that wont change existing behavior.

fwiw: what we really want is a fully rendered menu that is clipped and revealed without affecting menu item size / text wrapping. if you open the vertical ... menu on Chrome for Android, it works this way. the menu stays similar in size but just reveals differently (keeps the same sizing).

[JanMiksovsky]

Since it's quite rare for a menu item to wrap,

citation needed

I'm not aware of any data set we could draw upon here. In the many years I've designed app UI, I don't think I've seen a single app with a menu item that wraps. In OS menus, I'm not even sure such a thing is possible. While it's not to say that no one would ever want to wrap menu item text, wrapping would run counter to the underlying purpose of a menu to present a scannable list of commands that can be scanned very quickly. Wrapping would slow down reading, and would create the possibility of ambiguity — the user wouldn't be able to immediately tell whether the separate lines of text were separately-interactive items, or a single unit.

It's probably for those reasons that the Material Design guidelines show only single-line menu items. There's an explicit recommendation to use a dialog instead of a menu in the (again, presumably rare) case that an item is so long that it needs to wrap.