[css-layout-api] Review the LayoutOptions.sizing parameter

[bfgeek]

I've introduced a new option for the layout, which should help out a little for servo, and easier for implementations to implement initially.

registerLayout('foo', class {
  static layoutOptions = {sizing: 'block-like'}; // or {sizing: 'manual'}
  *layout(children, edges, constraints, styleMap, breakToken) {
    constraints.fixedInlineSize; // For 'block-like' sizing this *always* fixed, its never null.

    return {autoBlockSize: 100}; // Now autoBlockSize is the size if 'block-size' was 'auto'.
                                 // The actual block-size might get affected by max-height, height, etc..
  }
});

For the 'manual' sizing mode:

registerLayout('foo', class {
  static layoutOptions = {sizing: 'manual'};
  *layout(children, edges, constraints, styleMap, breakToken) {
    constraints.fixedInlineSize; // This may exist, e.g. abs-pos'd, layout, auto within block container (see sizing interactions).

    return {inlineSize: 100, blockSize: 100}; // These do something in this mode
                               // they get ignored if constraints.fixedInlineSize, fixedBlockSize exist still,
                               // but otherwise they are the size of the fragment.
  }
});

[css-meeting-bot]

The Working Group just discussed Review the LayoutOptions.sizing parameter, and agreed to the following resolutions:

• RESOLVED: Accept the new parameter in https://github.com/w3c/css-houdini-drafts/issues/747

The full IRC log of that discussion

<dael> Topic: Review the LayoutOptions.sizing parameter
<dael> github: https://github.com//issues/747
<dael> iank_: This is...we had one layout option for the child display. This is one mode I think we should add that flips the type of sizing you default to
<dael> iank_: As I was building examples it's really nice if you don't have to worry about your size. block-like is handled for you.
<dael> iank_: Like in my earlier demo you're always given a fixed size and you're given an auto block size.
<dael> iank_: Thing that makes it more custom is a manual sizing mode where you explicitly say the sizing.
<dael> iank_: If we use block-like initially it makes it a lot easier on impl to do it this way and less compat risk.
<dael> iank_: Is there any feedback?
<dael> smfr: Minor objection ot size as a word since it's height and width
<dael> iank_: This is the engine taking care of the size
<dael> smfr: But it's a scalar.
<dael> dbaron: CSS is using block-sizing already
<dael> smfr: What happens with a disctionary of auto block size?
<dbaron> s/block-sizing/block-size/
<dael> iank_: In block-like it takes care of it for you. In some circumstances you'll get a fixed size like abspos and you're constraining the block.
<dael> iank_: I think for compat risk we'd want block-like as a default.
<dael> Rossen: This sounds more like native layout. Sizing and positioning are parts of layout, but you're not talking positioning. Engine for layout more for native layout mode or something like that for the name.
<dael> Rossen: Instead of 'sizing' to imply I want you to do layout on my behalf and the type of layout is block0like.
<dael> iank_: It's not simply layout. It's also the size of your fragment.
<dael> iank_: That's why I sort of....
<dael> Rossen: ...Okay.
<dael> iank_: I'm fine calling it something else.
<dael> Rossen: I see what your intention was.
<dael> iank_: With this sizing is block0like it's computed as if you were a block container and that's pre-computed.
<dael> Rossen: So if you happen to be a flex item all the flexing will be ignored?
<dael> iank_: If you're a flex-item the engine can work out ahead of time what your size is going to be. If there's flexing that fixed inline size will be increased by the flex amount. Inline synthesis is handled by the engine and all you need to do is the flex size and that follows the same rules as the block size.
<dael> Rossen: I guess it's okay
<dael> iank_: You lose a little bit of power
<dael> iank_: It also allows if we're defaulting like servo can do it's inline sizing pass at the moment. From what I've used it's much easier and a lot less work. What it gives you is what you want 95% of the time.
<dael> Rossen: Was this edited in?
<dael> iank_: Yes.
<dael> Rossen: Objections to accepting this new parameter?
<dael> RESOLVED: Accept the new parameter in https://github.com//issues/747

[bfgeek]

Closing as resolved to accept specification as it currently written.