Repository navigation
[css-transforms-2] clamping of perspective() function to >= 1px should affect interpolation #6320
Description
Note: #3084, where the group decided to keep interpolation of the perspective property and the perspective() transform function different, is relevant background to this issue. Because of that decision, this issue applies only to the perspective() transform function and not to the perspective property.
The rules for interpolation of perspective say that perspective() functions are interpolated as matrices.
The definition of the perspective() function says:
If the depth value is less than 1px, it must be treated as 1px for the purpose of rendering.
It's not clear how this affects interpolation, since "for the purpose of rendering" probably doesn't include interpolation. However, since perspective values less than 1px rapidly lead the relevant component of the matrix to approach infinity, an animation from perspective(0) to some other perspective() value will spend most of its time between 0 and 1px, which probably isn't desirable.
It seems like it's probably useful to say that the clamping to 1px also affects interpolation endpoints, so that this doesn't happen. I think this would also be helpful for implementations since they don't need to worry about handling infinite or near-infinite values in matrices (like in Chromium issue 1205161, which is how I ended up here in the first place). On the other hand, it does add extra rules for handling what is basically an error case.
I'm curious what other folks think here. cc: @smfr @mattwoodrow @birtles.
Activity
dbaron commentedon May 27, 2021
I realize this is related to the post-reopening discussion in #413.
Correct handling of [0px,1px) values of perspective and perspective().
Correct handling of [0px,1px) values of perspective and perspective().
Correct handling of [0px,1px) values of perspective and perspective().
Correct handling of [0px,1px) values of perspective and perspective().
Correct handling of [0px,1px) values of perspective and perspective().
Correct handling of [0px,1px) values of perspective and perspective().
Correct handling of [0px,1px) values of perspective and perspective().
Correct handling of [0px,1px) values of perspective and perspective().
Correct handling of [0px,1px) values of perspective and perspective().
Correct handling of [0px,1px) values of perspective and perspective().
Bug 1713961 [wpt PR 29175] - Correct handling of [0px,1px) values of …
Bug 1713961 [wpt PR 29175] - Correct handling of [0px,1px) values of …
css-meeting-bot commentedon Jun 16, 2021
The CSS Working Group just discussed
Transforms, and agreed to the following:RESOLVED: clamp to 1px for both getComputedStyle() and interpolation as wellThe full IRC log of that discussion
<fantasai> Topic: Transforms<fremy> TabAtkins: but patent protection was not part of this, and this is not ideal
<TabAtkins> Like, look at the issues list, showing definite cross-browser discussion https://github.com/WICG/visual-viewport/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
<fantasai> github: https://github.com//issues/6320
<fantasai> github: https://github.com//issues/6346
<fantasai> dbaron[m]: Discussing 6320 and 6346 together
<fantasai> dbaron[m]: Group resolved that values less than 1px should be clamped to minimum of 1px
<fantasai> dbaron[m]: At the time, discussed as a render-time clamp
<fantasai> dbaron[m]: I tried implementing this. Believe I was the first
<fantasai> dbaron[m]: in the process, became clear that the time at which it became clamped was the time you convert to a matrix
<fantasai> dbaron[m]: problem with zero is that it puts infinite components into the matrix
<fantasai> dbaron[m]: There are 3 different ways convert to a matrix
<fantasai> dbaron[m]: 1) need to render, to find used value
<fantasai> dbaron[m]: 2) find resolved value for gCS()
<fantasai> dbaron[m]: computed value of transform function is "as specified with lengths made absolute"
<fantasai> dbaron[m]: but resolved value is a matrix
<fantasai> dbaron[m]: The third one, which is maybe more interesting, is interpolation
<fantasai> dbaron[m]: Perspective function gets interpreted as matrices
<fantasai> dbaron[m]: if you were to not clamp, and then interpolate from 0 to 2px,
<fantasai> dbaron[m]: entire range of animation would be clamped to 1px during render time, because animating from infinity to 0.5
<fantasai> dbaron[m]: which crosses 1 basically right when it gets to 0.5
<fantasai> dbaron[m]: Conclusion was do the clamp anytime I convert to matrices
<fantasai> dbaron[m]: so for gCS and for interpolation also
<fantasai> dbaron[m]: I've already implemented this in Canary ... does anyone think we should do something different?
<fantasai> dbaron[m]: not clear to me what that could be
<fantasai> github: https://github.com//issues/6320
<fantasai> smfr: Seems fine. What happens when perspective property or transform with only perspective, not converting matrices, do we need to describe beahvior there?
<fantasai> dbaron[m]: for perspective property, group explicitly resolved in 3084 that the animation should be different
<fantasai> dbaron[m]: so perspective property should interpret as specified
<fantasai> dbaron[m]: 2nd point, spec says that even a perspective() on its own gets interpolated as matrix
<fantasai> dbaron[m]: it describes the rules for interpolating matrix and perspective as the same thing
<fantasai> dbaron[m]: so decompose and do the pieces
<fantasai> dbaron[m]: for perspective it's trivial
<fantasai> dbaron[m]: but still the decomposition that gets interpolated is the matrix component, so ?? reciprocal
<fantasai> smfr: so that part is affected by your proposal
<fantasai> dbaron[m]: yes
<fantasai> smfr: I think it's reasonable
<fantasai> smfr: As long as we agree on where conversions to matrices happen
<fantasai> dbaron[m]: issues I filed are in terms of this should happen for inteprolation and this shoul dhappen or gCS
<fantasai> dbaron[m]: but rational was "wherever convert to matrix"
<fantasai> smfr: sounds fine
<fantasai> astearns: So original resolution for 413, did that cover resolved value?
<fantasai> dbaron[m]: no, said "for purpose of rendering"
<fantasai> astearns: so have a resolution for rendering, and you're saying extend to interpolation and resolved value
<fantasai> astearns: any other opinions?
<fantasai> astearns: ... implementation detail?
<fantasai> dbaron[m]: when editing spec, I'll see if it makes sense to fit that note in
<fantasai> [scribe missed, but guesses note was about the "convert to matrix" rationale]
<fantasai> RESOLVED: clamp to 1px for both getComputedStyle() and interpolation as well
<fantasai> dbaron[m]: possible not web-compatible, but can figure that out when we have data