11:13:51 <RRSAgent> RRSAgent has joined #positionobserver
11:13:51 <RRSAgent> logging to http://www.w3.org/2015/08/27-positionobserver-irc
11:14:03 <iank> RSSAgent, make logs public
11:14:16 <iank> RRSAgent, make logs public
11:15:16 <iank> ojan: Would like to talk about PositionObserver, proposal to get standard of rendering pipeline, proposal how to fit resize observer into the pipeline. Fine if we drop off last point.
11:15:42 <iank> ojan: Use-cases for position observer.
11:16:58 <iank> ojan: Infinite scrollers, Disqus type comment system - lazy load when near viewport, Ad visibility detection - we've observed that they do a lot of work trying to detect if the ad is visible.
11:17:36 <iank> ojan: The advert something something standards board, setting up standards guidelines on what counts as an ad impression.
11:18:32 <iank> ojan: Work that Ads are doing to do this type of detection is quite expensive, requires performing polling. Triggers layout thrashing.
11:18:56 <iank> ojan: Standard requires polling every 100ms.
11:19:25 <iank> dbaron: would page visibility API applied to iframes work?
11:19:48 <iank> ojan: I don't remember why this wasn't expressive enough.
11:20:11 <iank> ojan: We had somebody from google ads to implement in chrome paint timing information.
11:21:28 <iank> ojan: You can't tell that you are visible, moz exposes paint count for this information, non-moz create a 1x1 flash plugin you can get information if it painted or not, nothing that solves occulsion problems.
11:21:49 <iank> ojan: for flash plugin use multiple to get higher resolution.
11:22:11 <iank> ojan: Meta: "What is a good solution for this problem, in addition with lazy loading and infinite lists."
11:22:29 <iank> ojan: Trying to come up with an API that solves all of the issues.
11:23:10 <iank> esphren: fb comments are also quite expensive, performing polling to detect when to load.
11:23:26 <iank> ojan: do those use cases make sense?
11:23:43 <iank> smfr: I'm not sure that infinite scrolling is in this problem space.
11:24:56 <iank> elliott: two different types of infinte scroll - network fetches when you reach end, view-cycling to reduce dom.
11:25:20 <iank> ojan: Explaining API on whiteboard.
11:25:41 <iank> ojan: var obs = new PositionObserver();
11:26:12 <iank> elliott: var obs = new PositionObserver(() => { ... });
11:26:20 <iank> elliott: obs.observe(e);
11:26:49 <iank> ojan: you observe a set of elements, then you get a list of change records.
11:27:08 <iank> dbaron, hober: <questions about change records>
11:27:28 <iank> elliott: changeRecords: boudningRect, viewportRect, element
11:27:48 <iank> smfr: is this client coords?
11:28:30 <iank> elliott: both boundingRect and viewportRect is in coordinate space of client coordinates.
11:29:29 <iank> ojan: PositionObserver takes a config dictionary, takes in an element for the viewport which it is relative to.
11:30:00 <iank> ojan: <draws on whiteboard going through example>
11:30:40 <iank> ojan: only fire the callback when the element intersects the start of the viewport.
11:31:06 <iank> ojan: case (1) just get callback when you enter/exit.
11:31:33 <iank> ojan: case(2) get callback when the percentage visability to the viewport changes.
11:32:06 <iank> ojan: case(3) extends the viewport so its slightly larger, i,e, 1s before.
11:32:15 <iank> smfr: this being time based is problematic.
11:32:28 <iank> ojan: this should be worded as "expected time".
11:32:38 <iank> ojan: decision between position vs. time here.
11:33:27 <iank> smfr: as an author with the time-based api the author then has to know how long it'll take to render content, but you don't know what device you are on.
11:35:09 <iank> dbaron: it seems like if there is something that has enough momentum to get into the range then you should fire the notification. Should be distance, or enough momentum to get into the viewport.
11:35:19 <iank> smfr: want to fire this event as fast as possible.
11:36:38 <iank> rossen: we spent a lot of time with WinJS team with their infinite scrollers, 6-8 screens of content, in order to realize all of these elements was distance based, they had 2 viewports of data before and after, (standard view cycling), all of the events were based on which portion of the viewports.
11:36:47 <iank> rosson: nothing was time based.
11:37:17 <iank> ojan: there are legitimate different ways to do this, chrome is time-based. we could expose both.
11:38:03 <iank> <discussion about distance being better>
11:38:11 <iank> shane: no reason why we can't add time later.
11:38:49 <iank> dbaron: i feel like there is a use-case for a bool when says "call me back if you know you are going to be placed into the distance trigger"
11:39:04 <iank> dbaron: if the fling/etc has enough momentum to get there.
11:39:48 <iank> hober: we prototyped an event that would fire, when you nearly reached the bottom "will reveal bottom", "did reveal bottom"
11:41:18 <iank> summary: stick with distance initially + dbaron suggestion for bool. (see above).
11:41:24 <iank> \o/
11:42:01 <iank> dino: we have use-cases for just inside the viewport
11:42:39 <iank> dino: we haven't progressed with out proposal before, because (ian summarizing) not powerful enough.
11:42:47 <iank> ojan: what is the sue-case again?
11:42:59 <iank> dino: animations that trigger based on position within the page.
11:43:09 <iank> ojan: i don't think that this will work for that.
11:44:02 <iank> dino: summary - could use this api if you could have -ve viewport modifier to trigger animations for elements going out/in of viewport.
11:44:22 <iank> ojan: async as threaded scrolling can't make sync api because of this.
11:45:36 <iank> smfr: <use-case for fast fling, wouldn't get notified?>
11:45:48 <iank> ^ not sure if i captured that properly.
11:46:13 <iank> elliott: fast fling should be fine, for use-case as ad is a blur, can't click.
11:46:25 <iank> smfr: probably fire this at scroll time.
11:46:50 <iank> eliott: we'd like to do this with queuing a task.
11:47:05 <iank> ojan: what are you concerns?
11:47:21 <iank> smfr: Concern about 1000's of items for infinite lists.
11:47:38 <iank> ojan: author can do willrevealbottom, just one element.
11:48:18 <iank> ojan: we will give ad networks example code to help them do the right thing.
11:48:38 <iank> smfr: I'm concerned about the viewport element, what happens if not in document, not parent, etc, etc.
11:48:51 <iank> smfr: lots of complexities with nested scrollers and what happens with those.
11:49:20 <iank> rossen: complexity with nested scroller? and add visibility.
11:50:04 <iank> ojan: ads only care about top level viewports?
11:50:40 <iank> rossen: <explaining complicated case>
11:52:26 <iank> elliott: API is designed for ads billing problem, not the ad spam problem.
11:52:41 <iank> ojan: not trying to do occlusion, clipping, opacity, etc.
11:53:01 <iank> ojan: not going to solve occlusion here
11:53:38 <iank> ojan: could add in v2: in addition to boundingRect, guarenteedVisableBoundingRect.
11:54:16 <iank> elliott: bloom filter of visibility, yes you are visible or you *might* not be visible.
11:55:08 <iank> elliott: from our research you need to do pixel read-back to get 100% acc.
11:55:40 <iank> matt: this is just test interestion of two rects.
11:56:13 <iank> ojan: i do think we want to check if something is a decender of viewport element.
11:56:34 <iank> smfr: PositionObserver is firing inside the iframe? is this is security risk?
11:57:17 <iank> ojan: no, because we already expose this today. moz: innerScreen{X,Y}, non-moz: iframe throttle behaviour to detect this as well.
11:57:34 <iank> ojan: we are exposing more information, but can get at this.
11:57:56 <iank> smfr: is a bit weird to me that you are just intersecting two rects.
11:58:16 <iank> elliott: i disagree with ojan, think we should apply all intermediate scrollers.
11:59:47 <iank> dbaron: get it right for people who aren't trying to cheat?
11:59:51 <iank> elliott, ojan: yes.
11:59:56 <iank> dbaron: time check!
12:00:32 <iank> <existential questions about what Houdini really is>
12:01:50 <iank> ojan: will do intersecting of rects up the ancestor chain.
12:02:06 <iank> smfr: can we change name?
12:02:13 <iank> <bikeshed discussion>
12:02:36 <iank> RectIntersectionObserver?
12:02:44 <iank> ViewportObserver?
12:03:05 <iank> ISSUE: have bikeshed discussion.
12:03:59 <iank> ojan: do this through public-webapps or WICG?
12:04:18 <iank> dbaron: i think this has enough momumtum that this could go to public-webapps.
12:04:28 <iank> dbaron: WICG is meant to be step before.
12:05:32 <iank> <no general objections to this api>