display-inside: block;
display-inside: default | row | column | ... ;
----
<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
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.
img-row {
display: block flow;
}
<img-row>
<img src=1.png>
<img src=2.png>
<img src=3.png>
</img-row>
While with this:
img-row {
display: block;
flow:horizontal;
}
So again partial solution, sigh.
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`
eg, `display: inline`, `display: inline-block`, `display: inline-flex`
----
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;
}
img-row {
display: block flex;
}
img-row {
display-outside: block;
display-inside: flex;
}
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).
display-inside: flow;
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.
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.