[css-houdini-drafts] [css-layout-api] Assorted TAG feedback

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

== [css-layout-api] Assorted TAG feedback ==
This is a summary of the [TAG Review comments](https://github.com/w3ctag/design-reviews/issues/224) for the [CSS Layout API](https://drafts.css-houdini.org/css-layout-api/).

The major issue of feedback is already covered by https://github.com/w3c/css-houdini-drafts/issues/750 (where we asked why a Promise-style design was not used).

### Constructors for Fragments
We generally try to enable constructors for objects returned by the platform (like Events) to enable JS authors to synthesize the same behavior. As such, we were wondering why there's no way to construct the `Fragment` types returned?

### Expectations for thrown exceptions
In `create a layout fragment` algorithm, what happens if the `StructuredDeserialize` operation fails? Is it the "otherwise null" result, or something else? Larger question: what is the expectation if the script powering the layout function throws? Does it keep trying over and over? Or does is abandon the script and stop executing it?

### IntrinsicSizes object as a dictionary type
Is the `IntrinsicSizes` object reused across layout passes? If the developer caches an `IntrinsicSizes` object and retrieves it in a later layout pass, will it have the same data? If not, should this be a dictionary structure instead, as it appears to be purely for containing data w/no operations...

### `layoutNextFragment` -> `layout`?
In reflecting about the recursive nature of how a given pass through the layout generator function can recursively call `layoutNextFragment` on it's children, it seems to me that `layoutNextFragment` should really be called `layout` instead; this would appear to match `intrinsicSizes()` which is already named the same as the generator function required at registration. If `layout` is too general, then maybe `layoutFragment`? 

### IDL/usage bugs
* `layoutNextFragment` takes a `LayoutConstraints` IDL object in all cases--however, in many of the examples, you pass a `LayoutConstraintsOptions` dictionary into the method--this is not allowed per the IDL--you'll either want to new-up a `LayoutConstraints` object wrapped around your dictionary, or just change the API to take the dictionary instead for simplicity. This might be an early opportunity to throw if the wrong data-types would be passed back.
* Example 6, the `layoutFragment` method tries to get the `fragmentRequest.layoutChild` but that doesn't exist (I think it's supposed to be `box` instead).
* Example 6, the `layout` API is invoked with arguments in the wrong positions, per the definition (e.g., `constraints` is not the first argument).

### Readability
In general, this is a complex spec--there's no way around that. IMHO, the conceptual contents of section 5 (Layout) including some much-needed diagrams, would be a better lead-in to the spec than diving into section 3 right away.

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

Received on Tuesday, 22 May 2018 14:54:06 UTC