annevk
commented
3 months ago I think we already have the problem of strong references due to FrozenArray holding strong references. In https://github.com/whatwg/html/issues/8545 @smaug---- felt most strongly about fixing this, but since then Gecko might also have shipped this "leak" or is about to?
As for the overall ask: I suspect WebKit would be okay with aligning here, but not necessarily willing to lead the charge.
cc @rniwa
What is the issue with the HTML Standard?
Given discussions like https://github.com/whatwg/html/issues/10219 and the general problems with mutable
FrozenArray<>attributes (see https://github.com/whatwg/webidl/issues/810), I was considering whether we could upgrade toObservableArray<>. It has some advantages:It automatically ensures that
element.ariaFlowToElements === element.ariaFlowToElements. And actually, that equality stays true forever; the array object identity never changes, even if the values inside do.It allows authors to do convenient code like
element.ariaFlowToElements.push(foo).The spec might be simpler (not sure), because the getter and setter are generated automatically, and the backing list is always available. The hard part is writing the spec to keep the backing list updated.
I think this would look something like the following:
Fix https://github.com/whatwg/html/issues/10219. Let's say this creates a new hook, "null out".
For each element,
ariaFlowTohas a boolean, "in explicitly-set mode", initially false.The spec monitors the DOM for any changes to
id=""s which could cause the "gathered from the DOM" set of elements to change. If "in explicitly-set mode" is false, then the spec updates the backing list with the new set of elements.The spec monitors the DOM for any changes to
aria-flowto="". Those reset the backing list with the gathered-from-the-DOM set of elements, and sets "in explicitly-set mode" to false.The "set an indexed value" and "delete an indexed value" hooks:
The "null out" hook:
Possible issue: in this version, the backing list holds strong references to the elements. I'm not sure exactly what problems that creates.
Possible issue: at least in the spec, we need to monitor for changes to
id=""s, instead of computing lazily. Assuming implementations have a per-spec implementation ofFrozenArray<>, this is probably an extra cost. Optimization is definitely possible in a variety of ways, but it's more code to write.I'm not sure there's any implementer appetite for continuing to churn in this space. But I thought I'd mention it and write down the above sketch. /cc @annevk @alice @petervanderbeken.