diff options
authorDaniel Silverstone <>2020-05-25 12:23:42 +0100
committerDaniel Silverstone <>2020-05-25 12:23:50 +0100
commit916ac380e9931dc85627c7a5b34b6af1c8e8aa86 (patch)
parentb45ce6f2e22276ad1fda840e686a57e0d29628d8 (diff)
devday: Nodelist plan
Signed-off-by: Daniel Silverstone <>
1 files changed, 34 insertions, 0 deletions
diff --git a/developer-weekend/may-2020.mdwn b/developer-weekend/may-2020.mdwn
index 589968c..5f40f1a 100644
--- a/developer-weekend/may-2020.mdwn
+++ b/developer-weekend/may-2020.mdwn
@@ -207,6 +207,40 @@ All of the requisite bindings will need to be written to support the form
behaviours since driving this through the DOM may necessitate JS interactions
with the forms (e.g. validation).
+## Unifying behaviour of `NodeList` and `HTMLCollection`
+In order to support Forms properly, a `RadioNodeList` which inherits from
+`NodeList` has to act as though it were a subview of an `HTMLFormControlsCollection`
+which inherits from `HTMLCollection`. Given that `NodeList` and `HTMLCollection`
+are independent heirarchies (they are both top level types) there is nominally
+no way for this to occur.
+1. Inside libdom, add the concept of a `_dom_live_node_view`
+2. That type's API has ref/unref, implements the tree walker which takes a visitor
+ function pointer. The treewalker always returns the number of nodes it visited
+ afterwards, to make counting easier.
+3. The node visitor API is: `visitor(context, node, index) -> decision`
+ where decision is one of `stop`, `traverse_siblings`, or `traverse_all`.
+4. Rework `NodeList` in terms of this new API, the `NodeList` visitor method
+ will be the current matching matching behaviour, plus the decision of whether
+ to iterate deeply or not. This will allow us to shake out the behaviours
+ of the tree walker etc.
+5. Rework `HTMLCollection` in terms of the new API. The visitor method
+ will, this time, need to match elements. For named item lookup, the
+ visitor will be able to stop iteration at that point since there's no point
+ continuing.
+6. a) Implement `HTMLFormControlsCollection` with its own `namedItem`
+ method which, for the purposes of libdom, can return either an element or
+ a radioitemlist - the client will have to deal with this.
+ b) Implement `RadioItemList` so that it can be returned by (a).
+ Note: These two will essentially have to share some logic in order to work
+ compatibly. Since (a) is sharing logic with `HTMLCollection` that ought
+ to be moderately easy/safe to do.