[go: up one dir, main page]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-overflow-4] Confirm interaction of positioned elements and continue:discard #2971

Open
frivoal opened this issue Jul 31, 2018 · 3 comments

Comments

@frivoal
Copy link
Collaborator
frivoal commented Jul 31, 2018

The spec says:

Positioned elements whose static position is in the discarded content are not rendered.

Are we sure about that? Discussions in the Syndey F2F meeting seemed to generally converge on this, but other possibilities were raised.

@frivoal frivoal added the css-overflow-3 Current Work label Jul 31, 2018
@fantasai
Copy link
Collaborator

Judging by https://www.w3.org/TR/css-break-4/#transforms and the idea that discarded contents are like pages that don't get rendered, I think actually discarding contents should be based on where they are positioned.

@frivoal
Copy link
Collaborator Author
frivoal commented Aug 13, 2021

Based on #2971 (comment), 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.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-overflow-3] Confirm interaction of positioned elements and continue:discard.

The full IRC log of that discussion <dael> Topic: [css-overflow-3] Confirm interaction of positioned elements and continue:discard
<dael> github: https://github.com//issues/2971
<dael> astearns: Should we wait for florian?
<dael> fantasai: Let me see state of discussion
<dael> fantasai: Question is what happens to elements with relative position or sticky and how to handle if anchor is in discarded section of content
<dael> fantasai: Behavior when paginating may be different.
<dael> fantasai: Here we need more feedback. Don't know if we can resolve
<dael> fantasai: What do we want to spec for stuff that occurs in discarded content but positioned into earlier flow that is not discarded
<dael> astearns: need more feedback. Anyone in mind?
<dael> fantasai: Various people working on impl and familiar with fragmentation model in their engine
<dael> astearns: Anyone on call have an opinion?
<dael> astearns: Sounds like raising this issue as needs more GH discussion and we'll take back there

@astearns astearns removed the Agenda+ label Sep 1, 2021
@fantasai fantasai added css-overflow-4 and removed css-overflow-3 Current Work labels Feb 1, 2023
@frivoal frivoal changed the title [css-overflow-3] Confirm interaction of positioned elements and continue:discard [css-overflow-4] Confirm interaction of positioned elements and continue:discard Feb 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants