Certain (background-*/border-*) related properties were not triggering
the behavior that disables native styling for buttons.
Updated the `border_background_properties` function to include
all properties in the `border` and `background` shorthands.
Differential Revision: https://phabricator.services.mozilla.com/D235326
Also, we have to tweak the serialization of animation shorthand.
We serialize animation shorthand only when animation-timeline is the
initial value (i.e. time-driven animations), so the resolved value of
animation-duration component is always 0s.
Differential Revision: https://phabricator.services.mozilla.com/D235353
We can resolve them off the main thread now due to registered custom
properties (which requires the computed <url> serialization).
Differential Revision: https://phabricator.services.mozilla.com/D234959
`has_anchor_function` in `CalcLengthPercentage` will be used to avoid traversing
the calc tree if we know the calc node tree does not have any anchor function.
Anchor resolution is done in a separate phase, because layout code queries for
`auto` insets without having a full context for the percentage basis.
Differential Revision: https://phabricator.services.mozilla.com/D231257
`has_anchor_function` in `CalcLengthPercentage` will be used to avoid traversing
the calc tree if we know the calc node tree does not have any anchor function.
Anchor resolution is done in a separate phase, because layout code queries for
`auto` insets without having a full context for the percentage basis.
Differential Revision: https://phabricator.services.mozilla.com/D231257
While required for Bug 1912241, unopaque operation can easily break the `Sync`
trait assumption for `OpaqueElement`. So, tighten the usage of unopaqued
element to ensure that it is used only for read-only access, and that it does
not leak out for general use.
Also, add documentation around functions for unopaque operation, cautioning
against its usage, if possible.
Differential Revision: https://phabricator.services.mozilla.com/D233758
Division denominators used to be assumed as resolvable numbers, but now
with color components we can have "numbers" that are only resolved
later, so we should handle that.
Differential Revision: https://phabricator.services.mozilla.com/D233236
- Serialize color components with `calc(..)` when specified in a calc node.
- Channel keywords outside `calc(..)` are serialized without `calc(..)`.
Differential Revision: https://phabricator.services.mozilla.com/D233234
When the result of a resolved relative color is in the color(srgb ..)
syntax, make sure not to clamp the components during the calculations.
Differential Revision: https://phabricator.services.mozilla.com/D232338
As per spec. This fixes an interop-2024 subtest, so would be nice to get
in sooner rather than later.
Most of the changes are rejiggering from passing the allowed flags to
pass the forbidden_flags, which was a bit easier now that we need to
check for them for specificity.
Differential Revision: https://phabricator.services.mozilla.com/D232735
The behavior of Servo_InterpolateColor was "backward": as the progress parameter
increased from 0.0 to 1.0, it would result in an increasing proportion of the
"left" color and a decreasing proportion of the "right" one, which was highly
counter-intuitive.
Callers were in effect working around this by passing (end, start) or (right, left)
to the (left, right) parameters of Servo_InterpolateColor. But the mismatch meant
that the meaning of "increasing" vs "decreasing" interpolation directions ended up
inverted as the interpolation was happening backwards from what the color-mix code
expects.
To rationalize the usage here, this patch renames the "left"/"right" parameters of
Servo_InterpolateColor to "start" and "end" for clarity, and makes the progress
parameter represent progress from the "start" color to the "end", which is the
natural expectation for the API. Then we swap the arguments at the callsites in
Gecko so as to pass (start, end) or (left, right), matching the formal parameters
of the function instead of reversing them.
With this change, we can also remove the tweak to adjust_hue added in bug 1885716 at
https://searchfox.org/mozilla-central/rev/3dbe1a8812ba126164526b5a9583600be233823e/servo/components/style/color/mix.rs#410-411
and revert to the condition as written in the spec, as "left" and "right" are no
longer swapped in comparision to the spec description.
A few reftests are added to confirm that hue interpolation directions (increasing vs
decreasing, longer vs shorter) now behave consistently.
Differential Revision: https://phabricator.services.mozilla.com/D232158
Note that both keywords are disabled in the CSS parser for now, behind
these about:config prefs:
layout.css.stretch-size-keyword.enabled
layout.css.webkit-fill-available.enabled
Prior to this patch, we handled both keywords as pure aliases for
'-moz-available' (which has the correct 'stretch' behavior in the inline axis
but which just behaves like the initial value in the block axis).
This patch changes that so that 'stretch' and '-webkit-fill-available' will now
actually do the right thing in the block axis (if they're enabled at all, via
their aforementioned about:config prefs).
The relevant spec text here is:
https://drafts.csswg.org/css-sizing-4/#valdef-width-stretchhttps://drafts.csswg.org/css-sizing-4/#stretch-fit-sizing
Differential Revision: https://phabricator.services.mozilla.com/D217688
The destination color was passed to the calculation function, but could
eaily be avoided by a better api. The function is not a member function
taking a single color, nor requiring loose args any more that can cause
confusion.
Differential Revision: https://phabricator.services.mozilla.com/D230500
First, we have to allow the functional parameter for named view
transition pseudo elements.
In this patch, we fix the case when `getComputedStyle()` resolve the style
lazily (i.e. call `Servo_ResolveStyleLazily()`) if its style is not available.
In this case, we have to make sure the matching function work.
We will make sure `aElement->GetPseudoElement(aPseudo)` work in the next
patch so we can retrieve the computed style from the pseudo elements
directly.
Differential Revision: https://phabricator.services.mozilla.com/D230354
The raw declaration block might change for a given rule. We need to keep
track of it properly for devtools in order to not lose track of rules.
Could I convince someone from DevTools to write a test for this? :)
Otherwise please point me to the right test to extend / change, and I
can.
Differential Revision: https://phabricator.services.mozilla.com/D230439
Per spec, "*" should be always matched, but its specificity is lower.
I only verify this by dumping the StrongRuleNode and the computed value
after doing cascade by myself. For now, we cannot use `getComputedStyle()`
for named view-transition (Bug 1919347). So only implementation in this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D230356
In order to match the selectors for the view-transition pseudo element,
we have to make sure we are using the correct `PseudoElement` (which includes
the functional parameter) when collecting the rules.
Note that this function is also used when matching the pseudo element in
the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D230024
