3 ms·

In anything implementing the current draft of CSS Display Module Level 3, the `display` values we commonly use today become a shorthand for two orthogonal prope

In anything implementing the current draft of CSS Display Module Level 3, the `display` values we commonly use today become a shorthand for two orthogonal properties. For example, `display: block` becomes shorthand for `display: block flow`, where `block` is the <display-outside> and `flow` is the <display-inside>. ---- https://drafts.csswg.org/css-display/#propdef-display https://drafts.csswg.org/css-display/#propdef-display > The `display` property defines box’s display type, which consists of the two basic qualities of how an element generates boxes: > * the inner display type, which defines [...] the kind of formatting context it generates, dictating how its descendant boxes are laid out. > * the outer display type, which dictates how the box participates in its parent formatting context. ... > <display-outside> = block | inline | ... > <display-inside> = flow | flow-root | table | flex ... ... Short `display` | Full `display` | Generated box ----------------|--------------------|--------------- 'block' | 'block flow' | block-level block container 'flow-root' | 'block flow-root' | block-level block container that establishes a new block formatting context 'inline' | 'inline flow' | inline box 'inline-block' | 'inline flow-root' | inline-level block container ----------------|--------------------|--------------- 'flex' | 'block flex' | block-level flex container 'inline-flex' | 'inline flex' | inline-level flex container ---- ---- It looks like there were, in the first draft of the spec, independent `display-inside/outside` properties, with `display` being a "one property that sets multiple properties" shorthand: https://www.w3.org/TR/2014/WD-css-display-3-20140911/#the-display https://www.w3.org/TR/2014/WD-css-display-3-20140911/#the-di... But that has since been changed to `display` being a "one property that takes multiple values" shorthand, in the current version of the spec: https://www.w3.org/TR/2015/WD-css-display-3-20150721/#changes https://www.w3.org/TR/2015/WD-css-display-3-20150721/#change... > Changes since the 11 September 2014 Working Draft include: > Removed `display-inside`, `display-outside`, and `display-extras` longhands, in favor of just making `display` multi-value. (This was done to impose constraints on what can be combined. Future levels of this specification may relax some or all of those restrictions if they become unnecessary or unwanted.)

c-smile 10y ago
Even that display-inside is a fuzzy one. What does it mean display-inside: block; for example? I would expect flex-direction to go there display-inside: default | row | column | ... ; So display-inside: row; will replace children horizontally.
- jewbacca 10y ago
  In this formulation, `block` is a <display-outside> value, and would not be valid as a <display-inside> value. ---- <display-inside>, which can be `flow`, `flex`, `grid`, etc, but not `block`: > defines [...] the kind of formatting context it generates, dictating how its descendant boxes are laid out" https://drafts.csswg.org/css-display/#formatting-context https://drafts.csswg.org/css-display/#formatting-context Which, as I interpret it, is "just" another level of indirection on top of your proposal, providing a mechanism for more messy and incompatible, legacy and future, layout systems to coexist.
  - c-smile 10y ago
    So if I have this: img-row { display: block flow; } and markup <img-row> <img src=1.png> <img src=2.png> <img src=3.png> </img-row> I will still have a problem with white space appearance between image of these [inline-]blocks ? While with this: img-row { display: block; flow:horizontal; } child images will be treated as blocks and so white spaces will not go into rendering/layout tree of the img-row. So again partial solution, sigh.
    - deleted 10y ago
      [deleted]
    - jewbacca 10y ago
      As far as I can tell, the only way the source-whitespace will appear is when both of the following are true: 1. The parent has `display-inside: flow` or `display-inside: flow-root` (ie, the "original", pre-flexbox, formatting contexts) eg `display: block`, `display: inline`, `display: inside-block` 2. The children have `display-outside: inline` eg, `display: inline`, `display: inline-block`, `display: inline-flex` In any other combination, the source-whitespace disappears, in some way or other. ---- What I think you want, a horizontal row disregarding source-whitespace, could be achieved with `display-inside: flex` (eg, `display: flex`, `display: inline-flex`) on the parent (with `flex-direction: row` being the default). So: img-row { display: flex; } aka img-row { display: block flex; } aka (though this syntax has been temporarily removed) img-row { display-outside: block; display-inside: flex; } aka img-row { display-outside: block; display-inside: flex; flex-direction: row; /* the default */ } ---- Note that this longhand syntax doesn't seem to be implemented in Chrome, at least, yet. So if you want to check it out, you'll have to work in the shorthand (still translatable from the longhand as specified in the draft spec https://drafts.csswg.org/css-display/#propdef-display https://drafts.csswg.org/css-display/#propdef-display).
gsnedders 10y ago
> But that has since been changed to `display` being a "one property that takes multiple values" shorthand, in the current version of the spec FWIW, there is a WG resolution to have display-inside/outside properties in Level 4.

c-smile 10y ago

Even that display-inside is a fuzzy one. What does it mean display-inside: block; for example? I would expect flex-direction to go there display-inside: default | row | column | ... ; So display-inside: row; will replace children horizontally.

jewbacca 10y ago
In this formulation, `block` is a <display-outside> value, and would not be valid as a <display-inside> value. ---- <display-inside>, which can be `flow`, `flex`, `grid`, etc, but not `block`: > defines [...] the kind of formatting context it generates, dictating how its descendant boxes are laid out" https://drafts.csswg.org/css-display/#formatting-context https://drafts.csswg.org/css-display/#formatting-context Which, as I interpret it, is "just" another level of indirection on top of your proposal, providing a mechanism for more messy and incompatible, legacy and future, layout systems to coexist.
- c-smile 10y ago
  So if I have this: img-row { display: block flow; } and markup <img-row> <img src=1.png> <img src=2.png> <img src=3.png> </img-row> I will still have a problem with white space appearance between image of these [inline-]blocks ? While with this: img-row { display: block; flow:horizontal; } child images will be treated as blocks and so white spaces will not go into rendering/layout tree of the img-row. So again partial solution, sigh.
  - deleted 10y ago
    [deleted]
  - jewbacca 10y ago
    As far as I can tell, the only way the source-whitespace will appear is when both of the following are true: 1. The parent has `display-inside: flow` or `display-inside: flow-root` (ie, the "original", pre-flexbox, formatting contexts) eg `display: block`, `display: inline`, `display: inside-block` 2. The children have `display-outside: inline` eg, `display: inline`, `display: inline-block`, `display: inline-flex` In any other combination, the source-whitespace disappears, in some way or other. ---- What I think you want, a horizontal row disregarding source-whitespace, could be achieved with `display-inside: flex` (eg, `display: flex`, `display: inline-flex`) on the parent (with `flex-direction: row` being the default). So: img-row { display: flex; } aka img-row { display: block flex; } aka (though this syntax has been temporarily removed) img-row { display-outside: block; display-inside: flex; } aka img-row { display-outside: block; display-inside: flex; flex-direction: row; /* the default */ } ---- Note that this longhand syntax doesn't seem to be implemented in Chrome, at least, yet. So if you want to check it out, you'll have to work in the shorthand (still translatable from the longhand as specified in the draft spec https://drafts.csswg.org/css-display/#propdef-display https://drafts.csswg.org/css-display/#propdef-display).

gsnedders 10y ago

> But that has since been changed to `display` being a "one property that takes multiple values" shorthand, in the current version of the spec FWIW, there is a WG resolution to have display-inside/outside properties in Level 4.