.fallback is always the default font for the lang group unless we're a
system font (in which case it's "none").
The only reason we need that is because we need to react to
language changes (which affect the initial font).
Simplify the model a bit doing the language lookup in gfxTextRun (this
should avoid allocating a few nsStyleFont structs too.
Depends on D130732
Differential Revision: https://phabricator.services.mozilla.com/D131312
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
Apparently using transparent borders and outlines is a common
accessibility technique to make those visible in HCM.
Bug 1740924 comment 9 seemed to indicate we were the only browser
rendering those browsers, but I just confirmed that Edge at least does
show them.
Keep respecting system colors as that's per spec.
Differential Revision: https://phabricator.services.mozilla.com/D131412
This causes (among other things) pages to be dark when using regular
windows system colors and forcing colors to "always", which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D131165
There's only one meaningful usage of it, which is to disable native
appearance of the <input type=range> (the windows native theme is no
longer exposed to content).
<input type=range> is inconsistent with every other native widget, which
only disables native appearance if the author specifies backgrounds or
borders. So make it match literally all other widgets and simplify a bit
the code.
We had no tests for this special behavior, let me know if you think it's
worth adding one (but I don't feel very strongly about it).
Differential Revision: https://phabricator.services.mozilla.com/D127082
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
