You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 13, 2018. It is now read-only.
The docs mention when linking with paper-item to use noink to prevent the ripple from freezing. This seems to take away one of the primary reasons to use paper-item in the first place. The ripple I think is a pretty significant piece of UX feedback. I'm curious the reason for the change in structure if you lose one of the primary benefits? Is there a better solution here to maintain the polish of the ripple effect?
Additionally, as an FYI placing the link inside the item, as explained in the docs, limits the size of the touch area, making it much smaller than the item itself. I've solved this by wrapping the paper-item with the link instead... although I'm not sure if that creates any issues when using core-selector or any other menu-based components.
The text was updated successfully, but these errors were encountered:
I've also just found that if I use paper-item inside of a core-menu now, without a wrapper link, the ripple is very very janky. It appears to do a double ripple, and then freezes the background. If I wrap the paper-item in an a tag it fixes this, but if the a tag is inside the item (as described in the docs), it still occurs. To clarify this does not happen when using paper-item without core-menu, so it may be a core-menu issue.
The double ripple is a bug. The cause is core-menu sets the active attribute on the selected element, which is conflicting with the focus handling code. This needs to be fixed but for now you can work around it by setting selectedAttribute on core-menu to something other than active. I'll add a note in the docs about this.
There is more discussion about links and the ripple effect in this thread: googlearchive/paper-ripple#10. In summary, because both the ripple and link navigation is triggered by pointer down, and link navigation is handled by the platform, there isn't a good way to make them play nicely together and noink will at least the ripple from looking "frozen" when the browser navigates to the link.
The docs mention when linking with
paper-item
to usenoink
to prevent the ripple from freezing. This seems to take away one of the primary reasons to usepaper-item
in the first place. The ripple I think is a pretty significant piece of UX feedback. I'm curious the reason for the change in structure if you lose one of the primary benefits? Is there a better solution here to maintain the polish of the ripple effect?Additionally, as an FYI placing the link inside the item, as explained in the docs, limits the size of the touch area, making it much smaller than the item itself. I've solved this by wrapping the
paper-item
with the link instead... although I'm not sure if that creates any issues when usingcore-selector
or any other menu-based components.The text was updated successfully, but these errors were encountered: