Absolute Positioned Floating Header Jitters in Saf

问题:

I have a simple JSFiddle of a single floating header here:

http://jsfiddle.net/zT9KQ/

Basically, this uses translate3d to kick in the GPU and hardware accelerate the floating header so that it may be drawn more smoothly. The header jitters in the latest Safari but gets drawn perfectly fine in the latest Chrome, FF and Opera. The actual code that is being affected by this (the code that spurred this question) is code I've written that cannot be shared publicly but works in a similar manner where fixed positioning is, unfortunately, not a valid solution.

I have tried:

1. Setting the backface-visibility CSS property to none.
2. Setting the perspective CSS property to 1000.
3. Playing with requestAnimationFrame during the animation logic.
4. Throttling the scroll event callback.
5. Setting the translateZ transform to something higher than 0px.

But none of this has worked (or at least - it seems reasonable to assume the GPU has kicked in but the jittering persists). I noticed that two questions are already open that are identical this one I'm raising but no one has answered them:

• Jitter in Sticky Header in Safari
• Implementing fixed position in javascript causes jitter in Safari when scrolling

Is this a known bug? Is there a performance hole I'm not sealing up?

EDIT

I have been receiving a lot of questions as to why position: fixed is not a valid option. To directly reply to Antony's comment on the question itself:

I'm not emulating/reinventing position: fixed. If you look at the top-voted answer (as of this comment), you will see that this seems to be a Safari issue. The reason position: fixed is undesirable in this case is because the code in question must be able to support multiple floating headers that sit below each other and have a "container" range where there may be infinitely nested containers. Using fixed positioning not only makes the code more complicated in the case where these floating headers live in a container that horizontally scrolls but also makes the component more brittle overall (calculating offsets when the widget needs to sit within another container somewhere else on the page). So, semantically, absolute positioning fits my needs better than fixed.

SECOND EDIT

Upon thinking about what Antony had been telling me (that I may be reinventing the wheel), and after hearing about -wekbit-sticky from user3716477, I would like to update the question to show what I'm trying to do. You can see how my code behaves in every browser other than Safari here:

http://cl.ly/3y1i3C473G2G

I have learned:

1. You cannot rely on the scroll or really any scroll-like events (such as mousewheel) since they are asynchronous in nature. I submitted a bug to Apple detailing what was happening and they closed the bug for this reason.
2. There is no real way to do what I want as of now - to have multiple floating headers that stack and replace each other. I guess I'll have to wait for something like -webkit-sticky to come out.
3. I should include all relevant information in SO questions from here on out. :-P

Thanks for playing guys! Here's the exact response I received from Apple:

Apple Developer Relations09-Jun-2014 01:16 PM

Engineering has determined that there are no plans to address this based on the following:

Code is using scroll events, which are asynchronous.

We are now closing this bug report.

If you have questions regarding the resolution of this issue, please update your bug report with that information.

Please be sure to regularly check new Apple releases for any updates that might affect this issue.

回答1:

Since there is an apparent delay between scrolling with the trackpad and the scroll event firing, you can attach the handler to an additional mousewheel event to smoothen things up.

$scrollContainer.on('scroll mousewheel', function () {
    // reinvent the wheel here
});

You can see in this demo here that jittering is far less likely to occur when you scroll with the trackpad. In the demo, I have invoked the handler on load to eliminate the flash when you first scroll on Safari. There may still be some occasional jitter, but if you want to minimize that, you can go the resource intensive way of using setInterval and requestAnimationFrame.

This might fix the problem for now, but as I have said before, this emulation approach is not ideal and you are very likely to run into more trouble down the road.

回答2:

It appears to be a bug with Safari scrolling. If you drag the scrollbar manually (don't use the trackpad gesture to scroll), then there is no jittering.

Chrome (and other browsers) handle scrolling differently which is why this bug is only present on Safari. You might want to submit a bug report to Apple.

回答3:

How about a little restructuring, like this: http://jsfiddle.net/me2loveit2/zT9KQ/6/

html:

<div>
<h1>Header</h1>
    <div class="container">
        <div class="content"></div>
    </div>
</div>

CSS:

.container {
    height: 300px;
    position: relative;
    overflow-y:scroll;
}
.content {
    height:1000px;
}
h1 {
    position: relative;
    top:0px;
    left:0px;
    margin: 0;
    width: 100%;
    background: black;
    color: white;
}

回答4:

If you are using something similar to the jiddle code you have to check if browser is safari and then make it a different way like:

$(function () {
    var $header = $('h1'),
        $container = $('.container'),
        $scrollContainer = $('.scroll-container'),
        scrollContainerOffset = $scrollContainer.offset().top;
    $scrollContainer.on('scroll', function () {
        var top = Math.max(0, $container.offset().top * -1 + scrollContainerOffset);
        $header.css('top', top + 'px');

    });
});

Even when it isn't the way you want your problem to be solved, it might be a workaround that may help...

回答5:

Scroll events are sent asynchronously in various browsers; you should not rely on them to do things like this.

The best solution would be to use position:-webkit-sticky; top: 0;

回答6:

You could try and disable all and any javascript-ish scroll handling and just simply remove

position: relative; from the .container.

Afterwards just add h1{ top:0; } and it will happily stick to the .scroll-container.

Excerpt from CSS absolute positioning:

Position it at a specified position relative to its closest positioned ancestor...

To explain - your absolute H1 will look up the tree for the first ancestor element which defines a "position" property and inherit it as a 0,0 reference point.

It could be a WTF at first, but this behaviour is a powerhouse once you tame it.

EDIT: Related to the original jsFiddle, I made some more property removals:

http://jsfiddle.net/253Ss/

^ .container wrapper could be removed as well, since it is no more neccessary in a technical sense.