Also, more directly go from StyleImageRendering to wr::ImageRendering.
* image-rendering: smooth the non-deprecated version of
OptimizeQuality, which maps to SamplingFilter::LINEAR /
wr::ImageRendering::Auto (which uses gl::LINEAR).
* image-rendering: pixelated maps to wr::ImageRendering::Pixelated /
SamplingFilter::POINT which is the same crisp-edges does.
Note that this uncovers that we were mapping image-rendering:
crisp-edges to wr::ImageRendering::Pixelated.
I'm going to preserve behavior on this patch but we should consider
switching that to map to wr::ImageRendering::CrispEdges on a
follow-up (filed bug 1728831 for this).
Differential Revision: https://phabricator.services.mozilla.com/D124378
This is an oversight. I made selecteditem be -moz-html-cellhighlight,
but that's for inactive cells.
Use the inactive cell color everywhere (though android doesn't
differentiate). This matches other browsers and what was reviewed on
this bug.
MANUAL PUSH: The semi-transparent text-selection-disabled color caused
one test failure CLOSED TREE.
break-before/after: page|column seem harder because you need to deal
with nested breaks, I think, but this should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D121206
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
Specifically:
For "bullets", i.e. 'list-style-type:disc|circle|square|
disclosure-closed|disclosure-open', we use a built-in font
(-moz-bullet-font, which has glyphs for those symbols + space) to
retain mostly backwards compatible rendering for those. Authors may
override that with an explicit 'font-family' ::marker style though.
We also use this font for 'list-style-image' in case it would
fallback to one of the above when the image fails to load (so that
we get the same width space).
When the -moz-bullet-font is used we also set 'font-synthesis' to
avoid synthesizing italic/bold for this font. Authors may override
this with an explicit ::marker declaration.
We also set 'letter-spacing' and 'word-spacing' to the initial value
for bullets for web-compat reasons. Again, authors may override
this with an explicit ::marker declaration. (This breaks backwards-
compat slightly but makes us compatible with Chrome. We used to
ignore these for list-style-type:<string> too.)
Differential Revision: https://phabricator.services.mozilla.com/D111693
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
Support fit-content for preferred size, min size, and max size. This
patch only implement the style system. For layout part, we will do that
in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D107161
Those can't be ordered at specified / computed value time, since the
percentage basis could be negative.
Needs tests of course, running through try atm.
Differential Revision: https://phabricator.services.mozilla.com/D115591
As per https://drafts.csswg.org/css-will-change/#will-change.
> If any non-initial value of a property would cause the element to
> generate a containing block for absolutely positioned elements,
> specifying that property in will-change must cause the element to
> generate a containing block for absolutely positioned elements.
But in this case the transform property wouldn't apply to the element so
there's no reason to create a stacking-context.
Differential Revision: https://phabricator.services.mozilla.com/D114121
We should just restore the state when seeing whitespace and an unknown
token like when we do when finding any other token a few lines below.
This is not an issue for most callers (it's only an issue for clamp())
because the other callers use either `parse_comma_separated()` (for
min/max), or `parse_nested_block()` (for parens / nested calc()).
Both of those functions restrict the input in such a way that
is_exhausted returns true (a few lines above) and thus we parse
successfully.
Differential Revision: https://phabricator.services.mozilla.com/D112681
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
