They are not transitionable:
https://drafts.csswg.org/css-transitions-1/#transitionable
There are some new failures in background-image-interpolation.html,
but I think the test is wrong, because it expects background-image
to be transitionable, even though the spec defines it with a discrete
animation type.
In legacy layout, anonymous text wrappers were inheriting the `overflow`
and `text-overflow` properties. This results in the creation of extra
clipping for these anonymous wrappers which could clip away floats. We
will likely implement `text-overflow` differently in non-legacy layout.
This change marks all legacy layout pseudo elements as "legacy" and also
adds a new pseudo element for non-legacy layout that does not inherit
`overflow`.
Fixes#30562.
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
* Implement support for `drop-shadow`
* Clean up remnant from early attempts
* Fix misleading comments on GenericSimpleShadow
If Servo-specific `style` changes will need to be upstreamed anyway, I might as well fix a thing that had thrown me off!
* Revert "Fix misleading comments on GenericSimpleShadow"
This reverts commit cdc810b826ac082041adc212c24649ee3b86ca0a.
* Clean up an import
* Update test expectations
* Fix missing expectation on Layout 2013
These are gated by the same layout.css.font-tech.enabled pref as the
closely-related `tech()` function for the @font-face src descriptor;
once the spec questions are settled, we should enable them all together.
Differential Revision: https://phabricator.services.mozilla.com/D155359
There are a couple of current issues/discussions that may lead to a change in the set of supported keywords, so we may want to hold back a little on actually shipping this.
- In https://github.com/w3c/IFT/pull/113, the WebFonts WG proposes several new incremental-* keywords (and maybe implies dropping the currently-defined incremental?)
- In https://github.com/w3c/csswg-drafts/issues/7633, I just proposed renaming the feature-* keywords to features-* (plural) for better readability; I'd like to see a decision on that before we ship this to release.
Differential Revision: https://phabricator.services.mozilla.com/D155458
Fix some tests to:
* Not assume `double` precision.
* Account for recent working group resolution with regards to NaN: https://github.com/w3c/csswg-drafts/issues/7067#issuecomment-1111211295
Not sure I caught all, but normalizing to 0 was already our existing
behavior. This feature needs more work before it can be enabled more
generally, so make it nightly-only, for now.
Also, it's unclear per spec what the serialization for infinity*1s or so
should be. Right now we serialize to <very-big-number>s, which seems
reasonable, but some tests (but not others!) expect different behavior.
I left those untouched for now.
Differential Revision: https://phabricator.services.mozilla.com/D154883
We now have test coverage, so let's do this.
The remaining failures are just about infinity/nan, which is a
completely different feature.
Differential Revision: https://phabricator.services.mozilla.com/D154831
Now that the style system has keywords for this, we don't need to define them in gfx
but can just use the enum directly. (No functional change, just code simplification.)
Depends on D154237
Differential Revision: https://phabricator.services.mozilla.com/D154238
This aligns with CSS Fonts 4 (rather than Fonts 3) and with behavior in other browsers;
I don't expect any significant breakage, given that specifying multiple format strings
was never supported in other engines AFAIK, and never served any useful purpose.
Depends on D154234
Differential Revision: https://phabricator.services.mozilla.com/D154235
We have unshipped these since forever, no point in keeping the pref
around. Move the relevant tests to chrome ref/mochitests.
Differential Revision: https://phabricator.services.mozilla.com/D154152
This matches what Linux and macOS do, and that allows the fix for bug 1782623
to work on Windows for unstyled selects.
This also simplifies the CSS (though it adds a new system color which is a bit
more annoying). I filed https://github.com/w3c/csswg-drafts/issues/7561 to
propose adding a more generic way to do this in the future (not just for
Firefox).
Differential Revision: https://phabricator.services.mozilla.com/D153549
When something switches to display: none, right now we rely on
StopAnimationsForElementsWithoutFrames(), which posts a restyle and the
previous ProcessPendingRestyles call was papering over it.
For other elements in the display none subtree it doesn't matter,
because we don't keep their styles around, but for the display: none
element themselves we do need to update transitions on time.
We could, possibly more generally, remove
StopAnimationsForElementsWithoutFrames() altogether and cancel
animations when we clear style data, perhaps... But that's probably
worth a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D151600
Even we don't have internal aliases right now (and that seems a bit
silly) we do have pref-gated aliases. An alias ID passed to IsEnabled
with the wrong EnabledState would misbehave, assert, and crash.
Though we don't have such callers in the tree because InspectorUtils
passes only arguments that make us not look at the flags, it seems more
reliable this way.
Differential Revision: https://phabricator.services.mozilla.com/D151594
So we can specify the keyframe-specific composite operation. However,
these is a spec issue about the default composite for CSS Animations:
https://github.com/w3c/csswg-drafts/issues/7476.
I choose to use auto as the default composite for missing keyframes to match
the definition in web-animations-1 because I think this makes more sense:
> If the keyframe-specific composite operation for a keyframe is not set, the
> composite operation specified for the keyframe effect as a whole is used for
> values specified in that keyframe.
Differential Revision: https://phabricator.services.mozilla.com/D150808
This patch introduces animation-composition longhand but we don't
accept it in @keyframe rule for now. I will support this for @keyframe
in the patch series.
Besides, the shorthand of animation doesn't include animation-composition.
The spec issue is: https://github.com/w3c/csswg-drafts/issues/6946.
We could fix the shorthand once this spec issue gets updated.
Differential Revision: https://phabricator.services.mozilla.com/D150299
Previously, had the smallest input value over all entries was assigned. However,
that does not match the behaviour of `linear-gradient(...)`, which this easing
function is modeled after.
Differential Revision: https://phabricator.services.mozilla.com/D149916
To be honest, I'm a bit baffled that bug 1773795 caused a performance
regression, but I think it's because the standins codepath is not really
cached, so system colors that are "spoofed" always go through the
massive switch, which could potentially be expensive.
To fix, this, rejigger a bit the caches so that we key on both
color-scheme and use-standins. Also, while at it, make the set of colors
we spoof a single bitflag check, rather than relying on the compiler to
do something potentially smart with it.
I had to shuffle the order of colors around so that the expression to
initialize the bitfield is constexpr (doesn't go over 1 << 64), but
other than that this patch should be relatively straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D150100
This ensures they're clamped on Animated -> sRGB conversion, and in the
future we'll have to implement different color spaces so we'll need to
use it anyways.
Differential Revision: https://phabricator.services.mozilla.com/D149792
