- From: Loirooriol via GitHub <sysbot+gh@w3.org>
- Date: Sun, 11 Jun 2017 16:55:24 +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. I was thinking... if the main concern is that a block-level inline box does not make much sense and thus behaves like a block box, maybe that combination could be syntactically not allowed, at least for now. For example, add a new `inline` inner display type, but don't expose it in `<display-inside>`. This means `display: inline` and `display: run-in` won't have a two-keyword equivalent. <table> <thead> <tr> <td colspan="2"></td> <th>Block-level</th> <th>Inline-level</th> <th>Run-in</th> </tr> </thead> <tbody> <tr> <th rowspan="3">Inline</th> <td>Full</td> <td>—</td> <td>—</td> <td>—</td> </tr> <tr> <td>Short</td> <td>—</td> <td><code>inline</code></td> <td><code>run-in</code></td> </tr> <tr> <td>Box</td> <td>—</td> <td>inline box</td> <td>run-in inline box</td> </tr> </tbody> <tbody> <tr> <th rowspan="3">Flow</th> <td>Full</td> <td><code>block flow</code></td> <td><code>inline flow</code></td> <td><code>run-in flow</code></td> </tr> <tr> <td>Short</td> <td><code>block</code> (synonym: <code>flow</code>)</td> <td><code>inline-block</code></td> <td>〃</td> </tr> <tr> <td>Box</td> <td>block-level block container</td> <td>inline-level BFC root</td> <td>run-in BFC root</td> </tr> </tbody> <tbody> <tr> <th rowspan="3">Flow-root</th> <td>Full</td> <td><code>block flow-root</code></td> <td><code>inline flow-root</code></td> <td><code>run-in flow-root</code></td> </tr> <tr> <td>Short</td> <td><code>flow-root</code></td> <td>〃</td> <td>〃</td> </tr> <tr> <td>Box</td> <td>block-level BFC root</td> <td>inline-level BFC root</td> <td>run-in BFC root</td> </tr> </tbody> </table> That's only 5 basic values. `inline flow-root` and `inline-block` still generate the same box, but they are syntactically different per WG resolution in #1246. I reused `flow` and `flow-root` from the current spec, but they could be renamed to `block` and `block-root`, respectively. However, the term "block container" should have been called "flow container" because its contents are not required to be block-level, so `flow` makes sense for a flow container. <details> <summary>The spec would look like this</summary> <br /> **Syntax** ``` [ <display-outside> || <display-inside> ] | ... <display-outside> = block | inline | run-in ; <display-inside> = flow | flow-root | table | flex | grid | ruby ; ``` **Outer display roles** - `block`: generates block-level box when placed in flow layout. - `inline`: generates inline-level box when placed in flow layout. - `run-in`: generates run-in box when placed in flow layout. If a `<display-outside>` value is specified but `<display-inside>` is omitted, the element’s inner display type defaults to `inline` —except for `block`, which defaults to `flow`. **Inner display models** - `inline`: generates an inline box. Note this value is not allowed in `<display-inside>`. - `flow`: generates a block container. - `flow-root`: generates a block container that is a BFC root. - ... If a `<display-inside>` value is specified but `<display-outside>` is omitted, the element’s outer display type defaults to `block` —except for `ruby`, which defaults to `inline`. **Precomposed inline-level** - `inline-block`: syntactically equivalent to `inline flow` - `inline-table`: syntactically equivalent to `inline table` - `inline-flex`: syntactically equivalent to `inline flex` - `inline-grid`: syntactically equivalent to `inline grid` **Transformations** - Inlinification sets the outer display type to `inline`. If an inline box is inlinified, its in-flow children are recursively inlinified, so that no block-level descendants break up the inline. - Blockification sets the outer display type to `block`. It the inner display type is `inline` or layout-internal, it is set to `flow` so that it becomes a block container. </details> -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1496#issuecomment-307641908 using your GitHub account
Received on Sunday, 11 June 2017 16:56:06 UTC