[css-layout-api] issues with (optional) caching of intrinsic size computation and generated fragments

[heycam]

https://drafts.css-houdini.org/css-layout-api/#determining-intrinsic-sizes
https://drafts.css-houdini.org/css-layout-api/#generating-fragments

Both of these algorithms allow for caching the results of the author-supplied function, as long as the inputs are the equivalent. There needs to be a tighter definition of what it means for the passed in values to be "equivalent" to the ones from a previous invocation. I'm guessing it doesn't mean JS object identity, since for objects like LayoutEdges and BreakToken they are newly created objects. What does it mean for two BreakTokens to be equivalent? Is looking just at the data exposed on the BreakToken interface sufficient?

Also, I wonder if it's a problem to optionally cache these things. If an author writes a layout that uses some external data, like Math.rand(), two UAs could easily behave differently if one does caching and the other doesn't, and they have different strategies for optimizing out reflows.

[bfgeek]

Also, I wonder if it's a problem to optionally cache these things. If an author writes a layout that uses some external data, like Math.rand(), two UAs could easily behave differently if one does caching and the other doesn't, and they have different strategies for optimizing out reflows.

This is somewhat mitigated with the global scope switching (randomization). There are lots of things we don't have compat on here (which previously hasn't been exposed), e.g. number of passes to determine scrollbars, etc.

Our experience with paint so far is that switching the global scope randomly works pretty well to encourage developers to write idempotent code.

[heycam]

Just like switching global scope helps avoid authors to rely on state in that global, should we require that cached intrinsic/fragments be discarded at minimum every 1000 invocations too? That might help avoid accidentally relying on engine internal details of when / how many layouts happen.