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: Fri, 09 Jun 2017 08:38:55 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-307330950-1496997533-sysbot+gh@w3.org>
I don't like the idea of further splitting the `flow` value into obscurely-named subvalues that differ only in quite specific situations. The `flow-root` value itself had a lot of complaints about its name (e.g. #964), even though its effect is much more self-evident. Having two values that do the same thing most of the time but implicitly transform to completely different things in similar situations seems to be a very confusing perspective, especially for newcomers. Moreover, introducing new `flow-*` values wouldn't solve the original problem of `inline-block`/`inline flow-*` being incosistent with other `inline-something`/`inline something` pairs.

Isn't there any other option? For example, what is the worst implication of allowing `block` as both outer and inner display values? If we define `block block` the synonym of `block flow`, make `inline-block` compute as `inline block` (with `inline flow-root` as a used value) and naturally blockify as `block`, would it produce any ambiguity (given that other outer and inner display values are different and we would always be able to determine which part `block` is by the other part)?

And I still believe that a separate value, or maybe even a separate property, to switch on FC-ness of things explicitly would be useful. Maybe it actually has something to do with the scope of [css-containment], and introducing something like `contain: formatting` (as I suggested in the [comment](https://github.com/w3c/csswg-drafts/issues/964#issuecomment-275431659) in #964) would make sense?

GitHub Notification of comment by SelenIT
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1496#issuecomment-307330950 using your GitHub account
Received on Friday, 9 June 2017 08:39:01 UTC

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