On Wed, Jan 20, 2016 at 12:26 PM, Rossen Atanassov < Rossen.Atanassov@microsoft.com> wrote: > > -----Original Message----- > > From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] > > Sent: Tuesday, January 19, 2016 11:20 AM > > > > > Context: https://bugzilla.mozilla.org/show_bug.cgi?id=1236386 > > > https://bug1236386.bmoattachments.org/attachment.cgi?id=8703469 > > > > > > This issue's probably already been discussed but I don't know where. > > > The question is: how does a transformed element contribute to the > > > scrollable area of an "overflow:auto/scroll" ancestor? For example, > > > does its border-box before transformation contribute to the scrollable > area? > > Our implementation is complicated in this area. We first compute > scrollable bounds based on pre-transformed layout results. Later, during > composition, we adjust in the presence of transforms. Handling everything > during layout makes it very difficult to have performant transition and > animation effects based on transforms. > Ours is too. The scrollable area will lag behind the transform in many cases. I think that's OK, but I think we should also specify required behavior for the steady-state. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn
Received on Wednesday, 27 January 2016 01:27:12 UTC