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

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

From: SelenIT via GitHub <sysbot+gh@w3.org>
Date: Mon, 12 Jun 2017 09:58:45 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-307744671-1497261523-sysbot+gh@w3.org>
> will still have problem #1486, because you are still limited to 4 values

I supposed this limitation to be the key part of _fixing_ that issue — there would be no syntactically different forms of inline block with too subtle difference. There is just one layout mechanism inside (the flow layout) and we have 4 options how to inject it into the parent flow (on inline or on block level and as continuation of the parent formatting context or as an "island" of the new one), only one of which  corresponds to `inline-block`. And if we decide that `inline-flow-root` blockifies as `block` (probably not very intuitive, but IMHO less counter-intuitive than having two different syntaxes for virtually the same thing), we will have the consistency with the existing browser behavior (if I didn't miss something). Inlinification could still precerve `flow-root`-ness.

The `run-in` issue can be solved by adding a similar counterpart value to `run-in` that gives its content the `flow-root`-ness (`run-in-flow-root`?).

Also, all the existing `inline`-prefixed values would have the same meaning (`inline-flow-root` outer display) and wouldn't interfere with the only two values currently corresponding to the non-flow-root `inline` outer display (`inline` itself and `ruby`).

Your last proposal looks interesting, but it seems to me that having two syntactically different things that generate the same box and differ only in one very special case and in a very subtle technical way that doesn't make much sense for a typical CSS author is exactly the key question of #1486, the intent was to  avoid this as much as possible. Also, if we selectively prohibit specific values from certain combinations, wouldn't it be simpler to selectively change just the blockification rule for `flow-root`, without adding any more complexity to the spec?

Also, all the proposals that affect only nuances of the `flow` transformations don't seem to solve the `ruby` FC-ness problem (#1457). Only your initial proposal (and perhaps `flow-root`-ness as outer display feature?) seem to do it.

GitHub Notification of comment by SelenIT
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1496#issuecomment-307744671 using your GitHub account
Received on Monday, 12 June 2017 09:58:51 UTC

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