If I understand correctly, the top layer concept is there to affect paint order and how elements are displayed in general. Our proposal here doesn't affect painting of the content at all. The author would have to write their app to make sure the scrollingElement is visible. We're mainly concerned with how the designated element interacts with the Browser UI and user events.
To the more general question of how this interacts with the rest of the DOM, we haven't really thought about the details and edge cases yet. One proposal was that we could limit scrollingElement only to boxes that fill the viewport.
This isn't strictly necessary though. You could imagine having a slightly smaller root scroller with some DOM behind it as background. Or implementing a scrolling popup by making it the scrollingElement, thus giving it overscroll glow and disabling scrolling on the background content.An important area we'll have to think through is how to handle events and their capture/bubbling behavior. My first thoughts are that the scrollingElement should be a bubbling/capture boundary but I don't know about use cases or potential issues with that yet. It'll be much easier to find these problem areas once we've built a more robust prototype and let people experiment with it.
One basic question I have is do we conceive of the API call as promoting the scrollable div itself, or promoting its contents while retaining the existing root Viewport? The answer isn't entirely obvious, and we need to nail that down as it seems connected to most of the other problems.On Fri, Nov 20, 2015 at 10:53 AM, David Bokan <bo...@google.com> wrote:If I understand correctly, the top layer concept is there to affect paint order and how elements are displayed in general. Our proposal here doesn't affect painting of the content at all. The author would have to write their app to make sure the scrollingElement is visible. We're mainly concerned with how the designated element interacts with the Browser UI and user events.In that case, what happens to the rest of the contents? Do we consider the scroll offset for the the rest of the content to be permanently locked to (0, 0), and anything absolutely positioned near the top of the document with a high z-index would behave like top-aligned position: fixed? Or does it retain its own scrollable Viewport with a distinct scroll offset allowing those to be scrolled off? If the former, what happens when the scrollable div is unpromoted? If the latter, are you planning to generalize CC to support multiple Viewports?
Root Transform Layer|---Inner Container|---Page Scale Layer|---Inner Scroll Layer (*Inner Scroll Layer)|---Outer Clip Layer|---Outer Scroll Layer (*Outer Scroll Layer)|---#document Content|---DIV Clip Layer|---DIV Content Layer
Root Transform Layer|---Outer Clip Layer|---Outer Scroll Layer|---#document Content|---Inner Container|---Page Scale Layer|---Inner Scroll Layer (*Inner Scroll Layer)|---DIV Clip Layer|---DIV Content Layer (*Outer Scroll Layer)
To the more general question of how this interacts with the rest of the DOM, we haven't really thought about the details and edge cases yet. One proposal was that we could limit scrollingElement only to boxes that fill the viewport.The enterFullscreen API already relayouts the element it was called on to fit the fullscreen viewport, so it's something we need to support in general. The proposal to restrict to boxes that already fill the viewport sounds like it would have bad ergonomics (what's the failure mode if it didn't fill the viewport?) without simplifying our implementation much.I don't think you can totally assume a fixed size because of top controls complexities anyway. During top controls moves, a naive implementation that e.g. locked the viewport size to maximum viewport size might have glitches particularly with the vertical scrollbar, which would overflow off the bottom of the screen (a subtle but important problem that vertical_adjust solves in CC today).
This isn't strictly necessary though. You could imagine having a slightly smaller root scroller with some DOM behind it as background. Or implementing a scrolling popup by making it the scrollingElement, thus giving it overscroll glow and disabling scrolling on the background content.An important area we'll have to think through is how to handle events and their capture/bubbling behavior. My first thoughts are that the scrollingElement should be a bubbling/capture boundary but I don't know about use cases or potential issues with that yet. It'll be much easier to find these problem areas once we've built a more robust prototype and let people experiment with it.Fullscreen API had the same problem. We've had various bugs in it involving scrolling gestures bubbling up to the document and causing overscroll glow, or pinch and double-tap gestures resizing the fullscreen video controls. I worked around those with the big hammer of disabling scroll and pinch entirely, but that's awkward.