Closed jarednorman closed 12 years ago
Waypoints works by checking the document offset position of the subject elements. The offset of an element with display:none
is usually 0, but can vary by browser implementation. What is the expected behavior? Should the waypoint trigger at the point where it might render if it were not display none? Should it not trigger at all?
I'd be satisfied with not triggering at all, or triggering where the element might render. Both seem good to me. The current behaviour, while I totally understand technically why it is doing that, isn't helpful or intuitive.
Completely (ok not completely) aside from the subject at hand: Why are you using display none elements as waypoints? In 99% of cases they act better in designs as visibility hidden or 0 opacity elements. Consider this market research.
While I think it would make sense if display: none elements never triggered the waypoint event, I can't think of a situation where it matters to me, now that I know that I can skip the initial check. Before knowing I could do that, it was forcing some awkward antipatterns into my Backbone Views. Thanks for the help!
I found this thread while looking for a solution to a similar bug.
We had an issue where we had two waypoints in tabs in which the waypoints are children of invisible divs. This caused Waypoins (1.1) to continuously trigger the invisible waypoints (i guess the waypoint position is at the top of the invisible divs).
As a quick fix, I wrapped the code in the triggerWaypoint around an is Visible check:
if (way.element.is(':visible')){
[original code]
}
Without digging too deep into the code this fixed the issue for us.
Currently I seem to be forced to set the visibility to hidden on things, then in the callback, display: none them, set the visibility to visible, then fade them in. That's not clean code.