W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2020

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

From: Ian Kilpatrick via GitHub <sysbot+gh@w3.org>
Date: Wed, 23 Sep 2020 16:55:40 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-697691447-1600880139-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:17 UTC