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

upsuper · 2016-08-18T01:47:40Z

Please see the discussion in the mailing list 1, 2, and also whatwg/compat#48.

In the current spec, zero is invalid for perspective() function and perspective property, which, according to Tab, violates CSS's rule of limited range. The spec should be changed to something like

specify that there's a UA-defined minimum perspective length, and anything below that length (but not negative) is clamped to it.

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

upsuper · 2016-08-18T01:48:41Z

cc @tabatkins @smfr @grorg

upsuper · 2016-11-11T00:12:00Z

Note that, this change leads to interoperability issue in Firefox as shown in this bug. Imgur uses perspective(0) in an animation, which leads to some rendering weirdness.

They do something like:

@keyframes flipin {
  from { transform: perspective(500px) translate(-50%, 0) rotateX(-90deg) rotateY(0); }
  to { transform: perspective(0) translate(-50%, 115%) rotateX(0) rotateY(0); }
}

Browsers agree on the same weirdness if the value in perspective function is changed to 1px. What I don't quite understand is how Blink handles this case. If I understand the spec correctly, even if it handles perspective(0) itself like infinite, there should still be intermediate value inserted between 500px and 0. Probably Blink consistently handles 0 as infinite everywhere? (But how can an infinite value be animatable?)

smfr · 2017-01-12T17:45:51Z

RESOLVED: For animation/rendering purposes, canonicalize perspective(0) to perspective(inf).

smfr · 2017-01-12T17:49:49Z

RESOLVED: UAs must introduce near 0 clamping for perspective

upsuper · 2017-01-15T07:29:08Z

What about perspective property? Is perspective: 0 treated as perspective: inf as well?

Also, IIRC @tabatkins mentioned in the irc that perspective(calc(0)) is treated as perspective(epsilon), which should be mentioned at least in a note, I think.

upsuper · 2017-01-19T23:13:38Z

I don't think perspective(calc(0)) should be treated differently from perspective(0). That seems to make it harder to implement and doesn't seem to add much usefulness.

upsuper · 2017-02-24T00:07:26Z

So there is another webcompat issue reported to Firefox for not treating perspective: 0 as perspective: inf (which perspective: none does as well). I'm sad... but probably we should handle perspective property the same way.

ewilligers · 2019-09-06T21:38:17Z

If we decide to accept 0 in perspective() and perspective:, here is a possible spec change:
#4279

Possible Blink change with WPTs:
https://chromium-review.googlesource.com/c/chromium/src/+/1789207

Firefox already passes. Currently shipping Blink and Safari fail these suggested tests by rejecting perspective: 0px and hence not creating a stacking context.

Proposed implementation and test change for w3c/csswg-drafts#413 Change-Id: I4207cb9f91fd8743185e16fb87cd44f9b925cebd

css-meeting-bot · 2019-10-02T23:59:30Z

The CSS Working Group just discussed Zero value in perspective() function, and agreed to the following:

RESOLVED: 0 is allowed with 1px being the render time clamp

The full IRC log of that discussion

