[css-display] Reconsider if 'inline-block' and 'inline flow-root' should be syntactically equivalent #2947
Labels
Closed Rejected as Wontfix by CSSWG Resolution
Commenter Satisfied
Commenter has indicated satisfaction with the resolution / edits.
css-display-3
Current Work
Tracked in DoC
Comments
fantasai
added
css-display-3
|
The Working Group just discussed
The full IRC log of that discussion<dael> Topic: Reconsider if 'inline-block' and 'inline flow-root' should be syntactically equivalent<dael> github: https://github.com//issues/2947 <Oriol> Just IRC <dael> astearns: Thanks Oriol <dael> astearns: Hopefully he can follow along and we can resolve this <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 <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. <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. <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. <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 <Oriol> Exactly <dael> florian: Clarify. When we invoke blockification we'd also invoke flow-root so it's not observable except in terms of OM? <dael> fantasai: If you blockify... <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. <dael> TabAtkins: not that inline flow-root is impl yet so that's not observable. <Oriol> But can become observable in the future, and then it will be too late to change CSS Display <dael> florian: I was initially tempted by Oriol proposal because cleaner theoretical archetecture. seems to me now it's adding more complexity then needed. <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. <dbaron> There was another reason this came up, but I've forgotten what it was... <TabAtkins> Florian's statement is a concise statement of my own position <dael> astearns: Other opinions? <dael> dbaron: This came up in another discussion. trying to remember what that was <dael> astearns: subgrid? <dael> dbaron: Don't think so. I'm okay with it <fantasai> dbaron, were you thinking of the earlier discussion triggered by https://github.com//issues/1246#issuecomment-313211986 ? <dael> dbaron: Something else where I wanted it the other way. <dael> astearns: fantasai has a possibility <florian> s/overshadowed byt he complexity/overshadowed by the creation of 2 distinct behavior despite no use case for the difference/ <dael> dbaron: Don't remember if that was it <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 <dael> astearns: So may be painting into a corner <dael> florian: Goal is not to have distinction, goal is not to have inline-block constraint. We'd rather have the other behavior <dael> astearns: prop resolution: close no change <dael> astearns: We've done that before. <dael> florian: Used to side with Oriol but no longer. Prefer no change <dael> astearns: Oriol are you okay with the proposed resolution? <fantasai> or have anything to add? <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/ <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 <dael> astearns: Does anyone have reservations based on Oriol? <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. <dael> astearns: Other comments? <dael> astearns: Objections to close this issue no change? <dael> RESOLVED: Close this issue no change <fantasai> https://drafts.csswg.org/css-display-3/issues-wd-2017 <dael> fantasai: That's last issue in DoC |
fantasai
added
the
Commenter Satisfied
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From Automatic Box Type Transformations,
At first I thought this was acceptable because all current features that blockify also force block containers to establish a BFC, and thus the
flow-rootnature is not really lost in practice.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-rootandrun-in flow-rootend up generating a block container with no BFC. This would be bad, and would force authors to continue using hacks likeoverflow: hiddento ensure that the element establishes a BFC.For
inline-blockit's necessary to blockify toblockdue to backwards compatibility, and this is acceptable, but if the author explicitly usesflow-root, then this shouldn't be lost.Therefore, I'm asking for a reconsideration of the resolution reversal from #1496 (comment) in favor of the original resolution from #1246 (comment)
Current behavior: (blockifications in blue, inlinifications in green)
Unaliasing
inline-blockandinline flow-root,However, instead of treating
inline-blockas an exception, it may make more sense to separate theflowinner display type into two:Intuitively, the two extra values in the 3x3 grid would be
block, but which inlinifies to an inline box.run-in flow-root, but which blockifies to a block container with no forced BFC.Currently there may not be enough use-cases to syntactically allow these combinations, but it could be beneficial to leave the door open to add them in the future.
The text was updated successfully, but these errors were encountered: