Allow paper-dropdown-menu to take width according to its selected item text

[Qvatra]

I'm using paper-dropdown-menu as a select box in a form. I want element to be responsive to the width of a selected item. It seems it's not possible to make paper-dropdown-menu as wide as a selected item because paper-dropdown-menu uses input which cannot be styled to be responsive to its content (or at least I didn't find a way to do so).

A workaround could be to use a to show the selected item text, and hide the input. This way we circumvent the fixed size of the input. I've been able to make this work! I'm guessing that input is needed here for validation purposes only so hiding using styles should not affect validation behavior.

Is there a better approach to sizing this element's width? Or would this be something for which a PR could be created?

[ktiedt]

Also interested in this answer. (Pinging the Slack channel with this to try and get some attention).

[valdrinkoshi]

The size of paper-dropdown-menu is driven by the size of the internal paper-menu-button, and its size is determined by the paper-input it contains. paper-input uses internally a native input, which doesn't grow/shrink according to its value. Using a <div contentEditable style="display:inline-block"> would solve the issue http://jsbin.com/kukeda/1/edit?html,output

I believe paper-input is needed by paper-dropdown-menu for a11y, and the behavior it has with the label. Probably we should move this issue to paper-input... @notwaldorf WDYT?

[JanMiksovsky]

My own recommendation would be to leave paper-dropdown-menu as is. The use of paper-input is so woven into the fabric of the component that it seems risky to change that now. Among other things, paper-dropdown-menu directly exposes numerous attributes of the internal input elements such as error-message (from paper-input) and placeholder (from the internal input used by paper-input). While in theory it'd be possible to create a new internal element to avoid the use of paper-input, that seems like an enormous task, and likely to introduce numerous regressions.

While automatic sizing could be built in to paper-dropdown-menu, it seems risky to introduce that as default behavior, as that would likely break many existing layouts that rely on the component's current fixed width. Auto-sizing could be added as an optional flag, but that adds more to an already large API surface. It's also possible that there'd be variation in the exact behavior people would want with such a flag; even if it were implemented, it might not satisfy the original use case.

As a workaround, it's possible for users of paper-dropdown-menu to wire up auto-sizing behavior themselves. See http://jsbin.com/moracoz/edit?html,output.

@Qvatra Would such a workaround suffice?

[danbeam]

@tjsavage Chrome's settings UI also wants this (i.e. designers like bettes have asked for this for a while)

[JanMiksovsky]

@danbeam Would the above workaround suffice?

[danbeam]

@JanMiksovsky what @freshp86 said applies to all paper-dropdown-menu issues affected Chrome's Settings UI (which we both work on): https://github.com/PolymerElements/paper-dropdown-menu/issues/197#issuecomment-250269370