- From: Ian Kilpatrick via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Sep 2020 16:55:40 +0000
- To: public-css-archive@w3.org
Over the past few weeks I've done a fair bit of investigation on the model here. Broadly speaking there is the "ideal" model which is as follows. When calculating the scrollable-overflow for a scroll-container there are two rectangles we need to keep track of: [1] Inflow bounds -------------- To determine this correctly the engine needs to keep track of the bounds of all *inflow* children and their margins (pre relative-positioning and transform adjustments). Padding of the scroll container is then added to this rectangle and added to the scrollable-overflow. Importantly this *doesn't* include any float, or out-of-flow positioned children. This also only happens for a scroll container, this *isn't* part of the scrollable-overflow for non-scroll containers. [2] Scrollable-overflow bounds --------------------------- On top of this the "regular" scrollable overflow calculations apply, e.g. the scrollable-overflow for propagation rectangle which is post-transform, post-relative-positioning. The result of the scrollable overflow rectangle is the union of [1], [2]. Web-compat concerns ----------------------- Broadly speaking everything is a relative mess :). However the compat concerns only surround [1]. I created this handle table! | | Blink (inline) | Blink (block) | WebKit (inline) | WebKit (block) | Gecko (inline) | Gecko (block) | EdgeHTML (inline) | EdgeHTML (block) | |---------------------------|----------------|------------------------|-----------------|------------------------|----------------|---------------|-------------------|------------------| | [block-flow (inline-level)](https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=8499) | padding | padding | padding | padding | none | none | none | none | | [block-flow (block-level)](https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=8496) | none | child-margin + padding | none | child-margin + padding | none | child-margin | none | child-margin | | [flex](https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=8497) | none | child-margin + padding | none | child-margin + padding | none | none | none | none | (I didn't test grid). The "ideal" thing here (which developers are asking for) would be for each of the layout modes to include "child-margin + padding". (For the "block-flow (inline-level)" case "child-margin + padding" == "padding"). What to do ----------- We (Blink) are prepared to try and incrementally move to the "child-margin + padding" case for both axis, however stop when we find real world compat concerns. As an example this may end up as the following: - flex includes child-margin+padding. - block-flow (block-level) stays as is. (or visa versa). We've got some UseCounters in place, but we are in the process of adding more precise ones. -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/129#issuecomment-697691447 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 September 2020 16:55:43 UTC