This is a bit less complicated than lengths because there's no cycle
possible which could turn the color-scheme declaration invalid afaict.
So it's just that we need to defer the colors when color-scheme is
specified, which is slightly annoying, but maybe not too bad.
I had to tweak a bit the code to defer properties to fix a bug that we
were papering over accidentally. We were using the wrong registration
here:
https://searchfox.org/mozilla-central/rev/f60bb10a5fe6936f9e9f9e8a90d52c18a0ffd818/servo/components/style/custom_properties.rs#1613
That's the registration for reference.name, not for name, which
papered over some issues. The fix is simple tho, which is storing a
single CustomPropertiesMap.
Differential Revision: https://phabricator.services.mozilla.com/D211860
This is simpler given we only have a couple of windows with these looks,
and removes the dual mode of the ToolbarWindow class.
We just draw the title into the window frame and rely on CSS reserving
enough space (exposed as a new -moz-mac-titlebar-height environment
variable).
We remove the toolbox and toolbar appearance values on mac, now that
they do nothing (toolbar did, but it didn't support dark mode and is
effectively unused).
Differential Revision: https://phabricator.services.mozilla.com/D205469
This is simpler given we only have a couple of windows with these looks,
and removes the dual mode of the ToolbarWindow class.
We just draw the title into the window frame and rely on CSS reserving
enough space (exposed as a new -moz-mac-titlebar-height environment
variable).
We remove the toolbox and toolbar appearance values on mac, now that
they do nothing (toolbar did, but it didn't support dark mode and is
effectively unused).
Differential Revision: https://phabricator.services.mozilla.com/D205469
Add a TODO for bug 1883255, since D203361 fixes bug 1870348.
Add a TODO for bug 1884606, since WPTs for interpolating custom
properties with syntax `<transform-function>` and with value `none` now
fail.
Differential Revision: https://phabricator.services.mozilla.com/D203361
Unparsed custom properties are the
ComputedRegisteredValueInner::Universal variant.
Although the inner value is the ComputedRegisteredValueInner type,
custom property maps hold only the
ComputedRegisteredValueInner::Universal variant to keep behavior
unchanged for now.
D203360 also removes Arc<> from the CustomPropertiesMap value.
Differential Revision: https://phabricator.services.mozilla.com/D203360
Add a TODO for bug 1883255, since D203361 fixes bug 1870348.
Add a TODO for bug 1884606, since WPTs for interpolating custom
properties with syntax `<transform-function>` and with value `none` now
fail.
Differential Revision: https://phabricator.services.mozilla.com/D203361
Unparsed custom properties are the
ComputedRegisteredValueInner::Universal variant.
Although the inner value is the ComputedRegisteredValueInner type,
custom property maps hold only the
ComputedRegisteredValueInner::Universal variant to keep behavior
unchanged for now.
D203360 also removes Arc<> from the CustomPropertiesMap value.
Differential Revision: https://phabricator.services.mozilla.com/D203360
In order to do it, expose the button padding to CSS via env(), and make
the buttons just use the regular drawing.
This slightly changes the padding to the end of the titlebar to match
one half of the inter-button spacing, rather that however much padding
the headerbar has.
We could improve on this slightly by also exposing the headerbar padding
and applying that to the last button, but that's not terribly easy to do
due to us supporting re-ordering of the titlebar buttons, and reversing
their placement, so it'd involve some rather hacky CSS. Not impossible,
but not trivial, and this looks good enough IMO.
Differential Revision: https://phabricator.services.mozilla.com/D202616
This speeds up custom variable substitution by avoiding re-tokenizing,
and variable reference parsing by avoiding doing duplicate work.
This is a very noticeable improvement in the NewsSite subtests of
speedometer 3 (see comparison posted in bug 1879318 and the #perf-sp3
matrix channel). But it also probably helps most websites using lots of
variables, and the browser UI itself.
Finally, it also avoids some duplication. Now regular substitution and
fallback substitution is handled uniformly, which causes a progression
in some properties-and-values tests.
Differential Revision: https://phabricator.services.mozilla.com/D201116
This is a preliminary patch to keep all references (even duplicates), in
order to speed up substitution by avoiding re-tokenizing.
The assumption is that referencing the same variable multiple times
on the declaration is not common, and thus it's not a big deal to
optimize for that.
Differential Revision: https://phabricator.services.mozilla.com/D201082
Inherited properties with universal syntax and unregistered properties should
behave basically the same.
This removes some redundant checks and guarantees that we have the same
code-paths in those two cases.
Differential Revision: https://phabricator.services.mozilla.com/D200995
Reduce the amount of times we need to manually call the custom property
registration code by handling values with and without references in the same
function.
Differential Revision: https://phabricator.services.mozilla.com/D200993
Dependencies between custom properties and font-* properties are
resolved in bug 1855110, so these TODOs for bug 1856522 can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D199208
Resolution of such custom properties (And other properties depending on them)
must take place after font-related properties (Which are prioritary) are
resolved. Resolution of custom properties is therefore split into two phases,
before and after prioritary properties are resolved.
Differential Revision: https://phabricator.services.mozilla.com/D196195
Registered custom properties may utilize font-relative units such as `em`,
`ex`, etc. Font-related properties (More with `calc()` unit algebra), in
turn, may refer to such registered custom properties, leading to a cycle
(Note, unregistered properties are effectively copy-pastes, so it does not
suffer from this issue).
This patch:
1. Defers computation of registstered custom properties using font-relative
units
2. Keeps track of custom properties utilizing font-relative units
3. Keeps track of non-custom, font-related properties making variable
references
4. Expands the cycle detection to non-custom properties
Because of 1, this patch causes registered custom property using
font-relative units to resolve as if they're unregistered - this will be
addressed in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D196194
This implements a similar optimization as WebKit's, see the bug comment.
This should be specially useful for sites with lots of custom
properties.
This is a high-confidence win on this speedometer subtest:
* 1.9x faster in style updates.
* 4.2x faster in layout object destruction (we no longer free the huge
custom properties map).
* Also speeds up paint and layout a bit, probably from less memory
churn.
Differential Revision: https://phabricator.services.mozilla.com/D198308
If the initial values of custom property registrations contain viewport
units, changing the viewport will result in recomputing the initial
values.
Differential Revision: https://phabricator.services.mozilla.com/D194668
There are two issues here:
* The first one is that we were serializing the specified url value,
which arguably should include the whole expanded URI, but for reasons
(mainly not copying urls around) doesn't. That means that
ToComputedValue::from_computed_value(cv).to_css() is not equivalent
to cv.to_css(). In order to fix that, teach the custom properties
code to serialize computed values as well. This saves an extra
conversion too.
* The second one is that we were using the property registration's url
data in order to resolve URIs against. That is not correct. Instead,
use the value's URL data (introduced in bug 1863620) to do this.
With those two bugs fixed, we can resolve registered custom property
urls correctly. Use generics to avoid repetitive code.
Differential Revision: https://phabricator.services.mozilla.com/D194387
This patch computes initial value when initial values are collected. The
initial value cannot be computed earlier (for example, at parse time)
without breaking intended behavior, since CSSOM expects the initial
value string of a CSSPropertyRule to remain uncomputed.
Although <length> and <length-percentage> can be accurately computed
already for initial values since valid initial values are always
font-indepent, this patch leaves <length> and <length-percentage>
uncomputed for simplicity (until bug 1856524 is implemented).
Differential Revision: https://phabricator.services.mozilla.com/D193839
This is needed to be able to use chrome environment variables in
chrome stylesheets and have them work in non-chrome documents.
This will be used to communicate the right transition duration in
scrollbars.css, but should also be useful to have the right base URI for
<url>-typed custom properties.
Differential Revision: https://phabricator.services.mozilla.com/D193048
This should cause no change in behavior, but only because because
Cascade::apply_prioritary_properties is not yet called after font-*
declarations have been processed and before registered custom properties
are computed (see bug 1856522).
Depends on D191614
Differential Revision: https://phabricator.services.mozilla.com/D191160
Now that the custom properties context includes the computed context,
some other fields have been made redundant and can be removed (see
D191161).
Depends on D191613
Differential Revision: https://phabricator.services.mozilla.com/D191159
The stylist is kept in order to avoid needing to unwrap it each time a
stylist is used.
Because a computed context is always required to make a custom
properties builder, cascade_custom_properties_with_context is renamed to
cascade_custom_properties (and the previous cascade_custom_properties,
which did not require a computed context, is removed).
Differential Revision: https://phabricator.services.mozilla.com/D191613
D190382 replaces ValueComponent with a specified types specialization of
a generic type. D190383 specializes the new GenericValueComponent for
computed types.
The goal here is to no longer use Self as the ToComputedValue computed
value of ValueComponent.
Differential Revision: https://phabricator.services.mozilla.com/D190382
We resolve calc expressions and use appropriate units by computing
ToComputedValue trait, computing each component's value, then converting
it back to that component's type, before making a new VariableValue from
the computed value's CSS string to store in the computed properties map.
Differential Revision: https://phabricator.services.mozilla.com/D190254