[css-transforms-2] clamping of perspective() function to >= 1px should affect interpolation #6320

dbaron · 2021-05-27T20:57:52Z

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.

The text was updated successfully, but these errors were encountered:

dbaron · 2021-05-27T21:34:16Z

I realize this is related to the post-reopening discussion in #413.

This makes a number of fixes to handling small values of the perspective CSS property and the perspective() transform function to match the css-transforms-2 specification and the resolutions in w3c/csswg-drafts#413 : * Accept zero values of the perspective property at parse time. (They were already accepted for the perspective function.) Zero values are currently accepted by Gecko, but it treats them as the identity matrix (that is, as infinite perspective) rather than clamping to 1px. * Use -1.0 rather than 0.0 as the internal representation of perspective: none. * For both rendering and interpolation, treat values smaller than 1px as 1px. (This is what the spec says to do for rendering and what I believe it should say for interpolation; see w3c/csswg-drafts#6320.) * TODO: Describe other effects (if any?) of cleanup of Blend function. Parts of this are somewhat risky, since previously transform: perspective(0) was treated as the identity matrix and perspective: 0 was a syntax error, whereas this makes both be treated as very substantial transform (perspective from 1px away). The risk for handling of values in (0px, 1px) is probably less substantial since those were already treated as extreme transforms, and this makes them less extreme. Fixed: 1205161 Change-Id: Ie11a3d27d32e6ce16c39d670f6423a6710ba0971

