The current spec says: "If only the X value is given, the Y value
defaults to the same value.", so we should update the behavior.
Besides, we also update the serialization, so we serialization both
specified and computed value by servo. We enable the preference
for all the css-transforms, so some of them are passed now.
Differential Revision: https://phabricator.services.mozilla.com/D10638
With this change, all of Chrome, Edge, Firefox, and Safari serialize
background-size by omitting the second "auto" if the value is "auto
auto". Other keywords are still repeated.
Differential Revision: https://phabricator.services.mozilla.com/D10446
Also remove specified-value-only keywords, since those are handled
only in Rust code and C++ doesn't need to know about them.
Differential Revision: https://phabricator.services.mozilla.com/D9634
1. Add a new preference, layout.css.step-position-jump.enabled, for
step(_, jump-*) timing functions.
2. We still keep JumpEnd and End tags, even though there is no difference
between them. Therefore, we could disable the preference if needed.
3. Update the calculation of StepTiming to match the algorithm in the spec.
4. For servo, we implement the correct step function algorithm except
for the handling of before_flag. This could be fixed later.
Depends on D9313
Differential Revision: https://phabricator.services.mozilla.com/D9314
First, we generate StyleComputedTimingFunction by cbindgen from Rust, and use
it in nsTimingFunction, so we could copy it directly without handling
the different memory layout. However, we have to rewrite the
nsTimingFunction and mozilla::ComputedTimingFunction for this.
Second, the rust-bindgen seems cannot generate the correct generic members
from complex C++ templates, especially for the nested template struct,
(https://github.com/rust-lang-nursery/rust-bindgen/issues/1429)
So we have to hide StyleTimingFunction to avoid the compilation errors.
Differential Revision: https://phabricator.services.mozilla.com/D9313
We make sure the step number is always positive, so using
computed::Integer is safe and can derive ToComputedValue.
Depends on D9311
Differential Revision: https://phabricator.services.mozilla.com/D9845
TimingFunction is defined in a separate spec (i.e. css-easing), instead
of transform, so we move it into a different file.
Depends on D9310
Differential Revision: https://phabricator.services.mozilla.com/D9311
frames() timing function was removed from the spec, so we drop it.
Besides, some devtool tests are removed because they use frame(). I will
add them back by using new step function later.
Differential Revision: https://phabricator.services.mozilla.com/D9309
In order to get the correct computed value of these keywords, we have to
make sure we store the correct computed values in sizing properties in
both inline axis and block axis.
-moz-max-content and -moz-min-content should behave as the property's
initial value in block axis. -moz-fit-content and -moz-available are not
supported in block axis, so we also treat them as initial values.
Differential Revision: https://phabricator.services.mozilla.com/D8290
This matches the spec, https://drafts.csswg.org/css-values/#angles, which says:
> All <angle> units are compatible, and deg is their canonical unit.
And https://drafts.csswg.org/css-values/#compat, which says:
>When serializing computed values [...], compatible units [...] are converted into a single canonical unit.
And also other implementations (Blink always serializes angles as degrees in
computed style for example).
Also allows us to get rid of quite a bit of code, and makes computed angle value
representation just a number, which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D8619
I had to fix the conversion for BackgroundSize too, hopefully we can
simplify all this using cbindgen in the future instead of CalcValue.
Differential Revision: https://phabricator.services.mozilla.com/D7580
This commit adds the multi-position gradient color-stops syntax.
GradientItem::parse_comma_separated is extended to attempt to parse
a LengthOrPercent after each color stop. If it succeeds, it appends
an additional color stop with a duplicate color and the specified
position.
This change is only to the parsing, serialization is left unchanged
as per [1].
[1] https://github.com/w3c/csswg-drafts/issues/2714
Differential Revision: https://phabricator.services.mozilla.com/D7380
There are a few mentions of nsRuleNode left but they are mostly
historical references so it makes sense to keep them.
Differential Revision: https://phabricator.services.mozilla.com/D5505
We define the standalone types for using derive macro easily and overriding
the behaviors of this traits. This could avoid defining the general
behavior of booleans.
Depends on D4788
Differential Revision: https://phabricator.services.mozilla.com/D4813
Here, we change the animation type of offset-path as ComputedValue, so
we could do animation on it. Also enable the wpt for offset-path
interpolation. In test_transition_per_property.html, we add some basic tests
ifor offset-path.
ToAnimatedZero for PathCommand will be dropped later.
Because the animations of arcs with mismatched flags are fallen back to
discrete animations, the result of getComputedValue is not normalized in this
case. This makes some wpt failed even though the progress is 100%.
Depends on D4786
Differential Revision: https://phabricator.services.mozilla.com/D4787
Implement Animate trait for SVGPathData.
The basic idea is: we normalize |this| and |other| svg paths, and then
do interpolation on the normalized svg paths. The normalization is to
convert relative coordinates into absolute coordinates, so we could do
real number interpolation on each path command directly.
In this patch, we also make |clip-path:path()| animatable.
Differential Revision: https://phabricator.services.mozilla.com/D4786
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
