This seems like more sensible behavior. We have another use of
only_generic(), but that affects font sizing and other browsers agree
with us there:
<div style="font-family: monospace">Should be 13px</div>
<div style="font-family: something, monospace">Should be 16px</div>
So not touching that one.
Differential Revision: https://phabricator.services.mozilla.com/D130732
This should mitigate the code size impact. Also make get_resolved_value
non-generic to avoid monomorphizing it multiple times.
Differential Revision: https://phabricator.services.mozilla.com/D130354
This removes the various assumptions that the animation code does.
Code size might be a concern, we can optimize if it is a problem,
but let's do the obvious thing for now.
Differential Revision: https://phabricator.services.mozilla.com/D130017
This patch adds the animation-timeline longhand property. For
shorthand, we will do that in the next patch.
This patch includes the aut-generated code in
devtools/shared/css/generated/properties-db.js, by `./mach devtools-css-db`.
Note:
1. we will use this property in Bug 1676791. For now, only make sure
we parse it and serialize it correctly.
2. The syntax of animation-timeline may be updated, based on the spec
issue: https://github.com/w3c/csswg-drafts/issues/6674.
However, it's not a big problem to update it later, so we still can
prototype this property based on the current version of spec.
Differential Revision: https://phabricator.services.mozilla.com/D126450
The specifics of how this is going to work are still getting spec'd /
discussed in https://github.com/w3c/csswg-drafts/issues/6576, but this
allows DevTools to work fine and the feature to be complete enough for
Nightly experimentation (with the other in-flight patches).
Otherwise devtools crashes when trying to inspect pages that use them.
Differential Revision: https://phabricator.services.mozilla.com/D124656
This works modulo the existing nested layer order bug. Will be covered
by WPT /css/css-cascade/layer-import.html once the feature is enabled (I
can probably enable it right away for those tests, but I'd rather fix
the obvious bugs first).
Differential Revision: https://phabricator.services.mozilla.com/D124538
This works modulo the existing nested layer order bug. Will be covered
by WPT /css/css-cascade/layer-import.html once the feature is enabled (I
can probably enable it right away for those tests, but I'd rather fix
the obvious bugs first).
Differential Revision: https://phabricator.services.mozilla.com/D124538
Same, I want to land this separately to see if it affects
micro-benchmarks. If so, we might want to pack the layer order
_somewhere_ (though in this case I'm not sure where, tbh).
With this, layer rules should have an effect on the page. There are
a few things missing before being able to enable them:
* Fix nested layer order in some cases (when parent layers are declared
out of order, see the previous commit mentioning this).
* Some kind of OM representation, perhaps.
* Tests of course, which are coming in bug 1728722 and bug 1727276.
But this should be enough to allow playing with them.
Depends on D124337
Differential Revision: https://phabricator.services.mozilla.com/D124338
I want to land this separately because we might want to get smarter with
the size of the Rule struct (maybe restricting layer order to a u8 per
scope and packing it with the source order, since 255 layers seem
plenty), but I'd rather do the obvious thing for now.
Depends on D124336
Differential Revision: https://phabricator.services.mozilla.com/D124337
This was being used when we had special code for gecko profiler in the servo
codebase but we just removed the last one. This is safe to remove now. The
"enabled" feature in the gecko-profiler crate is being controlled by
gkrust-shared directly now.
Differential Revision: https://phabricator.services.mozilla.com/D120796
Add initial support for the color-scheme CSS property, allowing pages to
choose between light and dark system colors per-element, and such.
Things that are left to do so that this can be enabled by default:
* Dark system colors on Windows / Android / Standins.
* Dark Canvas/CanvasText/Link visited colors (which right now are set
via PreferenceSheet).
* Dark form controls in nsNativeBasicTheme.
* Processing the color-scheme meta tag to fill-in
Document::mColorSchemeBits.
But this seems like enough progress to be landable on its own.
Differential Revision: https://phabricator.services.mozilla.com/D120843
Alias -apple-system to it, and put it behind a pref for now. This is
pretty boring (read: uncontroversial hopefully) code. The follow-up work
is modifying StaticPresData to look up the fonts using system APIs,
probably. Maybe a bit more work if on macOS they can't be named.
Differential Revision: https://phabricator.services.mozilla.com/D119984
This changes font-family storage to reuse the rust types, removing a
bunch of code while at it. This allows us to, for example, use a single
static font family for -moz-bullet and clone it, rather than creating a
lot of expensive copies.
Differential Revision: https://phabricator.services.mozilla.com/D118011
So we update d property in the style system as well. This makes sure we
have the correct computed style and the correct rendering result.
Differential Revision: https://phabricator.services.mozilla.com/D115570
This prevents incorrectly reusing cached results when the contents go
away and new contents are allocated with the same address.
Note that these keep alive transitively everything else under them, so
all other medialist keys don't need this.
By making this a proper hashmap it should also improve cache lookup
times if the cache grows too big.
Differential Revision: https://phabricator.services.mozilla.com/D115202
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
https://drafts.csswg.org/css-images-4/#image-set-notation has:
> [...] it also specifies the image’s natural resolution, overriding any other
> source of data that might supply a natural resolution.
Astounding that there was literally no WPT for this at all. I added three: one
for backgrounds, one for list-style-image, and one for `content`. Cursor is not
handled on this patch because that one requires a fair amount of extra work.
Differential Revision: https://phabricator.services.mozilla.com/D112474
No behavior change, just cleanup. Actually seem this technically _adds_ some code even
though it's a cleanup, but that's mostly because of the wrapping of the
derive list. The resulting code is simpler (more in-line with our usual
things, so I think it's an improvement).
Differential Revision: https://phabricator.services.mozilla.com/D111551
