It turns out we were already generating all the necessary include
statements, and we can simply remove all this goofy code soup that
uses the C preprocessor to speculatively look for include files.
While conceptually is_supported_property_index is a cheap index lookup,
it is not currently cheap for an container such as HTMLAllCollection
that is operating on an uncached collection. Instead - just do the
lookup once. It also happens to look a little nicer to not blindly
dereference an optional.
This uses a faster hashtable lookup in the case of HTMLCollection.
Also port invoke_named_property_setter to FlyString to avoid a
FlyString->String->FlyString conversion that surfaces from this change.
This removes some ambiguity about what the return value should be if
the index is out of range.
Previously, we would sometimes return a JS null, and other times a JS
undefined.
It will also let us fold together the checks for whether an index is a
supported property index, followed by getting the value just afterwards.
This is `counter(name, style?)` or `counters(name, link, style?)`. The
difference being, `counter()` matches only the nearest level (eg, "1"),
and `counters()` combines all the levels in the tree (eg, "3.4.1").
These control the state of CSS counters.
Parsing code for `reversed(counter-name)` is implemented, but disabled
for now until we are able to resolve values for those.
The new method is Parser::parse_all_as_single_none_value(), which has a
few advantages:
1. There's no need for user code to manually create a StyleValue.
2. It consumes tokens so that doesn't have to be done manually.
3. Whitespace before or after the `none` is consumed correctly.
It does mean we create and then discard a `none` StyleValue in a couple
of places, namely parsing for `grid-*` properties. We may or may not
want to migrate those to returning the IdentifierStyleValue instead.
This seems to have been required when pseudo-elements were first
implemented, but has since become unused. It's also awkward because we
don't have access to the DOM Element and its CountersSet at this point.
So, let's remove it.
For reference, Chrome&Firefox both return the computed value for
`content: counter(foo)` as `counter(foo)`, not as the computed string.
So not computing it here seems like the intended behaviour.
This represents each element's set of CSS counters.
https://drafts.csswg.org/css-lists-3/#css-counters-set
Counters are resolved while building the tree. Most elements will not
have any counters to keep track of, so as an optimization, we don't
create a CountersSet object until the element actually needs one.
In order to properly support counters on pseudo-elements, the
CountersSet needs to go somewhere else. However, my experiments with
placing it on the Layout::Node kept hitting a wall. For now, this is
fairly simple at least.
We now follow the rules from the spec more closely, along with an
unspecified quirk for when the offsetParent is a non-positioned body
element. (Spec bug linked in a comment.)
This fixes a whole bunch of css-flexbox tests on WPT, which already had
correct layout, but the reported metrics from JS API were wrong.
