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

dbaron · 2021-06-03T17:32:29Z

Like #6320, this is a followup to the resolution in #413. It also depends on #4869 since the relevant piece of the spec isn't in great shape.

In #413 the group resolved that values less than 1px in the perspective() transform function should be clamped to a minimum of 1px. It was described there as a "render time clamp".

However, the resolved value of transform is (interoperably, I think) a matrix() or matrix3d() value. If perspective(0) is put in the matrix without the clamping, we'd need to figure out how to represent infinity in the matrix. While there are, in theory, ways we could do this (like calc(-1/0), it's not clear that those ways are actually reliably supported across engines. It seems both easier and more useful to produce the matrix that would actually be used at render time, but applying the clamping when producing the resolved value.

So I'd like to propose that the clamping of perspective() also apply to the resolved value.

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

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 <[email protected]> Reviewed-by: Xianzhu Wang <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> 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 <[email protected]> Reviewed-by: Xianzhu Wang <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> 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 <[email protected]> Reviewed-by: Xianzhu Wang <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/master@{#889344} -- wpt-commits: 7ad807c75d871dfde7bebd901590ecd754d6ae74 wpt-pr: 29175

astearns · 2021-06-16T17:24:46Z

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

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 <[email protected]> Reviewed-by: Xianzhu Wang <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/master@{#889344} NOKEYCHECK=True GitOrigin-RevId: 50b1cc46560ac75003b6c64db76fc14d23508735

dbaron added css-transforms-2 Needs Feedback/Review Needs Edits labels Jun 3, 2021

dbaron self-assigned this Jun 3, 2021

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

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

Merged

dbaron added the Agenda+ label Jun 4, 2021

css-meeting-bot mentioned this issue Jun 16, 2021

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

Closed

astearns removed the Agenda+ label Jun 16, 2021

mozilla-apprentice mentioned this issue Jun 16, 2021

[css-transforms-2] clamping of perspective() function should affect resolved value of transform mozilla/wg-decisions#568

Open

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

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 should affect resolved value of transform #6346

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

dbaron commented Jun 3, 2021

astearns commented Jun 16, 2021

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

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

Comments

dbaron commented Jun 3, 2021

astearns commented Jun 16, 2021