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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Add a preference, layout.css.clip-path-path.enabled, for |clip-path:path()|.
Differential Revision: https://phabricator.services.mozilla.com/D4965
--HG--
extra : moz-landing-system : lando
This also removes one of my FIXMEs from when I was looking at this code.
We don't seem to have a pre-existing test for this feature, sigh. I'll try to
write one if I have cycles for it...
Note that it not applying XBL rules is a feature, given the current state of
affairs. Video controls and such are right now unusable with no styles enabled.
Differential Revision: https://phabricator.services.mozilla.com/D4795
--HG--
extra : moz-landing-system : lando
We always serialize as an atom, which is the previous behavior (though previous
code was using string escaping which I think was not totally sound either...).
Differential Revision: https://phabricator.services.mozilla.com/D4753
--HG--
extra : moz-landing-system : lando
We're wasting 1kb there, which is kind of stupid.
The only advantage of using a bloom filter is that memory usage doesn't increase
even if there's a gazillion attribute selectors and such. But:
* For IDs we already have a bunch of data structures for invalidation and such
which key on the id, so the bloom filter would be a very minor thing.
* For attribute selectors we don't have such a data structure, but if people
used a gazillion attribute selectors we should!
Differential Revision: https://phabricator.services.mozilla.com/D4668
--HG--
extra : moz-landing-system : lando
So that we don't waste a bunch of memory with stuff like <svg:use>. I
plan to shrink AuthorStyles further, but this should help regardless, and isn't
very complex.
Differential Revision: https://phabricator.services.mozilla.com/D4618
--HG--
extra : moz-landing-system : lando
This restores the old allocation semantics for "append" operations between
Latin1 and UTF-16 while keeping the buffer re-use optimization for the
"assign" cases.
MozReview-Commit-ID: 8JCw3AaCNLN
Differential Revision: https://phabricator.services.mozilla.com/D3582
--HG--
extra : moz-landing-system : lando
We only care about ascii char for svg path, so we could parse the string
as byte slice.
Differential Revision: https://phabricator.services.mozilla.com/D4168
--HG--
extra : moz-landing-system : lando
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
Emilio Cobos Álvarez
Simon Sapin
Anshul Malik
chansuke
Matt Brubeck
kingdido999
Hiroyuki Ikezoe
Cameron McCormack
Brad Werth
Daniel Varga
Henri Sivonen
Boris Chiou
Pyfisch
Craig Disselkoen
Ciure Andrei
arthur.iakab
Xidorn Quan