- 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