whatwg
"determine the value of a named property" should not imply a new object each time
Some people seem to read https://html.spec.whatwg.org/multipage/forms.html#dom-form-nameditem as implying that a new nodelist should be returned each time when there are multiple matching elements. That's not the intent, I assume, and it might be worth clarifying the spec to make it clear.
All browsers I tested (Firefox, Chrome, Safari) return the same nodelist on multiple accesses.
Is this another map-of-weak references situation? Or will they cache the nodelist indefinitely?
Gecko caches indefinitely. I think Chrome does the same if I read https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/container_node.cc?l=1530-1535&rcl=9d179ecc8ad5e63a9dc77942810961a6a18705e9 and its callees correctly, but I could be wrong...
If the list changes such that it contains a single node, would you then no longer return the list? Would you return the same list again if it were to contain multiple nodes again? I guess this needs some tests.
If we continue returning the same list forever once we decide to return a list it'd be pretty straightforward to keep a map on the form element to make this explicit.
If the list changes such that it contains a single node, would you then no longer return the list?
That's a good question. In Gecko, it looks like yes: when the list becomes length-1 we forget the list and just point to the one element; if the length then becomes longer than 1 we create a new list. I don't know what other browsers do.
Tentatively marking as a good first issue.
This is for someone with some background in JavaScript and interested in writing web-platform-tests to explore various scenarios around form's namedItem() method to see what kind of caching browsers implement for returned lists.
Once that step is complete we'd modify the existing algorithm in the HTML Standard to add that caching (and invalidation, if any), using the map primitive from https://infra.spec.whatwg.org/.
