- 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