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

I still believe that there is a significant difference between "usually obviously different, the same in specific conditions" and "indistinguishable in most cases, different in a yet _theoretical_ specific case". And introducing such entities primarily as a workaround for an inconsistency occured because of legacy reasons looks a bit like trying to invent a sledgehammer in order to crack a nut.

Currently we have 4 flow layout options (FC-continuing inline box, FC-continuing block box, FC-changing inline box and FC-changing block box) that cover all cases that occur currently in practice, right? We have just a legacy requirement that FC-changing inline box, at least in one of it syntactical forms (which is at the moment the only available option in practice), has to blockify as FC-continuing block box. It seems that neither approach (current `flow-root` as an internal display type, as outer display type, and `flow-root`ness as a separate feature) solves that automatically without additional assumptions. And splitting the FC-changing internal flow type into different options (like "always new BFC" and "new BFC only if in other FC") inevitable creates several combinations that have little practical value and probably should be explicitly prohibited (as in your latest proposal).

Looking for the least complex solution, I came up with the following proposal that from the first glimpse seems to solve both #1457 and the inline-block dilemma:

* Leave all inner display values as is;
* Introduce just one new outer display value like `atomic-inline` (or even plain `inline-block`?).

For inner display values that automatically isolate their contents from the parent flow (`table`, `flex`, `grid`, and `flow-root`) this value would be effectively the alias of `inline` (and even may compute to it). But for `flow` and `ruby`, it would create an atomic inline box with the "island" of other FC, which could easily become layout-containing etc. And it would get blockified as `block`, exactly like `inline`.

So we would still have 5 options of flow layout:

<table>
<tr>
<th>Short `display`</th>
<th>Full `display`</th>
<th>Box</th>
<th>Blockifies as</th>
</tr>
<tr>
<td>`inline`</td>
<td>`inline flow`</td>
<td>inline box</td>
<td>`block`</td>
</tr>
<tr>
<td>`block`</td>
<td>`block flow`</td>
<td>block-level flow container</td>
<td>`block`</td>
</tr>
<tr>
<td>`inline-block`</td>
<td>`atomic-inline flow` (`inline-block flow`)</td>
<td>atomic inline-level flow container (effectively the same behavior as inline-level BFC container)</td>
<td>`block`</td>
</tr>
<tr>
<td>`flow-root`</td>
<td>`block flow-root`</td>
<td>block-level BFC container</td>
<td>`flow-root`</td>
</tr>
<tr>
<td>—</td>
<td>`inline flow-root`</td>
<td>inline-level BFC container</td>
<td>`flow-root`</td>
</tr>
</table>

There would still be two syntactically different ways to get the behavior or the inline-level BFC container, but their distinction would be more obvious (one isolated "from inside" and another "from outside"), and I suppose that `inline flow-root` option would be rarely used. And `inline-block` preserves the same inner display as `block` (unlike the current spec!) and blockifies as `block`, like it happens in browsers. Also, we would get the `atomic-inline ruby`/`inline-block ruby` option to solve the ruby layout containment issue. What have I missed?

-- 
GitHub Notification of comment by SelenIT
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1496#issuecomment-308455296 using your GitHub account

Received on Wednesday, 14 June 2017 14:49:05 UTC