This makes a number of fixes to handling small values of the perspective CSS property and the perspective() transform function to match the css-transforms-2 specification (the latest updates to which come from the resolutions in w3c/csswg-drafts#413): * Accept zero values of the perspective property at parse time. (They were already accepted for the perspective function.) Zero values are currently accepted by Gecko, but it treats them as the identity matrix (that is, as infinite perspective) rather than clamping to 1px. * Use -1.0 rather than 0.0 as the internal representation of perspective: none. * For both rendering and interpolation, treat values smaller than 1px as 1px. (This is what the spec says to do for rendering and what I believe it should say for interpolation; see w3c/csswg-drafts#6320.) It also substantially simplifies PerspectiveTransformOperation::Blend, although I *believe* the only substantive change is the clamping of its inputs to be 1px or larger. Parts of this are somewhat risky, since previously transform: perspective(0) was treated as the identity matrix and perspective: 0 was a syntax error, whereas this makes both be treated as very substantial transform (perspective from 1px away). The risk for handling of values in (0px, 1px) is probably less substantial since those were already treated as extreme transforms, and this makes them less extreme. There are thus three possible less-risky alternatives, from more risk (but less than this) to lowest risk: * Use this patch, but omit the changes to perspective: 0 and perspective(0) except for the change that makes perspective: 0 valid, but treat perspective: 0 as an identity transform like Gecko does. * Use this patch, but omit all the changes to perspective: 0px and perspective(0). * Change the behavior only when DBL_TRUE_MIN <= perspective < DBL_MIN, by treating perspective (property or function) as DBL_MIN in those cases. However, it's worth trying this riskier alternative and following the CSS Working Group's decision because that decision was made for good reasons. Taking this approach has two advantages: (1) It eliminates the only case where the valid values of a CSS property are an open range (a range exclusive of its endpoint), which creates difficulties for defining clamping of values to the valid range, which is important to CSS both for calc() and for animations (e.g., when the timing function result is outside of [0, 1]). (2) It eliminates a discontinuity in behavior at zero. Discontinuities in behavior cause animations that cross the discontinuity to behave poorly. Fixed: 1205161 Change-Id: Ie11a3d27d32e6ce16c39d670f6423a6710ba0971

This makes a number of fixes to handling small values of the perspective CSS property and the perspective() transform function to match the css-transforms-2 specification (the latest updates to which come from the resolutions in w3c/csswg-drafts#413): * Accept zero values of the perspective property at parse time. (They were already accepted for the perspective function.) Zero values are currently accepted by Gecko, but it treats them as the identity matrix (that is, as infinite perspective) rather than clamping to 1px. * Use -1.0 rather than 0.0 as the internal representation of perspective: none. * For both rendering and interpolation, treat values smaller than 1px as 1px. (This is what the spec says to do for rendering and what I believe it should say for interpolation; see w3c/csswg-drafts#6320.) It also substantially simplifies PerspectiveTransformOperation::Blend, although I *believe* the only substantive change is the clamping of its inputs to be 1px or larger. Parts of this are somewhat risky, since previously transform: perspective(0) was treated as the identity matrix and perspective: 0 was a syntax error, whereas this makes both be treated as very substantial transform (perspective from 1px away). The old behavior of transform: perspective(0) was interoperable across browsers. The old behavior of perspective: 0 was different in Gecko (where it was valid syntax, but like transform: perspective(0) was treated as the identity matrix), but the old behaviors across browsers still had in common that they all led to the identity matrix (whether valid or invalid syntax), which is not true of the new behavior. The risk for handling of values in (0px, 1px) is probably less substantial since those were already treated as extreme transforms, and this makes them less extreme. There are thus three possible less-risky alternatives, from more risk (but less than this) to lowest risk: * Use this patch, but omit the changes to perspective: 0 and perspective(0) except for the change that makes perspective: 0 valid, but treat perspective: 0 as an identity transform like Gecko does. * Use this patch, but omit all the changes to perspective: 0px and perspective(0). * Change the behavior only when DBL_TRUE_MIN <= perspective < DBL_MIN, by treating perspective (property or function) as DBL_MIN in those cases. However, it's worth trying this riskier alternative and following the CSS Working Group's decision because that decision was made for good reasons. Taking this approach has two advantages: (1) It eliminates the only case where the valid values of a CSS property are an open range (a range exclusive of its endpoint), which creates difficulties for defining clamping of values to the valid range, which is important to CSS both for calc() and for animations (e.g., when the timing function result is outside of [0, 1]). (2) It eliminates a discontinuity in behavior at zero. Discontinuities in behavior cause animations that cross the discontinuity to behave poorly. Fixed: 1205161 Change-Id: Ie11a3d27d32e6ce16c39d670f6423a6710ba0971

This makes a number of fixes to handling small values of the perspective CSS property and the perspective() transform function to match the css-transforms-2 specification (the latest updates to which come from the resolutions in w3c/csswg-drafts#413): * Accept zero values of the perspective property at parse time. (They were already accepted for the perspective function.) Zero values are currently accepted by Gecko, but it treats them as the identity matrix (that is, as infinite perspective) rather than clamping to 1px. * Use -1.0 rather than 0.0 as the internal representation of perspective: none. * For rendering of both the perspective property and the perspective() transform function, treat values smaller than 1px as 1px. * For interpolation of the perspective() transform function, treat values smaller than 1px as 1px. This is an additional clarification to the resolution that I proposed in w3c/csswg-drafts#6320. * When handling the perspective() transform function when finding the resolved value of the transform property (which is a matrix() or matrix3d() value), treat values smaller than 1px as 1px. (Resolved values are the results of getComputedStyle().) This is an additional clarification that I proposed in w3c/csswg-drafts#6346. Note that interpolation and resolved values of the perspective property since both interpolation and resolved values match the specified values. In the case of interpolation that was resolved specifically in w3c/csswg-drafts#3084. It also substantially simplifies PerspectiveTransformOperation::Blend, although I *believe* the only substantive change is the clamping of its inputs to be 1px or larger. Parts of this are somewhat risky, since previously transform: perspective(0) was treated as the identity matrix and perspective: 0 was a syntax error, whereas this makes both be treated as very substantial transform (perspective from 1px away). The old behavior of transform: perspective(0) was interoperable across browsers. The old behavior of perspective: 0 was different in Gecko (where it was valid syntax, but like transform: perspective(0) was treated as the identity matrix), but the old behaviors across browsers still had in common that they all led to the identity matrix (whether valid or invalid syntax), which is not true of the new behavior. The risk for handling of values in (0px, 1px) is probably less substantial since those were already treated as extreme transforms, and this makes them less extreme. There are thus three possible less-risky alternatives, from more risk (but less than this) to lowest risk: * Use this patch, but omit the changes to perspective: 0 and perspective(0) except for the change that makes perspective: 0 valid, but treat perspective: 0 as an identity transform like Gecko does. * Use this patch, but omit all the changes to perspective: 0px and perspective(0). * Change the behavior only when DBL_TRUE_MIN <= perspective < DBL_MIN, by treating perspective (property or function) as DBL_MIN in those cases. However, it's worth trying this riskier alternative and following the CSS Working Group's decision because that decision was made for good reasons. Taking this approach has two advantages: (1) It eliminates the only case where the valid values of a CSS property are an open range (a range exclusive of its endpoint), which creates difficulties for defining clamping of values to the valid range, which is important to CSS both for calc() and for animations (e.g., when the timing function result is outside of [0, 1]). (2) It eliminates a discontinuity in behavior at zero. Discontinuities in behavior cause animations that cross the discontinuity to behave poorly. Fixed: 1205161 Change-Id: Ie11a3d27d32e6ce16c39d670f6423a6710ba0971

This makes a number of fixes to handling small values of the perspective CSS property and the perspective() transform function to match the css-transforms-2 specification (the latest updates to which come from the resolutions in w3c/csswg-drafts#413): * Accept zero values of the perspective property at parse time. (They were already accepted for the perspective function.) Zero values are currently accepted by Gecko, but it treats them as the identity matrix (that is, as infinite perspective) rather than clamping to 1px. * Use -1.0 rather than 0.0 as the internal representation of perspective: none. * For rendering of both the perspective property and the perspective() transform function, treat values smaller than 1px as 1px. * For interpolation of the perspective() transform function, treat values smaller than 1px as 1px. This is an additional clarification to the resolution that I proposed in w3c/csswg-drafts#6320. * When handling the perspective() transform function when finding the resolved value of the transform property (which is a matrix() or matrix3d() value), treat values smaller than 1px as 1px. (Resolved values are the results of getComputedStyle().) This is an additional clarification that I proposed in w3c/csswg-drafts#6346. Note that interpolation and resolved values of the perspective property since both interpolation and resolved values match the specified values. In the case of interpolation that was resolved specifically in w3c/csswg-drafts#3084. It also substantially simplifies PerspectiveTransformOperation::Blend, although I *believe* the only substantive change is the clamping of its inputs to be 1px or larger. Parts of this are somewhat risky, since previously transform: perspective(0) was treated as the identity matrix and perspective: 0 was a syntax error, whereas this makes both be treated as very substantial transform (perspective from 1px away). The old behavior of transform: perspective(0) was interoperable across browsers. The old behavior of perspective: 0 was different in Gecko (where it was valid syntax, but like transform: perspective(0) was treated as the identity matrix), but the old behaviors across browsers still had in common that they all led to the identity matrix (whether valid or invalid syntax), which is not true of the new behavior. The risk for handling of values in (0px, 1px) is probably less substantial since those were already treated as extreme transforms, and this makes them less extreme. There are thus three possible less-risky alternatives, from more risk (but less than this) to lowest risk: * Use this patch, but omit the changes to perspective: 0 and perspective(0) except for the change that makes perspective: 0 valid, but treat perspective: 0 as an identity transform like Gecko does. * Use this patch, but omit all the changes to perspective: 0px and perspective(0). * Change the behavior only when DBL_TRUE_MIN <= perspective < DBL_MIN, by treating perspective (property or function) as DBL_MIN in those cases. However, it's worth trying this riskier alternative and following the CSS Working Group's decision because that decision was made for good reasons. Taking this approach has two advantages: (1) It eliminates the only case where the valid values of a CSS property are an open range (a range exclusive of its endpoint), which creates difficulties for defining clamping of values to the valid range, which is important to CSS both for calc() and for animations (e.g., when the timing function result is outside of [0, 1]). (2) It eliminates a discontinuity in behavior at zero. Discontinuities in behavior cause animations that cross the discontinuity to behave poorly. Fixed: 1205161 Change-Id: Ie11a3d27d32e6ce16c39d670f6423a6710ba0971 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2924023 Commit-Queue: David Baron <dbaron@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/master@{#889344}

This makes a number of fixes to handling small values of the perspective CSS property and the perspective() transform function to match the css-transforms-2 specification (the latest updates to which come from the resolutions in w3c/csswg-drafts#413): * Accept zero values of the perspective property at parse time. (They were already accepted for the perspective function.) Zero values are currently accepted by Gecko, but it treats them as the identity matrix (that is, as infinite perspective) rather than clamping to 1px. * Use -1.0 rather than 0.0 as the internal representation of perspective: none. * For rendering of both the perspective property and the perspective() transform function, treat values smaller than 1px as 1px. * For interpolation of the perspective() transform function, treat values smaller than 1px as 1px. This is an additional clarification to the resolution that I proposed in w3c/csswg-drafts#6320. * When handling the perspective() transform function when finding the resolved value of the transform property (which is a matrix() or matrix3d() value), treat values smaller than 1px as 1px. (Resolved values are the results of getComputedStyle().) This is an additional clarification that I proposed in w3c/csswg-drafts#6346. Note that interpolation and resolved values of the perspective property since both interpolation and resolved values match the specified values. In the case of interpolation that was resolved specifically in w3c/csswg-drafts#3084. It also substantially simplifies PerspectiveTransformOperation::Blend, although I *believe* the only substantive change is the clamping of its inputs to be 1px or larger. Parts of this are somewhat risky, since previously transform: perspective(0) was treated as the identity matrix and perspective: 0 was a syntax error, whereas this makes both be treated as very substantial transform (perspective from 1px away). The old behavior of transform: perspective(0) was interoperable across browsers. The old behavior of perspective: 0 was different in Gecko (where it was valid syntax, but like transform: perspective(0) was treated as the identity matrix), but the old behaviors across browsers still had in common that they all led to the identity matrix (whether valid or invalid syntax), which is not true of the new behavior. The risk for handling of values in (0px, 1px) is probably less substantial since those were already treated as extreme transforms, and this makes them less extreme. There are thus three possible less-risky alternatives, from more risk (but less than this) to lowest risk: * Use this patch, but omit the changes to perspective: 0 and perspective(0) except for the change that makes perspective: 0 valid, but treat perspective: 0 as an identity transform like Gecko does. * Use this patch, but omit all the changes to perspective: 0px and perspective(0). * Change the behavior only when DBL_TRUE_MIN <= perspective < DBL_MIN, by treating perspective (property or function) as DBL_MIN in those cases. However, it's worth trying this riskier alternative and following the CSS Working Group's decision because that decision was made for good reasons. Taking this approach has two advantages: (1) It eliminates the only case where the valid values of a CSS property are an open range (a range exclusive of its endpoint), which creates difficulties for defining clamping of values to the valid range, which is important to CSS both for calc() and for animations (e.g., when the timing function result is outside of [0, 1]). (2) It eliminates a discontinuity in behavior at zero. Discontinuities in behavior cause animations that cross the discontinuity to behave poorly. Fixed: 1205161 Change-Id: Ie11a3d27d32e6ce16c39d670f6423a6710ba0971 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2924023 Commit-Queue: David Baron <dbaron@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/master@{#889344}

…perspective and perspective()., a=testonly Automatic update from web-platform-tests Correct handling of [0px,1px) values of perspective and perspective(). This makes a number of fixes to handling small values of the perspective CSS property and the perspective() transform function to match the css-transforms-2 specification (the latest updates to which come from the resolutions in w3c/csswg-drafts#413): * Accept zero values of the perspective property at parse time. (They were already accepted for the perspective function.) Zero values are currently accepted by Gecko, but it treats them as the identity matrix (that is, as infinite perspective) rather than clamping to 1px. * Use -1.0 rather than 0.0 as the internal representation of perspective: none. * For rendering of both the perspective property and the perspective() transform function, treat values smaller than 1px as 1px. * For interpolation of the perspective() transform function, treat values smaller than 1px as 1px. This is an additional clarification to the resolution that I proposed in w3c/csswg-drafts#6320. * When handling the perspective() transform function when finding the resolved value of the transform property (which is a matrix() or matrix3d() value), treat values smaller than 1px as 1px. (Resolved values are the results of getComputedStyle().) This is an additional clarification that I proposed in w3c/csswg-drafts#6346. Note that interpolation and resolved values of the perspective property since both interpolation and resolved values match the specified values. In the case of interpolation that was resolved specifically in w3c/csswg-drafts#3084. It also substantially simplifies PerspectiveTransformOperation::Blend, although I *believe* the only substantive change is the clamping of its inputs to be 1px or larger. Parts of this are somewhat risky, since previously transform: perspective(0) was treated as the identity matrix and perspective: 0 was a syntax error, whereas this makes both be treated as very substantial transform (perspective from 1px away). The old behavior of transform: perspective(0) was interoperable across browsers. The old behavior of perspective: 0 was different in Gecko (where it was valid syntax, but like transform: perspective(0) was treated as the identity matrix), but the old behaviors across browsers still had in common that they all led to the identity matrix (whether valid or invalid syntax), which is not true of the new behavior. The risk for handling of values in (0px, 1px) is probably less substantial since those were already treated as extreme transforms, and this makes them less extreme. There are thus three possible less-risky alternatives, from more risk (but less than this) to lowest risk: * Use this patch, but omit the changes to perspective: 0 and perspective(0) except for the change that makes perspective: 0 valid, but treat perspective: 0 as an identity transform like Gecko does. * Use this patch, but omit all the changes to perspective: 0px and perspective(0). * Change the behavior only when DBL_TRUE_MIN <= perspective < DBL_MIN, by treating perspective (property or function) as DBL_MIN in those cases. However, it's worth trying this riskier alternative and following the CSS Working Group's decision because that decision was made for good reasons. Taking this approach has two advantages: (1) It eliminates the only case where the valid values of a CSS property are an open range (a range exclusive of its endpoint), which creates difficulties for defining clamping of values to the valid range, which is important to CSS both for calc() and for animations (e.g., when the timing function result is outside of [0, 1]). (2) It eliminates a discontinuity in behavior at zero. Discontinuities in behavior cause animations that cross the discontinuity to behave poorly. Fixed: 1205161 Change-Id: Ie11a3d27d32e6ce16c39d670f6423a6710ba0971 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2924023 Commit-Queue: David Baron <dbaron@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/master@{#889344} -- wpt-commits: 7ad807c75d871dfde7bebd901590ecd754d6ae74 wpt-pr: 29175

css-meeting-bot · 2021-06-16T16:43:54Z

The CSS Working Group just discussed Transforms, and agreed to the following:

RESOLVED: clamp to 1px for both getComputedStyle() and interpolation as well

The 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

This makes a number of fixes to handling small values of the perspective CSS property and the perspective() transform function to match the css-transforms-2 specification (the latest updates to which come from the resolutions in w3c/csswg-drafts#413): * Accept zero values of the perspective property at parse time. (They were already accepted for the perspective function.) Zero values are currently accepted by Gecko, but it treats them as the identity matrix (that is, as infinite perspective) rather than clamping to 1px. * Use -1.0 rather than 0.0 as the internal representation of perspective: none. * For rendering of both the perspective property and the perspective() transform function, treat values smaller than 1px as 1px. * For interpolation of the perspective() transform function, treat values smaller than 1px as 1px. This is an additional clarification to the resolution that I proposed in w3c/csswg-drafts#6320. * When handling the perspective() transform function when finding the resolved value of the transform property (which is a matrix() or matrix3d() value), treat values smaller than 1px as 1px. (Resolved values are the results of getComputedStyle().) This is an additional clarification that I proposed in w3c/csswg-drafts#6346. Note that interpolation and resolved values of the perspective property since both interpolation and resolved values match the specified values. In the case of interpolation that was resolved specifically in w3c/csswg-drafts#3084. It also substantially simplifies PerspectiveTransformOperation::Blend, although I *believe* the only substantive change is the clamping of its inputs to be 1px or larger. Parts of this are somewhat risky, since previously transform: perspective(0) was treated as the identity matrix and perspective: 0 was a syntax error, whereas this makes both be treated as very substantial transform (perspective from 1px away). The old behavior of transform: perspective(0) was interoperable across browsers. The old behavior of perspective: 0 was different in Gecko (where it was valid syntax, but like transform: perspective(0) was treated as the identity matrix), but the old behaviors across browsers still had in common that they all led to the identity matrix (whether valid or invalid syntax), which is not true of the new behavior. The risk for handling of values in (0px, 1px) is probably less substantial since those were already treated as extreme transforms, and this makes them less extreme. There are thus three possible less-risky alternatives, from more risk (but less than this) to lowest risk: * Use this patch, but omit the changes to perspective: 0 and perspective(0) except for the change that makes perspective: 0 valid, but treat perspective: 0 as an identity transform like Gecko does. * Use this patch, but omit all the changes to perspective: 0px and perspective(0). * Change the behavior only when DBL_TRUE_MIN <= perspective < DBL_MIN, by treating perspective (property or function) as DBL_MIN in those cases. However, it's worth trying this riskier alternative and following the CSS Working Group's decision because that decision was made for good reasons. Taking this approach has two advantages: (1) It eliminates the only case where the valid values of a CSS property are an open range (a range exclusive of its endpoint), which creates difficulties for defining clamping of values to the valid range, which is important to CSS both for calc() and for animations (e.g., when the timing function result is outside of [0, 1]). (2) It eliminates a discontinuity in behavior at zero. Discontinuities in behavior cause animations that cross the discontinuity to behave poorly. Fixed: 1205161 Change-Id: Ie11a3d27d32e6ce16c39d670f6423a6710ba0971 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2924023 Commit-Queue: David Baron <dbaron@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/master@{#889344} NOKEYCHECK=True GitOrigin-RevId: 50b1cc46560ac75003b6c64db76fc14d23508735

dbaron added css-transforms-2 Needs Feedback/Review Needs Edits labels May 27, 2021

chromium-wpt-export-bot mentioned this issue Jun 1, 2021

Correct handling of [0px,1px) values of perspective and perspective(). web-platform-tests/wpt#29175

Merged

dbaron mentioned this issue Jun 3, 2021

[css-transforms-2] clamping of perspective() function should affect resolved value of transform #6346

Closed

dbaron self-assigned this Jun 3, 2021

dbaron added the Agenda+ label Jun 4, 2021

css-meeting-bot removed the Agenda+ label Jun 16, 2021

mozilla-apprentice mentioned this issue Jun 16, 2021

[css-transforms-2] clamping of perspective() function to >= 1px should affect interpolation mozilla/wg-decisions#565

Open

dbaron closed this as completed in 14f90cd Jun 16, 2021

emilio mentioned this issue Aug 2, 2021

[css-transforms] After #6320 there's no way to get an identity transform for interpolation of perspective #6488

Closed

dbaron mentioned this issue Oct 19, 2021

[css-transforms] Zero value in perspective() function #413

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-transforms-2] clamping of perspective() function to >= 1px should affect interpolation #6320

[css-transforms-2] clamping of perspective() function to >= 1px should affect interpolation #6320

dbaron commented May 27, 2021 •

edited

Loading

dbaron commented May 27, 2021

css-meeting-bot commented Jun 16, 2021

[css-transforms-2] clamping of perspective() function to >= 1px should affect interpolation #6320

[css-transforms-2] clamping of perspective() function to >= 1px should affect interpolation #6320

Comments

dbaron commented May 27, 2021 • edited Loading

dbaron commented May 27, 2021

css-meeting-bot commented Jun 16, 2021

dbaron commented May 27, 2021 •

edited

Loading