W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2021

Re: [csswg-drafts] [css-overflow-3] Confirm interaction of positioned elements and continue:discard (#2971)

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Fri, 13 Aug 2021 20:47:48 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-898712504-1628887667-sysbot+gh@w3.org>
Based on https://github.com/w3c/csswg-drafts/issues/2971#issuecomment-897162571, I thought we should update the spec to something like this:

> 
> * elements with [=relative positioning=] or [=sticky positioning=]
>    whose static position is in the discarded content are not rendered.
> 
> However:
> * elements with  [=static positioning=] whose static position is in the discarded content are not discarded.
> * elements with [=absolute positioning=] whose static position is in the discarded content are not necessarily discarded:
>   if their containing block is in the discarded content,
>   they are themselves discarded,
>   but otherwise,
>   if their 'inset' properties are such
>   that they would be positioned in the first fragment container,
>   they are laid out and rendered
>   (See [[css-break-4#transforms]]).
>   If they would themselves need to be fragmented
>   by the [=fragmentation container=] established by the 'continue' property,
>   the remaining content after the [=fragmentation break=] is discarded as above
>   (recursively if there are nested elements with [=absolute positioning=].
> 

Thinking more, I don't think that actually works, and we should go back to discarding all positioned elements whose static position in in the discarded content. If the containing block for the absolutely positioned element is the fragmentation container established by the continue property itself, and the top property has a specified value that brings the abspos before the fragmentation break then we're fine. However:
* if the containing block is a fragmented descendent of the fragmentation container established by the continue property, and the static position is not in the first fragment, not only would we rather skip laying them out to find the coordinates of the static position, we don't even know the hypothetical width of the subsequent discarded fragmentainer, so we can't lay it out. if `left` and `right` are auto, even if `top` would tell us to bring it into view, we wouldn't know at which horizontal position.
* if the containing block is an ancestor of the fragmentation container established by the continue property, and the static position in in the discarded content, we can't handle something like `top: 0; left: auto; right: auto`, we cannot place it, as we wouldn't know at which horizontal position.

So I think we need to keep discarding all positioned elements whose static position in in the discarded content.

Moreover, we have another issue: even if the static position is in the non discarded content (but also if it isn't), if the containing block is a fragmented descendent of the fragmentation container established by the continue property, and `top` is `auto` but `bottom` is some specified value, we cannot know if that value would be large enough to bring the abspos back into the first fragmentainer without laying out the subsequent fragmentainer(s) to figure out where the bottom is and measure back from there. Not only would we rather skip that work, the inline-size of these hyphothetical discarded fragmentainers aren't defined, so we cannot do that layout.

Therefore, we probably need to add this as well:

> If the block-end edge of the containing block of an absolutely positioned element is in the discarded content, and the inset in that direction of the absolutely positioned element is not `auto`, then the absolutely positioned element is also treated as if it had `display: none` and is not rendered.

Or possibly this:

> If the block-end edge of the containing block of a non-discarded absolutely positioned element is in the discarded content, and the inset in that direction of the absolutely positioned element is not `auto`, then that inset is calculated from the block-end edge of the content box of fragmentation container established by the continue property rather than from the block-end edge of the containing block.

Or possibly this:

> If the block-end edge of the containing block of a non-discarded absolutely positioned element is in the discarded content, and the inset in that direction of the absolutely positioned element is not `auto`, then the block-end of the inset-modified containing block is set to coincide with the block-end edge of the content box of fragmentation container established by the continue property.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2971#issuecomment-898712504 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 13 August 2021 20:47:50 UTC

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