- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 12 Apr 2018 14:36:08 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `How do layout and size containment interact with column/page fragmentation?`, and agreed to the following resolutions: * `RESOLVED: You're allowed to have forced breaks inside a layout contained thing but you can't propagate the break to the parent.` * `RESOLVED: Elements with size containment are monolithic for the purpose of fragmentation` <details><summary>The full IRC log of that discussion</summary> <dael_> Topic: How do layout and size containment interact with column/page fragmentation?<br> <dael_> github: https://github.com/w3c/csswg-drafts/issues/2527<br> <dael_> florian: We noticed containment was underdefined relating to fragmentation. Discussion conclusion is that elements with size containment should be monolithic for fragmentation.<br> <dael_> TabAtkins: Size yourself like you're empty<br> <dael_> florian: Then layout yourself as if you have no content. That's size containment. That used to be an effect of layout containment<br> <dael_> florian: There are cases where it's useful to do it without size.<br> <dael_> TabAtkins: Layout ctonainment is whatever happens inside of you it doesn't effect the rest of the page.<br> <dael_> dbaron: Doesn't this need to apply to that?<br> <dael_> fantasai: I think if you have layout containment you need to trap all forced breaks.<br> <dael_> TabAtkins: Which I believe it does already<br> <dael_> dbaron: If you're moving things around inside the layout containment it can effect the breaks<br> <dael_> astearns: Elements with size or layout containment should be in the resolution.<br> <dael_> fantasai: But layout containment can grow and shrink so it should be allowed to fragment like a normal container.<br> <dael_> astearns: If we allow a layout contained thing to fragment it means it has layout effects outside the boundery it's supposed to contain<br> <dael_> fantasai: But it's only changing size of container which it does.<br> <dael_> TabAtkins: Yes, spec says it's except for size is not trapped<br> <dael_> fantasai: Layout containment should trap forced breaks. Size containment can fragment normally, all that content overflows and it doens't grow in size. When we fragment we put it back together like it's exactly the same height as a monolith.<br> <dael_> florian: It's poss to impl, but the down side if you have a block tightly sized to contain several lines of text. The break would be 3.5 lines in the block. Regulate would be 3 lines in the first 4 lines in the second and so there would be one line overflowing the last box. It seems worse to slice the line. But what you said is possible.<br> <dael_> fremy: If next page is different size you size based on first page?<br> <dael_> florian: It'll work.<br> <dael_> TabAtkins: There are cases you can guar that you should have these effects and this keeps you honest because if you make a mistake you paint badly and it's obvious instead of your performance sucks.<br> <dael_> florian: WE have one resolution that layout containment traps forced breaks. That's missing.<br> <dael_> astearns: If they can fragment why are we trapping them?<br> <dael_> emilio: Size can, layout can't.<br> <emilio> s/emilio/fremy<br> <dael_> florian: No, relayouts inside a layout contained element shouldn't effect parent other then overall size changes. If we don't trap forced breaks arbitary changes will have effects outside. Like if you change widows inside you propagate all the way up.<br> <dael_> fantasai: astearns has a point because a forced break is realtive the same. THe forced breaks can't propagate out. If you say page-break-before:always at the top it takes effect before the section and that shouldn't happen if it has layout containment.<br> <dael_> astearns: So you're just not allowing forced breaks to propagate to parent. I'm good with that.<br> <dael_> fantasai: WE should be quite clear on that. It's subtle.<br> <dael_> dbaron: Spec may already say this.<br> <dael_> several: I don't think so.<br> <dael_> florian: Bullet 2 is fragmentation is if you have regions or overflow fragments.<br> <dael_> florian: I think we should add waht you said.<br> <dael_> fantasai: You're allowed to have forced breaks inside a layout contained thing but you can't break to the parent.<br> <fantasai> s/can't break/can't propagate the break/<br> <dael_> astearns: Prop: You're allowed to have forced breaks inside a layout contained thing but you can't propagate the break to the parent.<br> <dael_> astearns: Objections?<br> <dael_> RESOLVED: You're allowed to have forced breaks inside a layout contained thing but you can't propagate the break to the parent.<br> <dael_> florian: For size containment. Making them monolithic is a thing we can do. non-monolithic can works but triggers overflow. Do we prefer slicing sometimes or arbitary overflow sometimes? I prefer slice.<br> <dael_> astearns: If we preserve the size by disassociating the fragments pas thte first one with the layout thy should cotnain I prefer the first.<br> <dael_> florian: right. From end user reason PoV slicing seems better.<br> <dael_> astearns: fantasai to you object?<br> <dael_> fantasai: [missed]<br> <dael_> RESOLVED: Elements with size containment are monolithic for the purpose of fragmentation<br> <dael_> astearns: Anything for layout contained items?<br> <dael_> TabAtkins: Aside from the trapping fragmentation can change size and that's allowed to happen.<br> <dael_> TabAtkins: None of the containments prevent outside information to come in.<br> <dael_> astearns: It's communications both ways. This outside says you need to fragment and the thing inside says here's how I'll do it. It's 2 way.<br> <dael_> TabAtkins: But the communication out is only about size.<br> <dael_> astearns: Anything else on this issue?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2527#issuecomment-380827863 using your GitHub account
Received on Thursday, 12 April 2018 14:36:19 UTC