Rather than waiting until parsing another id (successfully or
unsuccessfully).
If we error before we even get to PropertyId::parse, we'd incorrectly
associate the error with the wrong property, incorrectly omitting it
sometimes.
Differential Revision: https://phabricator.services.mozilla.com/D78260
This begins to address #26625 by properly applying CSS variables during
keyframe computation and no longer using `apply_declarations`. Instead,
walk the declarations, combining them into IntermediateComputedKeyframe,
maintaining declarations that modify CSS custom properties. Then compute
a set of AnimationValues for each keyframe and use those to produce
interpolated animation values.
The current API was pretty awkward as a result of two things:
* Not being able to create empty iterators for smallbitvec.
* We used to call the `F` function multiple times, but turns out that
collecting the declarations in a SmallVec was a perf win.
So clean this up so that it looks more similar to other APIs, taking an
iterator directly.
This is a bit more code, but hopefully easier to understand (and also hopefully
easier to optimize).
The motivation for this work is that I plan to investigate rebasing / landing
https://github.com/servo/servo/pull/20151, and I don't want more instantiations
of apply_declarations and such.
Differential Revision: https://phabricator.services.mozilla.com/D74369
Although CssEnvironment is in Device of media query implementation, some code
creates CssEnvironment instance without Device. So I would like always to use it from Device of media query.
Differential Revision: https://phabricator.services.mozilla.com/D52506
Suppose that `prop` is a property that we haven't supported yet, while its `-moz-prop`
version is already supported.
If an author specifies in a declaration block this property in its standard form
as well as multiple verdor specific forms, as long as `-moz-prop` is specified, we
shouldn't report error for unknown property `prop`. Because that's just noise.
Differential Revision: https://phabricator.services.mozilla.com/D31998
I thought a bit about how to test it and it's not particularly great.
test_css_parse_error_smoketest.html is great to assert that something _gets_
reported, but not that it doesn't :)
Differential Revision: https://phabricator.services.mozilla.com/D30201
Also, buffer the errors, since we're going to want to look at the whole
declaration block to skip reporting them.
This shouldn't change behavior, just moves some work to the caller, and defers a
bit the work so that it happens only when error reporting is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D30200
The only fishy bit is the animation stuff. In particular, there are two places
where we just mint the revert behavior:
* When serializing web-animations keyframes (the custom properties stuff in
declaration_block.rs). That codepath is already not sound and I wanted to
get rid of it in bug 1501530, but what do I know.
* When getting an animation value from a property declaration. At that point
we no longer have the CSS rules that apply to the element to compute the
right revert value handy. It'd also use the wrong style anyway, I think,
given the way StyleBuilder::for_animation works.
We _could_ probably get them out of somewhere, but it seems like a whole lot
of code reinventing the wheel which is probably not useful, and that Blink
and WebKit just cannot implement either since they don't have a rule tree,
so it just doesn't seem worth the churn.
The custom properties code looks a bit different in order to minimize hash
lookups in the common case. FWIW, `revert` for custom properties doesn't seem
very useful either, but oh well.
Differential Revision: https://phabricator.services.mozilla.com/D21877
This implements the mechanism reusing the animation machinery for now, so it
asserts in a few cases that this wouldn't handle correctly.
For shorthands that have colors and other bits we'd need a more sophisticated
mechanism with a bit more code (that resolves colors and such), but it'd look
something like this regardless, and we should have this in any case.
Differential Revision: https://phabricator.services.mozilla.com/D11944
I think it used to be the case that all PropertyDeclaration variants had a
DeclaredValueOwned<T> inside. But that's no longer the case, so this abstraction
seems less useful now.
Differential Revision: https://phabricator.services.mozilla.com/D5978
Still not hooked into telemetry, I talked with :janerik and :gfritzsche about
that, but test incoming!
This intentionally doesn't handle CSSOM and such for now, will file followups
for those, though should be trivial.
I want to unify / clean up how we do the use counters and the error reporting
stuff for CSSOM, since the current function call still shows up in profiles,
but that should be a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D3828
The setup is that AnimationValue only contains physical properties, and
we physicalize when building keyframes and transitions.
Bug: 1309752
Reviewed-by: birtles
MozReview-Commit-ID: 9dI20N0LFrk
Summary:
This should make it easier to report errors, and also reduce codesize.
The reason this was so generic is that error reporting was unconditionally
enabled and was super-hot, but now that's no longer the case after bug 1452143,
so we can afford the virtual call in the "error reporting enabled" case.
This opens the possibility of simplifying a lot the error setup as well, though
this patch doesn't do it.
Test Plan: No behavior change, so no new tests.
Reviewers: xidorn
Bug #: 1469957
Differential Revision: https://phabricator.services.mozilla.com/D1734
MozReview-Commit-ID: F3wTdhX9MB5
It's only used for the error path in property parsing, so most of the time is
not useful.
Use the just-introduced NonCustomPropertyId::name to preserve the alias name,
which we were doing by passing the name around.
Bug: 1466645
Reviewed-by: xidorn
MozReview-Commit-ID: 46xxZKCoeBB
The early return for identical setting in importance matching as well
as the comment before `index_to_remove` are removed because the order
is web-exposing regardless of whether it's from CSSOM or parsing. e.g.
`top: 1px; left: 2px; top: 1px;` is effectively `left: 2px; top: 1px;`,
not `top: 1px; left: 2px;`.
The key here is that we only filter longhands if the shorthand is accessible to
content and vice-versa. This prevents the bug that prevented me to land this
patch before, which was us not expanding properly chrome-only shorthands.
Again, this is incomplete, and I need to teach LonghandsToSerialize to get a
potentially incomplete list of properties, and all that.
