Re: [csswg-drafts] [css-overflow-3] Clarify padding-bottom in overflow content (#129)

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)]( | padding        | padding                | padding         | padding                | none           | none          | none              | none             |
| [block-flow (block-level)](  | none           | child-margin + padding | none            | child-margin + padding | none           | child-margin  | none              | child-margin     |
| [flex](                      | 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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Wednesday, 23 September 2020 16:55:43 UTC