[WIP] Support native sticky

[ctjhoa]

Here is a PR to use native position: sticky if browser supports it. I think it's good to share my work on that and iterate with maintainers to get at a consensus. This could bring performance improvements as a majority of browsers support sticky https://caniuse.com/#feat=css-sticky

Here is the current test results on this branch:

1..182
# tests 182
# pass  181
# skip  0
# fail  1

I haven't add new tests yet.

I try to be the most compatible with the existing interface unfortunately there is some limitations:

• sticky element aren't suppose to go out of it's parent https://stackoverflow.com/questions/46913063/positionsticky-does-not-leave-parent which result with inconsistency between old/new behavior. For example, in the dummy app elements "not sticky to bottom" can't go out of their containers.

old

new

• [EDIT] sticky element doesn't go well with overflow: hidden. So this may breaks layouts that work today. That's why I need to remove row class from the dummy app. https://stackoverflow.com/questions/43909940/why-does-overflowhidden-prevent-positionsticky-from-working

I would like your thoughts on this.

[ctjhoa]

One solution to not break compatibility could be to add this as an opt-in feature.

[simonihmig]

@ctjhoa first thanks for your effort here, and sorry for the late response!

Before getting into details, can you explain the motivation for this change? I guess it's mainly about performance, right? But as the native template also includes the trigger components (to continue supporting the yielded isSticky* states I guess), which adds the scroll listeners/InteractionObserver from ember-in-viewport, I wonder if we really get any noticeable performance improvement?

[ctjhoa]

@simonihmig You're right it's for performance reasons.

I think that performance can be split in 2 things.

The first thing is the rendering performance which is way better when you let the browser use it's native implementation. Component are rendered smoothly even when you scroll very fast and there is no more "jumpy" rendering cause by javascript computations.

Then there are isSticky* states performance which still rely on ember-in-viewport and listerners/observers. This is not tackle with my PR and I do not know better way to achieve that. Even google complains about the lack of event regarding sticky states.

I find more important for the final users to see smooth rendering even if internal states are updated later. So using position: sticky directly may cause latency between what users saw and the internal state. I do not use isSticky* states so I don't know what drawbacks can occurred.

[spr1ne]

position: fixed always relative to browser window, if i will want start ember application in some container - position: fixed, it will break my app. In this case, maybe it’s worth completing the task? I can help with it. @simonihmig