[css-transforms-2] clamping of perspective() function should affect resolved value of transform #6346
Assignees
Comments
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jun 3, 2021
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
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jun 3, 2021
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
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jun 3, 2021
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
neptunesoft
pushed a commit
to neptunesoft/chromium
that referenced
this issue
Jun 4, 2021
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}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jun 5, 2021
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}
foolip
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jun 7, 2021
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}
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Jun 14, 2021
…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
jamienicol
pushed a commit
to jamienicol/gecko
that referenced
this issue
Jun 15, 2021
…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
|
RESOLVED: clamp to 1px for both getComputedStyle() and interpolation as well in #6320 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 of1px. It was described there as a "render time clamp".However, the resolved value of
transformis (interoperably, I think) amatrix()ormatrix3d()value. Ifperspective(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 (likecalc(-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: