Introduce events for position sticky

[AurelioDeRosa]

I'm opening this issue to revamp an issue I already raised in the W3C position mailing list that I feel received very little attention.

The point I'm making is the following:

The specifications of position: sticky don't mention any event fired when an element is stuck and when it returns to its original position, for example something like stickystart and stickyend. I think this could be very useful and it has different use cases.

The first use case is a website that needs to decrease the margin of a navigation bar when it starts sticking. Another use case might be to have an element that takes the full width of the page when it's sticking but a different width when it's in its original position.

A use case I can think of is an element that should have the width of its parent when is not sticking and the width of the window when sticking. An example is shown in this demo I've created:

https://jsfiddle.net/638rjsty/

And this is the result I'd like to achieve:

https://jsfiddle.net/4otjrrpf/

The second demo uses a library to simulate the support for position: sticky, so it can be seen in any modern browser.

[arschmitz]

@AurelioDeRosa couldn't you just use scroll events to check the position of the element? i know the semantics are not as pretty but that could be solved by a very small lib.

[dmethvin]

I think that's what it does?
https://github.com/AurelioDeRosa/audero-sticky/blob/master/src/audero-sticky.js

It would make sense to have separate events if it could save some layout engine effort to do it that way. It does seem like the layout engine knows when the important points occur and global scroll/resize listeners are often inefficient. For example there is a lot going on in that audero handler, it could be throttled using requestAnimationFrame to ensure it doesn't do any wasted computations.

[AurelioDeRosa]

Off-topic about my polyfill:

• @arschmitz As you know, listening for the scroll event is not ideal. It's triggered many times and this cause performance issues. Having specific events would improve the situation a lot.
• In my polyfill I have to listen for the scroll event because of how I position the element. I don't want any side effect in the page apart from what I'm forced to do. For example, an easier solution would be to have the sticky element as position fixed and then have the parent with position relative. However, this might effect other aspects of the layout which I don't want.

Coming back to my point, as @dmethvin stated, my main point is to improve the performance of any function that listen for the event.

[Cryrivers]

I would rather have a pseudo-class like :sticky, which selects active sticky elements.