[css-houdini-drafts] [css-layout-api] Design to allow for more layout engine optimizations. (#898)

bfgeek has just created a new issue for https://github.com/w3c/css-houdini-drafts:

== [css-layout-api] Design to allow for more layout engine optimizations. ==
Layout engines currently have various optimizations which apply to inputs to layout. E.g.

```html
<div id="parent" style="height: 100px;">
  <div>
      <div id="child1" style="height: 50px;"></div>
  </div>
</div>

<div id="parent2" style="height: 100px;">
  <div>
    <div id="child2" style="height: 50%;"></div>
  </div>
</div>
```

If the parents in the above example change from `100px` to `200px` only the second case has to perform layout on its immediate child (due to its percentage height descendant).

We currently have the `inputProperties` and `childInputProperties` for the style related inputs, however we don't have any "filter" for the layout constraints. E.g.

```webidl
interface LayoutConstraints {
    readonly attribute double availableInlineSize;
    readonly attribute double availableBlockSize;

    readonly attribute double? fixedInlineSize;
    readonly attribute double? fixedBlockSize;

    readonly attribute double percentageInlineSize;
    readonly attribute double percentageBlockSize;
   // snip
}
```

For example if the layout doesn't care about the percentageBlockSize we'll still trigger layout if this changes. There are also valid usecases for ignoring the other inputs.

There are two different possible approaches for allowing these optimizations.

1. Passing the used params on the output fragment. E.g.

```js
registerLayout('param-filter', class {
  async layout() {
    return {
       children: [],
       autoBlockSize: {},
       usedConstraints: {
         availableInlineSize: true,
         percentageBlockSize: true,
       }
    };
  }
});
```

In the above example the engine is allowed to re-use the result if the any constraints change except for the `availableInlineSize`, and the `percentageBlockSize`.

This is forwards compatible for other layout constraints are added over time.

2. Declaring up front:

```js
registerLayout('upfront-filter', class {
  static inputConstraints = {
    availableInlineSize: true,
    percentageBlockSize: true,
   };
});
```

There are various pros/cons of each approach.
 - (1) Is more consistent with the rest of the API surface.
 - (2) Allows for more fine grained optimizations. E.g. the layout may switch modes and start depending on a different set of constraints.

Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/898 using your GitHub account

Received on Friday, 7 June 2019 02:58:57 UTC