We already have NonNegativeLength and NonNegativeAu, so we can re-use it
to define the specified value and the computed value of border-spacing.
And then implement ToAnimatedValue for it.
MozReview-Commit-ID: CLckpKMYVXU
Add NonNegativeLength, which could be computed to NonNegativeAu. So we
can declare Either<NonNegativeLength, X>, X=Auto, Normal, or Number.
NonNegativeLengthOrAuto is for column-width.
NonNegativeLengthOrNormal is for column-gap.
NonNegativeLengthOrNumber is for -moz-tab-size.
MozReview-Commit-ID: AfU8XpA1um0
Add values::computed::NonNegativeAu, so BorderSideWith could be computed
to this non-negative Au, for the following properties:
1. outline-width
2. border-{*}-width
3. column-rule-width
4. -webkit-text-stroke-width
MozReview-Commit-ID: ASHaB2F7VtM
NonNegativeNumber: for -moz-box-flex, flex-grow, and flex-shrink.
GreaterThanOrEqualToOneNumber: for stroke-miterlimit.
MozReview-Commit-ID: Kgbt99BPdVA
When computing the distance between two filter functions, e.g.
HueRotate(0deg) and HueRotate(-360deg), we got an Err(()) and unwrap it
immediately in compute_filter_square_distance(), which causes a crash.
The root-cause is that we don't implement computed_distance of Angle, and we
assume we always get a valid result from compute_squared_distance() for
each filter function.
In the case where we accumulate transform:none onto decomposed matrix for
iteration composite whose iteration count is over 2, we pass zero
other_portion and self_portion which is over 1.0. We should care about the
case.
The concept of inherited style is about to get a bit more complicated, and this
will prevent consumers from doing it wrong.
Part 1 of Gecko bug1382806. r=emilio
While decomposing a 3D matrix, we should normalize the 2nd row right after the
Y scale computation. However, we accidentally use the length of the 1st row to
do the normalization. This causes the wrong Scale3D function while decomposing,
and then leads to the wrong decomposed 3D matrix.
Here, we correct it by using the right value (the length of the 2nd row).
r=hiro https://bugzilla.mozilla.org/show_bug.cgi?id=1381196
Store font-weight as integer directly
It doesn't make much sense to store `font-weight` as separate enums, especially given that we would need to support (somehow) arbitrary font weight value when we implement CSS Fonts Level 4.
This PR refactors the `font-weight` a bit to make it store as `u16` directly.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17430)
<!-- Reviewable:end -->
We have to build an identity matrix while add_weighted() between
InterpolateMatrix and none transform in some cases, e.g. trigger a
transition from a mid-point of another transition to none.
