Open bpinney opened 8 years ago
The issue might be with _computeMenuVerticalOffset
. It seems to fix the bottom of the screen issue if it always returns 8
instead of -4
. I do not know if the top location of the dropdown content is as intended after this change however. It also states in the code comments that these numbers are "somewhat magical" and are derived from the metrics of elements internal to paper input.
Indeed the issue is on the values for verticalOffset
.
There is a bug when you set a negative horizontal/verticalOffset
which renders your element outside the window. This should be fixed in iron-fit-behavior
(I'll open an issue there).
My understanding is that those "magical values" are there to guarantee some kind of alignment, but I couldn't figure out to what it should be aligned: https://jsbin.com/raduqo/1/edit?html,output While the 2 inputs are aligned, the 2 "allosaurus" items are not:
@cdata @notwaldorf what should be the alignment? How to proceed on this one?
FYI, created this issue on iron-fit-behavior
https://github.com/PolymerElements/iron-fit-behavior/issues/54
Description
The
noLabelFloat
attribute, used in_computeMenuVerticalOffset
to compute a -4 vertical offset for the menu, causing a lack of proper spacing between the menu and the bottom of the screen.Expected outcome
I expect the menu, at least the bottom of the screen, should have a proper 8px margin.
Actual outcome
Vertical offset is set to -4px, causing a bottom margin of -4px, in turn causing the menu to lack spacing between the bottom of the screen.
Live Demo
https://jsbin.com/raduco/1/edit?html,output
Steps to reproduce
paper-dropdown-menu
element in the page with the attributeno-label-float
.paper-dropdown-menu
element.