W3C home > Mailing lists > Public > public-css-archive@w3.org > June 2017

Re: [csswg-drafts] [css-display] Make 'flow-root' an independent keyword

From: Loirooriol via GitHub <sysbot+gh@w3.org>
Date: Mon, 12 Jun 2017 19:47:36 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-307900536-1497296854-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:14 UTC