- From: SelenIT via GitHub <sysbot+gh@w3.org>
- Date: Fri, 09 Jun 2017 08:38:55 +0000
- To: public-css-archive@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