The only reason it was on style_traits is so that they could use it from some
other crates, but Servo eventually ends up getting the value from an integer, so
may as well pass it around and do that in the end of the process anyway.
Differential Revision: https://phabricator.services.mozilla.com/D16557
It does not represent `<length> | <percentage>`, but `<length-percentage>`, so
`LengthOrPercentage` is not the right name.
This patch is totally autogenerated using:
rg 'LengthOrPercentage' servo | cut -d : -f 1 | sort | uniq > files
for file in $(cat files); do sed -i "s#LengthOrPercentage#LengthPercentage#g" $file; done
Differential Revision: https://phabricator.services.mozilla.com/D15812
--HG--
extra : moz-landing-system : lando
(Also remove stale decl for DoGetOverflowY, which cleanup_computed_getters.py
found for me.)
Differential Revision: https://phabricator.services.mozilla.com/D14618
--HG--
extra : moz-landing-system : lando
I'm pretty sure the FIXME I left in the outline-style code is a bug,
but I want to clean this up further and I didn't want to fix it without adding
a test.
Differential Revision: https://phabricator.services.mozilla.com/D12859
--HG--
extra : moz-landing-system : lando
Skip mask and text-decoration for now since there's a single test-case failing
for each that seem worth fixing in a different bug:
* For mask, there's the case of setting mask: url(foo.svg#bar), which we test
we serialize absolutely. But given we're uncomputing it we don't serialize
the resolved URL. Chrome doesn't either so we could just change the test, but
even if we decided to do it we probably should do it in a separate bug.
* For text-decoration, we need to resolve the value, when it's an interpolation
between currentcolor and other color. Right now that returns the empty string
which is not great:
https://searchfox.org/mozilla-central/rev/d850d799a0009f851b5535580e0a8b4bb2c591d7/servo/components/style/values/specified/color.rs#194
So I need to come up with something. Probably we need to implement the "hard"
version of the serialization code that doesn't reuse the animation machinery.
Definitely a separate bug though.
While at it, also serialize all <position> longhands with Servo, so that I can
clean up the tests.
Differential Revision: https://phabricator.services.mozilla.com/D11948
--HG--
extra : moz-landing-system : lando
Basically, we rewrite the type of generics::transform::Translate and its
ToCss to match the spec. Besides, we always serialize Translate by servo,
so we could drop a lot of duplicated code.
Differential Revision: https://phabricator.services.mozilla.com/D11206
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
With this change, all of Chrome, Edge, Firefox, and Safari serialize
border-image-repeat by omitting a repeated keyword, so we update a WPT
that was expecting duplicated keywords.
Differential Revision: https://phabricator.services.mozilla.com/D10445
--HG--
extra : moz-landing-system : lando
This is the first step to unprefix user-select.
This has no behavior change, it's just a nicer way to do the same thing which
allows us to unship individual values more easily using parse(condition).
Differential Revision: https://phabricator.services.mozilla.com/D11580
This is the first step to unprefix user-select.
This has no behavior change, it's just a nicer way to do the same thing which
allows us to unship individual values more easily using parse(condition).
Differential Revision: https://phabricator.services.mozilla.com/D11580
We could make sure we serialize TimingFunction for both computed
and specified values with servo (via CSSOM). However, Web animation
APIs could also serialize the timing function from a different code
path. We will fix it in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D10443
--HG--
extra : moz-landing-system : lando
This needs to update the "fill-rule" and "clip-rule" to use
predefined_type to avoid some compilation errors.
Differential Revision: https://phabricator.services.mozilla.com/D10142
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
This changes the serialization of -moz-image-region to be consistent with that
of clip(), but it's an internal property and the specified value is already
serialized by servo so I think it's the right thing to do.
There are also no internal callers of the getter.
Differential Revision: https://phabricator.services.mozilla.com/D7069
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.
Differential Revision: https://phabricator.services.mozilla.com/D2963
We have a different order in nsCSSPropertyId for no good reason. The only
invariant there is that longhands come before shorthands, and shorthands before
aliases.
Luckily that's also an invariant that NonCustomPropertyId has, so we can reuse
them.
Differential Revision: https://phabricator.services.mozilla.com/D2463
MozReview-Commit-ID: 1hsQu6hmqiN
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
MozReview-Commit-ID: DiSmMWK7Krp
... and cleanup unused keywords / getters using the scripts in
layout/style/tools
Differential Revision: https://phabricator.services.mozilla.com/D1901
MozReview-Commit-ID: BRUGcje7X0q
This changes the order of properties returned from gCS. The old order
doesn't make much sense, and other browsers don't agree on an identical
order either, so it should be trivial to change it. Also the spec isn't
super clear / useful in this case.
Several -moz-prefixed properties are excluded from the list due to their
being internal. I suspect they are never accessible anyway, so probably
nothing gets changed by this.
MozReview-Commit-ID: 9LfangjpJ3P
--HG--
extra : source : 879a7265c35f51c5954d8a44ccd374a606ecba0e
The idea is to turn the simple properties into a blacklist instead really soon,
and fix the offending ones soon after, so that only shorthands and properties
with layout dependence (and maybe the scrollbar properties, because the poke at
LookAndFeel) are not serialized by Servo.
MozReview-Commit-ID: JTLNnmXzny8
The idea is to turn the simple properties into a blacklist instead really soon,
and fix the offending ones soon after, so that only shorthands and properties
with layout dependence (and maybe the scrollbar properties, because the poke at
LookAndFeel) are not serialized by Servo.
MozReview-Commit-ID: JTLNnmXzny8
I manually diffed the generated lists and the original ones from in
nsCSSProps.cpp. All generated lists seem to contain the same set of
subproperties as their old correspondents.
There are still some differences:
Order of subproperties of many shorthands is changed. There are many
comments in the old lists stating that the order is important, but they
are mostly for serialization. I auditted all users of the subproperty
lists, and it doesn't seem to me any of them relies on the order.
gOutlineRadiusSubpropTable is renamed to gMozOutlineRadiusSubpropTable
which I don't think is a problem at all, but maybe worth mentioning.
MozReview-Commit-ID: 190SBZfxVOW
--HG--
extra : rebase_source : cd5e8b1667a4550542c361d31361e45456c6b6a3
This patch changes ServoCSSPropList.py to use classes for properties.
This allows extending the data in the file without needing to update all
users of this file.
Sorting in GenerateCSSPropsGenerated.py is removed because the data file
has the right order already.
MozReview-Commit-ID: D74bItCfpPH
--HG--
extra : rebase_source : e0138c255f77515f491496fcb8680686362f4e9e
