Looks like this produces sensible results for interpolation with 0, though I'm
not really convinced about the results from, let's say, 1px to 2000px in the
attached test-case, I would've expected a linear interpolation from that to go
through normal length interpolation.
css-transforms-1 says:
> Two transform functions with the same name and the same number of arguments
> are interpolated numerically without a former conversion. The calculated
> value will be of the same transform function type with the same number of
> arguments.
>
> Special rules apply to <matrix()>.
Which is what we do... I was going to file a spec issue but turns out that it's
already addressed in css-transforms-2:
https://drafts.csswg.org/css-transforms-2/#interpolation-of-transform-functions
Which says:
> The transform functions <matrix()>, matrix3d() and perspective() get
> converted into 4x4 matrices first and interpolated as defined in section
> Interpolation of Matrices afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D4942
The setup is that AnimationValue only contains physical properties, and
we physicalize when building keyframes and transitions.
Bug: 1309752
Reviewed-by: birtles
MozReview-Commit-ID: 9dI20N0LFrk
It's possible that both this_weight and other_weght have calculation errors
which are approximately equal to f64::EPSILON.
Bug: 1468294
Reviewed-by: birtles
MozReview-Commit-ID: 8OddG9rI3qd
We were working around the lack of alias support during parsing in
TransitionProperty by doing a Gecko lookup. That's a hack and is now gone.
Bug: 1419695
Reviewed-by: xidorn
MozReview-Commit-ID: EptUvJNTrZr
Corresponding to this spec change;
32812668df
The expected value in test_transitions_per_property.html can be calculated;
'start' + ('end' - 'start') * 0.25
Bug: 1464647
Reviewed-by: birtles, emilio
MozReview-Commit-ID: NI9gOUuPnG
The skew resetting of temp I think fixes a bug in presence of skew in every
direction, but again haven't double-checked.
Bug: 1459403
Reviewed-by: hiro
MozReview-Commit-ID: Bn93CoaG8Bu
Per bug 1322189 we really should. I've copied the setup we have already for
translate / scale, but we should really clean this up a bit more I'd think.
In any case, probably skew should be matched as well...
Bug: 1464615
Reviewed-by: hiro
MozReview-Commit-ID: Jky5k8HVfuH
Also call them "resolve" since it's the general term for computing something
more specific than what you have.
Though I don't feel strongly about that, feel free to push back.
Bug: 1464595
Reviewed-by: hiro
MozReview-Commit-ID: KtqjzlppZLp
It's not sound to insert random matrices in random positions in the transform
operation list.
I cannot make any sense of what the old code was trying to do.
Bug: 1458715
Reviewed-by: hiro
MozReview-Commit-ID: 5BtCiueEPlR
Most of types just derive it using proc_macro directly. Some of value
types need manual impl.
In my current plan, this new trait will be used in bug 1434130 to expose
values as well.
Bug: 1455576
Reviewed-by: emilio
MozReview-Commit-ID: LI7fy45VkRw
These won't "just work", pending changes from bug 1436048 to use a floating
point representation for those.
Bug: 1454883
Reviewed-by: xidorn
MozReview-Commit-ID: Bi5iTdFreMA
This should fix the following two "expected to fail" tests:
- getComputedStyle(elem) for url() listStyleImage uses the resolved URL
and elem.style uses the original URL
- getComputedStyle(elem) for url() listStyle uses the resolved URL
and elem.style uses the original URL
The key here is that we only filter longhands if the shorthand is accessible to
content and vice-versa. This prevents the bug that prevented me to land this
patch before, which was us not expanding properly chrome-only shorthands.
Again, this is incomplete, and I need to teach LonghandsToSerialize to get a
potentially incomplete list of properties, and all that.
