- From: Simon Pieters <simonp@opera.com>
- Date: Fri, 08 Apr 2016 10:44:06 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>, "Matt Woodrow" <mwoodrow@mozilla.com>
- Cc: "www-style@w3.org" <www-style@w3.org>, "Kartikaya Gupta" <kgupta@mozilla.com>
On Thu, 07 Apr 2016 22:43:10 +0200, Matt Woodrow <mwoodrow@mozilla.com> wrote: > > On 7/04/16 10:21 PM, Simon Pieters wrote: >> >> The scroll event is synced with animation frames per spec. It seems >> reasonable to update the exposed renderport as a new first substep of >> https://drafts.csswg.org/cssom-view/#run-the-scroll-steps >> >> It seems to me it doesn't need to be a callback, it can just be exposed >> somewhere, and you would typically read it from a 'scroll' event >> listener? > > It's possible to have the renderport change, without a scroll happening, > like when you scroll an outer container and change the visible area of a > child container. Right, or the position of a child container changes... > Unless we want to send a scroll event to those children (even though > their scroll position hasn't changed), I think we need a new event that > gets sent at the right times. > > I think it's also preferable to have to have an event, rather than a > property, since users will be tempted to read it at times other than > from a 'scroll' event where it is potentially out of date and misleading. What if there are use cases for reading it at other times? In particular during page load. With events it's typically racy whether the event gets fired before the relevant event listener has been set up, and it's a layer violation to fire an event in response to setting a listener. Maybe a Promise? I suppose that exposing a property could mean that it would have to flush layout on getting if we want to avoid out of date information, and maybe we don't want to introduce new things that flush layout? -- Simon Pieters Opera Software
Received on Friday, 8 April 2016 08:44:48 UTC