Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[css-transforms-1] What is the computed value of a <transform-list> in the middle of a layout dependent matrix decomposed interpolation? #2854

Open
tabatkins opened this issue Jul 2, 2018 · 4 comments
Open

[css-transforms-1] What is the computed value of a <transform-list> in the middle of a layout dependent matrix decomposed interpolation? #2854

tabatkins opened this issue Jul 2, 2018 · 4 comments
Labels
Closed Accepted by CSSWG Resolution css-transforms-1 Current Work Needs Edits

Comments

@tabatkins
Copy link
Member

From @alancutter on July 6, 2017 5:4

The <transform-list> syntax enables custom properties to animate like the transform property.
One quirk of transform is that the serialisation procedure 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:

<!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
@tabatkins
Copy link
Member Author

From @shans on October 19, 2017 0:6

We definitely can't depend on layout to produce computed styles. I think something like your blend suggestion makes sense. Flagging this for discussion with the Houdini TF.

@tabatkins
Copy link
Member Author

From @css-meeting-bot on November 9, 2017 18:42

The Working Group just discussed What is the computed value of a <transform-list> in the middle of a layout dependent matrix decomposed interpolation?, and agreed to the following resolutions:

  • RESOLVED: Add generic interpolation function. Name TBD. For Units and Values spec.
The full IRC log of that discussion <TabAtkins> Topic: What is the computed value of a <transform-list> in the middle of a layout dependent matrix decomposed interpolation?
<TabAtkins> GitHub: https://github.com/w3c/css-houdini-drafts/issues/425
<nainar> Scribenick: nainar
<nainar> TabAtkins: Problem - you have a rtanstition between translate 30% and rotation 30 deg. The 30% is less dependant on lyaout info.
<nainar> TabAtkins: you are in the middle of transition - due to incomaptiblilty you get matrix
<nainar> TabAtkins: What should CSSOM return for Computed value?
<nainar> TabAtkins: string based computd vaue can return layout dependant, but typed om cant
<nainar> dbaron: interpolatematrix in gecko internally. This is important for intepolation rules for transform Needs to interpolate between partial inter-polation results. So that you can change in the middle3of transtion
<nainar> dbaron: There is other rationale for interpolation this.
<nainar> dbaron: Thought we agrred to add this to transform spec?
<nainar> TabAtkins: Happy to add it but not there currently
<nainar> surma: why cant we interpolate on % value
<nainar> dbaron: you cant represent computed value without layout
<nainar> TabAtkins: GCS does used vaoue for this. We are trying to return ComputedValue which isnt representable as a list
<nainar> surma: Sounds like you need to solve geenrically.
<nainar> TabAtkins: Add interpolate function that interpolates between two values. Like cross fade
<nainar> TabAtkins: Proposal name is blend
<nainar> dbaron: Sounds too imge-y
<nainar> mwoodrow: Happy to accept concept not name
<nainar> dholbert: You could simplify calc in many cases.
<dholbert> s/calc/to calc/
<nainar> TabAtkins: computed value from 10 px to 10 px should be a px value not the function
<nainar> RESOLVED: Add generic interpolation function. Name TBD. For Units and Values spec.
<dbaron> s/Units and Values/Values and Units/

@tabatkins tabatkins mentioned this issue Jul 2, 2018
Closed
@tabatkins tabatkins mentioned this issue Jul 2, 2018
Closed
@tabatkins tabatkins changed the title [css-properties-values-api-1] What is the computed value of a <transform-list> in the middle of a layout dependent matrix decomposed interpolation? [css-values-4] What is the computed value of a <transform-list> in the middle of a layout dependent matrix decomposed interpolation? Jul 2, 2018
@alancutter alancutter mentioned this issue Jul 4, 2019
Closed
@Crissov Crissov mentioned this issue Jan 25, 2020
Closed
blueboxd pushed a commit to blueboxd/chromium-legacy that referenced this issue Oct 2, 2020
@george-steel
Fix TransformOperations::DependsOnBoxSize false positives
a911ce2 
Allow checks which skip a prefix, as needed for proper behavior in
TransformOperations::BlendRemainingByUsingMatrixInterpolation().
This method will now only create InterpolatedTransformationOperations
which are actually box-size dependent (as originally intended) ans
create a matrix otherwise. Add a DCHECK for this property.

