- From: Loirooriol via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Jun 2017 19:47:36 +0000
- To: public-css-archive@w3.org
> given that the used value of the outer display type of blockified items would become `flow-root` It seems our points of view are different because you take this for granted and I don't. Unless I'm missing something, this is not in the spec. But yes, making blockified elements "become a formatting context" would allow to preserve syntactic equivalence and flow-root-ness with just 4 flow values. (Well, flow-root-ness would be lost in inheritance). However, I would still consider adding new inner types or an independent `flow-root`. I don't think that users will be confused by different values usually behaving the same if the behavior is different sometimes. For example, I don't see anybody confused about `inline-flex` and `flex` behaving the same inside a flex container, because in a block container they are different. The proposals here are the opposite, `inline-block` and `inline flow-root` behave the same in flow layout but would be different in a theoretical layout that blockifies without triggering "becoming a formatting context". I'm not sure this thing exists, but it might, unless "becoming a formatting context" ends up being triggered by blockification itself. > all the proposals that affect only nuances of the `flow` transformations don't seem to solve the `ruby` FC-ness problem Yes, this could be addressed separately by adding a `ruby-root` internal type. -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1496#issuecomment-307900536 using your GitHub account
Received on Monday, 12 June 2017 19:47:42 UTC