I'm trying to make a page layout that has sections that slide in and out when navigated to. Each section fills the screen (100% width/height) and is positioned absolutely at a percentage-based value.

In the attached sample, there are four sections, positioned as follows:

[a]
[b][c][d]

where [a] is at 0 0, [b] is at 0 100%, [c] is at 100% 100%, and [d] is at 200% 100%.

Now, to achieve navigation I placed all sections in a 100% by 100% absolutely positioned, overflow hidden container. When a section is navigated to, the 'top' and 'left' values of the container are animated to the negative of the section's offset, e.g. if [d] is selected, container is animated to -200% -100%.

Strange behavior abounds! When navigating to a 0% offset (going left or going up), the transitions work fine. However, other combinations (i.e. negative offsets) result in seemingly illogical (yet consistent) quirks.

See for yourself: http://www.doronassayas.com/ypsite

Here's a summary:

  • [c] and [d] to either [a] or [b] works fine.
  • [a] to [b] and [a] to [d]: jumps to the end, jumps back to the beginning and starts animating.
  • [a] and [b] to [c] is the strangest - before the transition starts, the entire body (or some other high level element?) pops to some visual offset that is not traceable via CSS (invisible in Firebug and other development tools). So instead of ending up at [c], we end up at [d] (visually), even though the CSS values clearly show we are supposed to be at [c]. Doing random stuff like clicking in the Firebug hierarchy resets the view to the correct location. WTF?

Tested this in Firefox 4, Chrome 10 and Safari 5, and the same behavior occurs in all browsers, whether using jQuery.animate() or Louis Remi's very cool jQuery.transition plugin, which simply applies a -prefix-transition to the container along with the new offset values when animate() is called.

The consistency of the strangeness intrigues me. Any ideas?

Any help greatly appreciated.

有帮助吗?

解决方案

After considerable hair-pulling I finally diagnosed the buggy behavior by switching on overflow: auto on the body element. Turns out the positioning antics with negative values wreak havoc on the calculated width and height of the body, which keeps changing during transitions (and never actually stays on 100% of the window, which was the expected behavior). The result is fluctuating scrollbars and incorrect scroll locations of the body element, albeit surprisingly consistent across browsers.

The solution turned out to be very simple:

body
{
    position: fixed;
    top: 0;
    left: 0;
    bottom: 0;
    right: 0;
    padding: 0;
    margin: 0;
}

The fixed position, which I never used before, makes the body element maintain fixed size and position while ignoring any changes to its content. And there you have it! Lovely transitions, hardware-accelerated where supported thanks to jQuery and Louis Remi.

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top