| | 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 | |