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
We use the same setup WR uses, which is checking-in the files.
But I think it's much better than keeping the two things in sync manually :)
When you add a new value, you need to add it to the rust source, then run the
command, but since it doesn't need to build the style crate (it uses the Rust
AST, doesn't build) there's no problem.
Differential Revision: https://phabricator.services.mozilla.com/D2354
If we have a rotate axis whose length is extremely large, we will get an
infinite value, and its normalized vector is a zero vector, instead of an
unit vector, i.e. (x/inf, y/inf, z/inf) == (0, 0, 0).
The solution is: we scale the vector, so the length becomes a finite value, and
we could get a valid unit vector.
Therefore, we use a different normalization method, robust_normalize().
Bug: 1467277
Reviewed-by: hiro
Implement update source set & select image source
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#11416 (github issue number if applicable).
- [x] These changes require tests but cannot be written until implementation of responsive images is complete
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- 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/21181)
<!-- Reviewable:end -->
Which is more appropriate, given it represents a `<media-feature>` per spec, and
expression is a bit overloaded :)
Bug: 1422225
Reviewed-by: xidorn
MozReview-Commit-ID: Fed1nJhHxDu
Extract the common parts of `animated::Color` and `computed::Color` out
into `generics::color::Color<T>` that is generic over the type of
RGBA color.
Bug: 1465307
Reviewed-by: xidorn
MozReview-Commit-ID: EymSr7aqnAP
Refactored StyleComplexColor to support "complex" blending between
background (numeric) color and foreground color (currentColor).
Made explicit the distinction between numeric, currentColor and a
complex blend in Gecko and Stylo.
This is to support SMIL animation, for example, of the form:
<animate from="rgb(10,20,30)" by="currentColor" ... />
Bug: 1465307
Reviewed-by: hiro,xidorn
MozReview-Commit-ID: IUAK8P07gtm
And make transition-property more correct by serializing --0 unescaped instead
of escaped.
Bug: 1466645
Reviewed-by: xidorn
MozReview-Commit-ID: CCBSe5Frd0d
This would cause properties to change the value semantics between, e.g.,
@keyframes and non-@keyframes, which would be observable.
It happens not to be observable since the animation-* and transition-*
properties are not allowed in @keyframes, nor have bits in `contain`, and none
of the two properties are allowed in @page. But I think it's the right thing to
do.
This still causes a quirk like a property value in chrome / user origins being
potentially different if the value is specified via CSS var functions. But I
think that is fine.
Bug: 1466136
Reviewed-by: hiro
MozReview-Commit-ID: GhoPt0I34oO
