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
The reason why this doesn't work is because these styles come from
datetimebox.css, which is really an author style.
We could special-case these elements, but the approach that the CSSWG resolved
on for the new forced-colors spec is to respect system colors specified by
authors, see:
https://drafts.csswg.org/css-color-adjust-1/#forced-colors-properties
So this moves us towards that, and fixes the issue nicely.
Differential Revision: https://phabricator.services.mozilla.com/D108321
This is straight-forward and builds on the color animation code. This
implements only the <percentage> syntax, not the whole <color-adjuster>
syntax, which seems fairly more complex.
Of course, this only uses sRGB because that's all the colors we support,
but it should be feasible to extend to lab() / lch() colors once we
support those.
I believe this subset of syntax is useful and worth implementing, so
people can play with it and say if it's useful.
Differential Revision: https://phabricator.services.mozilla.com/D106698
This reduces the amount of assembly instructions generated by this
function from 18k+ to ~800.
This should make reasoning about its stack space usage sane, and should
fix the ASAN stack overflows, but also we should take this regardless,
because it's saner and makes reading it simpler.
I also think that the writing_mode shenanigans is fixing a bug (I think
before this, we'd pick the first physical value which mapped to any of
the properties, which is wrong), but I haven't bothered looking for a
test-case that fails before my patch. The relevant WPTs
(css/css-logical/animation*) still pass.
Differential Revision: https://phabricator.services.mozilla.com/D105342
This brings the time down to 1.6ms from 4.8ms on the test-case in the
bug. This should be improvable too, but I think this is a nice
improvement for regular styling as well.
Differential Revision: https://phabricator.services.mozilla.com/D105187
But discard it when backplating behind text, so that text is readable.
This should be uncontroversial... Dealing with widgets is a bit harder
so TBD.
Differential Revision: https://phabricator.services.mozilla.com/D91779
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
The current API was pretty awkward as a result of two things:
* Not being able to create empty iterators for smallbitvec.
* We used to call the `F` function multiple times, but turns out that
collecting the declarations in a SmallVec was a perf win.
So clean this up so that it looks more similar to other APIs, taking an
iterator directly.
This is a bit more code, but hopefully easier to understand (and also hopefully
easier to optimize).
The motivation for this work is that I plan to investigate rebasing / landing
https://github.com/servo/servo/pull/20151, and I don't want more instantiations
of apply_declarations and such.
Differential Revision: https://phabricator.services.mozilla.com/D74369
That way elements inside links, form controls, etc have the right
contrast, even if the page overrides the color.
We can't do it when inheriting from transparent because we've already
forgotten about the "right" color to inherit, so the default color makes
sense. But that is a pretty unlikely edge case.
Differential Revision: https://phabricator.services.mozilla.com/D73069
This patch computes the author-specified properties during the CSS cascade, and
removes the complex rule-tree-based implementation that tries to do the cascade
again.
This changes behavior in two ways, one of them which is not observable to
content, I believe:
* revert now re-enables the native styling. This was brought up in
https://github.com/w3c/csswg-drafts/issues/4777 and I think it is a bug-fix.
This is observable to content, and I'm adding a test for it.
* We don't look at inherited styles from our ancestors when `inherit` is
specified in a non-author stylesheet. This was introduced for bug 452969 but
we don't seem to inherit background anymore for file controls or such. It
seems back then file controls used to have a text-field.
I audited forms.css and ua.css and we don't explicitly inherit
padding / border / background-color into any nested form control.
We keep the distinction between border/background and padding, because the later
has some callers. I think we should try to align with Chromium in the long run
and remove the padding bit.
We need to give an appearance to the range-thumb and such so that we can assert
that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new
internal value for that.
Differential Revision: https://phabricator.services.mozilla.com/D67722
We're resetting `color` to the default color when there's a declaration that
applies in order to make stuff like this:
<div style="color: transparent">
<div style="color: red">
Red
</div>
</div>
To not show transparent. But the behavior we want is more like "override with
default color iff there's no other declaration that would set the color from an
user or UA sheet".
This implements that behavior, plus avoids it if we're not inheriting
from transparent, so that stuff like this preserves the behavior from before bug
844349:
<a href="foo">
<span style="color: red">Should be the red color</span>
</a>
Differential Revision: https://phabricator.services.mozilla.com/D60391
Font code is the only thing that was using Au in the style system without
interfacing with Gecko, and there was no real reason for it to do so.
This slightly simplifies the code.
Differential Revision: https://phabricator.services.mozilla.com/D57248
The micro-benchmark `style-attr-1.html` regressed slightly with my patch, after
the CascadeLevel size increase.
This benchmark is meant to test for the "changing the style attribute doesn't
cause selector-matching" optimization (which, mind you, keeps working).
But in the process it creates 10k rules which form a perfect path in the rule
tree and that we put into a SmallVec during the cascade, and the benchmark
spends most of the time pushing to that SmallVec and iterating the declarations
(as there's only one property to apply).
So we could argue that the regression is minor and is not what the benchark is
supposed to be testing, but given I did the digging... :)
My patch made CascadeLevel bigger, which means that we create a somewhat bigger
vector in this case. Thankfully it also removed the dependency in the
CascadeLevel, so we can stop using that and use just Origin which is one byte to
revert the perf regression.
Differential Revision: https://phabricator.services.mozilla.com/D53181
It's much nicer.
One nice thing about this is that the new code is subject to the existing
threadedness checking, which identified that several of these should be atomic
because they're accessed off the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D40792
And remove some of the ::placeholder and ::cue hacks where we need to use
!important to make the property not apply for content but apply on UA sheets.
The comment about the white-space property was wrong, we don't enforce it with
!important in the UA stylesheets for <input> (we do for <textarea> though), so
I've kept the flag since it really applies.
Differential Revision: https://phabricator.services.mozilla.com/D37717
This doesn't change the way C++ code uses static prefs. But it does slightly
change how Rust code uses static prefs, specifically the name generated by
bindgen is slightly different.
The commit also improves some comments.
Differential Revision: https://phabricator.services.mozilla.com/D35764
Remove unused code (3/N)
<!-- Please describe your changes on the following line: -->
Third PR in a series of PRs to remove unused/dead code from servo, powered by an (upcoming) tool of mine. Please take a look and tell me if you want to keep something.
* First PR: #23477
* Second PR: #23498
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they only remove dead code
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23499)
<!-- Reviewable:end -->
This avoids the expensive conversion, and cleans up a bunch.
Further cleanup is possible, just not done yet to avoid growing the patch even
more.
Differential Revision: https://phabricator.services.mozilla.com/D30748
To be more similar between Rust and C++. This introduces GenericFontFamily and
exposes that plus FontFamilyNameSyntax to C++, using that where appropriate
instead of plain uint8_t as we were doing.
As a follow-up, as discussed on IRC with Jonathan, we can remove the -moz-fixed
family, and turn it just into an alias of Monospace.
The only non-trivial change is the MatchType changes, but they're ok I think.
The code already assumed at most one CSS generic, and the struct still takes 8
bits. I've verified that the relevant tests are passing (though try is closed).
Differential Revision: https://phabricator.services.mozilla.com/D24272
It's not very easy to understand on its current state, and it causes subtle bugs
like bug 1533654.
It could be simpler if we centralized where the interactions between properties
are handled. This patch does this.
This patch also changes how MathML script sizes are tracked when scriptlevel
changes and they have relative fonts in between.
With this patch, any explicitly specified font-size is treated the same (being a
scriptlevel boundary), regardless of whether it's either an absolute size, a
relative size, or a wide keyword.
Relative lengths always resolve relative to the constrained size, which allows
us to avoid the double font-size computation, and not give up on sanity with
keyword font-sizes.
I think given no other browser supports scriptlevel it seems like the right
trade-off.
Differential Revision: https://phabricator.services.mozilla.com/D23070
This is the low-risk fix for this issue, that we should get into 67.
What's going on here is that font-family is tracked via the font list, from the
POV of the style system the font list is generally just the
RefPtr<SharedFontList>, but in Gecko there's also mDefaultGenericId.
The way we end up with the right mDefaultGenericId is fishy at best, bogus at
worst. I left various fixmes over time related to a bunch of this code.
After my patch, we end up with a mDefaultGenericId of serif, rather than the
right one (none).
The parent font always has none because nsLayoutUtils::ComputeSystemFont always
sets it to none if the font is known.
Before my patch, PrefillDefaultForGeneric with aGenericId of none (from the
parent), which makes it the default generic id for the current language, serif
in this case.
Before my optimization, apply_declaration_ignoring_phase called
copy_font_family_from, which resets both the font list _and_ the default
generic.
This patch achieves the same effect by not having the first mutation in the
first place.
This code is still terribly fishy in any case, all the _skip_font_family stuff
is just ridiculous. I'll try to clean up a bit after this, but for 68.
Differential Revision: https://phabricator.services.mozilla.com/D23026
The way the copy-on-write stuff works, and the way that we have to apply
properties from most specific to less specific guarantees that always that we're
going to inherit an inherited property, or reset a reset property, we have
already the right value on the style.
Revert relies on that, so there doesn't seem to be a reason to not use that fact
more often and skip useless work earlier.
Font-size is still special of course... I think I have a way to move the
specialness outside of the style, but piece by piece.
Differential Revision: https://phabricator.services.mozilla.com/D21882
The only fishy bit is the animation stuff. In particular, there are two places
where we just mint the revert behavior:
* When serializing web-animations keyframes (the custom properties stuff in
declaration_block.rs). That codepath is already not sound and I wanted to
get rid of it in bug 1501530, but what do I know.
* When getting an animation value from a property declaration. At that point
we no longer have the CSS rules that apply to the element to compute the
right revert value handy. It'd also use the wrong style anyway, I think,
given the way StyleBuilder::for_animation works.
We _could_ probably get them out of somewhere, but it seems like a whole lot
of code reinventing the wheel which is probably not useful, and that Blink
and WebKit just cannot implement either since they don't have a rule tree,
so it just doesn't seem worth the churn.
The custom properties code looks a bit different in order to minimize hash
lookups in the common case. FWIW, `revert` for custom properties doesn't seem
very useful either, but oh well.
Differential Revision: https://phabricator.services.mozilla.com/D21877
This is more consistent with what the Rust bits of the style system do, and
removes a pointer from ComputedStyle which is always nice.
This also aligns the Rust bits with the C++ bits re. not treating xul pseudos as
anonymous boxes. See the comment in nsTreeStyleCache.cpp regarding those.
Can't wait for XUL trees to die.
Differential Revision: https://phabricator.services.mozilla.com/D19002
