[c-smile]

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.

[jewbacca]

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).

[c-smile]

As far as I understand

    display-inside: flow;

is the current (default) layout method. So all runs having characters (including spaces) and children that have display:inline | inline-block will be replaced in line boxes preserving spaces between them (consecutive spaces are collapsed into one but still they will be there).

But suddenly all children that have display:block will be a) replaced on new row each and b) with spaces between them ignored.

Such a dichotomy is the source of weird hacks, like advices to remove spaces between blocks at all, etc.

[jewbacca]

Yes, it is my understanding that one of the major, inviolable design goals in this is not to break any old behaviour, or any such (yes, totally distasteful) "hacks" dependent on it. Now that particular old behaviour is "isolated" under the `display-inside: flow` formatting context, which has to remain the default.

Lets go back to the spec draft:

----

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-inside> = flow | flow-root | table | flex ...

> <display-outside> = block | inline | ...

----

It's not just the reframing into `display-inside` (how to lay out children) and `display-outside` (how to participate in parent) which addresses your problem -- that just provides a new way to specify the same behaviour as before. Split into 2 orthogonal axes, cleanly leaving room for new behaviour to exist in combination with old behaviour.

But, rather, it's that plus the specific provision of `display-inside: flex`, within this new framing, which addresses your problem.

If you stick with `display-inside: flow` in your examples of things that are problems, of course nothing is going to change, because that specifically specifies "behave like you always used to".

I'm honestly not sure I understand your complaint. I'm definitely open to the possibility that this is an internally-inconsistent or short-sighted solution, but I'm not seeing it here.