This accurately reflects the spec it's implementing. This algorithm is
used in 5 spots in the spec but the old buggy behavior was never
triggered:
* In both ::extract() and ::clone_the_contents(), invocations to this
method are guarded by a check to see if the start node is the
inclusive ancestor of the end node, or vice versa - effectively
resulting in the inequality checks to be accidentally correct.
* In ::surround_contents(), we forego the usage of this algorithm as
stated in the spec, and instead use a correct and more optimized
version that simply compares the start and end nodes.
A lot of words to say: no functional changes :^)
Functions in AK/GenericShorthands used pass-by-value which results in
copying values when calling those functions. This could be expensive
for complex types. To optimize performance, we switch the functions to
use forwarding references.
Returning numbers instead of booleans for the statuses made Ruffle
(through the wgpu crate) think a shader/program failed to compile/link,
as it does a strict type comparison.
Previously the enforcement was only done on creation. Not enforcing it
on change would cause a crash if the canvas width/height was set to
zero or less.
Required by https://qwasm2.m-h.org.uk, which adds a custom `name`
attribute to objects it generates. It then gets some of these objects
out with getParameter, and expects the `name` attribute to be there.
Rather than partly-converting number, dimension, and ident tokens at the
start of parsing a calculation, and then later finishing it off, we can
just do the whole step in convert_to_calculation_node(). This is a
little less code, but mainly means we are left with only a single use
of the Dimension type in the codebase, so that can be removed soon.
Various places in the spec allow for `<number> | <percentage>`, but this
is either/or, and they are not allowed to be combined like dimensions
and percentages are. (For example, `calc(12 + 50%)` is never valid.)
User code generally doesn't need to care about this distinction, but it
does now need to check if a calculation resolves to a number, or to a
percentage, instead of a single call.
The existing parse_number_percentage[_value]() methods have been kept
for simplicity, but updated to check for number/percentage separately.
An upcoming change requires that we can determine which property we are
parsing before we parse the value. That's the opposite of what this
code previously did, which was to parse a generic dimension or calc()
and then figure out what property would accept it.
