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