- From: Loirooriol via GitHub <sysbot+gh@w3.org>
- Date: Fri, 09 Jun 2017 14:53:54 +0000
- To: public-css-archive@w3.org
> introducing new `flow-*` values wouldn't solve the original problem of `inline-block`/`inline flow-*` being incosistent Yes, it would, because then we could have syntactical equivalences: `inline-block` = `inline flow-tight` `inline-table` = `inline table` `inline-flex` = `inline flex` `inline-grid` = `inline grid` Now the spec says `inline-block` behaves like `inline flow-root` but they can't be syntactically equivalent because the former blockifies to `block` (for legacy reasons) and the latter blockifies to `flow-root`. > what is the worst implication of allowing `block` as both outer and inner display values? I don't like overlaps between longhand properties, especially when the shorthand is not ordered. But given that both `block` and `flow-tight` would default to `block flow-tight` and there is no other overlap, I guess `flow-tight` might be renamed to `block`, yes. I would prefer `flow-block`, though. > I still believe that a separate value, or maybe even a separate property, to switch on FC-ness of things explicitly would be useful Yes, this is what I attempted to address in my initial proposal. I don't care if it's via an independent `flow-root`, more inner display types, a new property or some `contain` value, but I think there should be some way to FC-ify things without other side-effects. -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1496#issuecomment-307410958 using your GitHub account
Received on Friday, 9 June 2017 14:54:00 UTC