Closed richvdh closed 8 years ago
Thanks for the pull request (and sorry for the late response), @richvdh! let me take a look to make sure it's ready for merging, it seems pretty useful. 👍
BTW, @richvdh do you know if this will fix #18?
Empirically, not on its own, unfortunately.
Possibly the problem is that, as the zoom level changes, the relative size of the native scrollbar also changes - but we only check that relationship at first load.
FWIW the z-index: -1
in the CSS for this object doesn't seem to work in IE at all.
It just causes the object to overlay everything as a white box. Seems to be ok with visibility: hidden;
however.
Thanks for the heads up @rhukster. I will check it and update it accordingly. Also, PR's are welcome. ;)
@rhukster, fixed in v1.4.1 👍
In moderately complex applications, the size of the
HTMLElement
containing our scrolling content can be affected by many other changes to the DOM. Every time ourHTMLElement
is resized, we need to make sure that we callGeminiScrollbar.update
. Trying to track each and every change to the DOM which results in a resize is difficult and fragile.This PR proposes the following solution: we overlay the
HTMLElement
with an invisible<object>
with 100% width and height. To this object, we can attach an eventlistener which will be called whenever the parent element is resized; we can then use that to callGeminiScrollbar.update
.This also makes the window resize event listener redundant.
We also provide a hook by which clients can be notified of resize events, with an
onResize
member in the constructor options.