Bug 1713961 [wpt PR 29175] - Correct handling of [0px,1px) values of perspective...

Bug 1713961 [wpt PR 29175] - Correct handling of [0px,1px) values of 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 https://github.com/w3c/csswg-drafts/issues/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
   https://github.com/w3c/csswg-drafts/issues/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
   https://github.com/w3c/csswg-drafts/issues/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
https://github.com/w3c/csswg-drafts/issues/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