Re: [csswg-drafts] [css-display][css-ruby][css-contain] Becoming a formatting context

The Working Group just discussed `becoming a formatting context root`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: becoming a formatting context root<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/1457<br>
&lt;fantasai> TabAtkins: we addressed this a bit in the past, text we had was bad<br>
&lt;fantasai> TabAtkins: layout containment needs a formatting context root<br>
&lt;fantasai> TabAtkins: wanted to say that the element ends up being an FC root somehow<br>
&lt;fantasai> TabAtkins: only a few places where that's difficult<br>
&lt;fantasai> TabAtkins: Some are easy<br>
&lt;fantasai> TabAtkins: flow root, table, flex, grid, all satisfy condition<br>
&lt;fantasai> TabAtkins: for display: flow, becomes flow-root<br>
&lt;fantasai> TabAtkins: Next issue is with ruby<br>
&lt;fantasai> TabAtkins: ruby is effectively inline element<br>
&lt;fantasai> TabAtkins: wanted to create a ruby inline block thing<br>
&lt;fantasai> florian: we don't have that yet. If it's not useful, do we really want to add it?<br>
&lt;fantasai> TabAtkins: Better to fill the boxes, so this is consistent and defined<br>
&lt;fantasai> fantasai: How about saying layout containment doesn't apply to inlines. If you want it to apply, turn it into an inline block<br>
&lt;fantasai> Xidorn: create a wrapper box?<br>
&lt;fantasai> TabAtkins: wrapper boxes are scary and bad<br>
&lt;fantasai> fantasai: We have block ruby, it just creates a wrapper<br>
&lt;fantasai> TabAtkins: Make something block-like, either inline-block or block or somehting<br>
&lt;fantasai> fantasai: For most of these layout modes, the FCR-ification doesn't have much effect. Layout is fundamentally the same<br>
&lt;fantasai> fantasai: but for inlines and ruby, it's a very significant change to layout<br>
&lt;fantasai> fantasai: I'd rather say that layout containment just doesn't apply here, so the author is making an explicit decision about the layout change they're getting<br>
&lt;fantasai> TabAtkins: My two constraints for this problem is that contain should work on ruby because it works on inline, and that whatever effect it has should be possible to get without using 'contain' for its side-effect<br>
&lt;fantasai> florian: Suggestion is to apply contain to neither inline nor ruby<br>
&lt;fantasai> fantasai: that is my suggestion, yes<br>
&lt;fantasai> astearns: We don't have contain and inline ruby<br>
&lt;fantasai> astearns: is there a use case for contain on inlines?<br>
&lt;fantasai> fantasai: You can't get that. It turns into inline-block<br>
&lt;fantasai> astearns: So if we do this, what do we lose?<br>
&lt;fantasai> TabAtkins: Just that authors have to take an extra step of declaring inline-block<br>
&lt;fantasai> fantasai: I'm arguing that's a feature, not a bug<br>
&lt;astearns> s/if we do this/if we choose not to apply contain to inlines/<br>
&lt;fantasai> fantasai: If the author wants to have an inline block, should be explicit about it. if they didn't, then they're not going to be happy anyway<br>
&lt;fantasai> TabAtkins: internal table elements?<br>
&lt;fantasai> florian: We already resolved they don't apply<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-342337691 using your GitHub account

Received on Tuesday, 7 November 2017 00:46:44 UTC