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
At the moment in the default calculateWormholedPosition function, the scroll of the window is taken into account, even if the anchor element of the destination isn't the body and relative/absolute positioned. This results in a problem where scrolling adds an unnecessary top/left offset to the position of the EBD content element.
Maybe we could set the scroll offsets to 0 (or prevent the addition to the triggerLeft/triggerTop) if the anchorPosition is relative or absolute (or even fixed??)?
I saw there is already a minor fix for the body relative thingy, but with my suggestion this would fix it regardless of the anchorElement/anchorPosition and the isBodyPositionRelative-fix could be removed, or am i missing something?
And yes i can override the calculatePosition, but the rest works absolutly as i want it to work so overriding it for just this seems a bit odd :)
The isBodyPositionRelative-fix (#333) tackled the same issue, but only for default destination with the body as anchorElement and only the top scroll, if some pages use horizontal scroll it would cause the same issue :)
The text was updated successfully, but these errors were encountered:
markusm7
changed the title
Improvement calculate position for custom destination element
Improve calculate position for custom destination element
Oct 1, 2019
At the moment in the default
calculateWormholedPosition
function, the scroll of the window is taken into account, even if the anchor element of the destination isn't the body and relative/absolute positioned. This results in a problem where scrolling adds an unnecessary top/left offset to the position of the EBD content element.Maybe we could set the scroll offsets to 0 (or prevent the addition to the triggerLeft/triggerTop) if the
anchorPosition
isrelative
orabsolute
(or evenfixed
??)?I saw there is already a minor fix for the body relative thingy, but with my suggestion this would fix it regardless of the anchorElement/anchorPosition and the
isBodyPositionRelative
-fix could be removed, or am i missing something?And yes i can override the calculatePosition, but the rest works absolutly as i want it to work so overriding it for just this seems a bit odd :)
The
isBodyPositionRelative
-fix (#333) tackled the same issue, but only for default destination with the body as anchorElement and only the top scroll, if some pages use horizontal scroll it would cause the same issue :)The text was updated successfully, but these errors were encountered: