Since each selector can only have zero or one pseudo-element, we match
against it as a separate step, before matching the rest of the
selector. This should be faster, but mostly I did this because I could
not figure out how else to stop selectors without a pseudo-element from
matching the pseudo-element, eg so `.foo` styles don't affect
`.foo::before`.
This patch introduces the StyleComputer::RuleCache, which divides all of
our (author) CSS rules into buckets.
Currently, there are two buckets:
- Rules where a specific class must be present.
- All other rules.
This allows us to check a significantly smaller set of rules for each
element, since we can skip over any rule that requires a class attribute
not present on the element.
This takes the typical numer of rules tested per element on Discord from
~16000 to ~550. :^)
We can definitely improve the cache invalidation. It currently happens
too often due to media queries. And we also need to make sure we
invalidate when mutating style through CSSOM APIs.
Previously we would re-run the entire CSS selector machinery for each
property resolved. Instead of doing that, we now resolve a final set of
custom property key/value pairs at the start of the cascade.
- Replace "auto" with "auto const" where appropriate.
- Remove an unused struct.
- Make sort_matching_rules() a file-local static function.
- Remove some unnecessary includes.
CSS has rules about automatic blockification or inlinification of boxes
in certain circumstances.
This patch implements automatic blockification of absolutely positioned
and floating elements. This makes the smile appear on ACID2. :^)
We now detect situations like this, where variables infinitely recur,
without crashing:
```css
div {
--a: var(--b);
--b: var(--a);
background: var(--a);
}
p {
--foo: var(--foo);
background: var(--foo);
}
```
If a property is custom or contains a `var()` reference, it cannot be
parsed into a proper StyleValue immediately, so we store it as an
UnresolvedStyleValue until the property is compute. Then, at compute
time, we resolve them by expanding out any `var()` references, and
parsing the result.
The implementation here is very naive, and involves copying the
UnresolvedStyleValue's tree of StyleComponentValueRules while copying
the contents of any `var()`s it finds along the way. This is quite an
expensive operation to do every time that the style is computed.
Resolved style is a spec concept that refers to the weird mix of
computed style and used style reflected by getComputedStyle().
The purpose of this class is to produce the *computed* style for a given
element, so let's call it StyleComputer.
2021-09-24 15:12:15 +02:00
Renamed from Userland/Libraries/LibWeb/CSS/StyleResolver.h (Browse further)
