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.
We now ensure that `Node::is_character_data()` returns true for all
nodes of type character data.
Previously, calling `Node::length()` on `CDataSection` or
`ProcessingInstruction` nodes would return an incorrect value.
We were mistakenly executing the current node's script instead of the
document's pending parsing-blocking script.
This caused ~1000 WPT tests to time out, since we never ended up firing
a load event for XHTML pages that load multiple external scripts.
