- From: Cameron McCormack via GitHub <sysbot+gh@w3.org>
- Date: Mon, 26 Nov 2018 06:24:32 +0000
- To: public-houdini-archive@w3.org
heycam has just created a new issue for https://github.com/w3c/css-houdini-drafts: == [css-layout-api] issues with (optional) caching of intrinsic size computation and generated fragments == 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 `BreakToken`s 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. Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/841 using your GitHub account
Received on Monday, 26 November 2018 06:24:34 UTC