I believe there shouldn't be a ripple effect if preventDefault() was previously called on the event. This would allow the developer to cancel the event and later ripples without stopping further propagation of the event.
This would solve having interactable elements on top of objects that have ripple effects. In my case, I have a list of selectable objects, each with their own options button (similar in style to Google Play Music if you could select songs).
Example showing the problem:
http://jsbin.com/belejomipe/1/edit?html,output
Example showing it fixed:
http://jsbin.com/qosuwofijo/1/edit?html,output
Calling stopPropagation() on the event could accomplish this, but the dangers are well documented (https://css-tricks.com/dangers-stopping-event-propagation/), and my app does contain menus that require the event to propagate to correctly close.
isaldarriaga
commented
8 years ago
I believe there shouldn't be a ripple effect if preventDefault() was previously called on the event. This would allow the developer to cancel the event and later ripples without stopping further propagation of the event.
This would solve having interactable elements on top of objects that have ripple effects. In my case, I have a list of selectable objects, each with their own options button (similar in style to Google Play Music if you could select songs). Example showing the problem: http://jsbin.com/belejomipe/1/edit?html,output Example showing it fixed: http://jsbin.com/qosuwofijo/1/edit?html,output
Calling stopPropagation() on the event could accomplish this, but the dangers are well documented (https://css-tricks.com/dangers-stopping-event-propagation/), and my app does contain menus that require the event to propagate to correctly close.
I'm happy to create a PR of my current fix/hack (https://github.com/broken/paper-ripple/commit/7a6689acecb7187e234b6c14a6497d750bdb2b61).