[css-layout-api] Missing fragments and absolute children

[bfgeek]

<div style="display: layout(foo);">
  <div id=child1></div>
  <div id=child2>
    <div id=abspos></div>
  </div>
</div>

registerLayout('foo', class {
  layout(children) {
    const fragment1 = children[0].layoutNextFragment();

    return {childFragments: [fragment1]};
  }
});

What should be the behaviour of the abspos child?

[css-meeting-bot]

The Working Group just discussed Missing fragments and absolute children, and agreed to the following:

• RESOLUTION: Abspos parented to custom layout elements have static pos computed similar to flex and grid children
• RESOLUTION: The rules for abspos containing blocks is not changed with the presence of custom layout.
• RESOLVED: custom layout must return all fragments, otherwise return an error and fall back to block layout

The full IRC log of that discussion

<heycam> Topic: Missing fragments and absolute children
<heycam> github: https://github.com//issues/775
<heycam> iank_: in the Layout API, it's possible to have multiple children
<heycam> ... in the example in the issue, the second child has an abspos child in it
<heycam> ... its containing block is higher up in the tree
<heycam> ... inside of layout, we only lay out the first child, and return it
<heycam> ... what should the behaviour of the abspos be?
<heycam> Rossen: is there an expectation for anything to happen to the child box?
<heycam> iank_: in the current API, you can just leave out children
<heycam> ... and they don't lay out
<heycam> eae: effectively it's display:none
<heycam> ... so wouldn't it make sense for their children not to show up?
<heycam> Rossen: there are two things
<heycam> ... either the abspos child will be lifted outside the scope of the display:layout function grandparent, or not
<heycam> ... if it's lifted outside of it, I'm assuming layout will happen in the normal way
<heycam> iank_: your assumption is that it will display the abspos child somewhere else
<heycam> Rossen: if it's positions outside the scope of the display:layout
<heycam> ... would all abspos elements reach their containing block, during custom layout?
<heycam> ... you can have a bunch of inner levels of custom and normal layout
<heycam> ... will there be a discontinuity in that process?
<heycam> ... my assertion is that it shouldn't
<heycam> ... one potential problem is that if you rely on something as part of the custom layout, in that interleaving, and that's not calculated, you might get wonky results
<heycam> ... e.g. if you don't lay out child 2, and the abspos position depends on child 2's position, you'll have to syntehsize something for the static pos
<heycam> ... btu that's about it, or you might ahve something that is switching writing modes or whatnot
<heycam> ... but again my assertion here is that this shouldn't have an effect apart from residual things like static pos
<heycam> iank_: I'm fine with that
<heycam> ... what should happen with the static pos?
<heycam> Rossen: (a) we don't want to have a loss of content, regardless of what happens to the custom layout parent
<heycam> ... i.e. the abspos box should not just disappear, unless you explicitly say so
<heycam> dbaron: so you're saying is it should have its normal abspos containing block, and the custom layout is never an abspos containing block>
<heycam> Rossen: no
<heycam> ... my assertion is the box with abspos element will always generate a box, and it will be parented to the appropriate containing block, which may or may not be custom layout
<heycam> ... distinction is propagating through custom layout layers, second is ending up at a non-custom layout containing block
<heycam> ... so besides calculating some invalid or default static pos
<heycam> iank_: somethign along the lines of pretend that it did generate a (0, 0, 0, 0) fragment
<heycam> fantasai: for custom layout, unless we might want to let it control the static pos, but certainly you could just use the rules in flexbox
<heycam> ... which is you pretend that the static pos rectangle is the whole flexbox
<heycam> Rossen: what happens if a flex item is the whole area
<heycam> fantasai: if display:layout and child2 are both doing custmo layout
<heycam> Rossen: the outer one is the containing block
<heycam> fantasai: the parent gets used as the static pos relative
<heycam> ... if you didn't lay it out
<heycam> Rossen: then its parent
<heycam> fantasai: but that box still needs a position
<heycam> ... why isn't there a box?
<heycam> dino: on child2 if you put display:none, what happens to abspos?
<heycam> Rossen: same as always, it wouldn't display
<heycam> dino: why is different from not laying it out?
<heycam> Rossen: we shouldn't itnroduce things that are like display:none just because didn't lay out a box
<heycam> fantasai: it should just be (0, 0, 0, 0)
<heycam> dino: sure
<heycam> fantasai: the box should still existing, and you just happen to not position it
<heycam> Rossen: just becomes a position and an empty rect
<heycam> dino: if it had a position, you'd use that
<heycam> Rossen: hwihc is what I would epect
<heycam> iank_: yes
<heycam> Rossen: if my containing block some span e.g., didn't have anything else than the abspos, it still has a position calculated for it
<heycam> eae: makes a lot of sense
<heycam> Rossen: the static position of an abspos elemenet, with a custom layout parent, is based on that parent's fragment's box
<heycam> fantasai: similar to how static pos of a box that is parented to a flex container uses the rectangle of the flex container to calculate it static pos, rather than any hypotehetical "would have been" layout like block layout
<heycam> Rossen: the summary here is taht the static pos of abspos elements parented to custom layout is the same as in CSS, based on the rectangle of that parent
<heycam> fantasai: similar to flex/grid, not block
<heycam> ... in block and layout they use the hypothetical position if they weren't positioned
<heycam> ... for flex and grid, we don't try to calculate where it would have been, pretend you would have coincided with your entire parent
<heycam> RESOLUTION: Abspos parented to custom layout elements have static pos computed similar to flex and grid children
<fantasai> s/RESOLUTION/RESOLVED/
<heycam> Rossen: next problem, you've computed static pos, that's great. you end up with a custom element that has position:relative
<heycam> dbaron: there's an easier piece we should resolve first
<heycam> fantasai: proposal is that custom layout does not interrupt propagation of abspos
<heycam> dbaron: it doesn't change the rules for when something is an abspos containing block
<heycam> Rossen: the abspos is never exposed to the custom layout in any form
<heycam> iank_: other potential thing is about the behavior of the second child, in this case
<heycam> ... you are thinking that child2 should get laid out with available size zero, and would still show up?
<heycam> ... it's specced as not showing up
<heycam> ... that might be somethign easier to resolve on
<heycam> RESOLUTION: The rules for abspos containing blocks is not changed with the presence of custom layout.
<heycam> s/RESOLUTION/RESOLVED/
<heycam> Rossen: next is, if the containing block is custom layout
<heycam> fantasai: if you don't explicitly lay out a child the layout engine resolves its size and position to zero
<heycam> frremy: I'm fine with that, but it will not show up
<heycam> ... I think that's ok, but if I don't put return it, I don't want it in the layout
<heycam> frremy: similar to display:contents or something
<heycam> ... if I don't want to include a particular element, implementing something like -webkit-line-clamp, I don't want them generating
<heycam> dbaron: if I were to try to think about how I wanted custom layout to deal with being an abspos containing block, I feel like I would want to two different options probably
<heycam> ... don't necessarily need both options in v1
<heycam> ... one of them would be: I want a custom layout, might be an abspos conatining block, I want it to handle things I'm the abspos containing block for using the default rules
<heycam> ... I don't want to handle those with custom layout, just handle the in flow contents
<heycam> ... other option: I also want to take over layout for the descendants I'm the abspos containing block for
<heycam> ... and in that case, in many cases I'd want to get those sets of children separately
<heycam> ... i.e. process the in flow ones first, then the abspos ones
<heycam> iank_: I could imagine an API that is two additional callback functions, one where your'e routinign children, yes pass this to parent, no keep this one to myself
<heycam> ... and an out of flow layout pass, which gives you the children you're a containing block for
<heycam> ...and go ahead ans apply whatever abspos rules you want
<heycam> frremy: that;s useful for the grid polyfill
<heycam> ... if you set grid-column on them you still need to be able to place them in columsn, even if they're abspos
<heycam> ... doesn't have to be in the layout step, could be a separate step
<heycam> Rossen: only problem I have with this, is if you select which children you want to handle, that goes against the resolution we just had before
<heycam> frremy: what does grid do?
<heycam> Rossen: the API proposed, here are the children going through, I want to keep certain ones ... unless we specify we're not even going to expose abspos to your children
<heycam> ... because you really don't need to
<heycam> iank_: I think it's a niche use case, a callback for routing
<heycam> Rossen: but that's a more advanced feature
<heycam> Rossen: so, current issue is, element with custom layout, it's also an containing block for abspos, there's a descendant abspos, and the custom layout does no layout. what happens to the rest of the children?
<heycam> ... one of the assertions we should have here is that that child, at that level, is just a normal first level child, it has to be laid out
<heycam> ... it shouldn't be any different from other ones
<heycam> ... so if I have two children that are inside of this custom layout, one is an immediate child, one is a descendant, regardless how deep the descenadnt is, it's something I need to handle at the first level
<heycam> ... if I can decline layout for a first level child, I should be able to do that for the abspos descendant too
<heycam> ... might be different for layout logic, that's your business
<heycam> ... but the point is that I have a collection of children fragments that came up to me, if I decide to drop them all, I can
<heycam> ... from that point of view I don't think we need anything specific to abspos, but we still need to be clear as to what the rules are
<heycam> iank_: yes, we can discuss that
<heycam> fantasai: the original issue, we've got an element whose static pos we need to find, static pos is not the custom layout in this particular case, because it's a child of a child of the custom layout
<heycam> ... custom layout is responsible for laying out the child, when it does, that box will determine the static pos of the grandchild
<heycam> ... if the custom layout doesn't lay out that child, we still need to know where the static pos
<heycam> Rossen: we resolved that
<heycam> fantasai: we resolved that for a child of the custom layout, this is for a grandchild of the custom layout
<heycam> fantasai: it's different because if we don't run layout on the child of the custom layout, we don't know where it is
<heycam> ... it's a regular inflow child of the custom layout, inside that it the abspos
<heycam> ... the abspos's position is dependent on the size/pos of child2
<heycam> ... we don't have answer for the size/pos of child2
<heycam> Rossen: my point in the beginning is that the static pos of the abspos, is the origin
<heycam> ... this is relative to its parent
<heycam> ... if the parent doesn't compute to anything, it will be to the origin of its parent
<heycam> ... at some point there is some ancestor where that origin is defined
<heycam> fantasai: we didn't resolve on that
<heycam> Rossen: this is how custom layout is defined to work, relative to parent
<heycam> fantasai: I know it's relative to parent
<heycam> dbaron: I think we need a definition of what happens if custom layout decides not to lay out something
<heycam> ... in our engine, layout code can't not lay out something
<heycam> ... I suspect other engines are probably similar
<heycam> ... if you get laid out at (0, 0, 0, 0), whatever it is, it should be defined somewhere
<heycam> ... once we have that definition, it resolves this
<heycam> [-- break 20 mins --]
<fantasai> ScribeNick: fantasai
<fantasai> fantasai: key question is what dbaron said, what do we do to fragments which are not laid out?
<fantasai> frremy: A common use case for not laying out a child is when you want, e.g. lay out items until you run out of space and then have a continuation marker (like ...)
<fantasai> frremy: you want to just stop laying out at that point
<fantasai> frremy: Should try to address this in custom layout
<fantasai> frremy: makes sense to not generate a box for items that aren't laid out
<fantasai> frremy: rather than defaulting to (0,0,0,0)
<fantasai> frremy: So prefer to define same as 'display: none' or define something else similar
<fantasai> frremy: or throw an exception for now and figure it out later
<fantasai> frremy: Don't think it's useful to create a box that's zero-sized, this isn't useful
<fantasai> frremy: and not generating the box is sometimes useful
<fantasai> Rossen: I think not showing things is useful
<fantasai> myles: max-lines is simlar
<fantasai> similar
<fantasai> Rossen: Should be able to not lay out. If we don't lay out anything, the question is would we absoluely generate no fragment/box, or would we end up with an empty size and origin position?
<fantasai> s/or w/W/
<fantasai> Rossen: We still have to answer questions like from the OM, what's the size/position
<fantasai> Rossen: So what would make the most sense?
<fantasai> frremy: Compromise would be to have a box at zero/zero, but it just doesn't paint
<fantasai> iank_: Agree that we should say it doesn't paint.
<fantasai> iank_: but what about the rest of the subtree?
<fantasai> iank_: do we return zero for everything all the way down the subtree, or do we contineu with layout?
<heycam> fantasai: for max-lines specifically, frmo an implementation perspective, I think it does make sense to lay everything out
<heycam> ... that's a use case where you want to hide and show things dynamically, not having to relayout would be useful
<heycam> ... more generally I'm not sure
<heycam> ... if you're not going to display the stuff
<heycam> ... but you could display:none things you don't want to display
<heycam> Rossen: but this is a layout time decision
<heycam> eae: for max-lines it would be nice to not reflow things that aren't going to be displayed, unnecessary work
<heycam> koji: this could create next fragments, it's more about fragmentation, when the next fragment containiner is missing
<heycam> fantasai: you could make the same argument here
<heycam> ... we will support fragmentation
<heycam> iank_: it might be reasonable to say layout doesn't happen, and all CSSOM APIs return zero, getClientRects doesn't anything
<fantasai> iank_: Saying all this without imple experience, might change opinion based on experienc
<fantasai> iank_: everything returns zero, empty array for line boxes
<fantasai> dbaron: I think this is a magical semi-displayed case
<fantasai> dbaron: I'd rather have a lyout and have the APIs return a consistent state
<fantasai> iank_: we could also define a consistent state
<fantasai> dbaron: Sounds messy
<fantasai> iank_: I'm a little bit torn, agree with fremy that use cases for this are very valuable
<fantasai> Rossen: Another lense to use for reasoning, how would you serialize your collection of children in the case that fremy gave?
<fantasai> Rossen: e.g. for accessibility purposes
<fantasai> Rossen: Would want accessibilty tool to walk the same tree as what's visible
<fantasai> Rossen: Would you synthesize things in the AT or what?
<fantasai> iank_: Not accessible to normal users, so shouldn't be accessible to AT
<fantasai> iank_: The way to make this decision would be, what should happen in the max-lines case?
<fantasai> iank_: Could also punt this for now, get impl experience
<fantasai> iank_: Our current behavior is that you need to return all the fragments. Otherwise we'll fall back to block layout
<fantasai> Rossen: That's nice. Very predictable and verifiable
<fantasai> iank_: We should investigate, then reopen this issue.
<fantasai> Rossen: In which case, this is an error
<fantasai> iank_: Yep
<fantasai> Rossen: Fix your code. Make it work.
<fantasai> heycam: I think it might be easy to accidentally lose your custom layout
<fantasai> Rossen: Exactly
<fantasai> heycam: Might be that you change your ordering in certain window sizes, and then it breaks
<fantasai> fantasai: I think if you can't loop correctly over all the items in this list ...
<fantasai> Rossen: You shouldn't be doing custom layout.
<fantasai> iank_: Grid iterates in a particular order
<fantasai> frremy: But here you need to iterate in the right order
<fantasai> Rossen: Sounds like for this level of where we are, this is areasonable error case handling
<fantasai> Rossen: It is simple, it's easy to describe, and should be easy to fix on the script size
<fantasai> s/size/side
<fantasai> Rossen: With that, plus previous two resolutions, then we have a clear answer to what happens with abspos children
<fantasai> Rossen: If we need to get more sophisticated later, we can
<fantasai> Rossen: implementtion experience may suggest a beter pattern
<fantasai> frremy: Would need to feature detect somehow, whether the browser supports laying out all the boxes or not
<fantasai> iank_: Need to resolve on this, then: if you don't return all the fragments, we return an error and fall back to block layout
<fantasai> iank_: Falling back to block layout is what happens if the layout function throws an error
<fantasai> iank_: You can check by ...
<fantasai> heycam: What about existing content, that falls back to block currently and throws an error, and then later it starts to drop content
<heycam> fantasai: could fall back to content disappears?
<heycam> ... but we don't like dropping content
<fantasai> Rossen: We could fall back to 100em bright red...
<fantasai> iank_: Two ways to deal with that.
<fantasai> iank_: One is to use-count
<fantasai> iank_: Other, if that number is sufficiently hight, we can add a layout option
<fantasai> iank_: It's a bit heavy handed
<fantasai> iank_: but we can use-count it to check
<fantasai> ...
<fantasai> philipwalton: Could put a note in the spec explaining what we're planning to do
<fantasai> Rossen: This is simple, easy to spec, easy to explain, easy to see if you messed up. Can revisit later. It's a good solution.
<fantasai> RESOLVED: custom layout must return all fragments, otherwise return an error and fall back to block layout