- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Jul 2018 16:37:23 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Blockifications should establish BFC in block containers`, and agreed to the following:
* `RESOLVED: keep blockficiation and establishing FC are independent`
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: Blockifications should establish BFC in block containers<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/2673<br>
<rego> it seems oriol is not listening, despite he's on webex :(<br>
<dael> TabAtkins: Oriol has been asking for if blockification should auto establish btc rather then occiationally explicit. fantasai and I disagreeing because they don't happen every time<br>
<rego> so he should participate here on IRC I guess<br>
<dael> TabAtkins: If anyone disagrees and things blockification should auto be a BFC, great let's talk. If not looking for resolution of support<br>
<dael> Rossen_: You saying tha tblicification doen'st force BFC?<br>
<Oriol> I have problems with the cisco program but I'm in IRC<br>
<dael> TabAtkins: Not intrinisically.<br>
<dael> Rossen_: Example?<br>
<dael> TabAtkins: Have to look<br>
<dael> TabAtkins: Any time we blockify and inline block does not cause it to become a FC it just goes to block<br>
<dael> fantasai: That's true in that it does not change hte display computation. THat's required by backwards compat.<br>
<dael> fantasai: We could change to not change display and also make it a formatting context. We do that for lfoat abspos and others<br>
<dael> fantasai: Right now when we do blockification in cases where new element will establish new FC anyway. If we apply blickificaiton in flow blocks I don't think we'd want new FC. Grid items currently blockify and a subgrid isn't a new FC<br>
<dael> Rossen_: does subgrid blockify?<br>
<dbaron> q+ to comment on flow-root point from the issue<br>
<dael> fantasai: If we did we'd need an exception. It has to blockify because if it's an inline grid it becomes not an inline. When it's a grid item...if you have an item inside a grid that element is blockified. Blockification if it says display inline it becomes block. inline-table become block, inline-grid becomes block. But a subgrid isn't a new FC because it intertwinces with grid outside. Can't say it's a new FC, but it is blockified<br>
<dael> fantasai: I don't htink we can tie these two concepts together. block makes it a block. They almost always coincide but I don't think the concepts are intrinisicaly bound and shouldn't be tied in spec<br>
<dael> florian: Exception of subgrid this is an editorialtwist as to if you describe separately or together. So it's editorial.<br>
<Oriol> But I think a BFC is desired if you have `display: inline flow-root`. CSS DIsplay says it becomes `flock flow`, and a future feature might blockify without forcing BFC. Then the flow-rootness will be lost<br>
<astearns> ack dbaron<br>
<Zakim> dbaron, you wanted to comment on flow-root point from the issue<br>
<dael> dbaron: I think one other point in the issue from Oriol . I think Oriol trying to put in IRC too<br>
<dael> dbaron: Current blockification remove flow-root nature. If blockification always makes things FC it's fine. If it doesn't then maybe blockification rules need to be fixed so if you say flow-root you don't lose that<br>
<dael> fantasai: So far cases where lose flow-root is converting inline flow-root or a run-in flow-root. In case of inline block we can't change how display is computed due to backwards compat.<br>
<dael> fantasai: Every other casing where flow-root is blockified it establishes a new FC anyway.<br>
<dael> fantasai: We're flowing it, we're abspos it, putting it in a grid or flexbox. These are cases where element that is a block container it establishes a new FC<br>
<dael> dbaron: So in subgrid it's not possible to be a new FC?<br>
<dael> fantasai: Matter of termonology, but fundimental idea of a new FC is there's no intertwining between new and old FC. If there's info passed through the bounderies when you do something like whitespace collaposing it's porous. Same is true for display:block, margins collapse through boundary. The contents inside and outside participate<br>
<dael> fantasai: New FC creates a barrier without that bleedthrough. THe justificaiton and alignment doesn't pass through the inline block boundary. Same as a block element with new FC.<br>
<dael> fantasai: For a grid, if you nest a grid inside a grid same thing applies. No interactions between grid tracks inside a nested grid. Subgrid you do have negotiaion between inner subgrid context and outer parents and siblings. THey participate together in sizing algo<br>
<dael> fantasai: The size declarations and names of lines on parent pass to subgrid. There is fundamental bleeding through of the content and the layout calc. To say it's a new FC doesn't make sense.<br>
<dael> dbaron: Makes sense to me. Some point earlier I thought you said that...something about how these were still block formatitng context.<br>
<dael> fantasai: Grid items are considered grid level, not block. They participate in grid FC. But there is blockificaiton process that changes display values to make them block-like. We convert anything with a non-block outer display to a block<br>
<dael> dbaron: And one can be a subgrid?<br>
<dbaron> s/one/one of the blockified things/<br>
<dael> fantasai:You run blockificaiton on every grid item. You run it through blockification IMight be a no-op, but you run through.<br>
<dael> fantasai: Was we decided to do subgrid with a new type the display-type of a subgrid needs to be declared. If you say grid or inline grid doesn't really matter.<br>
<dael> fantasai: Blockificaiton process turns inline on subgrid to grid.<br>
<dael> dbaron: I worried you said display block could be subgrid<br>
<dael> fantasai: No, you can't<br>
<dael> florian: Blockification is really dis-inline-ification<br>
<dael> fantasai: In a sense. WE have outer display type which says how your behavior is when in flow layout. Outside of flow layout distinction between inline and block has no meaning and is ignored. Each display value corresponds to a state.<br>
<dael> fantasai: If I take subgrid and put it in a bfc it will not behave as subgrid, but it'll be the fallback behavior.<br>
<TabAtkins> Core point tho: grid items are blockified, subgrids are grid items (by definition) but aren't FCs (by definition), so blockification *cannot* imply FCification in general.<br>
<dael> fantasai: weither declared inline or block grid it'll make a difference in partiipation once in block container<br>
<dael> astearns: Back to original issue: We have a choice of keeping things as we are where blockification and formatting context are discussed sep. Or we changes that blockification implies a FC but it can be overwritten in places like subgrid<br>
<dael> astearns: Argument that 2 things are sep is compelling to me because having both explicit sounds easier to comprehend. I like that it's explicit<br>
<Rossen_> q+<br>
<florian> since this makes no behavior difference, this is editorial, and I like to leave it up to the editors to describe it the way they want. That helps the whole prose be coherent<br>
<dael> astearns: Argument to tie together is that there may be situations in the future where we might forget about forcing FC in blockificaiton case where we need it to happen. Benefit for the explicit call outweighs danger of forgetting to make that call in the future.<br>
<astearns> ack dbaron<br>
<AmeliaBR> Is there any consequence of blockification that *is* necessary for subgrid? Or can it just be that "grid-items are blockified (and create a formatting context), *except* for those with `display: subgrid`"?<br>
<fantasai> AmeliaBR, inline-grid needs to be converted to grid<br>
<fantasai> ('display' value)<br>
<dael> dbaron: blockficiation without FCification doesn't work in a block context. IN grid it's fine, but in block context it removes the things that are supposed to be FC> I think that's a piece Oriol doesn't like. Maybe it's that we never will use and so it's okay. Might be worth noting.<br>
<astearns> ack Rossen_<br>
<dael> astearns: Make sense to call that out in all current cases you need the 2 in a block context<br>
<Oriol> Yes, the problem is with flow layout<br>
<dael> Rossen_: fwiw, from impl experience we've had this model inside our engine since IE9. During style computation we independently decide inner layout type, outside layout placement (where you will be placed), and 2 aux ones, what is your placement and what is your layout type and that's if you're a BFC<br>
<dael> Rossen_: What I can tell you is they're all independent. But I don't see why we should unless from inline block PoV we have to.<br>
<dael> fantasai: address point from Oriol and dbaron where if you happen to use blockification for block level items question...example is an inline block when blockifies turns into display:block which is pourous. Argument is inline:block should be a Block flow-root and a new FC. Not convinced of that being the expectation.<br>
<dael> fantasai: I think that's part of why it's not in CSS 2.1...distinction between block, block layout, and bfc is not huge. inline block vs a block do form a pair.<br>
<Rossen_> s/what is your placement and what is your layout type and that's if you're a BFC/based on the layout placement and type we compute if you're a BFC and if you require a stacking context/<br>
<Oriol> I think it may be OK if inline-block doesn't become a flow-root, but if you esplicitly specify flow-root, you shouldn't lose it<br>
<dael> fantasai: formatting context establishment is a side effect because they just want this as a block to be a FC, not something they specificially needed.<br>
<dael> fantasai: I'm not sure what you would expect, but becming display:block isn't nec unexpected. If you said inline flow-root it's clear you wanted that but we're getting into fiddly cases and we decided inline-block and flow-root are identical<br>
<astearns> ack dbaron<br>
<dael> dbaron: I think this is a negative side effect of that. Prob fine ofr inline-block, but wierd if flow-root.<br>
<dael> dbaron: I think I'm okay just concluding here<br>
<dael> astearns: And close no change dbaron ?<br>
<dael> dbaron: I think no change and a note pointing out that there is this where if you do blockification without FC and people used flow-root explicitly<br>
<dael> astearns: Need to ask Oriol if he's okay closing with a note.<br>
<dbaron> s/there is this where/it isn't great if/<br>
<Oriol> OK, but note that if a future fewature allows blockification without BFC, then it will be more difficult to change<br>
<dael> astearns: And would anyone else obj to resolve no change except adding a note<br>
<dael> fantasai: 3 ways forward, to be clear.<br>
<dael> fantasai: 1) close no change FC and blockificiation are independant<br>
<dael> fantasai: 2) Blockificiation implies FCificiation so inline block convers to block flow root and we will need an exception for subgrid<br>
<dael> fantasai: 3) revert resolution where we said inline block and inline flow are identicatal and say they're independant and have same behavior except if you blockify.<br>
<dael> fantasai: THat lets you when you blockify inline flow-root it becomes display: flow-root<br>
<dbaron> I'd be fine with (3) based on this discussion but I don't know why we made that resolution to begin with.<br>
<dael> astearns: We're 30 on this issue. My preference would be close no change and raise a new issue on inline block and inline flow-root<br>
<dael> fantasai: We had an issue and resolved on the current. Only reason to re-open is if people want option 3 which gets you independfence for blockificiation and FCification but also clarifies the inline flow-root.<br>
<dael> astearns: Reopening that with this in mind makes sense and doesn't change how we'd resolve here.<br>
<dael> fantasai: fair enough<br>
<dael> astearns: I'd like to close this.<br>
<dael> astearns: Let's resolve that blockficiation and establishing FC are independent and we will add a note on the flow-root issue which can become a github issue to change our previous decision<br>
<dael> fantasai: This is last open issue before CR so we need to open the issue or go to CR<br>
<Oriol> Works for me<br>
<dael> astearns: obj to keep blockficiation and establishing FC are independent<br>
<dael> RESOLVED: keep blockficiation and establishing FC are independent<br>
<dael> astearns: Anyone think we should take up an issue about inline block and inline flow-root?<br>
<dael> florian: Rathe rnot<br>
<dael> dbaron: Don't know context of original decision so hard to know<br>
<dael> astearns: Let's leave at that this week. those in the discussion please decide if open new issue.<br>
<dael> Rossen_: Should we resolve on to CR?<br>
<dael> astearns: Let's give another week and go to CR next week.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2673#issuecomment-405996123 using your GitHub account
Received on Wednesday, 18 July 2018 16:37:30 UTC