- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Apr 2018 07:36:07 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Becoming a formatting context`, and agreed to the following resolutions: * `RESOLVED: layout and paint containment does not apply to non-atomic inlines` * `RESOLVED: clarify the definition of what and how a FC is created` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Becoming a formatting context<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1457<br> <florian> https://github.com/w3c/csswg-drafts/issues/1457#issuecomment-379156461<br> <dael> florian: Start reading here ^<br> <dael> florian: We've been discussing for a while, there's something in contain saying things must become a formatting context root. We've been deciding if this is the generic thing that should go in and if yes does it apply to inlines or ruby.<br> <dael> florian: fantasai has been pushing back for combined reasons. 1) do it make sense to layout and paint containment apply to non-atromic inlines. If yes we have to FC them. If not we shouldn't apply that. I'm reasonably convinced they shouldn't apply to inlines. This is a radically different thing and if you want hte layout ask for it.<br> <dael> florian: I agree there is no need for containment to apply on these things.<br> <dael> TabAtkins: Yeah.<br> <dael> florian: Maybe we can resolve on that?<br> <dael> Rossen: Prop: Layout containment and paint containment do not apply to non-atomic inlines.<br> <dael> smfr: THings with more then one box?<br> <dael> florian: Principle box.<br> <dael> dbaron: smfr means more then one fragment. I think they would apply to something inside a multicol over many columns. So what that means might be a problem. But if you have layout and size cotnainment for a thing split over multi columns you have to decide how to paginate and that gets interesting.<br> <dael> TabAtkins: It's either 0 or fixed height.<br> <dael> dbaron: Do you split arbitrarily or it has to be one piece? You can't use middle line breaks because it's not containing.<br> <dael> florian: I think containing and fragmenting is a separate discussion we should look at.<br> <dael> dbaron: File and issue?<br> <dael> florian: Yes.<br> <dael> RESOLVED: layout and paint containment does not apply to non-atomic inlines<br> <dael> florian: Do we need a term for this? There's a bunch of specs that talk about establishing a BFC. In flex is says that you establish a FC and it means blah blah. However in overflow spec when you set it to non-visible it must establish a formatting context. Same with multi column spanners. It's not a new type of FC, we jsut say you need to get one of these.<br> <dael> florian: In this case when you need to be a FC everything is already one except blocks and blocks become BFCs. We can just say that.<br> <dbaron> I filed https://github.com/w3c/csswg-drafts/issues/2527 on the fragmentation and contain issue<br> <dael> florian: What I'd like to have is...have an anchor term that is establish a formatting context because then it says what type of FC it is. We've many times said BFC and that's not what we meant.<br> <dael> florian: To try and stop from BFC-izing things having a term that does that sounds nice to me.<br> <dael> florian: fantasai was pushing back against this.<br> <dael> fantasai: I think it's "establishes a formatting context" and there's a definition for that.<br> <dael> florian: For what a FC is, but not when you establish one.<br> <dael> fantasai: Okay. We can add one to display.<br> <dael> florian: That definition should include that if you invoke that on non-atromic inlines you wrote your spec wrong because you need to blockify them first.<br> <dael> florian: I've got suggested text.<br> <dael> fantasai: There's a definition for a new formatting context but it doesn't say type.<br> <dael> florian: Buy you made the mistake of the wrong kind so if we get it repeatedly wrong.<br> <dael> fantasai: Some specs have said BFC when they meant FC. We have an anchoring term, if you have a problem with the definition we can adjust.<br> <dael> fantasai: Specs like multicol were written before flex and grid so writers were thinking about things that aren't blocks.<br> <dael> Rossen: The definition you're referring so, can you paste a link?<br> <dael> Rossen: florian if the definition is not enough, then where is your proposed text?<br> <dael> florian: Toward the bottom of the comment https://github.com/w3c/csswg-drafts/issues/1457#issuecomment-379156461<br> <dael> florian: [reads]<br> <dael> fantasai: It's not true. If you try and establish on a table row.<br> <dael> florian: It doesn't invoke on internal display types.<br> <dael> TabAtkins: If you're trying to FC [missed]<br> <dael> florian: I won't block on this, but it seems reasonable to me given that we've made the mistake multiple times after creation of flexbox and grid.<br> <TabAtkins> TabAtkins: This'll go in the guidance, like "don't blockify and inlinify the same element".<br> <dael> fantasai: I'd like to put effort into merging the wording.<br> <dael> Rossen: Let's resolve on clarifying the definition of what and how a FC is created.<br> <dael> Rossen: Objections?<br> <dael> RRESOLVED: clarify the definition of what and how a FC is created<br> <dael> RESOLVED: clarify the definition of what and how a FC is created<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1457#issuecomment-380357179 using your GitHub account
Received on Wednesday, 11 April 2018 07:36:10 UTC