| 1 | = IntersectionObserver = |
| 2 | ''by Ali Juma (ajuma@chromium.org)'' |
| 3 | |
| 4 | - Goal: find out if an element is visible |
| 5 | - Fully visible? |
| 6 | - Partially visible? |
| 7 | - Entirely offscreen? |
| 8 | - Sites do this with JS with bounding boxes over and over again |
| 9 | - API Overview |
| 10 | - var observer = new InstesectionObserver(callback, options); |
| 11 | - Options: |
| 12 | - root: Interseection with respect to an element or if null the viewport |
| 13 | - threshold: what fraction of intersection triggers notfication |
| 14 | - `observer.observe(target)` |
| 15 | - Implementation Challenges |
| 16 | - Lifetime management |
| 17 | - The observer and its callback need to live as long as there are targets to observe. |
| 18 | - Even if the observer no longer has any JS references |
| 19 | - The callback will keep the document alive. |
| 20 | - It’s easy to accidentally keep the document alive indefinitely |
| 21 | - Lack of Event Loop support |
| 22 | - HTML EventLoop |
| 23 | - https://webkit.org/b/160711 |
| 24 | - https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-8 |
| 25 | - Blink and Gecko schedule rAF in-sync with “updating the rendering” (that is, producing a frame) |
| 26 | - Any setTimeout call during rAF is guaranteed to fire after style/layout/paint for producing a frame |
| 27 | - IntersectionObserver WPTs depend on this model |
| 28 | - So do other WPTs |
| 29 | |