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
For now, |clip-path: path()| is chrome-only, and not for shape-outside,
so we only implement the parser for clip-path. Besides, I didn't put
path() in BasicShape because path() doesn't use the reference box to
resolve the percentage or keywords (i.e. SVG path only accept floating
point or integer number as the css pixel value). Therefore, I add it into
ShapeSource, instead of BasicShape.
Differential Revision: https://phabricator.services.mozilla.com/D3633
SVGPathData will be used by clip-path and offset-path (and/or more on the
properties which support <basic-shape>). Therefore, let's move
SVGPathData out of motion.rs.
Differential Revision: https://phabricator.services.mozilla.com/D3631
Just a minor fix to use cbindgen to avoid the conversion between
basic_shape::FillRule and mozilla::StyleFillRule.
Differential Revision: https://phabricator.services.mozilla.com/D4171
The implementation of ToCSS for Polygon has some rule, and we could use skip_if
to handle and serialization of fill-rule. However, we should derive ToCSS for
the pair of LengthOrPercentages, so define a new type for it.
Differential Revision: https://phabricator.services.mozilla.com/D4153
Define OffsetPath & SVGPathData on the servo-side, and StyleMotion &
StyleSVGPath on the gecko-side. We parse the SVG Path string into a
vector of PathCommand. To build the gfx::Path, we will convert it into
gfx::Path later in a different patch.
The basic flow is:
- Parse SVG Path String into SVGPathData (in Rust).
- Use cbindgen to make sure the layout of PathCommand and StylePathCommand, and then set the Box[PathCommand] into nsTArray<StylePathCommand>.
- Try to convert nsTArray<StylePathCommand> into gfx::Path. (This part will be implemented in a different patch.)
Finally, we use the gfx::Path to create a motion path transform.
The layout implementation is in the later patch.
Depends on D2962
Differential Revision: https://phabricator.services.mozilla.com/D2963
The '-moz-menulist-button' value currently behavies identically to the
'menulist-button' value. This is not implemented as an alias because later
patches in this patch series will change the behavior of our pre-existing
'menulist-button' value to more closely match what Chrome does.
Bug: 1428676
Reviewed-by: emilio
The patch at bug 1478391 comment 6 changed the way the math in Scrollbarbutton*
worked, which pretty surely caused this.
Restore the original order and math to be the same as before bug 1478391.
Bug: 1479216
Reviewed-by: xidorn
MozReview-Commit-ID: CK3iOqeX2NW
This builds on bug 1428676 and introduces StyleAppearance, which replaces the
NS_THEME_* constants.
Really sorry for the size of the patch.
There's a non-trivial change in the gtk theme, which I submitted separately as
bug 1478385.
Differential Revision: https://phabricator.services.mozilla.com/D2361
