- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Mon, 02 Jul 2018 06:09:20 +0000
- To: public-css-archive@w3.org
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:
== [css-properties-values-api-1] What is the computed value of a <transform-list> in the middle of a layout dependent matrix decomposed interpolation? ==
_From @alancutter on July 6, 2017 5:4_
The [`<transform-list>` syntax](https://drafts.css-houdini.org/css-properties-values-api/#supported-syntax-strings) enables custom properties to animate like the `transform` property.
One quirk of `transform` is that the [serialisation procedure](https://drafts.csswg.org/css-transforms-1/#serialization-of-the-computed-value) requires layout information in order to turn percentages of the element's box dimensions into a matrix.
Unfortunately this procedure requires layout information to turn an animation between `translateX(100%)` and `rotate(45deg)` into a single matrix. There is currently no way of representing such a value in CSS independent of what the layout is. You would need something like `blend(translateX(100%), rotate(45deg), 0.5)`.
Here's a more concrete example:
```html
<!DOCTYPE html>
<style>
#target {
/* Animation is paused at halfway. */
animation: x 1s -0.5s linear paused;
--y: var(--x);
}
@keyframes x {
from { --x: translateX(100%); }
to { --x: rotate(45deg); }
}
</style>
<div id="target"></div>
<script>
CSS.registerProperty({
name: '--x',
syntax: '<transform-list>',
initialValue: 'none',
});
// What should the computed value of --y be?
console.log(getComputedStyle(target).getPropertyValue('--y'));
</script>
```
Should the serialisation of the computed value of `<transform-list>` custom properties be the same as `transform` and depend on layout computations?
Should this layout computation dependency "infect" other custom properties that reference it via `var()`?
What happens when we try to serialise a `<transform-list>` custom property inside a layout worklet in the middle of layout computation?
I don't think depending on layout computation is a good idea here.
I recommend using `<transform-list-2> := <transform-list> | blend(<transform-list-2>, <transform-list-2>, <number>)` instead (but with a better name) and to serialise it as the original transform functions instead of as a matrix that incorporates layout computations.
_Copied from original issue: w3c/css-houdini-drafts#425_
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2854 using your GitHub account
Received on Monday, 2 July 2018 06:10:05 UTC