[css-layout-api] Removing `childDisplay: 'normal'` , and replacing with `childDisplay: 'inline'`.

[bfgeek]

Currently the default when registering a custom layout if for blockification to occur on all children. E.g.

<div style="display: layout(foo);">
  abc
  <div></div>
  def
</div>

abc, and def are wrapped in anonymous blocks.

This corrorsponds to:

registerLayout('foo', class {
  layoutOptions = {childDisplay: 'block'};
});

We also introduced childDisplay: 'normal' so that anonymous blocks weren't inserted and the inline level children could be laid out line by line.

This turns out to be difficult for our implementation currently, what is significatly easier is a `childDisplay: 'inline'.

E.g.

registerLayout('foo', class {
  layoutOptions = {childDisplay: 'inline'};
});

This would inlinify all the children into one "child" which could be laid out line-by-line.

In the example above the

would turn into an atomic inline.

[css-meeting-bot]

The Houdini Task Force just discussed Inlinifying layout, and agreed to the following:

• RESOLVED: Remove normal layout and replace it with "block" and inline" and add a note saying we will reintroduce normal layout later

The full IRC log of that discussion

<TabAtkins> Topic: Inlinifying layout
<myles> myles: what's the name of the API that enables this?
<TabAtkins> github: https://github.com//issues/946
<myles> iank_: the "child display type" can be either "block" or "inline". When you layoutNextFragment, you can layout linebox by linebox. In the fragment you have the inline size, box size, and <missed> and that allows you to achieve all these effects
<myles> iank_: It's easy to do string-based layout when you blockify everything
<myles> iank_: Previously, we did normal child display, which didn't blockify. We think that's difficult to standardize, because all the engines do it differently, so we're proposing just inline-ifying everything
<myles> iank_: All the engines have a different way of splitting around block-level children and inlines. There's no consistency. This mitigates that problem.
<myles> heycam: Could those differences be exposed?
<myles> s/Could/Would/
<emilio> q+
<myles> iank_: Yeah, so, we, this was one of why we want to go down this path is it's quite difficult for us at the moment to not expose those differences. The way we build our box tree, children get squished down as a prepass to building the box tree. So, if we have something block-level inside something inline-level, it will get split into 3 pieces
<myles> emilio: When you have a block inside inline, you have to split into multiple things.
<myles> iank_: The engines don't agree on various edge cases here.
<myles> iank_: For example, if you've got only out-of-flow children, the engines handle the out-of-flow children and floats differently
<myles> emilio: That may be true
<myles> iank_: We didn't want to go down the rabbit hole by speccing everything
<myles> emilio: how do markers work?
<myles> iank_: <misseD>
<myles> iank_: You don't get a separate item from a list item at the moment
<myles> TabAtkins: Because it's explicitly inline?
<myles> iank_: yes.
<myles> emilio: What about an outside marker?
<myles> iank_: I think that will get wrapped in an anonymous block.
<myles> Rossen: What is the issue in the proposal?
<myles> iank_: To remove child display "normal" for now, and instead just do inlinification
<myles> Rossen: That makes sense for flow layout, but it doesn't make sense for anything else
<myles> iank_: YOu have to nest your custom layouts to get things like this
<myles> iank_: We have an explicit switch here which switches the display type. You can flip it to indicate you want to inline-ify your children
<myles> Rossen: So this just sets your content to be inline rather than block?
<myles> iank_: yes.
<myles> cbiesinger: What happens to block children? DO tey become inline block?
<myles> iank_: yes
<myles> Rossen: In your example in the issue, the ABC followed by DEF ...
<myles> iank_: This would be represented as one child, with its children inline-ified
<myles> Rossen: Are you going to ignore <missed>?
<myles> iank_: Yes, because it's ismpler.
<myles> Rossen: It makes no sense
<astearns> s/<missed>/the display-outside value of the div/
<myles> iank_: It's the same as flexbox or grid blockifying. Just hte reverse.
<myles> Rossen: So how can display:block continue to be block?
<myles> iank_: You can't. You need two levels of custom layout. They must communicate internally
<myles> Rossen: That sounds complicated and unnecessary
<myles> iank_: It's simple to implement
<myles> Rossen: Yes, I know that. But the expectation is that I'd be able to handle flow layout in a fairly straightforward way for me, that restriction makes everything much harder
<myles> iank_: It depends on the use case
<myles> Rossen: Use case is normal CSS 2.1 support
<myles> iank_: If you just care about line grid snapping, this is what you want. You don't want to have to handle block level things
<myles> TabAtkins: We're not saying "you will never be able to do layout with block and inlines" but right now you have to pick either all block or all inline, because that's simpler.
<myles> dbaron: They both seem like reasonable options to have. Maybe it's worth having a note in the spec about reintroducing something else?
<TabAtkins> q?
<myles> majidvp: If we go wiht a simple model now, can we change the model later without breaking existing layouts?
<myles> iank_: Yes. To respect the display of the node, you would set the child display to be normal in a future version
<myles> dbaron: What layout capabilities do you have in inline content in this midel?
<myles> iank_: You can vary the given available space in the inline. You can shrink and expand how big the lines are (like the multicol layout)
<myles> iank_: The code for this is layout out many line boxes across the columns. You can also change how percentages resolve. You can also get the baseline information out. This one works by laying out the first two words with 0 available width, and then given available space to allow these other words to fix next to them, and then lay everything out with maximum available space
<myles> TabAtkins: Wouldn't that have a line break between "lorem ipsum"?
<myles> iank_: I have a non-breaking space between them
<myles> dbaron: It sounds like you've got a lot of control about the inputs and outputs of line layout, but nothing the internals of line layout
<myles> iank_: yes.
<myles> TabAtkins: Was this just an introduction, or do you want a resolution for this change?
<myles> TabAtkins: Proposed resolution: Remove
<myles> RESOLVED: Remove normal layout and replace it with "block" and inline" and add a note saying we will reintroduce normal layout later
<myles_> ScribeNick: myles_
<myles_> emilio: At which point does the simplification happen? If I put float:right in the div, do I get a div with floating style and display none?
<myles_> iank_: The float will switched to an intermediate line in this case, because we don't handle it
<myles_> emilio: Do you also modify the computed style, or just layout box
<myles_> iank_: The computed style, just like flex and grid
<myles_> emilio: No.
<myles_> TabAtkins: Flex and grid blockify at computed value time
<myles_> emilio: They don't add or remove float properties
<myles_> TabAtkins: Those don't apply
<myles_> cbiesinger: in chrome it modifies the computed style, but per spec it shouldn't
<myles_> iank_: For us, the computed style of target float is none
<myles_> iank_: Firefox logs "left" and Safari logs "none"
<myles_> <silence>
<myles_> iank_: abspos modes of custom layout don't exist
<myles_> emilio: We could specify it
<myles_> iank_: in that case, we don't need special handling
<myles_> emilio: They just don't appear in teh custom layout stuff, like normal out of flow
<myles_> cbiesinger: What static position do they get?
<myles_> iank_: They're block children, so the padding inline block. Whatever the standard static position of an internal line box
<myles_> cbiesinger: If there's a custom algorithm, how does it know where the static position is?
<myles_> iank_: It's the static position of the marker inside the element
<myles_> emilio: I think it depends
<myles_> koji: It may be more comlicated when teh containing block is inline, and we compute merged boxes
<myles_> iank_: It should be fine ...?
<myles_> iank_: If you've got out-of-flow inside inline, that position is somewhere in the line box. For the purposes of layout, it's just positioning line boxes. It doesn't care about out-of-flow children. When we then handle out-of-flow as a postpass, they are handled naturally
<myles_> koji: Static position is fine. I was thinking about when the containing block is inline ancestor and we have right currently
<myles_> iank_: In that case, the out of flow layout parts would pick up where those open span and close span is
<myles_> iank_: it might be easy if we just do this
<myles_> iank_: I can't spell
<myles_> iank_: It crashes. We currently don't handle that.
<koji> s/right currently/`right: 0`/
<myles_> Rossen: Are we still working through this issue? I think we should move on.
<myles_> iank_: okay
<myles_> TabAtkins: Before the next topic, who put WebAssembly integration on the agenda?
<myles_> TabAtkins: Does anyone have anything we want to hit first?
<myles_> TabAtkins: Font enumeration? property registrations?