- From: Rossen Atanassov <Rossen.Atanassov@microsoft.com>
- Date: Tue, 19 Jan 2016 23:26:17 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>, Robert O'Callahan <robert@ocallahan.org>
- CC: www-style <www-style@w3.org>
> -----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. > > In the referenced testcase Chrome seems to say "no" if the transformed > > element is a direct child of the box, "yes" otherwise. Firefox says > > "yes, but only in the vertical direction". Edge says "yes". More > > testing would probably be worthwhile. Again, we will allow you to scroll there but the layout result will be off - we won't subtract the scrollbar size from the content box. > I think the answer needs to be "yes". We've slid into treating transforms as a > kind of positioning scheme, and it seems obviously correct that snap points > should respond to transforms, so scrolling in general should as well. Agree about the snap points argument. Rossen
Received on Tuesday, 19 January 2016 23:26:49 UTC