Font code is the only thing that was using Au in the style system without
interfacing with Gecko, and there was no real reason for it to do so.
This slightly simplifies the code.
Differential Revision: https://phabricator.services.mozilla.com/D57248
For the individual transform properties if they spec a value that can be
expressed as 2d we treat as 2d and serialize accordingly.
We drop Translate::Translate and Scale::Scale, and then rename
Translate::Translate3D as Translate::Translate, Scale::Scale3D as
Scale::Scale. So now we use Translate::Translate to represent 2d and 3d
translation, and Scale::Scale to represent 2d and 3d scale. There is no
difference between 2d and 3d translate/scale in Gecko because we always
convert them into 3d format to layers (on the compositor thread), so this
change makes things simpler.
Differential Revision: https://phabricator.services.mozilla.com/D52931
Move all the entires of SpecialColorKeyword into SystemColor
and rearrange their computation to match.
Add the new SystemColor entries into the property list of nsXPLookAndFeel.
Differential Revision: https://phabricator.services.mozilla.com/D50903
This also includes the implementation of SetAnimatable, FromAnimatable,
and merge the final matrix with motion path.
Besides, we always use PathBuilderSkia for calculating the gfx::Path for
web-renderer.
Differential Revision: https://phabricator.services.mozilla.com/D50011
This is a gross hack, of course, but has the advantage of not breaking sites
that use both zoom and -moz-transform / -moz-transform-origin.
There should be no behavior change when the pref is off, of course, and the
webcompat team wanted to experiment with this.
Differential Revision: https://phabricator.services.mozilla.com/D49792
Mostly renaming for clarity, as the gradient parsing code is a bit hairy.
This also changes -webkit- gradients, which is, I think, the right thing to do
(otherwise I need to give up on the type system and sprinkle parse_non_negatives
around, which would be unfortunate).
I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1008112 on
Chromium still accepting negative radii for those, so will wait to submit the
patch for review until they reply there with their intentions.
Differential Revision: https://phabricator.services.mozilla.com/D47141
We always check StyleWillChangeBits_TRANSFORM bit together with a
transform-like property set, so using WillChangeBits::TRANSFORM bit to
represent all transform-like properties is ok.
However, it seems the new test case works well even if we don't have this
patch. I still add it for individual transform properties to make sure
the test coverage is enough anyway.
Differential Revision: https://phabricator.services.mozilla.com/D47509
Also, update the serialization by the shorter perference because this is
a new feature and using older syntax doesn't make sense.
Besides, use `cssOffset` for web animation IDL attribute name.
Differential Revision: https://phabricator.services.mozilla.com/D45607
This is in the interests of allowing the frontend team to experiment with
switching from XUL grid to CSS grid, without inadvertently changing the
display values for the grid items via css-grid-item blockification.
This patch's new pref is not expected to remain in the codebase for long.
We're just adding it so that the behavior remains the same by default, because
we do currently have some XUL code that inadvertently depends on -moz-box
display values being blockified to 'block'. The plan is for folks to remove
that dependency e.g. by adding explicit 'display:block' styling to frontend
code as-needed. After we've done that, we can tentatively flip the pref to true
by default, and then remove the pref entirely.
Differential Revision: https://phabricator.services.mozilla.com/D45258
1. Add `generics::motion::OffsetPath`, and use specified `Angle` and
computed `Angle` to define specified `OffsetPath` and computed `OffsetPath`.
2. Add `ray` function into `OffsetPath`.
We also tweak the degree from 150deg to 135deg in wpt (e.g.
offset-path-ray-001.html and others) to avoid floating point precision issues.
For example:
```
// offset-path: ray(150deg ...);
// offset-distance: 20px;
matrix:
{
{0.500000 0.866025 0.000000 0.000000},
{-0.866025 0.500000 0.000000 0.000000},
{0.000000 0.000000 1.000000 0.000000},
{10.000000 17.320509 0.000000 1.000000}
}
// rotate(60deg) translate(20px)
matrix:
{
{0.500000 0.866025 0.000000 0.000000},
{-0.866025 0.500000 0.000000 0.000000},
{0.000000 0.000000 1.000000 0.000000},
{10.000000 17.320507 0.000000 1.000000}
}
```
Their translate parts, 17.320509 vs 17.320507, are almost the same (only
tiny difference), which may cause the reftest failed.
Differential Revision: https://phabricator.services.mozilla.com/D42721
These two bugs (bug 1572738 and bug 1572451) are stylo regressions.
When font-family changes, we try to recompute the font-size with a length /
percentage combinations in case the generic family changes, so the user
preferences are kept.
When calc() is involved, we clamp to non-negative too early, via
NonNegativeLength::scale_by.
I think we should generally dump this "try to track font-size across calc()"
thingie, as as various comments note it is not quite perfect, and it's not clear
how it should work in presence of min()/max().
This patch fixes the issue and simplifies code a bit, I may consider removing
this altogether in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D41776
