[css-transforms-2] Should the overflow area take scroll position into account.

[mattwoodrow]

When we have a scrolled transformed element, where the perspective property is set on the overflow:scroll element, then the accumulated transform matrix depends on scroll position (since the offset between transformed element, and perspective origin moves).

This means that the computed overflow area for the transformed element can change, and thus, the scrollable length of the overflow:scroll element (and the size of the scrollbar thumb).

The following testcase demonstrates a case where Gecko is recomputing the overflow/scrollable length as you scroll, but WebKit/blink don't, and you can't scroll the whole orange rectangle into view:
https://bug1198135.bmoattachments.org/attachment.cgi?id=8684006

You can also have the reverse case, where the transformed content scrolls fully into view early than expected, and there is remaining scroll range with no content.

[jonjohnjohnson]

Just wanted to add that this has implications on what I'm guessing is the underlying logic of not only transforms/perspective, but also sticky positioning, which currently has the same interop issue of scrollHeight depending on scroll position in at least gecko.
Gecko issue and test case -> https://bugzilla.mozilla.org/show_bug.cgi?id=1314422
Also this test case between webkit/blink/gecko -> http://jsfiddle.net/78oamb6u/57/

[css-meeting-bot]

The CSS Working Group just discussed Should the overflow area take scroll position into account..

The full IRC log of that discussion

<dael> Topic: Should the overflow area take scroll position into account.
<dael> github: https://github.com//issues/3322
<dael> matt: had bugs with parallax scroll efects. You can scroll past content and get white area or can't scroll all content into view
<dael> matt: Wondering is we should take into account when fixing scroll
<dael> AmeliaBR: For 2d most browsers extend scrollbars to cover 2d translated position.
<dael> AmeliaBR: Question is to do with 3d?
<dael> matt: Yes, particularly hard with 3d where scrollable range changes based on scroll position
<dael> dbaron: This is cases where scrolling moves things because of prespective
<dael> AmeliaBR: What is spec proposal? Or jsut general rec. to browsers?
<dael> matt: Worth spec you should be able to scroll to all of transformed values. I can try and translate geck work to words
<dael> smfr: I think scroll ehight needs to be conputed to make transformed elements visible to all scroll positions. Need to do computations to get max scroll height. No thing like that in css now
<dael> heycam: Do you need to get extremes or all in between?
<dael> matt: I do overflow at scroll position 0 and 1 and use that to calc how fast transform moves and use that to calc when bottom edge scrolls into view
<dael> AmeliaBR: Are you willing to try and draft some text? Maybe we can say tentatively sounds good pending seeing it written down?
<dael> matt: Willing to have a go with that
<dael> dbaron: Q of if other browsers interested/willing to impl
<dael> Rossen_: Is this always stable? If transform is based on scroll position and you're scaling
<dael> AmeliaBR: It isn't transform based on scroll position. The flattened position of the elment on screen after you flatten is based on scroll position based on how prespective position gets scrolled
<dael> smfr: It's not stable, further you scroll the bigger the scroll height. I don't think you can compute max, you have to do something like Matt suggests with doing a computation on a fixed scrolling format
<dael> dbaron: Max is to the position that would cause the bottom of the thing to scroll into view
<dael> matt: and possibility of multiple transforms so it's the last piece of content
<dael> Rossen_: Hearing no pushback. Matt, you expressed willingness to try and put prop text together. Let's do that, circle back in issue, and when you're ready we can discuss and resolve.
<dael> matt: sgtm
<dael> smfr: Before we go there, we could say we're not going to fix this and go simplier. You don't take prespective into account when compute scroll height. Is there content we know is broken? The parallax is for ambient backgrouns usually
<dael> AmeliaBR: I suspect authors are playing with adding extra padding until get result they want
<dael> Rossen_: Matt do you have reports
<dael> matt: I had one where an author was trying to create parallax and ran into this.
<dael> Rossen_: smfr sounds like this could become a symptom. Are you opposed to addressing?
<dael> smfr: NOt theoretically opposed. Just thinking this could fall off priority list as this is a tricky chunk of code
<dael> Rossen_: But from a stnadrds point of view try and address issue and let impl catch up
<dael> smfr: Can address by saying we're not going to address this specifically. Is alternative so bad we won't handle it
<dael> Rossen_: I don't hear objection on merits of proposed behavior. Unless I misunderstand
<dael> matt: Always had case when you have scrollable overflow you should be able to get to all elements. We should uphold that. Parallax is pretty popular
<dael> Rossen_: smfr would you be opposed to proceeding by having Matt draft proposal?
<dael> smfr: Not objection
<dael> Rossen_: Matt action is to you.

[dbaron]

I think #8193 and #8851 are closely related and possibly duplicates of this issue, though they also have a bit of discussion.