oliverjash@ - Thanks for filing the issue...!!

Could you please let us know which URL from comment #0 will help us in reproducing the issue. Tried testing by opening all three URLs in chrome and compared with firefox behavior. Observed that both chrome and firefox behaved in the same manner.
Also if possible please provide a screen cast or screen shot of the issue observed.

Thanks...!!

@krajshree This is not really a bug report, more of a request to implement a CSS property defined in the specification.

Here is an example that uses `will-change: scroll-position`. If you open developer tools and enable paint flashing, you will see the scrollable container repaints on scroll. If `will-change: scroll-position` was implemented, this would not happen.

There are workarounds to this as detailed in my original post, but all of them have trade offs.

Forgot to link to the example mentioned in my above comment. Here it is: http://output.jsbin.com/juzodog/3

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

scroll-position is one of the values specified in https://drafts.csswg.org/css-will-change/#will-change. I think this sounds like a reasonable request. Rob, WDYT?

I don't think that we would use the signal in this way. We already expect overflow: auto | scroll elements to scroll but we don't promote on low DPI  when the text rendering quality would be degraded. We've chosen to have the repaint in order to preserve subpixel text anti-aliasing.

For your particular issue, if chrome could tell that the background of the scroller is opaque and the text contents will paint into it (e.g. contain: paint) it will promote it anyways. We are working on expanding the cases that we can detect are effectively opaque to reduce repaints on low dpi scrolling. The main issue right now is that if the scroller isn't a stacking context any positioned content is promoted as it may stack separately (and would also need to be opaque), see issue 756206.

We could use the hint for overflow:hidden (which normally doesn't user scroll) or possibly to paint the entire region of a scroller rather than just a little bit of extra content as suggested on the spec.

Closing as the repainting is an intentional choice over grayscale anti-aliasing, and supporting will-change: scroll-position wouldn't change the way we handle this.

@flackr

Thanks for the response.

I'm happy to promote it manually, however my main issue is the only non-hacky/declarative way to promote it manually is with `will-change: transform`, but the transform breaks `position: fixed` elements inside. See my original post for examples.

Do you have any ideas what would be the best way to promote it manually *without breaking fixed elements*? After all, `will-change` is supposed to be a declarative hint—I just can't find one that suits without breaking fixed elements. If `scroll-position` isn't the right hint, is there anything else that is?

The issue is really that the spec / web platform really does not intend the developer to know about the concepts of layers and promotion. The user agent is free to make the decisions about layering that it feels will best present the page.

You can use backface-visibility, which you rightfully pointed out is a bit hacky. Alternately, if you use any style on the scroller which causes a stacking context (See https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/style/ComputedStyle.cpp?type=cs&q=ComputedStyle::UpdateIsStackingContext+file:%5C.cpp&sq=package:chromium&l=762 ) and set an opaque background color on the scroller chrome will detect that promoting it will not lose subpixel anti-aliasing for the scrolled content and go ahead and promote it. I'm not sure what the least hacky choice would be - maybe will-change: position? (See attached example), but it's obviously still a lie.

Deleted: composite-scroll.html 5.0 KB

composite-scroll.html 5.0 KB View Download

@flackr

Thanks for providing some context. In my case, the scroller is not opaque, however the text contents are inside a container which is opaque. For example: http://jsbin.com/juzodog/4

Because of this, Chrome does not detect that promoting it will not lose subpixel anti-aliasing. Is this a use case that Chrome would consider supporting?

For context, this is quite common when showing a modal, where the non-opaque overlay is scrollable but all of its text contents are on an opaque background on an inner element.

This is absolutely something we would consider supporting. I've filed this work under issue 642885. Assuming this particular case is common I suspect it wouldn't be all that difficult to support.