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
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
With this change, we first generate a data file ServoCSSPropList.py from
Servo data, and then use this data to generate ServoCSSPropList.h.
This change itself serves as a checkpoint with a runtime check that all
information generated from Servo side matches what we have in the Gecko
side. Following patches will start replacing uses of nsCSSPropList.h
with either the data file or the header file.
The reason that it generates data file rather than header directly is
that, many users of PythonCSSProps.h invokes C++ preprocessor manually
to extract data from nsCSSPropList.h without passing in search paths,
so it is non-trivial to replace the use of nsCSSPropList.h there with
a generated header. Generating a Python data file would hopefully
simplify those users rather than adding more complexity to them.
I also thought about generating JSON rather than plain Python file, but
JSON doesn't allow trailing comma in array, which makes it less pretty
to generate via mako template.
MozReview-Commit-ID: CwK2oL88r6F
--HG--
extra : rebase_source : aaf98cfd768740fdd6ac4961fc825d84adaf94a5
With this change, we first generate a data file ServoCSSPropList.py from
Servo data, and then use this data to generate ServoCSSPropList.h.
This change itself serves as a checkpoint with a runtime check that all
information generated from Servo side matches what we have in the Gecko
side. Following patches will start replacing uses of nsCSSPropList.h
with either the data file or the header file.
The reason that it generates data file rather than header directly is
that, many users of PythonCSSProps.h invokes C++ preprocessor manually
to extract data from nsCSSPropList.h without passing in search paths,
so it is non-trivial to replace the use of nsCSSPropList.h there with
a generated header. Generating a Python data file would hopefully
simplify those users rather than adding more complexity to them.
I also thought about generating JSON rather than plain Python file, but
JSON doesn't allow trailing comma in array, which makes it less pretty
to generate via mako template.
MozReview-Commit-ID: CwK2oL88r6F
--HG--
extra : rebase_source : 926cca8548d42ecb0dd364ea5c52a46a4973e819
Cameron McCormack
Boris Chiou
Emilio Cobos Álvarez
Xidorn Quan
Gurzau Raul
Andreea Pavel