<dael> Topic: Zero value in perspective() function
<dael> github: https://github.com//issues/413
<dael> AmeliaBR: The issue is that now spec says perspective param needs to be a positive non-0 which goes against general rule that we don't have indeterminate ranges that include everything except exact value. need firm closed range
<dael> AmeliaBR: Eric put together a PR for exact wording. Prop: it's a closed range that's UA determined for the end of the range
<dael> AmeliaBR: No, his is specifically 0 is valid but when you give 0 then your matrix eq is the identity matrix. 0 is valid parsing value with clearly defined behavior
<AmeliaBR> Eric's PR text: https://github.com//pull/4279/files
<dael> smfr: Problem with 0 as identity you get discontinuity of animating from 0. 0 is no perspective and then you animate to non-0 and it's super close. It's like scale 0 which is non-invertable. perspective(0) should be like perspective(infinity)
<dael> AmeliaBR: Expecting perspective(0) to be same as infinitly large which is no transformation. Does cause discontinuity when moving from that to a very small value
<dael> dino: I don't htink matters what we do. If you animate to 0 it's a horrible result. Rather it disappears or infinity it looks bad
<dael> AmeliaBR: Just important to have a clear rule
<dael> dino: 0 = infinity is best user result even though it doesn't quite make sense
<dael> Rossen_: Where do we take this?
<dael> AmeliaBR: Do we accept Eric W. proposed edits?
<dael> dbaron: The discussion you were having made me feel like we'd be better saying it's UA defined close range at some amount slightly above 0 rather than say 0 is valid
<dael> dino: Should be clampped a fair way above 0. I fyou want to do something good for user don't let them get close
<dael> TabAtkins: 0 not valid or valid and clampped upward
<dael> dbaron: I was saying not valid, but okay with clamp upward
<dael> TabAtkins: IN general that's an open range and I don't like that. Much prefer 0 is valid with a UA clamp to reasonable minimum.
<dael> AmeliaBR: Agree we don't want UA dependent limits for parsing validity. Actual rendering clampping upwards seems reasonable
<dael> TabAtkins: Letting 0 be eq to a minimum value UA clamps to, that's the best situation. That's our normal principle for these ranges
<dael> AmeliaBR: TabAtkins will you make edits for this interpretation?
<dael> TabAtkins: Yeah
<dael> AmeliaBR: Other question is on impl and what do they do and who will change
<dael> dino: webkit is willing to change. It's rendering time. CSS goes to 0, but won't paint as 0
<dael> TabAtkins: Agreed
<dael> mwoodrow: I think gecko would be willing to change but I'd like to define it in the spec
<dael> TabAtkins: 1px?
<dael> mwoodrow: Fine
<dael> myles: Need to say if 0 returned by gCS?
<dael> TabAtkins: If it's a render time clamp gCS will be 0
<dael> AmeliaBR: As far as limit 1px should be valid and used on exact math. 0px not exact math and somewhere in there browsers are allowed to clamp rendering code
<dael> TabAtkins: Right now I don't think...I think every browser does 1px and down below. Render depends on precision or when the rendering library barfs. I'm fine with UA defined limit with a suggest of 1px. I fwe want defined 1px is a nice thing to hit
<dael> florian: If we have a specific value it's not an open range anymore
<dael> Rossen_: Proposal is
<dael> TabAtkins: 0 is allowed with 1px being the render time clamp
<dael> Rossen_: Objections?
<dael> RESOLVED: 0 is allowed with 1px being the render time clamp

ewilligers · 2019-10-10T09:12:32Z

If it's a render time clamp gCS will be 0

RESOLVED: 0 is allowed with 1px being the render time clamp

With the perspective property, I understand the resolution to mean that 0px gives gCS result 0px but renders as if 1px was supplied.

With the perspective() function, I am less clear about the intent.

Does perspective(0) give gCS result "matrix3d(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, -Infinity, 0, 0, 0, 1)" or "matrix3d(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, -1, 0, 0, 0, 1)" ?

tabatkins · 2019-10-10T23:14:56Z

@ewilligers I don't quite understand the question. perspective: X; and transform: perspective(X); are identical, right?

ewilligers · 2019-10-11T00:41:44Z

gCS for perspective: X is a length. gCS for transform: perspective(X) is a matrix3d(). Example

We have at least the following options.

Option 1: clamping does not affect gCS results.

gCS for transform: perspective(0) is "matrix3d(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, -Infinity, 0, 0, 0, 1)".

I don't think this option would address @smfr's concern: to avoid infinity during animation, we need to clamp at computed value time.

Option 2: clamping at computed value time for transform: perspective(X) , at render time for perspective: X.

Option 3: clamping for perspective: X and transform: perspective(X) at computed value time.

For consistency between perspective: X and transform: perspective(X), I would suggest Option 3.

AmeliaBR · 2019-10-11T01:28:50Z

(If I'd thought about this interaction between the two perspective() related issues we discussed last week, I would have argued stronger for changing the perspective function to compute/animate as itself!)

But, that said: we don't have an infinity keyword in CSS. But, the agreed upon format for serialization (from #3768 (comment)) is calc(1/0). So you could use that in the computed value for representing perspective(0) as a matrix3d function.

tabatkins · 2019-10-14T23:04:26Z

Yeah, I'm not against the idea of serializing the infinity as calc(1/0) or calc(-1/0).

But I'm also fine with clamping at computed-value time, as long as we do it for both cases (Eric's option 3).

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

This updates the `perspective` property and `perspective()` function to reflect some existing errors (regarding negative values) and some new CSS working group resolutions that have at this point all shipped in Chrome and some of which have shipped in Gecko: * w3c/csswg-drafts#413 resolved that 0 is allowed in both the property and the function, but values of both that are less than 1px are clamped to 1px. * w3c/csswg-drafts#6488 added the `none` value to the perspective() function; it was already a value of the perspective property. It also adds some clarification about what large/small/none values mean.

This updates the `perspective` property and `perspective()` function to reflect some existing errors (regarding negative values) and some new CSS working group resolutions that have at this point all shipped in at least one of Firefox or Chrome (and which I think are all likely to ship in the other soon, and hopefully in Safari as well): * w3c/csswg-drafts#413 resolved that 0 is allowed in both the property and the function, but values of both that are less than 1px are clamped to 1px. * w3c/csswg-drafts#6488 added the `none` value to the perspective() function; it was already a value of the perspective property. It also adds some clarification about what large/small/none values mean.

