0

This is my first SO question, so please forgive any question faux-pas!

I have two containers on my HTML DOM that float:left. Each has content that must be perfectly aligned with the other. The left container (A) has overflow-y:hidden while the right container (B) has overflow-y:scroll. I use an onscroll callback to set the scroll position of container A like such:

    A.scrollTop = B.scrollTop;

This works great in 99% of use-cases... until a client zooms below 100%. When zoom is below this level, rows in one container are sometimes 1 pixel off from those in the other. My first guess is that this is a rounding issue, but I can't figure out where I can find values that I could use to build an algorithm to predict when & how the error will occur. In addition, both containers have exactly the same height, and their content is of identical height as well, so I'd expect any rounding errors to be the same for each of them!

I've created a jsFiddle demonstrating the behavior here. (I've used divs in this example, but other elements exhibit the same behavior) (I'm testing in chrome)

Can anyone explain why these two containers exhibit different behaviors when setting scrollTop to the same value? Also, given that browser-zoom detection is difficult at best (discussion here) does anyone know an efficient way to identify and correct for this issue?

Community
  • 1
  • 1
MattE_WI
  • 377
  • 1
  • 11

2 Answers2

0

Looks like scaling problem, not sure. Forcing scrollTop might help. JSFiddle demo here.

$('#b').on('scroll', function () {
    var top = $(this).scrollTop();

    if (top != $('#a').scrollTop()) {
        $('#a').scrollTop(top); 
        $(this).scrollTop(top);
    } 
});
JungleZombie
  • 1,181
  • 11
  • 11
  • Ahh! OK, this makes it easier to see what's going on under the hood in the browser - Looks like the floating-point math used to *return* a value from scrollTop is *different* than the math used to *set* a value to scrollTop. So, edge cases generate this difference that spans the x.5 'rounding border'. Setting **both** elements' scrollTop values in one pass solves the issue... – MattE_WI Jun 10 '14 at 16:05
  • There was a bit of unneeded logic in your callback above though, I've created a fork with a more streamlined version here: http://jsfiddle.net/mattebel/hwbdc/ – MattE_WI Jun 10 '14 at 16:11
  • I'm glad it helped you with your question, edited the unneeded logic out, so that the reply remain clean. – JungleZombie Jun 10 '14 at 16:57
0

Update: I just revisited this question to see if there were any changes in Chrome's handling of this datapoint... lo and behold, Chrome now returns a floating point value for scrollTop!

Problem solved!

MattE_WI
  • 377
  • 1
  • 11