This change causes explicitly-specified role attributes to be ignored in
the case where the specified role is “orphaned” — that is, when its
element lacks a required ancestor with an appropriate role.
Per https://w3c.github.io/aria/#document-handling_author-errors_roles,
determining whether to ignore certain specified landmark roles requires
first determining whether the element for which the role is specified
has an accessible name.
But if we then try to retrieve a role for such elements, we end up
calling right back into the accessible-name computation code — which
would cause the calls to loop infinitely.
So to avoid that — and to have handling for any other future cases the
spec may introduce of such recursive calls that will loop indefinitely —
this change introduces a parameter that callers can pass to cause
role-attribute lookup to be skipped during accessible-name computation.
This change adds a virtual to_element function to ARIAMixin, and
overrides it in DOM::Element so it can then be used back inside
ARIAMixin to get an element when needed (for example, when computing a
role requires checking the roles of ancestors of an element).
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 :^)
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.
When we know what kind of dimension we want, it's awkward to attempt to
parse any dimension type, including quirks that only affect lengths, to
then throw it away unless it's the type we wanted in the first place.
Additionally, move the unitless angle/length behavior for SVG attributes
into these methods, where it belongs.
Instead, only try to parse the type of dimension we want. This is
currently more code, but some could be factored together later.