Note that the interpolation defined in the css-transforms-1/2 specs
assume that transform styles are calculated after layout, with matrix
interpolation always producing a Matrix3DTransformOperation. As style
is calculated before layout, this isn't possible in cases where the
inputs to matrix interpolation are layout-dependent, so we have
InterpolatedTransformOperation to defer interpolation in these cases.

There is a currently CSSWG resolution to spec this behavior and give
InterpolatedTransformOperation a defined serialization, having
interpolation return a matrix as per the current spec where possible
(the inputs of matrix interpolation are layout-independent) and an
interpolated operation otherwise (where the current spec is
inconsistent). The added DCHECK enforces this behavior.
Resolution: w3c/csswg-drafts#2854

This is to prepare for using DependsOnBoxSize for invalidation of
compositor animations, enabling acceleration of percent-containing
transform.
Design Doc: https://docs.google.com/document/d/1zgr5CHRMpvlqodn1e0eM9J3MjL2eEMfAHrHsZUK7gMM/

Bug: 389359
Change-Id: I2302546225ac52f47104d2dd77b02f874d2f6ef8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2432194
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Reviewed-by: Ian Vollick <vollick@chromium.org>
Commit-Queue: George Steel <gtsteel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#813278}
@css-meeting-bot css-meeting-bot mentioned this issue Sep 29, 2021
Open
fantasai added a commit that referenced this issue Sep 29, 2021
@fantasai
[css-values-4] Add generic interpolation function. #581 #2854
05ba515
@fantasai
Copy link
Collaborator

@tabatkins Edits checked in, please look them over and close out the issue if they're acceptable to resolve this issue?

This was referenced Sep 29, 2021
Closed
Closed
@tabatkins
Copy link
Member Author

Yeah, this'll need some edits in Transforms to specify that it's used, but mix() is indeed sufficient for the purposes.

@fantasai fantasai changed the title [css-values-4] What is the computed value of a <transform-list> in the middle of a layout dependent matrix decomposed interpolation? [css-transforms-1] What is the computed value of a <transform-list> in the middle of a layout dependent matrix decomposed interpolation? Oct 22, 2021
@fantasai fantasai removed the css-values-4 Current Work label Oct 22, 2021
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
@george-steel @copybara-github
Fix TransformOperations::DependsOnBoxSize false positives
32a44b6 
Allow checks which skip a prefix, as needed for proper behavior in
TransformOperations::BlendRemainingByUsingMatrixInterpolation().
This method will now only create InterpolatedTransformationOperations
which are actually box-size dependent (as originally intended) ans
create a matrix otherwise. Add a DCHECK for this property.

Note that the interpolation defined in the css-transforms-1/2 specs
assume that transform styles are calculated after layout, with matrix
interpolation always producing a Matrix3DTransformOperation. As style
is calculated before layout, this isn't possible in cases where the
inputs to matrix interpolation are layout-dependent, so we have
InterpolatedTransformOperation to defer interpolation in these cases.

There is a currently CSSWG resolution to spec this behavior and give
InterpolatedTransformOperation a defined serialization, having
interpolation return a matrix as per the current spec where possible
(the inputs of matrix interpolation are layout-independent) and an
interpolated operation otherwise (where the current spec is
inconsistent). The added DCHECK enforces this behavior.
Resolution: w3c/csswg-drafts#2854

This is to prepare for using DependsOnBoxSize for invalidation of
compositor animations, enabling acceleration of percent-containing
transform.
Design Doc: https://docs.google.com/document/d/1zgr5CHRMpvlqodn1e0eM9J3MjL2eEMfAHrHsZUK7gMM/

Bug: 389359
Change-Id: I2302546225ac52f47104d2dd77b02f874d2f6ef8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2432194
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Reviewed-by: Ian Vollick <vollick@chromium.org>
Commit-Queue: George Steel <gtsteel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#813278}
GitOrigin-RevId: a911ce265552bcfa3bc5c29e1f6b54248e5d5158
@graouts graouts mentioned this issue Oct 24, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Accepted by CSSWG Resolution css-transforms-1 Current Work Needs Edits
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tabatkins @fantasai