Re: [csswg-drafts] [css-display] Reconsider if 'inline-block' and 'inline flow-root' should be syntactically equivalent

The Working Group just discussed `Reconsider if 'inline-block' and 'inline flow-root' should be syntactically equivalent`, and agreed to the following:

* `RESOLVED: Close this issue no change`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Reconsider if 'inline-block' and 'inline flow-root' should be syntactically equivalent<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/2947<br>
&lt;Oriol> Just IRC<br>
&lt;dael> astearns: Thanks Oriol<br>
&lt;dael> astearns: Hopefully he can follow along and we can resolve this<br>
&lt;dael> fantasai: The question was...this was raised by Oriol. We had discussed  in past that we should h ave inlineblock and inline-block have same behavior<br>
&lt;AmeliaBR> From issue: However, in #2673 it was resolved that blockifications and establishing FC are independent. This means that a future feature which only blockifies would make inline flow-root and run-in flow-root end up generating a block container with no BFC.<br>
&lt;dael> fantasai: I don't remember subtleties. TabAtkins ? If you  blockify an inline block it turns into display:block it's an inline flow-root.<br>
&lt;dael> fantasai: If you remove inline and swap with block you get bfc.  When you  blockify inline-block it's not a bfc due to  compat.<br>
&lt;dael> fantasai: We made inline flow-root blockify same as inline-block because we wanted them to compute to same. But when you blockify iether you loose block flow-root ness. Oriol suggested revert and make them distinct where they're same but when blockfiy inline flow-root it's different<br>
&lt;Oriol> Exactly<br>
&lt;dael> florian: Clarify. When we invoke blockification we'd also invoke flow-root so it's not observable except in terms of OM?<br>
&lt;dael> fantasai: If you  blockify...<br>
&lt;dael> TabAtkins: Only exception is subgrid so far. That's not relevent here. When we blockify something that can be inline we flow-root it as well.<br>
&lt;dael> TabAtkins: not that  inline flow-root is impl yet so that's not observable.<br>
&lt;Oriol> But can become observable in the future, and then it will be too late to change CSS Display<br>
&lt;dael> florian: I was initially tempted by Oriol proposal because cleaner theoretical archetecture. seems to me now it's adding more complexity then needed.<br>
&lt;dael> florian: To clarify a bit more, request is to have the behavior we want on inline flow-root and therefore force undeisreable on linline-block.  We can't have both due to compat. Theoretical nice design is overshadowed byt he complexity.<br>
&lt;dbaron> There was another reason this came up, but I've forgotten what it was...<br>
&lt;TabAtkins> Florian's statement is a concise statement of my own position<br>
&lt;dael> astearns: Other opinions?<br>
&lt;dael> dbaron: This came up in another discussion. trying to remember what that was<br>
&lt;dael> astearns: subgrid?<br>
&lt;dael> dbaron: Don't think so. I'm  okay with it<br>
&lt;fantasai> dbaron, were you thinking of the earlier discussion triggered by https://github.com/w3c/csswg-drafts/issues/1246#issuecomment-313211986 ?<br>
&lt;dael> dbaron: Something else where I wanted it the other way.<br>
&lt;dael> astearns: fantasai has a possibility<br>
&lt;florian> s/overshadowed byt he complexity/overshadowed by the creation of 2 distinct behavior despite no use case for the difference/<br>
&lt;dael> dbaron: Don't remember if that was it<br>
&lt;dael> astearns: Ass I undnerstand trade off is keeping simple for now vs not being able to use flow-root nature distinct from inline-block for some future thing not yet known<br>
&lt;dael> astearns: So may be painting into a corner<br>
&lt;dael> florian: Goal is not to  have distinction, goal is not to have inline-block constraint. We'd rather have the other behavior<br>
&lt;dael> astearns: prop resolution: close no change<br>
&lt;dael> astearns: We've done that before.<br>
&lt;dael> florian: Used to side with Oriol but no longer. Prefer no change<br>
&lt;dael> astearns: Oriol are you okay with the proposed resolution?<br>
&lt;fantasai> or have anything to add?<br>
&lt;florian> s/We'd rather have the other behavior/We'd rather have the other behavior but we can't have just that so the proposal is to have both/<br>
&lt;Oriol> I guess it's OK for now, but once multivalue display is added it will be too late to change in case later in the future a feature that blockifies without BC is added<br>
&lt;dael> astearns: Does anyone have reservations based on Oriol?<br>
&lt;dael> florian: Inline-block is odd in that  it's a flow-root that doesn't show in OM. We can do it later in terms o f layout even if not in  OM. Will n ot have perfect corrispondence. Given that  is lost and we do want 2 FC we can later since it's  not observable right now. We could revert it later.<br>
&lt;dael> astearns: Other comments?<br>
&lt;dael> astearns: Objections to close this issue no change?<br>
&lt;dael> RESOLVED: Close this issue no change<br>
&lt;fantasai> https://drafts.csswg.org/css-display-3/issues-wd-2017<br>
&lt;dael> fantasai: That's last issue in DoC<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2947#issuecomment-413256638 using your GitHub account

Received on Wednesday, 15 August 2018 16:38:51 UTC