style: Use more CascadeData and less Stylist for XBL stuff.
Just some more use-cases that can be converted right away.
I'm trying to make XBL not use a whole Stylist, slowly...
<!-- 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/20026)
<!-- Reviewable:end -->
Added derive(ToCss) annotation : WIP
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
<!--
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable). -->
<!-- Either: -->
<!--
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
-->
<!-- 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/20019)
<!-- Reviewable:end -->
The reason why bug 1355721 regressed this is because in non-e10s we definitely
flush before parsing the standards quirks-mode. And bug 1355721 introduced an
unconditional UpdateStylistIfNeeded, unless the counter style / font
equivalents.
That means that the stylist wouldn't remain on its initial state after the first
flush, which itself means that when the compat mode changed, the UA and user
rules were already on the stylist with the quirks mode keys. That makes
class-names be keyed in ascii lowercase.
After that no user style changed, so no rebuild happens for the cascade data in
the user origin, so we keep looking at the wrong keys indefinitely.
We should try to avoid the flush there and ensure that by the time we create a
pres shell the quirks mode is already up-to-date...
Bug: 1394233
Reviewed-by: xidorn
MozReview-Commit-ID: 25dD2bca3tN
Now that PropertyDeclaration and AnimationValue have the same discriminants,
that means the trick found in PropertyDeclaration::id can be done in
AnimationValue::id.
By making AnimationValue have the same representation as PropertyDeclaration
and Void variants for non-animatable properties, we know by constructions
that all properties have the same discriminant in both.
style: Add infrastructure to have a standalone author stylesheet collection
Right now Gecko uses a whole `Stylist` for stuff like XBL / Shadow DOM.
That's not great, because it has tons of unrelated logic, and also eats up a lot of memory. Also, it prevents us to optimize style changes in shadow hosts the same way we do for the document.
These patches mostly rejigger stuff around so that you can define a `DocumentStylesheetSet` and then an `AuthorStylesheetSet`, which would contain just the Shadow DOM sheets / XBL resource sheets.
It still doesn't introduce any use for the later, but that will come later.
There's a patch in this PR that requires Gecko changes, posted in https://bugzilla.mozilla.org/show_bug.cgi?id=1436798.
<!-- 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/20004)
<!-- Reviewable:end -->
In particular, `rebuild` is now done entirely by CascadeData, which simplifies
more stuff.
The eventual final state for this is that the data structure we use to store the
XBL / Shadow DOM stuff will be something like:
struct AuthorStyles { CascadeData, AuthorSheetCollection }
MozReview-Commit-ID: 8TExtP58L4X
This will make it easier to handle it properly for Shadow DOM, though this patch
doesn't do that.
This also makes some method inline and infallible for convenience, since nobody
checks the errors anyway.
Bug: 1436798
Reviewed-by: bholley
MozReview-Commit-ID: Hq3erAUs5tf
Chances are we need to pass it around in a bit.
Also invert the boolean because I don't want to reason about double negations,
even if they're simple.
MozReview-Commit-ID: KhX4lDKwDoj