|author||Daniel Silverstone <firstname.lastname@example.org>||2020-05-25 12:23:42 +0100|
|committer||Daniel Silverstone <email@example.com>||2020-05-25 12:23:50 +0100|
devday: Nodelist plan
Signed-off-by: Daniel Silverstone <firstname.lastname@example.org>
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
@@ -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
+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.