…9653) This updates the `perspective` property and `perspective()` function to reflect some existing errors (regarding negative values) and some new CSS working group resolutions that have at this point all shipped in at least one of Firefox or Chrome (and which I think are all likely to ship in the other soon, and hopefully in Safari as well): * w3c/csswg-drafts#413 resolved that 0 is allowed in both the property and the function, but values of both that are less than 1px are clamped to 1px. * w3c/csswg-drafts#6488 added the `none` value to the perspective() function; it was already a value of the perspective property. It also adds some clarification about what large/small/none values mean.

dbaron · 2021-10-19T15:18:22Z

The followup issue for which this was reopened was resolved in #6320 and #6346, so closing again.

…ne). Fixing the neutral element for addition was missed when making changes for perspective clamping and for adding 'perspective(none)'. Followup to #6488 and #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 (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

upsuper added the css-transforms-1 Current Work label Aug 18, 2016

smfr mentioned this issue Jan 12, 2017

[css-transforms] Spec doesn't actually define perspective(0), and behavior is crazy anyway #886

Closed

smfr added the Needs Edits label Jan 12, 2017

cvrebert mentioned this issue Jan 15, 2017

Document zero-perspective transform quirk whatwg/compat#48

Open

smfr added css-transforms-2 and removed css-transforms-1 Current Work labels Mar 22, 2017

ewilligers mentioned this issue Sep 6, 2019

[css-transforms] Zero value in perspective #4279

Closed

ewilligers added the Agenda+ label Sep 6, 2019

chromium-wpt-export-bot mentioned this issue Sep 9, 2019

CSS: perspective and transform: perspective() accept 0px web-platform-tests/wpt#18911

Closed

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 9, 2019

CSS: perspective and transform: perspective() accept 0px

df9a395

Proposed implementation and test change for w3c/csswg-drafts#413 Change-Id: I4207cb9f91fd8743185e16fb87cd44f9b925cebd

css-meeting-bot removed the Agenda+ label Oct 2, 2019

mozilla-apprentice mentioned this issue Oct 2, 2019

[css-transforms] Zero value in perspective() function mozilla/wg-decisions#115

Open

tabatkins closed this as completed in 3febf59 Oct 3, 2019

ewilligers mentioned this issue Oct 10, 2019

[css-transforms-2] Is it necessary to serialize all 3 components of translate given the 3rd component is 0px #3305

Open

mozilla-apprentice mentioned this issue Oct 10, 2019

[css-transforms] Zero value in perspective() function mozilla/wg-decisions#121

Closed

tabatkins reopened this Oct 14, 2019

dbaron added the Needs Feedback/Review label Mar 25, 2021

dbaron mentioned this issue May 27, 2021

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

Closed

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 mentioned this issue Oct 7, 2021

Updates to CSS perspective property and perspective() function. mdn/content#9653

Merged

3 tasks

dbaron closed this as completed Oct 19, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

upsuper commented Aug 18, 2016

upsuper commented Aug 18, 2016

upsuper commented Nov 11, 2016

smfr commented Jan 12, 2017

smfr commented Jan 12, 2017

upsuper commented Jan 15, 2017

upsuper commented Jan 19, 2017

upsuper commented Feb 24, 2017

ewilligers commented Sep 6, 2019 •

edited

Loading

css-meeting-bot commented Oct 2, 2019

ewilligers commented Oct 10, 2019

tabatkins commented Oct 10, 2019

ewilligers commented Oct 11, 2019 •

edited

Loading

AmeliaBR commented Oct 11, 2019

tabatkins commented Oct 14, 2019

dbaron commented Oct 19, 2021

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

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

Comments

upsuper commented Aug 18, 2016

upsuper commented Aug 18, 2016

upsuper commented Nov 11, 2016

smfr commented Jan 12, 2017

smfr commented Jan 12, 2017

upsuper commented Jan 15, 2017

upsuper commented Jan 19, 2017

upsuper commented Feb 24, 2017

ewilligers commented Sep 6, 2019 • edited Loading

css-meeting-bot commented Oct 2, 2019

ewilligers commented Oct 10, 2019

tabatkins commented Oct 10, 2019

ewilligers commented Oct 11, 2019 • edited Loading

AmeliaBR commented Oct 11, 2019

tabatkins commented Oct 14, 2019

dbaron commented Oct 19, 2021

ewilligers commented Sep 6, 2019 •

edited

Loading

ewilligers commented Oct 11, 2019 •

edited

Loading