Hacker News new | ask | show | jobs
by c-smile 3381 days ago
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.
1 comments
jewbacca 3381 days ago
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.

link