[css-houdini-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?

alancutter has just created a new issue for https://github.com/w3c/css-houdini-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? ==
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: test 1s -0.5s;
  --y: var(--x);
}
@keyframes test {
  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.

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

Received on Thursday, 6 July 2017 05:05:03 UTC